Assessment Results を書く
監査結果を書くモデルが Assessment Results です。指摘 1 件を、観察・所見・リスクの 3 つに分けて書いてみましょう。
このセクションを終えるとできること
- 監査の結果を observation、finding、risk の 3 層に分解できる。
- observation に、確かめた事実を記録できる。
- finding で、satisfied か not-satisfied かを自分で判定して書ける。
2026 年 9 月 7 日から 11 日、前のセクションの計画に沿って、受発注システムの内部監査が実施されたとします。記録を確認し、聞き取りをした結果、次のことが分かりました。
- バックアップは毎日作成されており、復元試験の記録も揃っていた。
- アカウントの棚卸しは半期ごとに実施されていた。ただし、2026 年 4 月の棚卸しで不要と判定されたアカウント 3 件のうち 1 件が、判定から 22 営業日後まで削除されずに残っていた。社内基準 mk-ac-02 の期限は 5 営業日以内なので、超過している。聞き取りによれば、削除作業の担当者が決まっていなかった。
この結果を記録するモデルが Assessment Results（アセスメントリザルツ、評価結果）です。監査報告書にあたります。
Word の監査報告書なら、2 点目は「指摘事項」の 1 件として、事実と判定と影響をひとつの文章にまとめて書くところです。Assessment Results はこれを 3 つの単位に分解します。観察した事実の observation、基準に照らした判定の finding、残る危険の記述の risk です。この章はこの 3 層だけに絞り、文書全体の外枠は次のセクションで組みます。
観察した事実：observation
observation は、「いつ、どうやって確かめて、何を見たか」の記録です。判定や評価を含めない、事実だけの層です。必須項目は 4 つあります。
| 項目 | 役割 |
|---|---|
uuid | この観察 1 件の識別番号 |
description | 何をどう確かめたか |
methods | 確かめたやり方（EXAMINE / INTERVIEW / TEST） |
collected | 確かめた日時 |
見たことの中身は remarks に書きます。バックアップの確認を observation にすると、こうなります。
observations:
- uuid: 16cd11ef-57b4-4cd5-a5ea-ab4d4ff76133
title: バックアップと復元試験の記録の確認
description: 直近 1 か月のバックアップの記録と、2026 年 6 月に実施した復元試験の記録を確認した。
methods:
- EXAMINE
collected: "2026-09-08T14:00:00+09:00"
remarks: 毎日のバックアップが記録されており、欠落はなかった。復元試験の記録には、実施日と結果、確認者の記名があった。「問題なし」の確認も observation として残る点に注目してください。監査報告書では「特記事項なし」の 1 行に消えがちな確認作業が、何をいつ確かめたかの記録として残ります。
アカウント棚卸しの observation を完成させてください。確かめたのは 2026-09-08 の 16 時。methods は、記録の確認と聞き取りの両方を行ったことから自分で選びます。remarks には「2026 年 4 月の棚卸しで不要と判定されたアカウント 3 件のうち 1 件が、判定から 22 営業日後まで削除されずに残っていた。聞き取りでは、削除作業の担当者が決まっていなかったことが原因とされた。」と書きます。
基準に照らした判定：finding
finding（所見）は、観察した事実を基準に照らして「満たしている／いない」を判定する層です。1 件の構造は次のとおりです。
| 項目 | 役割 |
|---|---|
uuid / title / description | 識別番号と、所見の要約 |
target | 何に対する判定か（管理策の本文への参照と、判定の結果） |
related-observations | 根拠になった observation への参照 |
中心は target です。type: statement-id は「管理策の本文（statement）に対する判定です」という宣言で、target-id に本文の id を書きます。ミナト精機の社内基準カタログでは、本文の id は mk-ac-02_statement のような形でした。判定の結果は status の state に、満たしている satisfied か、満たしていない not-satisfied のどちらかで書きます。
バックアップの所見はこうなります。
findings:
- uuid: 0dd1c239-665d-40ef-9cb1-8b760f2666bd
title: 業務データのバックアップは実施されている
description: バックアップの作成と復元試験は、SSP の記述のとおり実施されている。
target:
type: statement-id
target-id: mk-bk-01_statement
status:
state: satisfied
related-observations:
- observation-uuid: 16cd11ef-57b4-4cd5-a5ea-ab4d4ff76133次はアカウント棚卸しの所見です。判定を自分で下してください。事実はこうでした。棚卸し自体は半期ごとに実施されている。しかし、不要と判定したアカウント 1 件の削除が 5 営業日以内に行われていなかった。mk-ac-02 の本文は「情報システムの利用者アカウントを半期に 1 度棚卸しし、不要になったアカウントは 5 営業日以内に削除する」です。
この finding の status と related-observations を書き足してください。state の値は、mk-ac-02 の本文と観察された事実を突き合わせて自分で判定します。根拠の observation は、この章で書いた棚卸しの観察（uuid: 4d854202-9c2c-424f-aba8-97279063f8a0）です。
残る危険：risk
finding が「基準を満たしていない」という判定なら、risk は「その結果、何が起きうるか」の記述です。必須項目は、uuid、title、description（リスクの説明）、statement（起きうることの記述）、status（リスクへの対応の状態）の 5 つです。
risks:
- uuid: b583b652-a361-4975-a733-1b96f1857896
title: 不要になったアカウントの残存
description: 退職や異動で不要になったアカウントが、削除されないまま残ることがある。
statement: 不要なアカウントが残っている間は、本人以外がそのアカウントを使っても気付きにくく、受発注データへの不正なアクセスの経路になりうる。
status: openstatus: open は「リスクが確認され、まだ対応が済んでいない」状態です。対応が進むと investigating（調査中）、remediating（是正中）、closed（解消済み）などに変わっていきます。この status は、第 4 部の最後のモデル POA&M 側で引き継いで進めていきます。
finding からは related-risks で risk を参照できます。これで 3 層がつながりました。事実（observation）を根拠に判定（finding）があり、判定から危険（risk）への参照が伸びる、という構造です。
理解の確認
observation の remarks に「不適合であった」と書くのは、この 3 層の設計に照らすと適切ではありません。なぜですか。
バックアップの確認は問題なしでしたが、observation と finding（satisfied）の両方が書かれています。この記録の価値として最も適切なものはどれですか。
次へ
指摘 1 件を 3 層に分解できました。次のセクションでは、この 3 層を Assessment Results の文書としてまとめます。評価 1 回分を表す results の外枠、監査計画への参照、そして文書全体の完成です。
このセクションは OSCAL 1.2.2 系の仕様に基づいて執筆しています。