AI部品表（AIBOM）：完全ガイド
AI部品表（AIBOM）とは、AIシステム内のデータセット、モデル、依存関係を体系的に一覧化したものであり、AIサプライチェーンに透明性をもたらします。
AI部品表（AIBOM）とは何ですか？
2026年5月、公式のOpenAIリリースを装った悪意のあるHugging Faceリポジトリが、フラグ付けされて削除される前に、同プラットフォームのトレンド1位に達しました。本物のモデルカードをほぼ一字一句そのままコピーしていたため、その掲載は正当に見え、すでにそれを取り込んでいた人には知る術がありませんでした。というのも、ソフトウェア依存関係スキャンはライブラリやパッケージを検査しますが、侵害はモデル自体に存在していたからです。
AI部品表（AIBOM）は、そのスキャンでは得られなかったものを提供します。つまり、侵害されたモデルや 汚染されたデータセットがすでに自社環境内にあるかどうかを把握する手段です。
AIBOMは、AIシステムを構成するデータセット、モデル、フレームワーク、依存関係の構造化されたインベントリであり、各コンポーネントの来歴が記録されます。これにより、通常は出所が文書化されない資産、すなわちサードパーティデータ、事前学習済みモデル、オープンソースライブラリを対象にできます。
AIBOMとソフトウェア部品表の関係
ソフトウェア部品表は、アプリケーション内のソフトウェアコンポーネントと依存関係、すなわちライブラリ、パッケージ、バージョン識別子、ライセンスを一覧化します。AIBOMは、このインベントリの実践をAI固有の資産にまで拡張し、学習データ、モデル重み、モデルの来歴、性能ベースラインを含めます。CycloneDXは、OWASPのBOM標準として、SBOMとAI/ML-BOMを相互運用可能なBOMタイプとして定義することで、これを実装しています。
AIBOMの中核コンポーネント
AIBOMは、AIシステムの構成、出所、運用プロファイルを定義するコンポーネント一式を記録します。2026年5月のG7 Cybersecurity Working Groupのガイダンスは、 CISAのAI SBOM最小要素として公開され、これらのコンポーネントを7つのクラスターに整理しています。
| コンポーネントクラスター | 記録する内容 | 含める理由 |
| メタデータ | AIBOMの作成者、作成日、スキーマバージョン、文書識別子 | インベントリアーティファクトの管理連鎖を確立する |
| システムレベルのプロパティ | ソフトウェア依存関係、フレームワーク、ランタイム環境、データ処理ロジック | 従来のSBOM内容に対応し、CVE追跡を可能にする |
| モデル | モデルの識別情報、アーキテクチャ、重みがどのように生成されたか（学習、ファインチューニング、蒸留）、文書化された制約 | モデル重みにはパッケージマネージャー相当のものがなく、来歴によって改ざんの特定が可能になる |
| データセットのプロパティ | 学習、検証、テスト用データセットの識別情報、来歴、ライセンス、収集方法、適用された前処理 | データ汚染はソフトウェア分析では特定できず、来歴記録によって学習データが改ざんされたかを追跡できる |
| 主要業績評価指標 | デプロイ時に記録された精度、公平性、敵対的耐性のベンチマーク | 挙動のベースラインを確立し、劣化が敵対的操作を示す可能性がある |
| インフラストラクチャ | 物理および仮想インフラストラクチャ、専用AIハードウェア（GPU、TPU）向けHardware BOMへのリンク | モデルを生成し実行する計算環境を文書化する |
| 文書構造と更新頻度 | AIBOM形式のバージョニング、更新トリガー、ライフサイクル移行記録 | インベントリがいつどのように更新されるかを定義し、各ライフサイクル移行を影響を受けるクラスター全体で必要な変更に結び付ける |
これら7つのクラスターは、AIBOMに何が含まれるかを示しています。各クラスターをいつ埋めるかはモデルのライフサイクルに依存します。記録は一度で完成するのではなく、段階的に構築されます。
モデルライフサイクル全体でAIBOMを生成・維持する方法
AIBOMレコードは4つのライフサイクル段階を通じて形作られ、各段階で上記のコンポーネント分類から特定のクラスターが埋められます。
- データの調達と準備。 AIBOMはここから始まり、データセットのプロパティとして、モデル学習開始前にすべての学習、検証、テスト用データセットの識別情報、来歴、ライセンス、完全性を記録します。このクラスターは初回収集時と、再学習またはファインチューニングのたびに更新します。
- モデル学習とファインチューニング。学習時には、入力データセット、学習コード、ハイパーパラメータ構成、結果として得られるモデル重みの関連付けを記録します。ファインチューニングのイベントでは、モデルクラスターとデータセットクラスターの両方を更新する必要があります。
- ビルドとデプロイ。 デプロイ時には、ソフトウェア依存関係、フレームワーク、ランタイム環境の詳細を含めて、システムレベルのプロパティクラスターを完全に埋めます。KPIのベースライン値も記録されます。インフラストラクチャコンポーネントは文書化されるか、HBOMを通じてリンクされます。
- 継続的な監視と保守。 AIBOMの保守はイベント駆動です。7つのクラスターのいずれかのコンポーネントに変更があれば、再学習済みモデル、パッチ適用済み依存関係、データセットのバージョン、インフラ変更を含めて更新がトリガーされます。自律型の検出ツールと機械可読形式により、変更発生時に更新することで記録の正確性が維持されます。
これら4つの段階を通じて、AIBOMが信頼できる状態を保つには、その形式と更新ルールが事前に固定されている必要があります。これは現在の標準で規定されている内容です。
AIBOMの標準とフレームワーク
現在、AIBOM実装の権威ある基盤を形成しているのは、相互に連携する4つの標準です。それぞれがガバナンススタックの異なる層に対応しています。
- NIST AI Risk Management Framework。 NIST AI Risk Management Frameworkは、信頼できるAIの基盤特性としてトレーサビリティと説明責任を確立しています。その初版である AI RMF 1.0は2023年1月にそのベースラインを定め、 Generative AI Profileは2024年7月にそれを生成AIシステムへ拡張しました。NISTの2025年4月の報告書 AI 100-5e2025は、AIサプライチェーンをSBOMの仕組みに明示的に結び付け、透明性の手段としてソフトウェア部品表と並んでモデルカードやデータカードに言及しています。
- OWASP CycloneDX ML-BOM。 CycloneDX v1.5で導入され、その後のバージョンで拡張されたML-BOM機能は、来歴文書化やデータセットに関する倫理的考慮事項を含め、AI/MLシステム向けのデータセット、モデル、構成を表現します。
- SPDX 3.0 AI and Dataset Profiles。 ISO/IEC標準であるSPDXは、バージョン3.0でAIおよびデータセットのプロファイルを追加しました。これらのプロファイルは、AIモデル、学習データ、プロンプトテンプレート、AIエージェント、ライセンスを文書化します。
- CISA and G7 Minimum Elements。CISAは、AIソフトウェアを対象とするSBOM Minimum Elementsを 2025年8月に公開しました。2026年5月には、すべてのG7加盟国とEUのサイバーセキュリティ機関が共同ガイダンスを公開し、AI SBOMの潜在的要素を7つのクラスターとして定義しました。これは G7共同ガイダンスに示されています。
AIBOMの採用はまだ初期段階であり、現在の実装は不完全または不正確であることが少なくありません。しかし、これらの標準は構築の土台を提供します。
セキュリティ、コンプライアンス、監査可能性においてAIBOMが重要な理由
セキュリティの観点では、AIBOMはデータセットの来歴とモデル重みのチェックサムを記録するため、チームはモデルが改ざんされたデータで学習されたかどうかを調査できます。脆弱性や侵害されたコンポーネントがAIインフラに影響した場合、AIBOMはどのシステムが影響を受けるかを示します。
コンプライアンスの観点では、EU AI Actには、特定のAIシステムおよびモデルに対する透明性と文書化の義務が含まれており、技術文書や学習コンテンツの要約も対象です。AIBOMは、構造化された構成記録を作成することで、これらの義務を支援します。
監査可能性の観点では、AIBOMは監査担当者やincident response teamに対し、特定のAIシステムが何から構築されたかという問いに、追跡可能でバージョン管理された回答を提供します。この記録は、どのデータセットで学習されたか、どのモデル重みがデプロイされているか、どのフレームワークと依存関係がそれを支えているかを示します。この記録がなければ、AIの構成に関する監査上の質問への対応は、よくても事後的な再構築作業になります。
これらの成果はいずれも、記録が正確かつ最新であることを前提としています。エンタープライズ規模でその状態に到達しようとすると、努力だけでは解消できない構造的制約に直面します。
Singularity™ AI SIEM
SentinelOneの世界最先端のAI SIEMで、脅威をリアルタイムで検知し、日々の業務を効率化しましょう。
AIBOM実装における課題
構造的制約により、AIBOMの実装は組織の成熟度やリソース状況にかかわらず困難になります。
- 標準とツールの未成熟さ。 CycloneDX ML-BOM、SPDX 3.0 AIプロファイル、G7ガイダンスはいずれも最近登場したため、実務とツールはまだ定着途上です。
- 不透明なサードパーティモデル。 推論API経由で利用されるプロプライエタリな基盤モデルは、その内部についてほとんど開示しません。名前、バージョン、エンドポイント、アクセス制御、ベンダーの証明は記録できますが、クローズドモデルの完全な構成は把握できません。
- 学習データの来歴。 外部で学習されたモデルでは、来歴が開示されない可能性があります。内部モデルでは、事後的な再構築は信頼できないため、学習時にそれを取得しなければなりません。
- 急速なモデルのバージョニング。 再学習やパラメータ変更のたびに、それぞれ独自のリスクプロファイルを持つ新たな実効バージョンが作られ、手作業のプロセスでは大規模に追跡できないバージョンの拡散が生じます。
- 異種混在環境。 エンタープライズAIは、クラウドプロバイダー、オンプレミスインフラ、SaaS AIツール、サードパーティアプリケーションに組み込まれたAI、エージェント型システム、ベクターデータベースにまたがります。
これらの制約は外部要因であるため、できることはそれらを前提に設計することです。次のセクションの失敗はその逆であり、防ぐ責任は自社にあります。
よくあるAIBOM実装ミス
| ミス | 結果 |
| 監査のために作成する一度限りの文書としてAIBOMを扱う | incident responseは、もはや本番環境を反映していない記録に基づいて判断を下すことになる |
| インベントリを手作業で維持する | モデル、データセット、APIの変化の速度が人手によるプロセスを上回るため、記録は最新性を失っていく |
| 来歴なしでモデル名とバージョンだけを記録する | データ汚染やモデル汚染は特定不能なままとなる。なぜなら、特定には学習系統、重みのチェックサム、実行メタデータが必要であり、それらは事後に再構築できないからである |
| エンジニアリングツールと切り離された単独のコンプライアンスファイルとしてAIBOMを運用する | 2つのインベントリが形成され、乖離する。 CISAのSBOMガイダンスは、部品表をサプライチェーンリスクのためのネストされたインベントリと定義しており、SBOMツールチェーンの外でAIBOMを運用するとそのつながりが断たれる |
| ITが承認したAIのみにインベントリ範囲を限定し、 shadow AIを除外する | 記録に体系的な盲点が残る |
上記の各エラーはプロセス上の選択であるため、それぞれにプロセス上の修正策があります。以下の実践により、インベントリは静的ファイルから運用上の統制へと変わります。
AIBOMのベストプラクティス
以下のアクションにより、AIBOMプログラムは静的な文書から運用可能なガバナンス手段へと移行します。
- 自律型の検出と生成を導入する。これをモデルレジストリ、APIゲートウェイ、クラウドAIサービスのインベントリに統合します。
- 機械可読形式に標準化する。 CycloneDX ML-BOMまたはSPDX 3.0 AIプロファイルを出力します。人が読めるスプレッドシートでは、インベントリのセキュリティ価値を運用化するワークフローに取り込めません。
- 来歴をソースで取得する。 学習およびファインチューニング用データセット識別子、モデル重みのチェックサム、学習実行メタデータ、推論APIのバージョン固定を記録します。内部モデルについては、学習時にMLパイプラインへ来歴追跡を組み込みます。
- CI/CDをAIBOMでゲートする。 学習アーティファクト作成時、レジストリへのプッシュイベント時、デプロイ構成変更時にAIBOMを生成し、AIBOMが欠落している、または古い場合は、次の環境への昇格を停止するパイプライン障害として扱います。
- 継続的にドリフトを監視する。 すべてのデプロイイベントで、デプロイ済みモデルアーティファクトのハッシュをAIBOMに記録されたハッシュと比較します。イベント駆動の頻度こそが、ガバナンス記録と陳腐化した文書を分ける要素です。
- アクティブディスカバリーによってshadow AIを見つける。既知のAI推論エンドポイントへの接続を特定し、検出された資産を明示的な未統制リスク分類付きでAIBOMに追加します。
これらの実践により、AIBOMは監査用アーティファクトから生きた記録へと変わります。これをクラウド規模で実行するにはツールが必要であり、そこでSentinelOneのAI Security Posture Managementが役立ちます。
SentinelOneでAIBOMガバナンスを強化する
AIBOMの品質は、それに情報を供給するディスカバリーの品質に左右されます。 Singularity Cloud Securityは、SentinelOneの Cloud-Native Application Protection Platformとして、統合されたData Security Posture Management（DSPM）をデータレイヤー向けに備えつつ、AI Security Posture Management（AI-SPM）機能を通じてクラウド環境全体でAIBOMを構築・維持します。
- インベントリを埋めるディスカバリー。 AI-SPMは、Amazon SageMakerのようなサービス上のジョブを含め、環境内で稼働するAIパイプライン、MLモデル、依存関係を検出します。承認済みAIとshadow AIの両方を対象とするため、列挙されたすべてのコンポーネントが、見えない盲点なくAIBOMエントリ候補になります。
- 記録の上に重ねるリスクコンテキスト。構成チェックとVerified Exploit Pathsにより、カタログ化されたどのコンポーネントが設定不備または悪用可能かが分かり、DSPMはsafe-to-trainゲートを通じて高リスクデータをAIパイプラインから排除します。Prompt Securityはプロンプトと応答を検査し、エージェント型AIを統制することで、AIBOMガバナンスをランタイム層まで拡張します。
- プラットフォーム全体での検証。 Singularity Platformは、エンドポイント、クラウド、アイデンティティのテレメトリを1つのデータレイクに統合するため、デプロイ済み環境が依然としてAIBOMと一致しているかを確認できます。ドリフトが発生した場合は、 Purple AIが介入します。これは同じデータ全体を横断して自律的に調査する自然言語アナリストです。IDCによると、Purple AIの顧客は脅威特定が63%高速化し、平均対応時間（MTTR）が55%短縮されました。
SentinelOneのデモを予約して、AIサプライチェーンリスクを評価し、クラウド環境全体で防御可能なAIガバナンスプログラムを構築してください。
業界をリードするAI SIEM
SentinelOneの世界最先端のAI SIEMで、脅威をリアルタイムで検知し、日々の業務を効率化しましょう。
重要なポイント
AIBOMは、AIシステムの背後にあるデータセット、モデル、フレームワーク、依存関係をインベントリ化し、各コンポーネントの出所を記録します。これは、学習データ、モデル重み、モデルの来歴といったAI固有の資産に、確立されたSBOMの実践を拡張するものです。
NIST、OWASP CycloneDX、SPDX、G7の標準は、AIBOMが何を記録するかを定義しています。このインベントリはセキュリティ、コンプライアンス、監査可能性にとって重要ですが、モデルの変化に応じて正確性を維持するには、自律型ディスカバリー、機械可読形式、来歴の取得、CI/CD統合が必要です。適切に実装すれば、AIBOMは単なる書類ではなく、実際に活用できる統制になります。
よくある質問
AI部品表、すなわちAIBOMは、AIシステムの構成要素を機械可読形式で一覧化したものです。これには、データセット、モデル、フレームワーク、ソフトウェア依存関係、および来歴やライセンスなどのメタデータが含まれます。その目的は運用にあります。
モデルが侵害されていることが判明した場合や、データセットが汚染されていることが示された場合、AIBOMがあれば、証拠に基づいて、自社のどのシステムにその構成要素が含まれているのか、またそれがいつ組み込まれたのかを特定できます。これがなければ、その答えを導き出すには、時間的なプレッシャーの中で再構築作業を行うことになります。
一部です。推論APIを介して利用するクローズドな基盤モデルについては、ベンダーが学習データや重みを開示していないため、完全な内部構成を記録することはできません。それでも、把握可能な情報は取得して固定できます。具体的には、モデル名、バージョン、APIエンドポイント、アクセス制御、およびベンダーによる証明です。
これらを主要なAIBOMエントリとして記録し、非開示の項目を明示的に示してください。そうすることで、インベントリ上で透明性がどこで途切れるかが分かり、暗黙の空欄を残しません。
G7の2026年5月のガイダンスでは、AIBOMの内容を7つのクラスターに整理しています。すなわち、メタデータ、システムレベルのソフトウェア特性、モデルの識別情報と重みの来歴、データセットの特性、主要業績評価指標、インフラストラクチャのドキュメント、および更新頻度の記録を含むドキュメント構造です。
これらのクラスターを合わせることで、AIシステムがどのように構築されたか、何の上で動作しているか、そしてライフサイクル全体を通じてインベントリがどのように変化するかを文書化します。
4つの標準およびフレームワークが、現在のAIBOMの実践を支えています。NIST AI Risk Management Frameworkは、ガバナンスとトレーサビリティに関する期待事項を定めています。ISO/IEC標準であるOWASP CycloneDX ML-BOMおよびSPDX 3.0 AI profilesは、モデルとデータセット向けの機械可読なフォーマット仕様を提供します。
CISAのSBOM最小要素とG7の7クラスターガイダンスは、AIシステムの透明性で何を把握すべきかを定義しています。これらを合わせることで、確立されたSBOMのアプローチをAIインベントリモデルへと拡張しています。
AIBOMをMLパイプラインに関連付けられたイベント駆動型の記録として扱います。モデル学習アーティファクトの作成、レジストリへのプッシュイベント、再学習、ファインチューニング、デプロイ構成の変更時に更新をトリガーします。デプロイ済みモデルのハッシュを記録されたハッシュと比較し、対応するAIBOMレコードが存在しない新しい推論エンドポイントまたはレジストリエントリに対してアラートを生成します。
AI security posture managementツールは、これらのチェックを継続的に実行し、発生時にドリフトを検出してフラグ付けできます。生成が必須のCI/CDステップである場合、古いインベントリは、管理されていないモデルが本番環境に到達する前に昇格を停止します。
さらに詳しく見る データとAI
セキュリティ運用を革新する準備はできていますか？
SentinelOne AI SIEM がどのようにお客様の SOC を自律型の強力な組織へと変革できるかをご覧ください。今すぐお問い合わせいただき、パーソナライズされたデモを通じて、セキュリティの未来を実際にご確認ください。
