AI Bill of Materials:実際に稼働しているものを追跡する
Tech
AI
AI Engineering
Supply Chain Security
MLOps

AI Bill of Materials:実際に稼働しているものを追跡する

モデル、データセット、API、エージェントツール、未解決の依存関係を対象とした、実用的なビルド時およびランタイムのインベントリ。

Uygar DuzgunUUygar Duzgun
Jul 28, 2026
更新日 2026年8月12日
18 min read

AI Bill of Materialsが役立つのは、2つの質問に答えられる場合だけです。デプロイ前に何が宣言されていたのか、そして意思決定、インシデント、監査が発生した時点で実際に何が稼働していたのか。両方に答えられない有効なJSONファイルは、インベントリの体裁だけを整えたものにすぎません。

実用的な設計は、対になったインベントリです。ビルドまたは調達時に標準ベースの記録を生成し、ランタイムでライブシステムを観測し、各フィールドの証拠を保持して、両者を差分比較します。重要なモデル、データセット、ランタイム、API、エージェントツール、ライセンスが未解決の場合は、リリースをブロックします。

読者レベル: 上級者向け。本ガイドは、モデルを利用するシステムを運用するエンジニア、セキュリティチーム、プラットフォーム所有者、技術ガバナンス責任者を対象としています。

目次

AI Bill of Materialsが答えるべきこと

AI Bill of Materialsは、通常AIBOMまたはAI BOMと略され、AIシステムを構成するコンポーネントと、その背後にある証拠を機械可読形式でまとめたインベントリです。従来のSoftware Bill of Materialsを、パッケージやライブラリの範囲を超えて拡張します。

インベントリによって、レビュー担当者は次の質問に答えられるようにすべきです。

リクエストを処理したモデルと不変のリビジョンは何か?
どのトークナイザー、アダプター、量子化方式、ランタイム、コンテナが関与したか?
どのトレーニング、ファインチューニング、評価、検索用データセットが宣言されているか?
動作に影響を与え得る外部API、エージェントツール、ベクトルストア、モデルゲートウェイは何か?
どのライセンス、利用制限、既知の制約、評価条件が適用されるか?
どの値が署名付きソースに由来し、どれがチームによって宣言され、どれがスキャナーによって推論され、どれが未知のままなのか?
承認済みビルドとライブデプロイメントの間で何が変わったか?

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ワークフロー
ビルド時の意図からランタイム観測、意味的検証、バージョン管理された差分、リリース判断までを示すAI Bill of Materialsワークフロー

_有用な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は、エンジニアリング、セキュリティ、監査担当者、顧客、自動化システムの間で共有される可能性があります。秘密の保管庫ではなく、インベントリとして扱ってください。

次のものを含めてはいけません。

APIキー、トークン、パスワード、接続文字列、秘密の署名マテリアル;
個人データを含む生のプロンプト、顧客との会話、取得文書、トレーニング例;
攻撃対象領域を広げる、制限のない内部URLやネットワーク詳細;
管理された文書IDとハッシュで代替できる、非公開の契約本文;
背後にある証拠よりも情報量の少ない、曖昧な保証ラベル。

シークレットは値を含めず、シークレットマネージャーのパスまたは論理識別子で参照します。機密データセットは、管理されたカタログ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つ目を追加します。

主張の確認

測定結果: 2026年7月の研究では、ダウンロード数が100を超える公開Hugging Faceモデルから97,940件のAIBOM成果物を生成・分析しました。
測定結果: 必須の構造フィールドは100%のカバレッジに達した一方、モデルカードの文書化率は平均19.51%でした。
測定結果: プレースホルダーの内容を超える意味のある説明を含んでいた成果物は、211件、つまり0.22%だけでした。
測定結果: 技術的制約は生成された成果物の16.74%に、安全性リスク評価は9.76%に存在しました。
公式プロジェクトの主張: k8s-aibomはKubernetesワークロードを観測し、フィールド単位の証拠ステータスを持つCycloneDX 1.6 ML-BOMレコードを出力します。
公式プロジェクトの制限: k8s-aibom v1.0はアルファ版で、非クリティカルな観測用途を対象としており、現在はアイデンティティを暗号学的に検証済みとはマークしません。
標準の確認: CycloneDXはAI/ML-BOMのサポートを文書化しており、SPDX 3.0.1はAI固有のクラスとプロパティを定義しています。
実務上の解釈: ビルド時の宣言とランタイムの観測を組み合わせ、その後、意味とドリフトを検証します。確認した情報源はこのワークフローの構成要素を支持しますが、普遍的な単一のリリースポリシーを証明するものではありません。
確立されていないこと: AIBOM、完全性スコア、署名、ランタイムスキャンだけでは、安全性、合法性、性能、コンプライアンスを証明できません。

Sources

Securing the AI supply chain on GKE: Introducing k8s-aibom for automated AI BOMs — Google Cloud公式リリースノート、2026年7月14日。
GoogleCloudPlatform/k8s-aibom — 公式ソースリポジトリおよび現在の制限。
CycloneDX Machine Learning Bill of Materials — 公式標準ドキュメント。
Authoritative Guide to AI/ML-BOM — 公式CycloneDX実装ガイド、2026年。
SPDX 3.0.1 AI profile — 公式標準ドキュメント。
OWASP AIBOM Generator — 公式オープンソースジェネレーターおよびドキュメント。
Model Cards for Model Reporting — 一次研究、改訂版2019年1月14日。
k8s-aibom and AICR integration — ユーザー投稿による実務者提案、2026年7月15日開始。
SPDX 3.0.1 Dataset profile — 公式標準ドキュメント。