# AI BOMとは — Model・Data・Containerの依存関係を追跡する

> AI BOMとML-BOMの役割、SBOMやModel Cardとの違い、Model・Data・Runtimeを本番環境まで追跡するための生成・保管・差分確認を整理します。

Canonical URL: https://labs.eastbraver.com/guides/ai-bom
Published: 2026-07-14
Updated: 2026-07-24
Category: field-guide
Tags: governance, model-ops, safety

AI BOMは、AIシステムを構成するModel・Data・Software・Runtimeと、その関係を機械可読な形で記録するBill of Materialsです。**採用予定ではなく、承認した構成と実際に動いた構成を比べられる状態にする。** ここまでつながって、運用で使える棚卸しになります。

「本番で使っているModelは何ですか」と聞かれて、Repositoryの設定だけを見ても答えきれないことがあります。

Applicationが指定したModel、実際に読み込まれたWeight、推論Runtime、Container image、接続先のVector Database。更新場所が分かれるほど、障害や脆弱性が見つかったときに「どこまで影響するか」を追いにくくなります。

## AI BOMとML-BOMは同じものを指すのか

AI BOMは、AIシステムの構成要素と依存関係を記録する考え方の総称として使われています。Model、Dataset、学習・評価環境、推論Runtime、Agent framework、外部Serviceまで、対象範囲は実装と目的によって変わります。

[CycloneDX](https://cyclonedx.org/capabilities/mlbom/)はMachine Learning Bill of MaterialsをML-BOMと呼び、Modelを中心に、Dataset・Model Card・Framework・License・Provenanceを表現します。CycloneDXでは、ML-BOMのSupportはVersion 1.5以降に含まれています。

[SPDX 3.0.1のAI Profile](https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/)も、AI Software Package、Model、Datasetを記述するための標準化された要素を定義しています。

つまり、AI BOMという名前だけでFormatは決まりません。CycloneDXのML-BOMとSPDXのAI Profileは近い課題を扱いますが、Schemaと表現範囲は同一ではありません。利用中のSBOM・脆弱性管理・監査基盤へ接続できるFormatを選びます。

## SBOM、Model Card、Asset Inventoryとの違い

| 記録 | 主な対象 | 答えたいこと |
| --- | --- | --- |
| SBOM | Package、Library、Container内のSoftware | どのSoftwareとVersionに依存しているか |
| AI BOM / ML-BOM | Model、Dataset、Runtime、Frameworkと関係 | どのAI資産を、どの構成で利用しているか |
| Model Card | Modelの用途、性能、制約、評価結果 | 何に使うModelで、どこに限界があるか |
| Asset Inventory / CMDB | 組織が管理するSystemやResource | 何を所有し、誰が管理しているか |

AI BOMはSBOMの置き換えではありません。推論Containerの脆弱性はSBOMで追い、そのContainerがどのModelとDatasetへつながるかをAI BOMで補います。

Model Cardも同じです。Model Cardが意図した用途や限界を説明しても、本番でどのVersionが動いたかは別の記録になります。

## WebエンジニアにもAI供給網の確認が必要になる

自前でModelを学習していなくても、Web ApplicationはAI供給網の一部になります。

外部のLLM APIを呼ぶ場合でも、Provider、Model ID、Region、Request時の設定、利用したToolやVector StoreはApplication側で選びます。Container上で推論する場合は、Model Weight、Tokenizer、Serving Runtime、GPU向けLibraryまで依存物が増えます。

棚卸しがないと、次の確認で止まります。

- 特定のModelやContainer imageに問題が見つかったとき、影響するServiceを探せない
- Modelの切り替えが承認済みの変更か、Runtime上のDriftかを分けられない
- Licenseや利用条件が変わったとき、どこで利用しているか分からない
- 障害時のTraceから、実行時のModel・Runtime・Data sourceへ戻れない
- 廃止したはずのModelやAgent frameworkが残っていても気付けない

[LLM](/guides/llm)と、それを利用するSystem全体は別のものです。AI BOMが扱うのは、Model単体の能力ではなく、そのModelを本番で動かすために組み合わされた依存関係です。

## 記録する要素は「識別子」と「根拠」を分ける

AI BOMへ入れる項目は、利用する標準とSystemによって変わります。ただ、名前の一覧だけでは差分確認に使えません。

| 要素 | 記録例 | 確認したい点 |
| --- | --- | --- |
| 対象System | Service、Environment、Owner、Deployment ID | どの本番処理に使われたか |
| Model | Provider、Model ID、Version、Digest、PURL | 同じModelを再識別できるか |
| Data | Dataset、評価Data、Vector Store、取得元 | どのDataへ依存したか |
| Runtime | Container digest、Serving Runtime、Framework | 何がModelを実行したか |
| 関係 | 学習元、派生Model、Service接続、Dependency | 構成要素をどの経路で利用したか |
| Policy情報 | License、用途、既知の制約、承認状態 | 利用条件に合っているか |
| Evidence | Manifest、Image metadata、設定値、観測時刻 | その値をどこから得たか |

特に分けたいのが、値とEvidenceです。

`Model: example/model-v2`と書いてあっても、Deployment manifestで宣言された値なのか、Container imageから推定した値なのかで確度が違います。取得できなかった項目を空欄へ埋めるより、`unresolved`として残した方が監査と調査に使えます。

## Build時、承認時、Runtime時の三つを比べる

AI BOMは一度生成して保管すれば終わり、ではありません。

### Build時の記録

Repository、Lockfile、Container image、Model artifactから、作る予定の構成を記録します。再現しやすい一方、動的に取得されたModelや本番で差し替わった接続先までは分かりません。

### 承認時の記録

本番へ出してよいModel、Container digest、Data source、外部ServiceをBaselineとして残します。Change RequestやDeployment IDと結び付けると、誰が何を承認したか追いやすくなります。

### Runtime時の記録

実際に動いているWorkloadを観測します。動的取得と設定Driftを拾える反面、観測だけでは人が宣言した値とToolが推定した値を区別できない場合があります。

### Declared BOMとObserved BOMの照合

Build evidenceからDeclared BOMを作り、Runtime evidenceからObserved BOMを取得します。両者をApproved baselineと比較した結果をDeploy gate、Review、History、Incident responseへ利用します。

- Build evidenceからDeclared BOMを作成します。
- Runtime evidenceからObserved BOMを作成します。
- Declared BOMとObserved BOMをApproved baselineへ照合します。
- 比較結果をDeploy gate、Review、History、Incident responseへ渡します。

*build時の宣言とruntime観測をbaselineへ照合する構成*

Build時のBOMとRuntime時のBOMは競合するものではありません。**作るつもりだった構成、承認した構成、実際に動いた構成を差分で見る。** これが基本になります。

## k8s-aibomが示したRuntime観測

Google Cloudは2026年7月14日、[k8s-aibom](https://cloud.google.com/blog/products/identity-security/introducing-k8s-aibom-on-gke-for-automated-ai-bills-of-materials/)をOpen Sourceとして公開しました。

[k8s-aibomのRepository](https://github.com/GoogleCloudPlatform/k8s-aibom)では、Kubernetes APIを監視する単一の非特権Controllerとして実装されています。DaemonSet、eBPF、Kernel access、既存PodへのSidecar追加を使わず、推論Service、Agent stack、RAG基盤、学習Job、評価Harnessを検出し、CycloneDX 1.6 ML-BOMを生成します。

検出値には、次のConfidenceが付きます。

- `declared`: Workload設定やAnnotationへ明示された値
- `inferred`: Container imageや引数のPatternから推定した値
- `unresolved`: 存在は検出したが、値を確定できなかったもの

BOMはCluster内の`AIBOM` Custom Resourceへ保存でき、任意でGoogle Cloud StorageやWebhookへ出力します。外部Storageへの書き込みでは、同じObjectを上書きしないPreconditionを使い、過去の記録を後から置き換えにくくしています。

ただし、2026年7月14日時点のRepositoryは`v1.0`のalphaです。非Criticalな観測用途を対象とし、GoogleがBuild済みContainer imageやHelm repositoryを提供する正式Support製品でもありません。推定値を事実として扱わず、導入前に検出範囲、権限、出力先、失敗時の挙動を確認します。

また、Runtime観測で見えるのは、観測できる範囲だけです。Managed APIの内部Weightや非公開の学習Dataまで、Application側のAI BOMが証明できるわけではありません。分からないものは、Provider管理の外部Serviceとして境界を残します。

## 既存の運用へどう接続するか

AI BOMを別の管理画面へ置くだけでは、更新されなくなる気がしています。既存の変更管理と障害対応へつなぐ方が扱いやすいです。

### CI/CDとDeployment承認

Build時に生成したBOMをArtifactとして保存し、承認済みBaselineとの差分をDeployment前に確認します。Model、Container digest、外部Providerが変わったときだけ、人へReviewを戻します。

### SBOMと脆弱性管理

ContainerとLibraryはSBOMで管理し、ModelやDatasetとのRelationshipをAI BOMで結びます。CVEだけでなく、Modelの公開停止、License変更、危険なArtifactの判定も影響範囲へ反映します。

### TraceとIncident response

Deployment IDやBOMの識別子を[ObservabilityとTrace](/guides/observability-tracing)へ結び付けます。あるRequestで何が起きたか調べるとき、回答内容だけでなく、その時点のModelとRuntime構成へ戻れるようにします。

### Identityと書き込み権限

BOMを書き込む主体と、参照・承認する主体を分けます。[IdentityとAuthorization](/guides/ai-identity-authorization)の境界を使い、Application Workloadが過去の監査記録を上書きできない権限にします。

## よくある誤解

### AI BOMがあれば安全性を証明できる

BOMは構成とEvidenceを記録するものです。Modelの出力品質、安全性、Compliance適合を自動的に証明しません。[AI Agent評価](/guides/ai-agent-evaluation)やPolicy確認と組み合わせます。

### Model名だけ記録すればよい

同じModel名でも、Revision、Quantization、Tokenizer、Runtime、推論設定が違えば挙動は変わり得ます。取得可能な識別子と実行条件を残します。

### Runtime scannerの推定は事実として扱える

推定には誤検出と未検出があります。宣言値、観測値、推定値を同じ欄へ混ぜず、EvidenceとConfidenceを残します。

### AI BOMはSBOMを置き換える

AI BOMだけでは、OS PackageやLibraryの脆弱性管理が薄くなります。SBOMを残し、Model・Data・Runtimeとの関係を追加します。

### 一度作れば監査資料になる

更新されないBOMは、過去の意図を示すだけです。生成時刻、対象Environment、Deploymentとの対応を残し、差分を継続して追います。

## EastBraver Labsの判断基準

EastBraver Labsでは、AI BOMを作ること自体をGoalにしません。

**「何が変わったか」「どのServiceへ影響するか」「その値を何から確認したか」へ戻れること**を、導入判断の基準にします。

最初から全項目を埋めるより、次の最小構成から始めます。

- Service、Environment、Owner、Deployment ID
- Provider、Model ID、取得できるVersionまたはDigest
- Container digest、Runtime、外部Data source
- 宣言・観測・推定・未解決の区別
- 生成元、生成時刻、保管先

そのうえで、Build時とRuntime時の差分を自動で出します。Criticalな処理で`unresolved`が増えた場合は、そのまま通さず人へ戻す。新しいModelへ切り替わった場合も、性能評価だけでなくLicense・Data境界・Rollbackを確認します。

Tool選定では、対応Formatの多さより、Evidenceを追えるか、既存のSBOMと接続できるか、書き込み権限を狭くできるか、生成失敗を検知できるかを見ます。

BOMをきれいに作れても、本番と結び付かなければ事故調査では使えません。まずは一つのServiceで、承認した構成と実際の構成を比べられるところから始めるのがよいと思います。

## 関連記事

- [モデル選定とエージェント運用が接続 - AIダイジェスト 20260714](/digest/ai-digest-20260714)

## 検証範囲

- 一次情報: 公式ドキュメント / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開