MCP Server for OSCAL — AWS が公開した「AI に最新の OSCAL 情報を教える」MCP サーバー

標準的な AI に「OSCAL の mapping モデルって何？」と聞くと、たいてい的外れな回答が帰ってきます。なぜなら、mapping モデルは最近追加されたモデルであり、学習データにそもそも載っていないからです。2026年2月4日に開かれた NIST OSCAL Monthly Workshop（第39回）¹ ² で、AWS の Principal Security Engineer である Fritz Kunstler さんが紹介したのは、その「的外れ」を直すために OSS として公開したツールでした。

このツールは MCP Server for OSCAL という名前で、AWS Labs の GitHub 配下に置かれています。やっていることは派手ではなく、「AI エージェントに OSCAL の専門知識をオンデマンドで差し込む」だけ。ただ、その差し込み方の設計が OSCAL 普及の文脈で読むと面白く、しかも発表者本人がコンプライアンス業界の出身ではない、という点もこの話の見どころでした。

3行サマリー

AI が OSCAL に関する内容を答えるときに、古い情報が帰ってきたり、ハルシネーションが発生してしまう問題を、Anthropic が定義した Model Context Protocol（MCP）で解く OSS ツールが awslabs/mcp-server-for-oscal
ノートPC上でローカル動作、外部接続なし、コンテンツの SHA-256 改ざん検出付き、uvx 一発で常に最新版が起動するという、配布のされ方そのものが OSCAL 試行のハードルを下げる作りになっている
発表時点では4ツール構成だったが、その後 component definition のクエリや OSCAL 検証まで含む12ツールへと拡張中で、AWS が業界初の PCI DSS の OSCAL パッケージを出した文脈ともつながっている

発表者の立ち位置を知っておく

Fritz さんは AWS で10年近く働く Principal Security Engineer ですが、本人が冒頭で断っていたとおり、GRC（Governance, Risk, Compliance、ガバナンス・リスク・コンプライアンス）の領域に関わり始めたのは2024年後半からの18か月ほどでした。OSCAL を渡されて「これを社内で動かしてくれ」と言われた側の人で、業界の生え抜きではありません。

その短い期間に、彼は OSCAL Foundation の立ち上げに関与し、AWS 社内では2025年12月に PCI DSS の Attestation of Compliance（AOC、PCI DSS 監査の合格証明書）と Responsibility Summary を OSCAL JSON で公開するプロジェクトをまとめ上げました。AWS Security Blog によれば、このパッケージは AWS Artifact から取得でき、業界で最初の PCI DSS の OSCAL コンプライアンスレポートだそうです³。Fritz さん自身も発表中で「PCI DSS の OSCAL パッケージを12月に出して、業界初だと思っている」と話していました。

つまり今回のツールは、彼が現場で OSCAL に取り組む過程で「これがないと回らない」と感じた問題への自前の解、という性格が強いものです。発表中に何度も「AI が頼れる存在になる前提が崩れていた」「だから自分で作った」というニュアンスが出てきました。

デモが映し出した問題

発表は長めのデモから始まりました。Fritz さんは Kiro という AI IDE（AWS が2025年に発表した、Amazon Q Developer の後継となる VS Code フォーク）を二つ立ち上げ、片方は MCP サーバーを無効化、もう片方は MCP Server for OSCAL を有効化した状態で同じ質問を投げます。

無効化された側で「OSCAL の mapping モデルについて教えて」と聞くと、Claude は「mapping モデルは私の学習データに含まれていない」「OSCAL のモデルは私が知っている範囲では6つだけ」と返します。「OSCAL の現在のバージョンは？」と聞いても「2026年2月時点では分からない」で打ち切られます。

有効化された側に同じ質問を投げると、AI は list_oscal_models というツールを自分で呼び出し、mapping-collection モデルが存在することを確認したうえで答えを組み立て直します。「OSCAL の現在のバージョンは？」には「スキーマによれば 1.2.0」と返してきます。NIST が OSCAL 1.2.0 を公開したのは2025年12月12日で、Claude の学習データのカットオフより後のはずですが、ツール経由でスキーマを直接参照しているので答えにブレが出ません。

このコントラストが、MCP Server for OSCAL の存在意義です。OSCAL のように仕様が頻繁に更新され、しかも公開されている例が少ない領域では、AI 単体は答えを外しがちで、それも一見もっともらしく外します。

なぜ MCP なのか

ここで前提を整理しておきます。MCP（Model Context Protocol、モデルコンテキストプロトコル）は Anthropic が2024年11月25日に公開したオープン標準⁴ で、AI モデルと外部システムの接続方法を統一するためのものです。Anthropic は「AI 用の USB-C ポート」と説明していました。AI ごと、ツールごとにバラバラの統合を書く必要がなくなり、MCP に対応した AI クライアント（Claude Desktop、Claude Code、Kiro、VS Code 上の GitHub Copilot など）であれば、MCP に対応したサーバーを接続するだけで機能を取り込めます。

Fritz さんは MCP の役割を、映画 Matrix の有名な場面で説明していました。トリニティが「ヘリ操縦できる？」と聞かれて「まだ」と答え、無線で「B-212のパイロットプログラムを送って」と頼むと、知識が直接インストールされて操縦できるようになるあの場面です。MCP は学習せずに必要な瞬間にだけ専門知識を差し込めるので、その「インストール」に近い、という比喩でした。

サーバーが提供している4つのツール

発表時点（2026年2月）でサーバーが公開していたのは4つのツールでした。MCP では「ツール」とは AI から呼び出せる関数とその使いどころを書いた説明文のセットを指します。実装は素朴な Python 関数です。

最も基本になるのが list_oscal_models で、利用可能な OSCAL モデルを一覧返すだけのツールです。catalog、profile、mapping-collection、component-definition、SSP、assessment-plan、assessment-results、POA&M といった主要モデルに加え、それぞれが GA（一般提供）かプロトタイプかという状態も付きます。Fritz さんがデモで使った最初のツールがこれで、AI が「自分の学習データに mapping は含まれていない」と諦める手前で、このサーバーに問い合わせれば最新の真実が分かる、という入口の役割を果たしています。

次の get_oscal_schema がツール群の中核で、Fritz さんも「ハートはこれ」と言い切っていました。OSCAL は仕様の中に説明文が書かれた self-documenting なスキーマなので、対象モデルの JSON Schema を返すと、定義と人間向けドキュメントを同時に AI に渡したことになります。AI はそれを解釈して、「マッピングモデルの必須フィールドは何？」「テンプレート JSON を書いて」といった依頼にスキーマ準拠の答えを返せるようになります。

list_oscal_resources は OSCAL コミュニティが集めているソフトウェアやコンテンツの紹介マークダウンを返し、query_oscal_documentation は外部の知識ベースを引くオプション機能（デフォルトは無効）です。後者は AWS 上で自分用の OSCAL 知識ベースを動かしたい組織向けで、ここだけは外部ネットワーク接続を伴います。

スライドにあった mcp.json の設定例も簡素で、uvx を使って mcp-server-for-oscal@latest を呼び出すだけ、という形でした。uvx は Python のパッケージ管理ツール uv に付属するランナーで、PyPI から指定モジュールを必要に応じて取得して実行してくれます。AI クライアントが起動するたびに最新版を取りに行くため、ユーザー側は更新を意識しなくていい、という配布ポリシーがここで実装されています。

ロードマップとその後の進化

発表時点（2026年2月）のロードマップとして紹介されていたのは三つでした。一つは query_component_definition ツールで、AWS が experimental として公開している awslabs/oscal-content-for-aws-services リポジトリに入っている AWS サービスのコンプライアンス情報を、AI が直接引けるようにする機能。もう一つは validate_oscal_content で、Trestle と OSCAL CLI を使い、ユーザーが書きかけの OSCAL ドキュメントを検証して修正のヒントを返す機能。三つ目が「agent as tool」パターンで、サーバー単体をスタンドアロンの AI エージェントとして動かせるようにする計画でした。

この発表からおよそ2か月後の2026年4月2日には v0.4.0 がリリースされており、ロードマップに挙がっていた機能はすでに本体に取り込まれています。GitHub のコミットログとリリースノートを追っていくと、ツール総数は4から12に増えていて、OSCAL 1.2.1 への対応、Anthropic 公式の MCP レジストリへの登録、Amazon Bedrock AgentCore への対応、Component Definition のクエリ、複数レベルのコンテンツ検証、そして Strands Agents を使った standalone エージェントモードまでが揃っています。発表時点で Fritz さんが「coming soon」と語っていた機能群が、半年ほどのスパンで実装されています。

OSCAL の普及戦略として読んでみる

このサーバーを OSCAL コミュニティの動きの中に置き直してみると、特徴的な役割が見えてきます。

MCP Server for OSCAL は、「OSCAL を読み書きするのは AI で、人間は AI に話しかけるだけ」というコンセプトです。Fritz さん自身がコンプライアンス業界外の出身で、社内 PoC を回すために AI に頼って OSCAL を書かせていた、というのがそのまま設計の出発点に出ています。つまり、OSCAL の細部を理解した専門家を増やすのではなく、OSCAL を理解した AI を増やす、という普及戦略です。

これは「OSCAL Pocket Guide」が「OSCAL を見せないアプリ」で同じ方向を狙っていたのと、戦略レベルでは似ています。違うのはアプローチで、Pocket Guide はモバイルアプリの中で OSCAL を裏側に回したのに対し、こちらは AI エージェントを通じて OSCAL を裏側に回しています。OSCAL を解釈する主体を、人間から別のレイヤに移そう、という流れがコミュニティ内で複数の場所から立ち上がっているのが面白いところです。

米国の文脈から見た位置づけ

米国側では、ちょうど FedRAMP が機械可読化への移行を法律と政府方針で固めつつあるタイミングです。OMB Memorandum M-24-15 が2024年7月に出され、FedRAMP は RFC 0024 で Rev 5 の認可パッケージを OSCAL を含む機械可読な形で出す方針を提示し、OSCAL Foundation がその具体形を業界として書き始めています。SSP のテンプレート、ベースライン、サンプルが GitHub に並ぶ環境はだいぶ整ってきました。

ただ、それを実際に書く現場は楽になっていません。SSP は数百ページ規模の文書で、各統制について事業者が文章を書き、参照を張り、検証を通す必要があります。AWS のように業界初の PCI DSS の OSCAL パッケージを出した組織でも、その内側ではコンプライアンスチームが OSCAL に苦戦していたことが、Fritz さんの話からは伝わってきました。

この MCP サーバーは、その「実際に書く側」の負荷を AI に肩代わりさせる入口を作る試みです。OSCAL の生のスキーマと格闘するのは AI に任せて、人間は要件と判断に集中する、という分担が現実味を帯びてきています。

日本から見たとき

コンプライアンス領域での AI 活用は、日本でも慎重に議論されます。生成 AI に直接プロンプトを投げて統制文を書かせると、出力にバラつきが出て監査に耐えにくい、という指摘はよく聞きます。MCP のように正規化された専門知識を検証された経路で AI に渡す設計は、その問題への一つの答え方です。

Fritz さんは AWS の社員ですが、このプロジェクトはサポート対象の AWS 製品ではなく、AWS Labs 配下の Apache 2.0 ライセンスの OSS です。社内で困った人が作って外に出した、という流れがそのまま見えます。日本の事業会社でも、内製ツールの一部を同様の距離で外に出すと、ユーザーとして自分たちが助かる、という形は再現しやすいはずです。

OSCAL に限らず、社内の制度文書や規程・統制カタログを AI に正しく扱わせたい場面は日本にも多い。MCP サーバーを書くハードルは高くありません。AWS のこのプロジェクトはサンプルとしてのコードベースが公開されていて、社内向けの「制度知識を AI に注入するサーバー」を作るときの参考実装として読めます。

参考文献

NIST OSCAL Monthly Workshop #39, AWS 回トランスクリプト（英語）。https://csrc.nist.gov/csrc/media/Projects/open-security-controls-assessment-language/images-media/2026/oscal-monthly-workshop-39-AWS/CAPTIONS_02.04.2026_AWS.txt ↩
NIST OSCAL Monthly Workshop #39, AWS 回スライド PDF。https://csrc.nist.gov/csrc/media/Projects/open-security-controls-assessment-language/images-media/2026/oscal-monthly-workshop-39-AWS/02.04.2026_AWS.pdf ↩
AWS Security Blog「Fall 2025 PCI DSS compliance package available now」。AWS Artifact 経由で取得できる、業界初の PCI DSS の OSCAL 形式パッケージの発表記事。https://aws.amazon.com/blogs/security/fall-2025-pci-dss-compliance-package-available-now/ ↩
Anthropic「Introducing the Model Context Protocol」2024年11月25日。MCP の初公開時の説明（「AI 用の USB-C ポート」の比喩はここから）。https://www.anthropic.com/news/model-context-protocol ↩

この記事は、生成AIを用いて執筆し、著者が確認・編集したうえで公開しています。