OSCAL Control Mapping Model — OSCAL Compass から始まり OSCAL Foundation で標準化が進んだ、統制フレームワーク間の対応を機械可読化する OSCAL モデル

OSCAL の議論ではコントロールカタログ（catalog）や SSP（System Security Plan、システムセキュリティ計画書）が中心に語られがちですが、複数の統制フレームワークを並行して扱う実務では、別の悩みが現れます。NIST SP 800-53 に対して整えた統制実装の状態が、PCI DSS や CMMC、社内独自の統制セットにどこまで通用するかを、そのたびに紙の表で照合し直していてはきりがありません。2025年7月16日に開かれた NIST OSCAL Monthly Workshop（第37回）^{1 2} では、その照合作業を OSCAL の中に持ち込むための新しいモデル、OSCAL Control Mapping Model（OSCAL 統制マッピングモデル）が、標準化の進捗報告として紹介されました。

登壇したのは OSCAL Foundation の Technical Coordinator である Stephen Banghart さんと、IBM Research の Anca Sailer さん、IBM Research India の Vikas Agarwal さんの3人です。Stephen さんは NIST 時代に OSCAL の立ち上げに関わった当事者で、現在は OSCAL Foundation でモデル開発の取りまとめ役を務めています。Anca さんと Vikas さんは OSCAL Compass というオープンソースプロジェクトを通じてマッピングモデルの原型を作り、OSCAL Foundation に持ち込んだ張本人たちです³。

発表は二段構えでした。前半は「業界主導で OSCAL のような標準をどう成熟させていくか」という協調プロセスの一般論を、Stephen さんがマッピングモデルを具体例に置きながら説明します。後半は Anca さんと Vikas さんが、マッピングモデルの具体的なスキーマと、OSCAL Foundation で議論されている拡張案を解説する構成です。

3行サマリー

• マッピングモデルは「ある統制フレームワークの統制が、別のフレームワークの統制とどう対応するか」を機械可読に記述するための新しい OSCAL ドキュメントタイプで、OSCAL Compass（IBM が始め、現在は CNCF Sandbox 入りした OSS）が原型を作って NIST に提案した
• 2025年7月時点では NIST がホストするプロトタイプの段階で、OSCAL Foundation の Technical Working Group（TWG、技術作業部会）が業界からの意見を集めながら成熟を進めていた。その成果はその後 OSCAL v1.2.0（2025年12月12日リリース）で正式モデルとして本体に取り込まれた⁴
• スキーマは mapping-collection をルートに、ソースとターゲットのカタログ／プロファイルを置き、各 map 要素で個々の統制ペアの関係を equivalent-to subset-of superset-of intersects-with などの修飾子で記述する。OSCAL Foundation 側からは、AI ツールが返す確信度を数値で持たせる案や、method フィールドにユーザー定義値を許す拡張案が提案されていた

協調作業の前提

Stephen さんが冒頭に置いたのは、OSCAL に限らない一般論でした。技術標準というのは「複数の組織や人がお互いに意思疎通するための共通言語」だから、その言語を作る作業自体は協調が前提になる、という整理です。NIST は OSCAL の立ち上げ当初からこの考え方を採っており、コミュニティドリブンで仕様を育てる姿勢を続けてきました。OSCAL Foundation はその姿勢を業界側でも引き受けるために、2025年2月に発足した非営利団体です⁵。

Stephen さんが整理した協調プロセスは6つのフェーズで、use case → implementation → introduction → collaborative development → prototyping and testing → final publication という流れになります。誰かが「今の標準ではうまく扱えないユースケース」を見つけ、自分の問題を解くためにカスタム実装を作り、それをコミュニティに持ち込む。良さそうなら共同開発の段階で大勢が手を入れ、プロトタイプと検証を経て、最終的に NIST が公式リリースする。聞いてみれば素直な流れですが、OSCAL のような多者参加の標準では、各フェーズで誰が何を持ち寄るかが見えていないと議論が空転する、という指摘でした。

ここで Stephen さんが繰り返していたのは、「標準作りに貢献するハードルは思っているより低い」という一点です。コードでの実装まで持っていなくても、ユースケースを持ち込むだけで議論は動く。今からマッピングモデルがどのフェーズにいて、これからどこに向かうのかを共有しておくから、関心のある人は次の TWG 会合に来てほしい、という呼びかけがこのセクションの結びでした。

マッピングモデルが解こうとしている問題

ここから話は具体例としてのマッピングモデルに切り替わります。

統制フレームワーク同士の対応関係を整理する「マッピング」という作業は、OSCAL の外でも長く行われてきた地味な定常業務です。組織がすでに NIST SP 800-53 のあるベースラインを実装済みで、新しく PCI DSS 4.0 への準拠が必要になったとしましょう。ゼロから PCI 対応を組み立て直すのではなく、「800-53 をやっておけば PCI のここまでは満たされているはずだ」「足りないのはこの統制群だ」という対応表が作れれば、追加の作業を最小化できます。GRC の現場では、この差分把握こそが投資判断の入口になります。

これまで、こうした対応関係は Excel やコンサルタントのレポートの形で配布されていました。読み手は人間で、機械が解釈する前提では作られていません。OSCAL マッピングモデルがやろうとしているのは、同じ情報を機械可読に表現することで、SSP・コンポーネント定義・アセスメント結果といった他の OSCAL モデルと噛み合うパイプラインに乗せることです。Anca さんは IBM の本業（コンプライアンス自動化）の中で「同じ評価を一度回して複数の枠組みに対して報告する」運用を目指しており、その実現には機械可読なマッピングが不可欠でした。

OSCAL でこの対応関係を表現できるようになると、活きるユースケースは複数あります。大企業が独自に作った内部統制フレームワークを起点に、それを SP 800-53、PCI DSS、ISO/IEC 27001 などの外部要件にマッピングして、一度の証跡収集で複数の枠組みに対する説明が成立する。第三者アナリストがフレームワーク間の関係を機械可読の形で出版する。技術統制の実装結果が新しい規制に自動的にマッピングし直される。スライドで Anca さんが挙げていたのは、こうした「同じ運用状況を多面的に再利用する」筋立てでした。

OSCAL Compass というルーツ

このユースケースに最初に手をつけたのが、Anca さんと Vikas さんが関わる OSCAL Compass というオープンソースプロジェクトです。OSCAL Compass はもともと IBM 社内の compliance-trestle というプロジェクトとして始まり、Red Hat との協業を経て、2024年6月21日に CNCF（Cloud Native Computing Foundation）の Sandbox プロジェクトに採択されています⁶。中核は OSCAL を扱う Python / Go の SDK と、OSCAL のアーティファクトを Kubernetes 上のポリシーエンジン（Kyverno、Open Cluster Management Policy Framework など）に橋渡しする「Compliance-to-Policy」ツール群です。Anca さん本人は IBM の Distinguished Engineer として、Compass を中心としたコンプライアンス自動化の研究と実装をリードしている人物です。

OSCAL Compass のチームは、OSCAL のコア部分だけでは「フレームワークをまたいで統制実装の状態を使い回す」要件が満たせないと早い段階で気づき、独自に拡張モデルを設計して NIST に持ち込みました。Stephen さんが「実装を持って紹介しに来てくれると話が早い」と言っていたのは、まさにこのパターンです。NIST 側はその設計を整理し直し、pages.nist.gov/OSCAL-Reference 配下にプロトタイプのマッピングモデルとしてホスト⁷、コミュニティが触れる形にしました。

ここで重要なのは、マッピングモデルが既存の OSCAL モデル群を改変するのではなく、新しいドキュメントタイプとして横に並ぶ形で導入された点です。OSCAL の他モデル（catalog、profile、SSP など）には何も変更を加えなくて済むので、後方互換性を壊さずに新機能を足せます。Stephen さんはこの設計判断を「particularly smart」と評価していました。

OSCAL Foundation がボールを引き取った

OSCAL Compass のプロトタイプがコミュニティに紹介されたあと、その熟成を引き受けたのが OSCAL Foundation の Technical Working Group（TWG）でした。TWG は OSCAL Foundation の主要な技術作業部会で、毎週開催され、Foundation の会員でなくても参加できます。

ここで TWG が果たしているのは、Stephen さんが整理した6フェーズの中の共同開発の役回りです。Compass チームという比較的小さな集団で作られた初期プロトタイプを、より広い当事者（他のベンダー、規制側、エンドユーザー）と合議的に揉んで、ユースケースの幅と表現力を広げる。最終的に NIST が公式リリースを出す前段で、業界の合意形成を済ませる、という分担です。

Michaela Iorga さん（NIST OSCAL チームのリード）も会場でこの座組を明確に補足していて、OSCAL の所有者は依然として NIST であり、最終的に正式モデルをリリースするのも NIST だが、その手前の成熟工程で OSCAL Foundation が業界の声を集めてくれているのは決定的に重要だ、と述べていました。Foundation の声が大きくなるほど、最終モデルが現場のユースケースに耐えるものになる、という整理です。

マッピングモデルの中身

ここから後半は Vikas さんに引き継がれ、プロトタイプのスキーマと、OSCAL Foundation で議論中の拡張案が解説されます。

ルート要素は mapping-collection で、OSCAL の他モデル同様に metadata と back-matter を持ちます。マッピング固有の構造は、おおまかに mapping-provenance（出どころ情報）と1つ以上の mapping（個別の対応記述）の二段構成です。簡略化した JSON で書くと、骨格は次のようになります。

{
  "mapping-collection": {
    "uuid": "...",
    "metadata": { "title": "PCI DSS 4.0 to NIST SP 800-53 Rev 5" },
    "mapping-provenance": {
      "method": "automated",
      "matching-rationale": "semantic",
      "confidence-score": "high"
    },
    "mapping": [
      {
        "source-resource": { "href": "PCI DSS 4.0 のカタログ" },
        "target-resource": { "href": "NIST SP 800-53 Rev 5 のカタログ" },
        "map": [ /* 個々の統制ペア */ ],
        "source-gap-summary": { /* ソース側で対応がない統制 */ },
        "target-gap-summary": { /* ターゲット側で対応がない統制 */ }
      }
    ]
  }
}

mapping-provenance には、そのマッピング全体の素性を記述するフィールドが入ります。method はマッピングをどう作ったか（手作業／自動／ハイブリッド）、matching-rationale はどの抽象度で対応を取ったか（構文一致／意味一致／機能一致）、confidence-score は AI ツールなどが返す確信度、description は補足記述です。Vikas さんが強調していたのは、これらのフィールドが個別の map 要素レベルで上書きできる点でした。基本は mapping-provenance に「全体としては LLM ベースの自動マッピング、確信度は高」と書いておき、特定の map だけ手作業で見直したなら、その map の中で method: manual と上書きする、という使い方です。

mapping の中に並ぶ map 要素が、個々の統制ペアの対応を表す部分です。1つの map には source 側の統制と target 側の統制をそれぞれ列挙する source と target のサブ要素があり、両者を結ぶ relationship 修飾子で関係性を表現します。NIST の概念ページに整理されている修飾子は5種類です⁸。

スライドに載っていた PCI DSS 4.0 と NIST SP 800-53 の対応例を、簡略化した JSON で並べるとこんな具合です。

{
  "map": [
    {
      "source": [{ "control-id": "pci.1.1.1" }],
      "target": [{ "control-id": "SC-1" }],
      "relationship": "equivalent-to",
      "coverage": "100"
    },
    {
      "source": [{ "control-id": "pci.1.1.2" }],
      "target": [
        { "control-id": "AC-1" },
        { "control-id": "SC-1" }
      ],
      "relationship": "intersects-with",
      "coverage": "80"
    }
  ]
}

最初の map は PCI の 1.1.1 と SP 800-53 の SC-1 が同等で、カバレッジ100%の単純な対応です。2つ目の map は PCI の 1.1.2 が SP 800-53 の AC-1 と SC-1 の2つに部分的に重なる関係で、カバレッジ80%と記述しています。「ターゲット側の2つの統制とソースの要求事項に20%の不一致がある」というニュアンスを、修飾子と数値の組み合わせで機械可読に書ける、というのが要点でした。

スキーマの末尾には source-gap-summary と target-gap-summary が置かれます。ここに記述されるのは「明示的にどの map にも入らなかった統制群」で、いわば「写像で取りこぼした要素のリスト」です。これが要る理由は素直で、ある統制が gap-summary にも map にも出てこなければ、「マッピング作業者がまだそこに手を付けていない」のか「対応する統制が target に存在しないと判定済み」なのかが区別できないからです。gap-summary で明示的に「ここは対応なし」と書いておくと、後続のツールがそのギャップを安心して埋めにいけます。

OSCAL Foundation で議論されている拡張案

プロトタイプのスキーマだけでは表現しきれないケースに対して、Vikas さんは TWG で議論中の拡張案も3つ紹介していました。発表時点では確定ではないものの、現状の方向性が見えるので、要点だけ並べておきます。

1つ目は、method フィールドへのユーザー定義値の許容です。現状の method は manual / automated / hybrid 程度の限られた文字列ですが、名前空間付きで組織独自の値（たとえば org.example.method:llm-graph-based）を入れられるようにし、ベンダーや内部ツールの分類体系をそのまま記述できるようにする案でした。OSCAL の他のモデルにある prop の name 名前空間と同じ発想です。

2つ目は、confidence-score の数値化です。現状は単純な文字列なので「high」「medium」のような曖昧な値しか入れられませんが、これを score（0.0〜1.0 の数値）と description（補足文字列）の組に分け、AI ツールが出力する数値スコアをそのまま受け止められるようにする提案でした。加えて、カテゴリ値（low / medium / high のような分類）も併用できるようにするかは、現在 TWG で議論中です。

3つ目は、coverage（カバレッジ）フィールドの追加です。マッピング全体の出どころ情報（マッピング全体としてどれくらいの target 統制をカバーできているか）にも、個別の map 要素レベル（この source 統制群と target 統制群が要求する全要件のうち、何%が一致しているか）にも、任意で coverage 値を持てるようにする案でした。これが入ると、target カタログのうちどれくらいがソース側の統制実装でカバーできるかを集約値として取り出せます。

これらの拡張は、Vikas さんが「会員からの意見次第で形が変わる」と明言していたとおり、議論の途中です。実際に OSCAL v1.2.0 として公開されたスキーマでは、mapping-collection ルートと mapping-provenance、map 要素、matching-rationale などが含まれた一方で、提案された拡張のすべてがそのまま入ったわけではありません。最新の正式仕様は NIST の v1.2.x マッピングモデルリファレンスを当たるのが確実です⁹。

「source と target はどっちがどっち？」という議論

スキーマの説明が一通り終わったあと、Michaela さんが「ここは記録に残しておきたい」と切り出して、source と target の方向性について議論を提起しました。これがマッピングモデルの設計上、地味だけれど根深い論点だったので、要点を残しておきます。

NIST が最初にモデルを設計したときの想定は、「一度評価して複数回報告する」というユースケースを念頭に置いたものでした。組織が独自に維持している技術統制やカスタム統制（クラウドハイパースケーラの内部統制セットや、大企業が自社用に定義した統制カタログなど）を source として持ち、それを SP 800-53 や PCI DSS のような外部要件に target としてマッピングしておく。ソース側で評価を回せば、その結果をターゲット側に投影して「この外部規制をこれだけカバーできている」と説明できる、という流れです。

ところが Vikas さんが発表中に示していた PCI 側を source、SP 800-53 側を target にする例は、その逆を行っていました。Michaela さんが指摘したのは、設計時の意図と実装側で出てくる例が逆向きになっていると、世界中の利用者が同じモデルを別々の方向で使ってしまい、機械での集約や報告で齟齬が起こる、という点です。

具体例として Michaela さんが置いたのは TLS の話でした。ソースが「implement TLS」、ターゲットが「implement TLS 1.2 and above」というケースを考えると、どちらが subset-of でどちらが superset-of かは、見方によって割れます。要件の文面で見れば「TLS 1.2 and above」のほうが厳しい（少ない解しか許さない）ので上位集合と呼びたくなりますが、満たし方の取りうる技術解の集合で見ると逆になります。Michaela さんの整理は、「ターゲット側を評価するときに何回テストが必要になるか」を軸に取り、テスト数の多いほうを上位集合として扱うのが運用上一貫する、というものでした。

これは細かい取り決めの話に見えますが、機械可読化されたマッピングが世界中のコンプライアンスツールで自動的に読み解かれる前提に立つと、向きの解釈が割れた瞬間にツール間の相互運用性が崩れます。Michaela さんが「コミュニティの意見を集めて決めたい」と公開で投げかけていたのは、まさにこの相互運用性の問題でした。

マッピングが回ったあとの実務 — Delta 方式の component definition

スキーマの議論だけで終わると抽象論ですが、Vikas さんは終盤に「ではこのマッピングを使って実務がどう回るか」を Delta 方式という具体的なワークフローで示してくれました。

出発点は、ある組織が NIST SP 800-53 をベースに OSCAL 一式（profile、component definition、assessment plan、assessment results）を整え終わっている状態です。component definition は、その組織のソフトウェア・サービス・プロセスが各統制をどう実装しているかを記述する OSCAL のモデルで、内部に技術ルール（ポリシーエンジンが評価する具体的なチェック）まで持たせている、という前提です。

ここに新しい規制として PCI DSS 4.0 への準拠が必要になったとします。素直にゼロから component definition を書き直すと、すでに 800-53 向けに作った内容のかなりが重複します。そこで、

1. PCI DSS の各統制から NIST SP 800-53 の各統制へのマッピングを OSCAL マッピングモデルで作る
2. そのマッピングから、PCI 側で「完全に覆われている」「部分的に覆われている」「まったく覆われていない」統制を区別する
3. 部分・未カバーの統制に対してだけ、追加で必要な技術ルールを書き起こし、それを Delta PCI component definition という新しいコンポーネント定義にまとめる
4. 既存の NIST 800-53 component definition と Delta PCI component definition の 和集合 を取った assessment plan を組み立て、その単一の計画を1回回す
5. 出てきた assessment results から、NIST 800-53 向けの統制実装の状態と PCI 向けの統制実装の状態を、両方ともレポートとして引き出す

という流れになります。一連の工程の中でマッピングモデルが果たすのは、3の「Delta が何かを機械可読に決める」根拠の役回りです。マッピングが gap-summary まで含めて明示的にカバレッジを語っているので、Delta 側に何を追加すべきかが自動で決まる、という設計でした。

この Delta 方式は、新しい規制が追加されるたびにこのサイクルを回すだけで、既存の運用状況を最大限再利用できる構造になっています。フレームワーク数が10、20と増えていく現代の GRC 環境で、機械可読マッピングが効いてくる場面の一つです。

OSCAL の中での位置づけと、その後

マッピングモデルは2025年7月の発表時点ではまだプロトタイプ段階で、TWG で議論を続けている状態でした。Stephen さんも「これからプロトタイプと検証のフェーズに進み、その先に正式公開が来る」と整理していたとおりです。

その後、OSCAL v1.2.0 が2025年12月12日にリリースされ、Control Mapping Model が正式モデルとして本体に組み込まれました⁴。リリースノートには「Merging Control Mapping Model into develop branch」という PR が含まれており、これが正式追加の中身です。マッピングモデルは OSCAL の Control layer に属するモデルとして、catalog や profile と並ぶ位置づけになっています。OSCAL の概念ページにもマッピングモデルの専用ページが追加されており、equivalent-to subset-of superset-of intersects-with no-relationship の修飾子が公式に定義されました⁸。

ツール側も追随しており、OSCAL Compass の compliance-trestle は、新たにリリースされたマッピングモデルをサポートする旨をリポジトリで明示しています¹⁰。プロトタイプから正式モデルへの遷移という、Stephen さんが冒頭で説明していた協調プロセスのモデルケースを、リアルタイムで通過したことになります。

米国の文脈から見えるもの

米国の OSCAL 周辺で語られる議論の多くは、SSP や component definition のように、特定のフレームワーク内部の統制実装を深く扱う話でした。マッピングモデルはそれらと役割が違い、フレームワーク同士の橋を機械可読化するという、横方向の補助線を引く位置にあります。OSCAL Foundation が後に取り組む FedRAMP（米連邦政府クラウドの認可制度）Rev 5 の機械可読化作業や、CMMC（米国防総省サプライチェーン向けのサイバーセキュリティ認証）など他フレームワークへの展開でも、複数の枠組みが交差する場面でマッピングモデルが土台として参照される構図が見込まれます。

OSCAL Compass が IBM 発で CNCF Sandbox に入ったという経路にも、独自の意味があります。OSCAL の議論はこれまで NIST、FedRAMP、AWS、RegScale など米国の連邦周辺で進むことが多かったのですが、CNCF コミュニティに OSCAL の SDK と参照実装が置かれることで、Kubernetes やクラウドネイティブのエコシステムに OSCAL が浸透していく経路が広がります。Anca さんが本職のコンプライアンス自動化（特に AI 時代の継続的監査）で OSCAL Compass を回している話は、その動きを実装側から押し上げているものでした。

NIST と OSCAL Foundation の関係も整理しておく価値があります。NIST が標準の所有者で、OSCAL Foundation は業界側の合意形成と成熟を担う、という分業は2025年に固まったばかりで、マッピングモデルはその新しい分業体制で標準化を通過した初期の事例の一つです。2026年以降に OSCAL Foundation が引き受ける FedRAMP まわりの作業も、この同じパターン（業界側で集約 → NIST が公式リリース）の延長線上にあると考えると、流れが見やすくなります。

日本から見たとき

日本でも ISMS、政府情報システム統一基準、業界別ガイドラインなど、複数の統制セットを並行して満たす場面は珍しくありません。対応関係は今もスプレッドシートやコンサルタントの納品物で管理されていることが多い。OSCAL マッピングモデルがやっているのは、対応関係をデータとして持ち、equivalent-to / subset-of / superset-of / intersects-with で関係を明示することです。OSCAL を全面採用しなくても、社内統制と外部規制の対応表を「人が読む文書」から「機械で集約できる構造化データ」に置き直す、という第一歩だけでも意味はあります。

Delta 方式の component definition も、日本の組織にとっては読みどころです。新しい規制が来るたびに内部統制をゼロから書き直すのではなく、既存の運用状況とマッピングから差分だけを扱う。ISMS を複数持つ組織なら、同じ証跡を別フォーマットで何度も用意し直す負担を減らせるかもしれません。

OSCAL Foundation の TWG はオープンで、会員でなくても参加できます。日本から入るには言語と時差の壁はありますが、マッピングモデルを日本の制度に当てはめるとどこで整合性の問題が出るか、という視点だけでも共有する価値はあります。source と target の向きの議論が続いているように、細部はまだ決まり切っていません。