AIBOM（AI Bill of Materials）入門—AIシステムの部品表を作るべき理由

AIBOM（AI Bill of Materials）は、AIシステムを構成するモデル・データ・ツール・プロンプト・依存ライブラリを一覧化する「部品表」だ。SBOMが脆弱性管理の起点になったように、AIBOMはAIガバナンス・コンプライアンス・インシデント対応の起点になる。本記事ではAIBOMが必要になる背景、SBOMとの違い、CycloneDX-AI のサンプル構造、実装上の責任分担、そして「最小から始めて段階的に育てる」現実的な始めかたを解説する。

1. なぜ今、AIBOM なのか

ChatGPT 登場以降、現場には「自分たちが何を使っているのか把握できていない」AI システムが急増した。

RAG に使う Embedding モデルが OpenAI から Cohere に変わったが、誰も気づいていない
エージェントが呼ぶ MCP ツールに、開発時のテスト用エンドポイントが残ったまま本番稼働している
ChatGPT API を内部から呼んでいる業務スクリプトが 30 本以上あるが、台帳がない
カスタマーサポートが Claude を、営業が Gemini を、企画が ChatGPT を、それぞれ法人契約も無く使っている

これらは個別には小さく見えるが、組み合わさると次の事態を招く：

インシデント時の影響範囲が特定できない（特定モデルの脆弱性が公表されても、自社のどこで使っているか分からない）
規制対応で「使用モデル一覧」を求められても出せない（EU AI Act・ISO 42001 では当たり前に要求される）
アップデート / EoL に気づけない（古いモデル・古いプロンプト・古いツールを使い続け、品質劣化に気づかない）
シャドー AI の正体が見えない（正規の利用と無許可利用を区別する基準が存在しない）

AIBOM はこれらの根本問題を、構造化された 1 つの台帳で解く。

2. SBOM との違い

ソフトウェアの SBOM（Software Bill of Materials）は、ライブラリ・依存パッケージ・ライセンス情報を記録する。CycloneDX や SPDX が代表的フォーマットで、Log4Shell（2021）以降は事実上の業界標準となった。

AIBOM はその AI 拡張版だが、追跡対象が大きく異なる：

項目	SBOM	AIBOM
主対象	コードライブラリ	モデル・データ・プロンプト
変動頻度	リリース単位（月次〜）	日次・時間単位（モデル微調整、プロンプト変更）
ライセンス	OSS ライセンス	モデルライセンス＋データライセンス＋利用規約
脆弱性	CVE と紐付け	プロンプトインジェクション・データ汚染・モデル中毒
影響評価	関数呼び出しグラフ	データフロー＋意味的影響

SBOM が「静的構成の証跡」なら、AIBOM は「動的構成と意思決定の証跡」と表現したほうが近い。

3. AIBOM に含めるべき項目

最低限、次のカテゴリを構造化して保持する：

モデル

名称、バージョン、提供者（OpenAI / Anthropic / 自社ファインチューン等）
ライセンス、商用利用可否、データ学習利用の有無
ホスティング先（API / オンプレ / 法人テナント）
入出力経路（どのアプリ・エージェントから呼ばれているか）

データ

学習データ・RAG データの出所（社内 DB / 公開 Web / 第三者購入）
利用目的とユーザー同意の取得状況
最終更新日、更新トリガー
PII 含有の有無、匿名化の有無

プロンプト

システムプロンプト全文（バージョン管理）
ユーザープロンプトのテンプレート
変更履歴と承認者

ツール / MCP サーバー

ツール名、提供者、エンドポイント
それぞれの権限スコープと、呼び出すエージェントの一覧
副作用（読み取り / 書き込み / 送信）の分類

依存

ベクトル DB、Embedding モデル、ガードレール製品、観測ツール
それぞれのバージョン・契約状況

4. CycloneDX-AI のサンプル構造

CycloneDX はバージョン 1.5（2023 年）で machine-learning-model コンポーネント型とモデルカード（ML-BOM）を正式サポートし、AI 拡張がスタンダード化した。現行の 1.6 でもそのまま利用できる。最小例：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-31T10:00:00Z",
    "component": {
      "type": "application",
      "name": "customer-support-bot",
      "version": "2.4.1"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model:claude-sonnet-4-5",
      "name": "Claude Sonnet 4.5",
      "version": "claude-sonnet-4-5",
      "supplier": { "name": "Anthropic" },
      "licenses": [{ "license": { "name": "Anthropic Commercial Terms" } }],
      "modelCard": {
        "modelParameters": {
          "task": "text-generation",
          "architectureFamily": "transformer"
        },
        "considerations": {
          "useCases": ["customer-support"],
          "limitations": ["no medical advice", "no legal advice"]
        }
      }
    },
    {
      "type": "data",
      "bom-ref": "data:faq-knowledge-base",
      "name": "Customer FAQ Knowledge Base",
      "description": "RAG用ナレッジベース。社内FAQから抽出。",
      "data": [{
        "type": "dataset",
        "name": "faq-2026q1",
        "classification": "internal",
        "governance": {
          "owners": [{ "organization": { "name": "Customer Success Team" } }]
        }
      }]
    }
  ],
  "dependencies": [
    {
      "ref": "customer-support-bot",
      "dependsOn": ["model:claude-sonnet-4-5", "data:faq-knowledge-base"]
    }
  ]
}

これを各アプリ・エージェント単位で持ち、SBOM と同じリポジトリ構造（バージョン管理、CI で検証）に乗せる。

5. シャドー AI 検出との関係

AIBOM が整備されると、自動的にこう定式化できる：

AIBOM に登録されていない AI 利用 = シャドー AI

ネットワークログ・プロキシログ・API 利用ログから検出された LLM アクセスを、AIBOM の登録済みエントリと突合する。差分がシャドー AI として浮かび上がる。これが AI-SPM（AI Security Posture Management）の基盤となる。

逆に言えば、AIBOM が無い組織でシャドー AI 対策を語っても、何が「正規」で何が「シャドー」かを区別する基準が存在しない。順番として AIBOM が先。

6. 責任分担モデル

AIBOM を「誰が作って、誰が維持するか」を決めないと、形骸化する。AITB の推奨は：

役割	責任範囲
プロダクトオーナー	自プロダクトの AIBOM エントリの作成・維持
AI ガバナンスチーム	フォーマットの標準化、全社 AIBOM の集約
セキュリティチーム	AIBOM とインシデント対応プロセスの接続
法務・コンプラ	ライセンス・規制適合性のレビュー
開発リード	変更時の AIBOM 更新を CI に組み込む

CI で「AIBOM が更新されていない PR をブロック」する運用が、最も持続する。

7. 段階的な始めかた

完璧な AIBOM を最初から作る必要はない。次の順序が現実的：

業務利用 LLM サービスの一覧化（ChatGPT / Claude / Gemini / Copilot 等）── 1 週目
自社プロダクトに組み込んだ AI 機能の棚卸し── 2 週目
RAG で参照しているデータソースの一覧化── 3 週目
エージェントが呼ぶツール・MCP サーバーの一覧化── 4 週目
CycloneDX-AI 形式で構造化、Git リポジトリへ移行── 2 ヶ月目
CI / CD への組み込み（PR でブロック）── 3 ヶ月目
AI-SPM ツールでの自動差分検出（シャドー AI 検出）── 4 ヶ月目以降

「やる気のある一人」が Week 1〜2 を進めるだけで、組織の見え方が一変する。

8. AIBOM が真価を発揮するシーン

モデル提供者の重大インシデント時（API キー流出、バックドア発覚）：影響範囲を 30 分で確定
規制監査対応：「2026 年 3 月時点で使っていたモデルの一覧を出せ」に即答
EOL 通知への対応：使用中の旧モデル・旧 API バージョンを即特定
新規参入時の DD：組織として AI ガバナンスが機能している証跡として提示

これらの「いざという時」に AIBOM が無い組織は、月単位の遅れと信用毀損を被る。逆に、整備済みの組織はそれを差別化要因にできる。

AITB へのご相談で「何から手をつければいいか」と聞かれた場合、まず AIBOM から着手するよう勧めることが多くあります。社内での立ち上げ支援は無料相談よりご相談ください。