OSCAL Hub — RegScale が OSCAL Foundation に寄贈した OSCAL 文書を共有・検証する Web プラットフォーム

OSCAL の仕様は成熟を重ねているものの、実際に現場で触ろうとすると「コマンドラインを叩く」「YAML をエディタで書く」「自前で検証スクリプトを回す」などの技術的な操作が必要になります。エンジニア以外の認可担当者やコンプライアンス担当者にとっては、ここがそのまま参入障壁になっていました。2026年2月18日に開かれた NIST OSCAL Monthly Workshop（第40回）¹ ² で RegScale が紹介した OSCAL Hub は、その障壁を「Web ブラウザで完結する GUI」に置き換えにいったプロジェクトです。

登壇したのは RegScale の Co-founder & CEO の Travis Howerton さんと、同社の Sr. Director of AI & Platform Engineering である Dave Waltermire さんでした。Dave さんは長く NIST で OSCAL の仕様策定に関わってきた当事者で、現在は RegScale 側に移って OSCAL CLI と Claude プラグインの開発を率いている人です。発表は OSCAL Hub の Web UI から始まり、その裏側で動く OSCAL CLI、そして Claude Code から OSCAL CLI を呼び出す AI 連携、と順に説明が行われました。

3行サマリー

OSCAL Hub は Web UI、REST API、CLI を一つにまとめた OSS プラットフォームで、検証・変換・可視化・ATO 風ワークフローまでを GUI でこなせる
RegScale は2025年12月の OSCAL Plugfest で OSCAL Hub を公開し、ソースコードを OSCAL Foundation に寄贈済み。ホスト版（oscalhub.com）は誰でもサインアップでき、GitHub（RegScale/oscal-hub）からセルフホストもできる
別系統で進めている metaschema-framework/claude-plugins は Claude Code 用のプラグイン群で、Claude に OSCAL CLI を直接呼ばせて検証・修正・新規プロファイル作成を会話で進める使い方を示していた

OSCAL Plugfest と寄贈の経緯

OSCAL Hub の初公開は今回の発表ではなく、その前の2025年12月の OSCAL Plugfest でした。OSCAL Plugfest は OSCAL の実装者・規制側・コミュニティが集まって相互運用性の検証作業を行うハンズオン型のイベントで、ここで RegScale が OSCAL Hub を披露し³、同時にソースコードを OSCAL Foundation に寄贈すると発表しています。プレスリリースは2025年12月16日付⁴ で、寄贈先である OSCAL Foundation は OSCAL の普及と中立的なガバナンスを担う非営利団体です。

今回の Monthly Workshop は、その2か月後にあらためてコミュニティ向けに OSCAL Hub を紹介する、という位置づけでした。

RegScale という会社の立ち位置

RegScale はバージニア州 Tysons Corner に拠点を置く商用 GRC（Governance, Risk, Compliance、ガバナンス・リスク・コンプライアンス）ベンダーで、Continuous Controls Monitoring（CCM、統制の継続的モニタリング）を中心の打ち出しにしている会社です。商用製品は別にあり、OSCAL Hub はそこから切り出した「コミュニティに渡した側」の OSS です。

Dave さんがこの会社にいるという点は、OSCAL コミュニティの構造を読むうえで大きな意味を持ちます。Dave さんは長年 NIST 側で OSCAL の仕様と Java 実装（liboscal-java、oscal-cli）の中心人物だった人で、その人が今は RegScale で OSCAL CLI のフォーク（metaschema-framework/oscal-cli）と Claude 用プラグインを開発しています。NIST 公式の usnistgov/oscal-cli と互換を保ちつつ、より新しい OSCAL モデルや機能を取り込む位置づけの実装で、OSCAL Hub の CLI もこのフォーク側を使っています。

つまり OSCAL Hub は、コミュニティで OSCAL の中身を一番よく分かっている人物が、商用 GRC ベンダーの中で書いて、それを OSCAL Foundation に戻した、という素性のプロジェクトです。

何を解こうとしたのか — GUI とパッケージマネージャ的な配布

Travis さんが「なぜ作ったか」を語るときに繰り返していた表現は二つでした。一つは「学習曲線を下げる」、もう一つは「pip install や npm install のように OSCAL コンテンツを取りに行ける状態を作りたい」です。

前者は、OSCAL の技術的な美しさは認めたうえで、それがエンジニア寄りに偏っている現状への対処です。OSCAL CLI でできることは前からありますが、CLI に慣れていない人にとっては最初の一歩がそもそも踏み出せません。OSCAL Hub の役割は、その CLI でできる操作（検証、変換、プロファイル解決など）にドラッグ&ドロップの UI を被せて、非エンジニアであるコンプライアンス担当者の手元で完結させることです。

後者は配布の話です。これまで OSCAL コンテンツ（catalog、profile、component definition）の在処は NIST のリポジトリと FedRAMP の公式ページが中心で、組織や個人が出したテストファイルやサンプルを探すのは骨が折れました。Travis さんが OSCAL Hub の「Library」セクションで描いていたのは、コンテンツを公開し、検索し、評価・コメントし、版を上げていける場所を用意すること。バージョン履歴も保持されるので、PyPI や npm registry に近い使い方ができる、という発想でした。

Web GUI — ライブラリ、可視化、ATO ワークフロー

ログイン後の OSCAL Hub は、組織（organization）を最初の単位として持ちます。一人の利用者が複数の組織を持てて、組織ごとにコンテンツを公開・非公開、共有・閉じる、を選べる作りです。

組織内のダッシュボードからまず触れるのが Library です。OSCAL ファイルを一覧で見られて、検索・アップロード・ダウンロードができ、人気順や使用統計も取れる。各コンテンツに対しては評価（rating）とコメントを残せて、所有者が新しい版を上げていけば履歴として残ります。発表では「ベンダーが自社技術の component definition を作って公開する場として使ってほしい」というユースケースも語られていました。

ライブラリの隣にあるのが Authorization（認可）のセクションで、ここは「OSCAL の ATO（Authority to Operate、運用許可。連邦システムでの本番稼働の認可）パッケージを GUI で回す」という proof-of-concept として作られていました。アップロード済みの SSP（System Security Plan、システムセキュリティ計画書）から一つ選び、評価結果に当たる SAR（Security Assessment Report、評価報告書）を組み合わせ、認可日と失効日を入力すると、その先で SSP の中身が一気に可視化されます。

可視化の項目はかなり実用寄りでした。スライド上では情報種別と分類カテゴリ、関係者のロール、統制ファミリーごとの実装状況、資産インベントリ、評価結果のファミリー別集計、統制ごとの遵守分布、そして発見事項（findings）の一覧、と続きます。これらは全部、アップロードされた OSCAL ファイルを読んだ結果をダッシュボードに置き直しているだけです。

その先で認可テンプレートを選び、パラメータ（issued、expiration、impact level など）を埋めると、ATO レターのドラフトが自動で組み上がります。承認条件（conditions of approval）を追加し、署名すると、組織のインベントリに新しい認可済みパッケージが積まれる、という流れでした。あくまで proof-of-concept とのことで、現状でも未実装の挙動はありそうですが、関連する補助文書を Markdown で書いて添付できる機能まで含めて、ATO の周辺で動く実務を一気通貫で扱う設計の方向性が見えるデモでした。Travis さんが具体例として挙げていたのは、ISSM レター（Information System Security Manager、情報システムセキュリティ管理者からの承認文書）、ISSO レター（Information System Security Officer、情報システムセキュリティ責任者からの承認文書）、Privacy Impact Assessment（PIA、プライバシー影響評価）などです。

Web GUI — 検証・変換・カスタムルール・バッチ

Library と Authorization の隣には、OSCAL CLI でずっと提供されてきた基本機能群が GUI で並んでいます。

可視化（Visualize）は、OSCAL ファイルを投げると中身を表示するだけのシンプルなツールですが、コンテンツの種類（SSP、SAP、SAR、component definition、catalog、profile など）を判別してそれぞれに合う形で見せます。Travis さんはここを「sneak peek」と呼んでいて、書く前ではなく「もらった OSCAL を最初にざっと眺める」用途を想定している印象でした。

検証（Validate）は OSCAL ファイルをアップロードして、合否と警告を返します。デモでは AwesomeCloud の SSP を投げて「0 errors, 0 warnings」と出ていました。内部は OSCAL CLI を呼んでいるだけで、Travis さんが「we're just using the CLI under the hood」と説明していたとおり、機能としては既存の CLI と等価です。価値は「同じことを GUI でできる」点に置かれています。

変換（Convert）は XML から JSON、JSON から YAML、というような相互変換で、こちらも CLI のラッパーです。ドラッグ&ドロップで投げて結果ファイルをダウンロードする、という流れを実現できます。

少し面白いのが Custom Validation Rules で、OSCAL CLI に組み込まれた検証ルールに加えて、組織独自のルールを差し込めるようになっています。Travis さんはここを「OSCAL 文書のコンパイラ」に例えていて、ファイルがコードでルールが言語仕様、という考え方でした。CLI で扱える Metaschema 制約をそのまま GUI から登録・適用できる、と読むと分かりやすいと思います。

これらの処理はバッチでも回せるようになっていて、複数ファイルを一度に検証・変換した履歴がダッシュボードに残ります。失敗したものを開けば、CLI が出したエラーメッセージにたどり着けるので、GUI で始めて行き詰まったら CLI 出力に降りて原因を確認する、という導線が自然に成立する作りでした。

API と自前ホストの管理画面

GUI で見せた機能は、すべて REST API でも叩けます。Travis さんが想定していたのは、組織内の GRC ツールや独自アプリケーションから OSCAL Hub に検証や変換を投げて、結果をプログラム的に受け取るパターンです。Spring Boot で書かれた API バックエンドが GitHub の RegScale/oscal-hub リポジトリに同梱されており、自前で立てた場合も同じ API が使えます。

セルフホスト向けには管理パネル（admin panel）が用意されていて、組織やユーザーの管理、利用状況の analytics、生のログ確認、そして SIEM（Security Information and Event Management、セキュリティ情報イベント管理）へのログ転送までを画面から行えます。

OSCAL CLI — Dave さん側の「plumbing」

ここから発表は Dave さんに引き継がれます。Dave さんが扱うのは、OSCAL Hub の Web UI の裏で動いている OSCAL CLI そのものと、その周辺の AI 連携です。

OSCAL CLI は Java で書かれたコマンドラインツールで、OSCAL コンテンツに対する基本操作を提供します。XML / JSON / YAML 間の相互変換、ルールベースエンジンによる検証、profile から resolved catalog を作る profile resolution、Metaschema 定義から XML/JSON スキーマを生成する処理、などが含まれます。OSCAL は profile を「対象の統制 ID と微修正の指示の集合」として持つ仕様なので、profile resolution は実際の認可作業に入る前段でしばしば必要になる処理です。Dave さんはこの CLI を「OSCAL の plumbing（配管）」と呼んでいました。GUI も AI 連携も、最終的にはこの配管の上に乗っています。

CLI は単体で使う以外に、CI/CD パイプラインに組み込めるという点を Dave さんは強調していました。後で触れる SARIF 連携は、まさにその使い方を示すものです。

Claude プラグインで OSCAL CLI を会話から呼ぶ

Dave さんがその次に出したのが、Claude Code から OSCAL CLI を呼ぶ仕掛けでした。Claude Code は Anthropic が提供する CLI ベースの AI コーディングエージェントで、Skills と Plugins という二つの拡張点を持っています⁵。Skill は SKILL.md というマークダウン1枚に AI への指示と使いどころを書いたもので、Plugin はそれらに加えて hook や MCP サーバを束ねた配布単位です。

Dave さんが OSCAL コミュニティに向けて公開しているのが metaschema-framework/claude-plugins で、ここには metaschema、metaschema-tools、oscal、oscal-tools の4つのプラグインが入っています。oscal は OSCAL の各モデル（catalog、profile、component-definition、SSP、SAP、SAR、POA&M）を理解するための知識プラグインで、oscal-tools のほうが OSCAL CLI を実際に呼び出すコマンドと MCP サーバを提供するツーリングプラグインです。

デモは三段構えでした。

一段目は壊れた OSCAL profile の検証で、Claude にプロファイルを検証してくれと頼むと、プラグイン経由で OSCAL CLI を呼んで結果を受け取り、その出力を AI が読んで「何がなぜ失敗したか」を自然言語で要約します。続けて「修正してくれ」と指示すると、Claude が OSCAL の仕様（文書を変更したら UUID を更新するルール）を踏まえて新しい UUID を発行し、無効になっていた role の参照を修正し、catalog に存在しない統制 ID を削除して、再検証してパスするところまで持っていきました。

二段目は新規 profile の生成で、ローカルに置いてある NIST SP 800-53 catalog を指して「Access Control（AC）の統制と統制エンハンスメントを全部入れた profile を作ってくれ」と指示します。Claude は小さなスクリプトを書いて catalog を解析し、AC ファミリーの147統制を抽出してから profile を組み立て、最後に OSCAL CLI で検証して valid と確認していました。同じ profile を YAML に変換するときには、Claude が CLI のコマンド構文を一度間違えて、その誤りを自分で気づいて再実行する、という挙動も挟まれていて、AI が CLI と協調するときのリアルな姿が見えました。

三段目はリポジトリ全体からの SSP 生成で、CI/CD ワークフローや実装ファイルを Claude に分析させて「このリポジトリは 800-53 のどの統制を実装しているか」を書き出し、SSP の形で出力する、という野心的なデモでした。これは発表中に Claude が途中でクラッシュするというトラブルがあり、最終的に AC-1 だけを実装した最小限の SSP が出力された段階で打ち切られていました。Dave さん自身が「Claude のような AI を使うのは非決定的なプロセスで、毎回違うアプローチで問題を解こうとする」と注釈していたとおり、AI 連携の現状の限界もそのまま見えた回でした。

CI/CD と SARIF — GitHub の Code Scanning に OSCAL の検証結果を載せる

Claude のデモが回っている裏で、Dave さんはもう一つ別の仕組みを紹介していました。OSCAL CLI を GitHub Actions の中で動かして、検証結果を SARIF（Static Analysis Results Interchange Format、静的解析結果交換フォーマット）で書き出し、GitHub の Code Scanning にアップロードする、という連携です⁶。

SARIF は OASIS で標準化された JSON ベースのフォーマットで、静的解析ツールの出力を統一して扱うために作られました。GitHub Code Scanning は SARIF 2.1.0 をネイティブにサポートしており、SARIF ファイルを上げるとリポジトリの Security タブやプルリクエストの差分にアラートとして表示され、コードのどの行が問題かをアノテーションとして示してくれます。本来は脆弱性スキャンやリンタの結果を扱うものですが、Dave さんはこれを OSCAL コンテンツの検証エラーに転用していました。

仕組み自体は素直で、リポジトリへのコミットごとに GitHub Actions が OSCAL CLI を呼んで全コンテンツを検証し、結果を SARIF で吐き、github/codeql-action/upload-sarif 相当の経路で Code Scanning に投げる、という流れです。OSCAL CLI の SARIF 出力にはエラー箇所の文脈情報が含まれているので、GitHub 側で「この YAML ファイルのこの行で OSCAL の検証が落ちている」という形まで分かるようになっています。issues として開いたり、解決の経過を時系列で追ったりという、Code Scanning が普段やっていることをそのまま OSCAL の検証エラーに対しても効かせられる、というのが利点でした。

OSCAL を GitHub に置いて運用したい組織にとっては、これだけでもうれしい変化です。コンテンツ更新の品質ゲートが、専用の OSCAL ツールではなく GitHub のセキュリティ機能の上に乗るので、レビュアー側の学習コストが要りません。

OSCAL コミュニティの中での位置づけ

OSCAL Hub を、ここ数か月の OSCAL コミュニティの動きの中に置き直してみると、いくつかのことが見えてきます。

一つは、OSCAL 周辺のプロダクトの実装者が、NIST から商用ベンダーや独立 OSS 組織に分散してきていることです。Dave さんが NIST から RegScale に移って metaschema-framework/oscal-cli を続け、その成果が OSCAL Hub に組み込まれ、Claude プラグインも CC0 で別途公開される。この2か月後（2026年4月）に OSCAL Foundation が発表する「FedRAMP の OSCAL 化を業界主導で進める」という方針とも地続きで、仕様策定だけでなくツール開発のレイヤでも、コミュニティと商用ベンダーが NIST と並走する体制が組み上がっていく流れが見えます。

そして OSCAL Foundation への寄贈という選択は、この流れをさらに固めるものでした。RegScale が単独で持ち続けるよりも、Foundation 経由でガバナンスを中立にしておくほうが、他ベンダーや連邦機関にとって採用しやすい、という判断です。pip install のように OSCAL コンテンツを取りに行ける状態を本気で作るなら、その配布場所が特定企業に紐づいていない必要があります。

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

米国側では、FedRAMP（Federal Risk and Authorization Management Program、米連邦政府向けクラウドのセキュリティ認可制度）が機械可読パッケージへの移行を法律と政府方針の両方で固めつつあります。OMB Memorandum M-24-15（行政管理予算局通達 M-24-15、2024年7月）⁷ が機械可読化のデッドラインを設定し、FedRAMP PMO（Program Management Office、プログラム管理事務局）は2026年1月13日に RFC 0024「FedRAMP Rev 5 Machine-Readable Packages」⁸ を出して、Rev 5（NIST SP 800-53 Revision 5 ベースの従来型認可プロセス）の事業者にも OSCAL を含む承認済みフォーマットでの提出を求める方針を示しました。猶予期間は2027年9月30日までで、それまでに対応できない事業者は FedRAMP 認証を失う、という建て付けです。

ここで難しいのは、Rev 5 のパスに残る事業者の多くが、OSCAL ファイルを作るだけでもツールチェーンに苦戦していることです。AWS のような大手でも社内では同じ問題に直面していたことが、これまでの workshop の発表からも伝わってきています。OSCAL Hub の Web GUI と API は、まさにこの「Rev 5 を OSCAL で出さないといけないが、自社で全部書く余力はない」という現場に届くツールセットになり得ます。レビュー側、つまり連邦機関の Authorizing Official（認可責任者）が OSCAL パッケージを読み込んで判断するときも、テキストエディタで生の JSON を読むより GUI で構造を眺めるほうが現実的です。プレスリリースで言及されていた「最大85%のレビュー時間削減」⁴ という数字は、この双方の現場に効く想定です。

Claude プラグイン側は別軸の話で、こちらは AI を使った OSCAL 作成のレイヤを補強します。OSCAL CLI が CI/CD で動き、Claude が会話の中で OSCAL ファイルを生成・修正し、Code Scanning に検証結果が積まれていく、という GitHub 上で完結する OSCAL の開発体験は、SSP やプロファイルを「ソフトウェアとして」扱う土壌が整いつつあることを示しています。

日本から見たとき

コンプライアンス文書を「機械可読データに変換する話」と「GUI で扱える状態にする話」は、別々に考えたほうが整理しやすいです。ISMS 文書や政府情報システム統一基準を OSCAL か類似モデルに移すことは技術的には可能ですが、現場で動くかはその先に GUI や API があるかにかかります。OSCAL Hub は Web・CLI・API の複数経路を最初から揃えており、機械可読化を実務に着地させるときの参考になります。

Dave さんの Claude プラグインのデモで印象的だったのは、AI に OSCAL を自力で解釈させず、OSCAL CLI を呼ばせて結果を読ませる分担です。形式の厳しいフォーマットを AI 単体に書かせるとほぼ必ず失敗しますが、CLI の検証を挟めば AI 自身が失敗に気づけます。日本の現場でも、検証 CLI と Claude プラグイン（または MCP サーバ）をペアで揃えておく設計は筋が通ります。

RegScale は商用 GRC ベンダーですが、OSCAL Hub を OSCAL Foundation に寄贈し、商用製品とは別の場所に置きました。業界共通の課題向けの土台を、自社で抱え続けず中立な団体に渡してエコシステムを動かす、というやり方は、コンプライアンス以外でも参考になるはずです。

OSCAL Hub はまだ alpha とされており、Travis さん自身が「proof-of-concept レベル」と何度も断っていましたが、それでも GUI、API、CLI、AI 連携と、必要そうな経路が一通り揃った形で公開されているのは、OSCAL を実務で扱う側にとって心強い動きでした。

参考文献

NIST OSCAL Monthly Workshop #40, RegScale 回トランスクリプト（英語）。https://csrc.nist.gov/csrc/media/Projects/open-security-controls-assessment-language/images-media/2026/oscal-monthly-workshop-40-RegScale/CAPTIONS_02.18.2026_RegScale.txt ↩
NIST OSCAL Monthly Workshop #40, RegScale 回スライド PDF「Meet OSCAL Hub」。https://csrc.nist.gov/csrc/media/Projects/open-security-controls-assessment-language/images-media/2026/oscal-monthly-workshop-40-RegScale/02.18.2026_OSCAL_Hub.pdf ↩
RegScale ブログ「Introducing OSCAL Hub: The Industry Standard for Easier Authorization」2025年12月15日。https://regscale.com/blog/introducing-oscal-hub/ ↩
RegScale プレスリリース「RegScale Donates Open-Source OSCAL Hub to the OSCAL Foundation to Accelerate the Automation of Security Compliance Across Public and Private Sectors」Business Wire、2025年12月16日。https://www.businesswire.com/news/home/20251216876546/en/ ↩ ↩²
Anthropic Claude Code Docs「Extend Claude with skills」。https://docs.anthropic.com/en/docs/claude-code/skills ↩
GitHub Docs「About SARIF files for code scanning」。SARIF 2.1.0 のサブセットを Code Scanning がネイティブに扱う仕様を確認できる。https://docs.github.com/en/code-security/concepts/code-scanning/sarif-files ↩
OMB Memorandum M-24-15「Modernizing the Federal Risk and Authorization Management Program (FedRAMP)」2024年7月25日。https://www.fedramp.gov/docs/authority/m-24-15/ ↩
FedRAMP RFC 0024「FedRAMP Rev 5 Machine-Readable Packages」2026年1月13日公開、コメント募集は2026年3月11日まで。https://github.com/FedRAMP/community/discussions/114 ↩

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