Assessment Results を仕上げる
観察・所見・リスクを、内部監査結果の文書にまとめてみましょう。評価 1 回分の results と、監査計画への参照をそろえて完成させます。
このセクションを終えるとできること
- import-ap で、評価結果と評価計画を接続できる。
- 評価 1 回分を表す results の必須項目を書ける。
- 観察、所見、リスクを 1 つの結果の中に配置して、文書を完成できる。
前のセクションで書いた観察、所見、リスクを、1 つの文書にまとめます。文書の名前は「ミナト精機 受発注システム 内部監査結果（2026 年度）」、ファイル名は mk-audit-results.yaml です。
評価 1 回分を表す results
Assessment Results の必須ブロックは、uuid、metadata、import-ap、results の 4 つです。
import-ap は、どの評価計画に基づく結果かの宣言です。Assessment Plan が import-ssp で SSP を指したように、結果は計画を指します。
results は、評価 1 回分のまとまりのリストです。1 つの文書に results を複数持てる設計になっていて、たとえば毎月の点検結果を同じ文書に足していく使い方ができます。年 1 回の内部監査なら、1 年分の監査が 1 件の result です。result の必須項目は 5 つあります。
| 項目 | 役割 |
|---|---|
uuid / title / description | この評価 1 回分の識別番号と要約 |
start（と任意の end） | 評価の実施期間 |
reviewed-controls | 実際に確かめた管理策の範囲 |
reviewed-controls が計画とは別に、結果の側にもう一度あることに注目してください。計画した範囲と、実際に確かめられた範囲は、ずれることがあります。監査の途中で対象を広げた、時間が足りず一部を翌年に回した。結果の reviewed-controls は「実際に見た範囲」を記録するので、計画とのずれも文書に残ります。今回の監査は計画どおり 4 件を確かめました。
この文書に import-ap と、results の 1 件目（reviewed-controls の手前まで）を書き足してください。
3 層を結果の中に配置する
観察、所見、リスクは、result の中の observations、findings、risks というリストに入ります。前のセクションで書いた分をすべて配置した、文書全体の形はこうなります。
assessment-results:
uuid: e807d1a5-bfe6-40b1-8f7f-4e37df726281
metadata:
# …略…
import-ap:
href: mk-audit-plan.yaml
results:
- uuid: 46a7cf44-dd03-4287-b6dc-0e3b3a7cad45
title: 2026 年度 受発注システム内部監査の結果
description: 内部監査計画（2026 年度）に基づき、4 件の管理策について記録の確認と現地確認を行った結果。
start: "2026-09-07T09:00:00+09:00"
end: "2026-09-11T17:00:00+09:00"
reviewed-controls:
control-selections:
- include-controls:
- control-id: mk-ac-01
- control-id: mk-ac-02
- control-id: mk-ph-01
- control-id: mk-bk-01
observations:
- uuid: 16cd11ef-57b4-4cd5-a5ea-ab4d4ff76133
title: バックアップと復元試験の記録の確認
# …略…
- uuid: 4d854202-9c2c-424f-aba8-97279063f8a0
title: アカウント棚卸しの記録の確認
# …略…
risks:
- uuid: b583b652-a361-4975-a733-1b96f1857896
title: 不要になったアカウントの残存
# …略…
findings:
- uuid: 0dd1c239-665d-40ef-9cb1-8b760f2666bd
title: 業務データのバックアップは実施されている
target:
type: statement-id
target-id: mk-bk-01_statement
status:
state: satisfied
related-observations:
- observation-uuid: 16cd11ef-57b4-4cd5-a5ea-ab4d4ff76133
- uuid: 0c150e19-2201-4cf9-b2d6-6fae55b0e402
title: 不要になったアカウントの削除が期限を超えていた
target:
type: statement-id
target-id: mk-ac-02_statement
status:
state: not-satisfied
related-observations:
- observation-uuid: 4d854202-9c2c-424f-aba8-97279063f8a0これが「ミナト精機 受発注システム 内部監査結果（2026 年度）」の版 1.0.0 の骨格です。あとに残るのは、not-satisfied の所見から risk への参照です。
findings のうち、related-risks を付けるべき方にだけ書き足してください。どちらに付けるかは、各 finding の state を見て自分で判断します。
これで「ミナト精機 受発注システム 内部監査結果（2026 年度）」の版 1.0.0、OSCAL の検証を通る完全な文書になります。満たしている mk-bk-01 の所見は satisfied で根拠の観察を参照するだけ、満たしていない mk-ac-02 の所見は not-satisfied に加えて related-risks でリスクを参照します。監査で確かめた 4 件のうち、mk-ac-01 と mk-ph-01 の所見をこの文書に足すなら、同じ形で findings に並べていくことになります。
IFA の評価結果と見比べる
NIST のサンプルにも、対応する評価結果があります（ifa_assessment-results.yaml）。構造は今書いたものと同じで、import-ap、results が 1 件、その中に observations、risks、findings が並びます。
1 つ、見比べる価値のある違いがあります。IFA の結果の title は「IFA SYSTEM1234 Continuous Monitoring Results June 2023」、つまり 2023 年 6 月分の継続的な点検の結果です。年 1 回の監査ではなく、毎月の自動チェックの 1 回分が 1 つの result として記録されています。同じ Assessment Results というモデルが、年次の内部監査にも、月次の機械的な点検にも、同じ構造で使えるということです。評価の頻度や手段が変わっても、事実と判定とリスクの 3 層、そして計画への参照という骨組みは変わりません。
理解の確認
reviewed-controls は Assessment Plan にもあり、result の中にもあります。結果の側にもう一度書く理由はどれですか。
この監査結果の finding から、指摘の根拠になった事実を確かめたい読み手は、どうたどればよいですか。
次へ
監査の結果が文書になりました。監査報告書なら、ここで仕事はいったん終わりです。しかし指摘された側の仕事はここから始まります。見つかった問題をいつまでに誰がどう直すのか。それを追いかける最後のモデルが POA&M（是正計画）です。次のセクションで、指摘事項管理台帳の 1 行を POA&M に書き、8 つのモデルの一周を閉じます。
このセクションは OSCAL 1.2.2 系の仕様に基づいて執筆しています。