AI Bill of Materialsが役立つのは、2つの質問に答えられる場合だけです。デプロイ前に何が宣言されていたのか、そして意思決定、インシデント、監査が発生した時点で実際に何が稼働していたのか。両方に答えられない有効なJSONファイルは、インベントリの体裁だけを整えたものにすぎません。
実用的な設計は、対になったインベントリです。ビルドまたは調達時に標準ベースの記録を生成し、ランタイムでライブシステムを観測し、各フィールドの証拠を保持して、両者を差分比較します。重要なモデル、データセット、ランタイム、API、エージェントツール、ライセンスが未解決の場合は、リリースをブロックします。
読者レベル: 上級者向け。本ガイドは、モデルを利用するシステムを運用するエンジニア、セキュリティチーム、プラットフォーム所有者、技術ガバナンス責任者を対象としています。
目次
AI Bill of Materialsが答えるべきこと
AI Bill of Materialsは、通常AIBOMまたはAI BOMと略され、AIシステムを構成するコンポーネントと、その背後にある証拠を機械可読形式でまとめたインベントリです。従来のSoftware Bill of Materialsを、パッケージやライブラリの範囲を超えて拡張します。
インベントリによって、レビュー担当者は次の質問に答えられるようにすべきです。
CycloneDXはAI/ML-BOM機能について説明しています。これはモデル、データセット、設定、来歴、依存関係を表現するためのものです。SPDX 3.0.1にもAIプロファイルが定義されています。これらは相互運用可能なデータモデルであり、不足している証拠そのものの代替ではありません。
モデルカードが答えるのは、より限定された質問です。このモデルは何をすることを意図しているのか、どのように評価されたのか、どこで失敗し得るのか、という問いです。元のModel Cards論文は、意図された用途、評価条件、関連するグループ間の性能を含む文書化を提案しました。データカードは、データセットの起源、収集とアノテーション、意図された用途、下流の性能を形作る意思決定を記録します。Data Cards論文では、20件を超えるデプロイメントから得られた知見が報告されています。
両方を維持してください。モデルカードやデータカードは人間向けの文脈を提供します。AIBOMは、それらの文書をバージョン管理されたシステムインベントリに接続します。
有効なAIBOMファイルにも弱い証拠が含まれる理由
2026年7月の研究では、この違いが大規模に検証されました。著者らは、公開されているHugging Faceモデルレコード2,942,466件のスナップショットを収集し、ダウンロード数が100を超える97,940モデルを残して、OWASP AIBOM GeneratorでCycloneDX AIBOMを生成しました。100件の成果物をジェネレーターのレポートと照合し、その後、全セットにおけるフィールドの存在率を測定しました。
報告された平均完全性スコアは100点満点中54.31でした。必須の構造フィールドは、生成された成果物の100%に存在していました。モデルカードの文書化率は平均19.51%でした。
この差が重要な結果です。ファイルは構造的に有効でも、意思決定に必要な情報が欠落している可能性があります。
フィールド単位の結果は、さらに明確でした。
| 生成されたAIBOMのフィールド | 存在率 |
|---|---|
| --- | ---: |
| ライセンス | 73.14% |
| データセット | 39.35% |
| ハイパーパラメーター | 25.40% |
| 技術的制約 | 16.74% |
| 安全性リスク評価 | 9.76% |
| 意味のある説明 | 0.22% |
| エネルギー消費量 | 0.02% |
説明フィールドはほぼすべての成果物に存在しましたが、97,940件の説明のうち、プレースホルダーテキストを超える情報を含んでいたのは211件だけでした。スキーマの存在チェックでは、残りの説明も完全なものとして数えられます。
著者らが測定したこと: フィルタリングされた公開Hugging Faceスナップショットから生成されたAIBOMにおける、フィールドおよびカテゴリのカバレッジ。
著者らが推論したこと: モデルカードと外部参照の文書化が、弱い成果物とより強い成果物の差の大部分を生み出していること。
著者らが明らかにしていないこと: いずれかのモデルが安全、公平、高性能、法的に利用可能、または特定のデプロイメントに適しているかどうか。
著者らはまた、結果がHugging Face API、ジェネレーターの抽出ロジック、そしてダウンロード数が100以下のモデルを除外したスナップショットに依存すると警告しています。プライベートレジストリ、ゲート付きモデル、他のホスティングプラットフォーム、後から行われたリポジトリ変更では、異なる結果になる可能性があります。この結果が支持するのは、意味的な検証です。普遍的なスコア閾値を定めるものではありません。
ビルド時インベントリとランタイムインベントリは異なる問題を解決する
ビルド時AIBOMは意図を記録します。ランタイムインベントリは観測結果を記録します。
| 質問 | ビルド時の証拠 | ランタイムの証拠 |
|---|---|---|
| --- | --- | --- |
| どのモデルを出荷すべきか? | ロックファイル、マニフェスト、調達記録、モデルダイジェスト | ロードされたモデルID、エンドポイント、イメージダイジェスト、サービング設定 |
| どのデータを利用可能にすべきか? | トレーニングおよび評価の宣言、承認済み検索ソース | 接続されたベクトルストア、マウントされたデータセット、ライブデータサービス |
| エージェントが呼び出せるツールは何か? | ツールレジストリ、ポリシー、宣言されたMCPサーバーとAPI | 検出されたエンドポイント、アクティブな統合、観測された設定 |
| 推論を支えるソフトウェアは何か? | パッケージおよびコンテナSBOM | 実行中のイメージ、ランタイム、ドライバー、アクセラレーター |
| どの制限が適用されるか? | ライセンス、モデルカード、データカード、契約参照 | 現在のプロバイダー、リージョン、ルート、ポリシーバージョン |
| 承認済みシステムにドリフトが発生したか? | 比較用のベースライン | ベースラインとの差分比較対象となる証拠 |
ビルド時の証拠だけでは、緊急変更、シャドーデプロイメント、可変タグ、プロバイダーによるルート変更、設定ドリフトを見逃します。ランタイム観測だけでは、承認済みの目的、ライセンス、トレーニングの来歴、評価範囲を知らないまま、プロセス名やエンドポイントだけを確認することがあります。
Googleは2026年7月14日、ランタイム側を検討するためにk8s-aibomをオープンソース化しました。このコントローラーはKubernetesのワークロードとPodの状態を監視し、検出ルールを適用して、CycloneDX 1.6 ML-BOMドキュメントを出力します。文書化された対象範囲には、推論ランタイム、エージェントフレームワーク、ベクトルデータベース、トレーニングジョブ、評価ハーネスが含まれます。特権DaemonSetやカーネルアクセスなしで動作します。
このプロジェクトは、有用なアーキテクチャ上のポイントを示しています。ビルド時AIBOMとランタイムAIBOMは補完関係にあります。一方で、まだ初期段階のソフトウェアです。リポジトリではv1.0をアルファ版、非クリティカルな観測用途に適したものと位置付けています。ホスト型イメージやHelmリポジトリは提供しておらず、現在の`NoopVerifier`はアイデンティティを暗号学的に検証済みとしてマークできません。
NVIDIA AICRのメンテナーは、k8s-aibomとAICRの統合を提案しました。これは、k8s-aibomのランタイム観測を、AICRのデプロイメント意図および署名付きアテステーションに接続するものです。著者は、チームがデプロイしたものとシステムが実行しているものが同一であることを示す証拠を目標として説明しています。このIssueには、実装、担当者、マイルストーンへのリンクはありません。公式ロードマップや完成済みの設計ではなく、実務者による提案として扱ってください。
1つの新しいコントローラーを、普遍的な製品推奨に変えてはいけません。宣言された状態と観測された状態を組み合わせ、証拠を保持し、不確実性を可視化するというパターンを使ってください。

_有用なAI Bill of Materialsは、ビルド時の意図をランタイムの証拠、意味的チェック、バージョン管理された判断に接続します。_
記録する価値のある7つのレイヤー
正確なスキーマは、使用する標準とデプロイメントによって異なります。以下のレイヤーは、本番インベントリにおける実用的な最小構成です。
1. モデルのアイデンティティ
サプライヤー、モデルファミリー、不変のリビジョンまたはダイジェスト、形式、ベースモデル、アダプター、量子化、トークナイザー、サービングルートを記録します。`support-model`のような人間向けのエイリアスは便利ですが、トレーサビリティには不十分です。
外部APIの場合は、プロバイダーの安定したモデル識別子と、それを選択したゲートウェイルートを記録します。プロバイダーがエイリアスの背後にあるモデルを予告なく更新できる場合は、精度を捏造せず、リビジョンを未解決としてラベル付けします。
2. データと検索の依存関係
情報が存在する場合は、宣言されたトレーニング、ファインチューニング、評価、キャリブレーション用データセットを記録します。RAGシステムでは、ソースコレクション、埋め込みモデル、チャンク分割のバージョン、ベクトルストアサービス、アクセス・ポリシー、鮮度の境界を追加します。
データセットの識別子、バージョン、ハッシュ、契約、または管理されたカタログ参照を保存します。生の顧客レコードや非公開のトレーニング例をAIBOMにコピーしてはいけません。
チームがNext.jsとAIエージェントでカスタムデータシステムを構築する→場合、スキーマのバージョン、マイグレーションの境界、接続されたサービスは、モデルの成果物でない場合でもシステムコンテキストに含めるべきです。
3. ランタイムとソフトウェア
AIインベントリを通常のSBOMに接続します。コンテナダイジェスト、推論エンジン、フレームワーク、関連ライブラリ、ドライバーとアクセラレーターのクラス、モデルの挙動を変え得る設定を記録します。
これは重要です。同じ重みでも、トークナイザー、アテンションバックエンド、量子化経路、サービングエンジンが変わると挙動が異なる可能性があります。AIのトークン数が増えるとなぜコンピュート料金が変わるのか→の分析が示すように、デプロイメント記録にはモデル名だけでなく、ランタイムの予算と設定も必要です。
4. ツール、API、エージェント権限
企業内のどこかにインストールされているすべてのツールではなく、エージェントが到達できるツールを列挙します。モデルゲートウェイ、MCPサーバー、ブラウザーまたはコード実行ツール、外部API、各アクションを管理するポリシー参照を含めます。
インベントリは認可を強制しません。決定論的な制御と組み合わせてください。AIエージェントの権限→に関する記事では、モデルの自制はアクセス制御の境界ではない理由を説明しています。
5. 評価と運用上の制限
承認に使用した正確な評価セット、評価器のバージョン、閾値、日付、条件を参照します。既知の失敗モード、意図された用途と除外された用途、フォールバック動作、監視担当者、判断の有効期限を記録します。
テストの識別情報なしに「評価に合格」と書いてはいけません。モデルが変更されたのに結果文字列が変わっていない場合、それは弱い証拠です。
6. 権利、ポリシー、来歴
モデルとデータセットのライセンス、利用制限、再配布条件、ソースリポジトリ、モデルカード、データカード、論文、承認、アテステーションを記録します。ソースがアクセス制御されている場合は、参照とハッシュを保存します。
このレイヤーはレビューを支援します。法的な問題を判断するものではありません。権利情報が欠落または矛盾している場合は、その判断に責任を負う担当者へ回付します。
7. 所有権とライフサイクル
すべてのレコードには、所有者、システムの目的、環境、作成時刻、観測時刻、置き換えられたバージョン、保持ルールが必要です。所有者がいなければ、インベントリは放棄された事実のアーカイブになります。
再デプロイメント後も維持される安定したシステムIDを含めます。バージョン管理されたAIBOMには、何が変わったのか、誰が受け入れたのか、どの証拠がその判断を支えたのかを示す履歴が必要です。
すべての事実に、宣言済み、推論済み、検証済み、未解決のラベルを付ける
AIBOMには、フィールド単位で証拠の状態を持たせるべきです。文書全体に1つのラベルだけを付けると、多くの情報が隠れてしまいます。
最初の3つのラベルは、証拠の強さが異なることを示します。「宣言済み」は「検証済み」の弱い表記ではありません。トレーニングデータについてはサプライヤーの宣言が唯一利用可能な情報源である場合があります。一方、イメージダイジェストは機械的に検証できます。
k8s-aibomプロジェクトは現在、`declared`、`inferred`、`unresolved`を実装し、属性に対する証拠ロケーターを備えています。READMEでは、暗号学的な`verified`状態を現在提供しているとは主張せず、ロードマップ上の項目としています。自分のシステムでも、この正直さを維持してください。
概念的なレコードは次のようになります。
{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }
これは設計スケッチであり、準拠したCycloneDXまたはSPDXドキュメントではありません。実際の成果物には、選択した標準のスキーマとバリデーターを使用してください。
再現可能なAIBOMワークフロー
ステップ1:システム境界を定義する
対象となるアプリケーション、環境、所有者、ユーザー向けの意思決定を明示します。インベントリが1つのモデルエンドポイント、エージェントワークフロー、完全なプロダクトのいずれを対象とするのかを決めます。
「すべてのAI」のような境界はテストできません。「本番サポートエージェントと、その回答またはアクションを変更できるすべてのサービス」であれば可能です。
ステップ2:ビルドおよび調達の証拠を収集する
通常のSBOMを生成し、モデルとデータセットの識別子を解決し、不変のダイジェストを取得して、モデルカード、データカード、ライセンス、評価、承認をリンクします。
OWASP AIBOM Generatorは、Hugging FaceのメタデータをCycloneDX 1.6に抽出し、不足フィールドを報告できます。出力は初期インベントリとして扱ってください。大規模研究が示すように、自動入力されたフィールドにも内容のチェックが必要です。
ステップ3:標準ドキュメントを出力する
利用者が解析できる形式を選びます。CycloneDXはAI/ML-BOM機能と実装ガイドを提供しています。SPDX 3はAIおよびデータセットプロファイルを提供しています。
形式の選択は、受け取り側のシステム、ポリシーエンジン、アテステーションパイプライン、顧客要件に従うべきです。実際の利用者が両方を必要としない限り、2つの形式を維持するのは避けてください。
ステップ4:自動化では把握できない情報を補完する
意図された用途、制約、データセットの来歴、評価条件、権利、リスク判断を埋める担当者を割り当てます。意思決定に重要なフィールドでは、「N/A」「標準モデル」「マーケティング文のコピー」のようなプレースホルダーを拒否します。
未知の値には明示的な理由を求めます。「サプライヤーがトレーニングデータを開示していない」は、空の配列よりも優れた証拠です。これは、作業不足と利用できない情報を区別できるためです。
ステップ5:ライブデプロイメントを観測する
利用可能な最小権限の仕組みを通じて、ランタイムのモデルID、イメージダイジェスト、エンドポイント、接続されたストア、エージェントツール、設定を収集します。KubernetesではAPIを監視するコントローラー、マネージドAPIスタックではゲートウェイ設定、デプロイメントマニフェスト、プロバイダーのレスポンス、監査ログが利用できる場合があります。
スキャナーが文字列を照合しただけなのに、ランタイム検証済みと主張してはいけません。推論済みとしてマークし、照合に使った証拠を保持します。
ステップ6:構文、意味、ドリフトを検証する
3つのチェックを分けて実行します。
最初のチェックは自動化できます。2つ目にはドメインルールが必要で、一部のフィールドでは人によるレビューも必要です。3つ目には、バージョン管理されたレコードと安定した比較境界が必要です。
ステップ7:署名、保存、差分比較、有効期限設定を行う
成果物をハッシュ化し、ビルドまたはデプロイメントに結び付け、追記専用または管理された証拠システムに保存し、人間が読める差分を生成します。AIBoMGenは、トレーニング中にモデルと環境の取得をハッシュ、署名、in-totoアテステーションと組み合わせる研究プロトタイプの1つです。
署名は作成後の完全性を保護します。完全でない、または虚偽の宣言を真実に変えるものではありません。
有効期限またはレビュー日を設定します。前四半期の完全なインベントリは、今日の可変的な本番システムを説明しません。
インベントリをリリースゲートに変える
インベントリは、意思決定を変えるときに役立ちます。リリース期間の前にポリシーを定義してください。
| 条件 | デフォルトのアクション | 理由 |
|---|---|---|
| --- | --- | --- |
| 重要なモデルまたはランタイムのアイデンティティが未解決 | ブロック | デプロイされたコンポーネントを追跡できない |
| ランタイムに未宣言のモデル、API、ツール、データストアが存在 | ブロックして調査 | 承認済みの境界からドリフトしている |
| モデルのリビジョンが変わったが、評価参照が変わっていない | ブロック | 承認の証拠が候補を対象としていない |
| 必須ライセンスまたは利用制限が欠落 | 責任者によるレビューへ回付。ポリシーで必要な場合はブロック | 権利は利用可能であることから推論できない |
| ヒューリスティックによる推論が宣言と矛盾 | 証拠をブロックまたは隔離 | 少なくとも一方の情報源が誤っているか古い |
| 重要でない説明に詳細がない | 期限付きの是正項目を作成 | その欠落はサービス停止を正当化しない可能性がある |
| 観測時刻が変わっただけでAIBOMが変更 | 許可 | 重要なシステムドリフトは発生していない |
システムに合わせて重大度を調整します。文章作成アシスタントと医療上の意思決定ツールに、同じ普遍的な閾値を適用すべきではありません。
次の4つの運用指標を追跡します。
入力済みフィールド数を最適化してはいけません。それでは、完全性研究が明らかにした問題をそのまま再現することになります。
同じシステム原則は、コードエージェントの活動とインフラストラクチャ→の分析にも現れています。モデルの能力は、デプロイされたシステムの一部にすぎません。ユーザーが実際に受け取るものを決めるのは、ランタイム、ツール、ルーティング、運用上の制御です。
シークレットと個人データを除外する
AIBOMは、エンジニアリング、セキュリティ、監査担当者、顧客、自動化システムの間で共有される可能性があります。秘密の保管庫ではなく、インベントリとして扱ってください。
次のものを含めてはいけません。
シークレットは値を含めず、シークレットマネージャーのパスまたは論理識別子で参照します。機密データセットは、管理されたカタログID、バージョン、分類、所有者、完全性ハッシュで参照します。メタデータさえ機密である場合は、成果物全体にアクセス制御を適用します。
AIBOMで証明できないこと
AI Bill of Materialsはトレーサビリティを向上させます。しかし、次のことを証明するものではありません。
7月の完全性研究が測定したのは、モデルの品質ではなく文書化のカバレッジです。k8s-aibomリポジトリも、その出力がコンプライアンスを証明するものではないと明示しています。どちらの制限も重要です。
AIBOMは、意思決定から検査可能な証拠へ移動するための地図として使用してください。評価、認可、監視、インシデント対応、プライバシー管理、責任あるレビューと組み合わせます。地図があれば、各レビュー担当者がどのシステムを評価しているのかが分かるため、これらのプロセスを迅速化できます。
よくある質問
AI Bill of Materialsとは何ですか?
AI Bill of Materialsは、AIシステムを構成するモデル、データセット、ソフトウェア、ランタイム、ツール、来歴、制限、証拠を機械可読形式でまとめたインベントリです。有用なAIBOMは、不変のバージョン、所有者、未解決の事実、承認済み状態とライブ状態の間の変更を特定します。
AI BOMはSBOMと同じですか?
いいえ。SBOMはソフトウェアコンポーネントと依存関係をインベントリ化します。AI BOMは、そのソフトウェアインベントリを、モデル、データセット、アダプター、評価、意図された用途、制約、ランタイムルートなどのAI固有のコンポーネントに接続します。本番AIシステムには通常、両方が必要です。
AIBOMにはCycloneDXとSPDXのどちらを使うべきですか?
下流のツールと証拠の利用者がサポートする形式を使用してください。CycloneDXには文書化されたAI/ML-BOM機能があり、SPDX 3にはAIおよびデータセットのプロファイルがあります。まず1つの正規形式を検証してください。ポリシー、顧客、統合が必要とする場合にのみ、2つ目を追加します。
