Mapping Collection を仕上げる
map を束ねて、1 冊の対応表に仕上げてみましょう。作った経緯（provenance）と、「対応しない」判断（no-relationship）の残し方も練習します。
このセクションを終えるとできること
- mapping-collection の構造（mappings、source-resource、target-resource）を書ける。
- provenance の各項目（method、matching-rationale、status）の値を、作り方に応じて選べる。
- 対応しないという判断を、no-relationship と remarks で記録できる。
前のセクションで、1 つの対応（map）が書けるようになりました。この章では map を束ねて、「ミナト精機の社内基準と CSF 2.0 の対応表」を 1 冊のファイルに仕上げます。
対応表 1 冊の構造：mapping-collection と mappings
全体の構造から見ます。外枠は 3 たび同じ形で、包む名前が mapping-collection: になります。
mapping-collection:
uuid: 9d2b4f6c-8a1e-4b3d-b7c9-5e1a3d7f9b2d
metadata:
title: ミナト精機 社内基準と NIST CSF 2.0 の対応表
last-modified: "2026-07-20T09:00:00+09:00"
version: "1.0.0"
oscal-version: "1.2.2"
provenance:
# …略（この後の節で扱います）…
mappings:
- uuid: 7a4c9e2b-3d6f-4f1a-8c5e-9b2d4f6a8c1e
source-resource:
type: catalog
href: mk-standards-catalog.yaml
target-resource:
type: catalog
href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/CSF/v2.0/yaml/NIST_CSF_v2.0_catalog.yaml
maps:
# …ここに前のセクションで書いた map が並ぶ…mappings の 1 件が mapping、「どの文書からどの文書への対応か」というまとまりです。個々の map が管理策同士をつないでいたのに対し、mapping はその外側で文書同士をつなぎます。
| 項目 | 役割 | この対応表での値 |
|---|---|---|
source-resource | 対応元の文書 | 社内基準カタログ |
target-resource | 対応先の文書 | CSF 2.0 の公式 Catalog |
maps | 対応の一覧 | 前のセクションで書いた map たち |
source-resource と target-resource は、type と href の組です。type に入るのは catalog か profile。対応づけの相手は Catalog とは限らず、Profile（選択の結果）との対応も書けるので、どちらの種類かを明示します。href は参照先の場所で、社内基準カタログは同じ置き場のファイル名、CSF 2.0 は NIST の公開場所をそのまま指しています。
map の sources と targets に書いた mk-bk-01 や PR.DS-11 という id-ref は、この source-resource と target-resource が指す文書の中で探される、という関係です。
誰がどう作った対応か：provenance
外枠の直後にあった provenance（由来）は、この対応表を誰がどうやって作ったかの記録です。
対応表は判断の塊です。同じ 2 つの文書を渡しても、人が読み比べて作った対応と、機械が言葉の一致だけで作った対応では、信頼度が違います。だから Mapping Collection では、由来の記録が必須項目になっています。uuid と metadata 以外で必須の外枠を持つのは、ここまでの 3 モデルで Mapping Collection だけです。
| 項目 | 意味 | 選べる値 |
|---|---|---|
method | 誰が対応づけたか | human（人手）、automation（機械）、hybrid（併用） |
matching-rationale | 何を根拠に対応づけたか | syntactic（文言）、semantic（意味）、functional（機能） |
status | 対応表の状態 | draft、complete、not-complete、deprecated、superseded |
mapping-description | 作り方の説明文 | 自由記述 |
matching-rationale の 3 語は、対応づけの根拠の深さを表します。syntactic は文言の一致（同じ言葉や単語が使われている）、semantic は意味の一致（読み比べて同じ意味だと判断した）、functional は機能の一致（実際に満たされる効果が同じ）です。前のセクションでやった本文の読み比べは semantic にあたります。
status の主なものは、作成中の draft、対応づけを終えた complete、一部だけ対応づけて公開する not-complete です（ちなみに、deprecated は廃止済み、superseded は新版に置き換え済み）。
ミナト精機の対応表の provenance は、こう書けます。
provenance:
method: human
matching-rationale: semantic
status: complete
mapping-description: 情報システム部の情報セキュリティ担当が、社内基準と CSF 2.0 の本文を読み比べて作成した。対応しないという記録：no-relationship
対応表を埋めていくと、必ず「対応先が見つからない条文」に出会います。社内基準では mk-ph-02（機密書類の施錠保管）がそれです。いちばん近そうな CSF 2.0 の候補を挙げるなら、この管理策でしょう。
| id | 属するカテゴリー | 本文 |
|---|---|---|
| PR.DS-01 | データセキュリティ（PR.DS） | 保存中のデータの機密性、完全性、可用性が保護されている |
読み比べます。PR.DS-01 が守る対象は「データ」、つまり情報システムに保存されている電子的な情報です。mk-ph-02 が守るのは紙の書類で、サイバーセキュリティの規格である CSF 2.0 の守備範囲から外れています。近そうに見えて、対応しない。
この「検討したが、対応しない」も、判断の成果です。Excel の対応表で空欄のままにすると、後から見た人には「まだ調べていない」のか「調べた結果対応がない」のか区別が付かず、同じ検討をやり直すことになります。OSCAL では、relationship の 6 語の最後の 1 つ、no-relationship を使って、この判断を map として残せます。
あわせて、判断の理由を残す場所として remarks を使います。自由記述の備考で、map に限らず OSCAL の多くの要素に置けます。Excel 対応表の備考欄と同じ役割です。
mk-ph-02 と PR.DS-01 を読み比べた上の判断を、map として記録してください。relationship は「no-relationship」とし、remarks に「PR.DS-01 が守る対象はデータであり、紙の書類の施錠保管は対応しないと判断した。」と理由を残します。向きは社内基準から CSF 2.0 へです。
完成形：対応表 1 冊
社内基準 6 件ぶんの対応を入れた完成形を示します。まだ登場していなかった CSF 側の対応先を、先に 2 件確認しておきます。
| id | 属するカテゴリー | 本文 |
|---|---|---|
| PR.AA-01 | アイデンティティ管理、認証、アクセス制御（PR.AA） | 認可された利用者、サービス、ハードウェアの識別情報と認証情報が、組織によって管理されている |
| PR.AA-06 | アイデンティティ管理、認証、アクセス制御（PR.AA） | 資産への物理的なアクセスが、リスクに見合う形で管理され、監視され、実施されている |
mapping-collection:
uuid: 9d2b4f6c-8a1e-4b3d-b7c9-5e1a3d7f9b2d
metadata:
title: ミナト精機 社内基準と NIST CSF 2.0 の対応表
last-modified: "2026-07-20T09:00:00+09:00"
version: "1.0.0"
oscal-version: "1.2.2"
provenance:
method: human
matching-rationale: semantic
status: complete
mapping-description: 情報システム部の情報セキュリティ担当が、社内基準と CSF 2.0 の本文を読み比べて作成した。
mappings:
- uuid: 7a4c9e2b-3d6f-4f1a-8c5e-9b2d4f6a8c1e
source-resource:
type: catalog
href: mk-standards-catalog.yaml
target-resource:
type: catalog
href: https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/CSF/v2.0/yaml/NIST_CSF_v2.0_catalog.yaml
maps:
- uuid: 2e5a7c9b-4d1f-4b8e-9a3c-6e8b1d3f5a7c
relationship: subset-of
sources:
- type: control
id-ref: mk-ac-01
targets:
- type: control
id-ref: PR.AA-01
remarks: 社内基準はパスワードの扱いに限る。PR.AA-01 は証明書や機器の識別情報まで含むため、社内基準のほうが狭い。
- uuid: 8b1d3f5a-7c9e-4e2b-a4d6-1f3a5c7e9b2d
relationship: subset-of
sources:
- type: control
id-ref: mk-ac-02
targets:
- type: control
id-ref: PR.AA-01
remarks: アカウントの棚卸しと削除は、PR.AA-01 の「識別情報と認証情報の管理」の一部にあたる。
- uuid: 4f6a8c1e-2b4d-4a7c-b9e1-3d5f7a9c1e3b
relationship: subset-of
sources:
- type: control
id-ref: mk-ph-01
targets:
- type: control
id-ref: PR.AA-06
- uuid: 1a3c5e7b-9d2f-4d6a-9c4e-2b4d6f8a1c3e
relationship: subset-of
sources:
- type: control
id-ref: mk-bk-01
targets:
- type: control
id-ref: PR.DS-11
- uuid: 3b5d7f9a-1c4e-4d8b-a2c6-5e7a9c1e3b5d
relationship: intersects-with
sources:
- type: control
id-ref: mk-tr-01
targets:
- type: control
id-ref: PR.AT-01
- uuid: 6c8e1a3b-5d7f-4c9a-8e2b-4f6a8c1e3d5f
relationship: no-relationship
sources:
- type: control
id-ref: mk-ph-02
targets:
- type: control
id-ref: PR.DS-01
remarks: PR.DS-01 が守る対象はデータであり、紙の書類の施錠保管は対応しないと判断した。mk-ac-01 と mk-ac-02 が、どちらも PR.AA-01 に対応していることに注目してください。複数の条文が 1 つの管理策に対応する形は、規格対応ではごく普通に起こり、map を 2 件書くだけで表せます。
これが「ミナト精機の社内基準 × CSF 2.0 対応表」の版 1.0.0 です。Excel の対応表と見比べると、同じ「どの条文がどの管理策と対応するか」に加えて、Excel の形式では持てなかった情報が 3 つ入っています。対応の度合い（relationship）、対応表そのものの作られ方（provenance）、そして検討済みの「対応なし」の記録です。
理解の確認
ここまでの 3 モデルのうち、provenance（由来の記録）が必須なのは Mapping Collection だけです。なぜだと考えられますか。
2 つの規格の管理策を、担当者が本文の意味を読み比べて対応づけました。provenance の method と matching-rationale の組み合わせはどれですか。
次へ
第 2 部はここまでです。Control Layer の 3 つのモデルで、「守るべきことを決め、選び、対応づける」が一通り書けるようになりました。
次の第 3 部から、Implementation Layer に入ります。決めたルールを、誰が・何で・どう満たしているかを書く層です。最初のモデルは Component Definition。アオバドライブというクラウドストレージのベンダーが提供する、部品側のセキュリティ説明書を読むところから始めます。
このセクションは OSCAL 1.2.2 系の仕様に基づいて執筆しています。