「いま使っている AI システムは、どのモデルで、どんなデータを使い、どこのクラウドで動いていますか？」――発注した側がこれに答えられないケースは、少なくありません。 AI チャットボットや RAG、業務自動化を外部に開発してもらったものの、「中で何が動いているか」がブラックボックスになっている、という状況です。これは、いざ脆弱性が出たとき・モデルを差し替えたいとき・監査を求められたときに、大きく影響してきます。
この「中身が見えない」という課題に対し、2026 年 5 月 13 日、米 CISA（サイバーセキュリティ・インフラセキュリティ庁）と G7 のサイバーセキュリティ専門家が、「Software Bill of Materials for AI（AI 向けソフトウェア部品表）最小要素」を公表しました（CISA: Software Bill of Materials for AI - Minimum Elements）。AI システムもソフトウェアシステムである――この当たり前の事実を出発点に、AI システムの構成を一覧化する「AI SBOM（AIBOM）」の最小要素が、国際的な合意として整理されました。
ポイントは、AIBOM が「あれば便利な資料」から「調達時に求められる要件」へと移りつつあることです。本記事では、CISA/G7 のガイドを一次ソースに、SBOM と AI SBOM の違い、なぜ AI システムは中身が見えないのか、AI SBOM の 7 つのクラスター、AI 開発を発注するときの確認チェックポイント 7 項目、AI SBOM がないと困る場面、FAQ を整理します。専門用語が多いテーマですが、要は 「発注した AI の部品表を、きちんと出してもらえるか」 という、とても実務的な話です。
目次
- SBOMとは何か：ソフトウェアの「部品表」
- AI SBOM（AIBOM）とは：AIシステムは何でできているか
- なぜAIシステムは「中身が見えない」のか
- CISA/G7が示すAI SBOMの7つのクラスター
- なぜ今、AI SBOMなのか：調達要件への移行
- AI開発を発注するときの確認チェックポイント7項目
- AI SBOMがないと困る4つの場面
- 国内の文脈：経産省SBOM手引き・製造業の義務化・NIST
- よくある質問（FAQ 10問）
- 参考一次ソース
- まとめ
- あわせて読みたい
SBOMとは何か：ソフトウェアの「部品表」
SBOM（Software Bill of Materials、ソフトウェア部品表） とは、あるソフトウェアが どんな部品（コンポーネント・ライブラリ・依存関係）でできているかを一覧化したリストです。製造業の「部品表（BOM）」のソフトウェア版だと考えると分かりやすいでしょう。
なぜ重要かというと、ソフトウェアは多数のオープンソース部品の上に成り立っており、ある部品に脆弱性が見つかったとき、「自社のどのシステムがその部品を使っているか」をすぐに特定できるかが、対応スピードを左右するからです。
たとえば 2021 年の Log4j（Apache Log4j の脆弱性、CVE-2021-44228）では、世界中の企業が「自社システムのどこで Log4j を使っているのか分からない」状態に陥り、調査に多くの時間を要しました。SBOM があれば、こうした「どこで使っているか分からない」という事態を防ぎやすくなります。
米 CISA は、SBOM の「最小要素（Minimum Elements）」を整理しており、サプライヤー名・コンポーネント名・バージョン・依存関係などの基本項目を定義しています（CISA: 2025 Minimum Elements for a Software Bill of Materials (SBOM)）。
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
AI SBOM（AIBOM）とは：AIシステムは何でできているか
AI SBOM（AIBOM） は、この考え方を AI システムに広げたものです。CISA/G7 のガイドは、出発点として 「AI システムもソフトウェアシステムである（AI systems are software systems）」 ことを明確にしています。つまり、通常のソフトウェアに対する SBOM 最小要素に 加えて、AI に特有の要素を考える必要がある、という整理です。
AI システムが通常のソフトウェアと違うのは、「コード」だけでなく「モデル」と「データ」が中核を占める点にあります。
| 構成要素 | 通常のソフトウェア | AIシステム |
|---|---|---|
| コード・ライブラリ | あり | あり |
| 学習済みモデル | なし | あり（種類・バージョン・出所が重要） |
| 学習・参照データ | なし | あり（品質・権利・偏りが重要） |
| 外部API・サービス | 場合による | 多い（LLM API・ベクトルDB等） |
| インフラ・実行環境 | あり | あり（GPU・クラウド依存が強い） |
AIBOM は、これら 「AI システムが何でできているか」を可視化する部品表です。どのモデルを使い、どのデータで動き、どの API に依存し、どこで実行されているか――を一覧化することで、保守・監査・セキュリティ対応の土台ができあがります。
なぜAIシステムは「中身が見えない」のか
AI 開発を外部に委託すると、発注側からは中身が見えにくくなりがちです。理由は次の 4 つです。
1. モデルが「どれを使っているか」分かりにくい
「生成 AI を使ったチャットボット」と言っても、その裏で動いているのが商用 LLM API なのか、オープンソースモデルなのか、独自にファインチューニングしたものなのか――発注書や納品物に明記されていないことが多くあります。モデルが変われば、性能もコストもセキュリティの特性も変わります。
2. データの流れが見えない
ユーザーが入力したデータが、どこに送られ、どこに保存され、学習に使われるのか――この データの流れが分かりにくいと、情報漏えいや権利侵害のリスクを評価できません。とくに RAG（検索拡張生成）では、社内データがどこまで AI に渡るかの設計が重要になります。
3. 外部APIへの依存が積み重なる
AI システムは、LLM API・ベクトルデータベース・各種ツール連携など、複数の外部サービスに依存します。どこか一つが仕様変更・値上げ・サービス終了になると、システム全体が影響を受けます。依存関係が見えていないと、このリスクを管理しにくくなります。
4. 「動いているからいい」で構成が記録されない
PoC から本番に移る過程で構成が変わっても、ドキュメントが追いついていないことが多くあります。その結果、数か月後には「正確な構成を説明できる人がいない」状態になってしまいます。
要点：AI システムの「中身が見えない」のは、担当者の怠慢が原因ではありません。モデル・データ・API・インフラという見えにくい要素が組み合わさっているからこそ、意識して「部品表（AIBOM）」として記録しておくことが大切です。
FREE DOWNLOAD
AI/RAG導入後のKPIと改善運用、先に設計しませんか？
PoCで終わらせず、利用率・精度・削減工数・改善バックログまでOutcomeOpsで回す設計を確認できます。
CISA/G7が示すAI SBOMの7つのクラスター
2026 年 5 月 13 日に公表された CISA/G7 の「Software Bill of Materials for AI - Minimum Elements」は、AI SBOM に含めたい要素を 7 つのクラスターに整理しています。これは G7 の専門家の合意を反映したもので、網羅的・義務的なものではなく、AI 技術の進展に合わせて広がっていくベースラインとして位置づけられています。
| # | クラスター（CISA/G7） | 何を記録するか |
|---|---|---|
| 1 | Metadata（メタデータ） | AI システムの基本情報・識別子・作成者・バージョンなど |
| 2 | Models（モデル） | 使用しているモデルの種類・バージョン・出所・ライセンス |
| 3 | Dataset Properties（データセット特性 / DP） | 学習・参照に使うデータの特性・出所・取り扱い |
| 4 | System Level Properties（システムレベル特性 / SLP） | システム全体の構成・依存関係・連携先 |
| 5 | Key Performance Indicators（主要性能指標 / KPI） | 性能・精度に関する指標 |
| 6 | Security Properties（セキュリティ特性 / SP） | セキュリティに関わる属性・対策の状況 |
| 7 | Infrastructure（インフラ） | 実行環境・クラウド・ハードウェア依存 |
ここで大切なのは、これらが 「AI システムもソフトウェアシステムである」という前提のもと、通常の SBOM 最小要素に“加えて”考えるものとされている点です。つまり、コード・ライブラリの部品表（通常の SBOM）に、モデル・データ・性能・インフラといった AI 固有の情報を足したものが AI SBOM（AIBOM）になります。
中堅・中小企業が、この 7 クラスターをいきなりすべて完璧に整える必要はありません。ただし、「どのモデルを使い、どんなデータで動き、どこで実行されているか」という最低限の構成情報は、発注時・納品時に押さえておきたいところです。
なぜ今、AI SBOMなのか：調達要件への移行
AI SBOM が注目される一番の理由は、「任意の資料」から「調達要件」へと立場が変わりつつあることです。
CISA/G7 のガイドは、AI のサプライチェーンの 透明性（transparency） を高めることを目的としています。AI システムを調達する側――政府機関や大企業――が、**「この AI は何でできているのか（AIBOM を出してください）」**を求めるようになれば、開発・提供する側も AIBOM を整備しておく必要が出てきます。
これは中堅・中小企業にとっても、他人事ではありません。
- 発注側になる場合：AI 開発を外注するとき、「構成情報（AIBOM 相当）を出せるか」を発注先の選定基準にできます
- 提供側になる場合：自社が AI システムを納品・提供する立場であれば、AIBOM を整備しておくことが、今後の競争力や信頼につながります
- 取引先から求められる場合：大企業や官公庁との取引で、サプライチェーンの一部として AIBOM の提出を求められることがあります
製造業の SBOM がそうであったように、最初は「先進的な取り組み」だったものが、数年で「取引の前提条件」になる――AI SBOM も同じ道をたどりつつあります。
AI開発を発注するときの確認チェックポイント7項目
CISA/G7 の 7 クラスターを、中堅・中小企業が AI 開発を発注するときに確認できる 7 項目にまとめました。発注先（開発会社）に質問する形でお使いいただけます。
■ モデルとデータ
□ 1. どのモデルを使うか（商用API / オープンソース / 独自）と、そのバージョン・ライセンスを明示できるか
□ 2. 学習・参照するデータの出所・範囲・取り扱い（どこに保存し、学習に使うか）を説明できるか
■ 構成と依存
□ 3. システムが依存する外部API・サービス・ライブラリを一覧化できるか
□ 4. 実行環境（クラウド・リージョン・インフラ）がどこかを明示できるか
■ セキュリティと運用
□ 5. データの流れ（入力 → 処理 → 保存）と、情報漏えい対策を説明できるか
□ 6. ログの取得方法と、稼働状況・性能の監視方法を提示できるか
■ 引き継ぎと保守
□ 7. 上記の構成情報を「ドキュメント（AIBOM 相当）」として納品物に含められるか
「出せない」という答えも、それ自体が判断材料
このチェックで、発注先が 「モデルは答えられない」「データの流れは説明できない」「構成のドキュメントは出せない」 という場合、それも発注を判断するうえで大切な材料になります。中身を説明できる開発会社を選んでおくことが、後々の保守・監査・脆弱性対応のしやすさに直結します。
AI SBOMがないと困る4つの場面
AIBOM を整備していないと、具体的にどんな場面で困るのか。4 つ挙げます。
1. 脆弱性が出たとき
使っているモデルやライブラリ、依存する API に脆弱性が見つかったとき、「自社の AI システムが影響を受けるか」をすぐに判断できません。Log4j の AI 版のような事態が起きたとき、AIBOM があれば数分、なければ数週間の差になることもあります。
2. モデルを差し替えたいとき
「もっと性能の良いモデルに変えたい」「コストの安いモデルに切り替えたい」と思っても、現状どのモデルをどう使っているかが分からなければ、影響範囲を見積もれません。
3. 監査・取引先対応を求められたとき
大企業や官公庁との取引、あるいは社内の監査で **「この AI は何でできているか説明してください」**と求められたとき、AIBOM がなければ答えられません。これは取引機会の損失にもつながります。
4. 開発会社を変えたい・引き継ぎたいとき
開発を委託していた会社を変える、あるいは社内に引き継ぐとき、構成情報が文書化されていないと、引き継ぎがとても難しくなります。「作った人しか分からない」状態は、事業継続のうえでもリスクになります。
国内の文脈：経産省SBOM手引き・製造業の義務化・NIST
AI SBOM は海外発の概念ですが、SBOM 自体は国内でも導入が進んでいます。
経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引」
経済産業省は、ソフトウェアサプライチェーンの管理に向けて 「ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引」 を公表し、SBOM の作成・運用の考え方を整理しています（経済産業省: ソフトウェアの脆弱性対策に関する取組（SBOM））。AI システムの構成管理を考えるうえでも、この国内の手引きの考え方が土台になります。
製造業を中心に進む SBOM の実務
医療機器や自動車などの分野では、SBOM の整備が 取引・規制の要件になりつつあります。AI SBOM（AIBOM）も、この流れの「AI 版」として、今後同じように実務へ広がっていくと見られます。
NIST「Secure Software Development Framework（SSDF）」
米 NIST の 「Secure Software Development Framework（SSDF, SP 800-218）」 は、安全なソフトウェア開発のための実践集で、SBOM の活用もその一部に位置づけられています（NIST SSDF）。AI システムの開発・調達でも、こうした枠組みと整合させておくと安心です。
よくある質問（FAQ 10問）
Q1. AI SBOM（AIBOM）は、うちのような中小企業にも必要でしょうか？
A. 規模に関わらず、「自社の AI が何でできているか」を把握しておくことをおすすめします。最初から完璧な AIBOM を作る必要はありませんが、最低限「どのモデル・どのデータ・どの API・どこで実行」の 4 点は押さえておきたいところです。
Q2. SBOM と AI SBOM は何が違うのでしょうか？
A. SBOM は主にコード・ライブラリの部品表です。AI SBOM（AIBOM）は、それに モデル・データ・性能・インフラという AI 固有の要素を加えたものです。CISA/G7 も「AI システムもソフトウェアなので、通常の SBOM に“加えて”考える」と整理しています。
Q3. AIBOM は誰が作るのがよいでしょうか？発注側でしょうか、開発側でしょうか？
A. 実際に作るのは 開発・提供側が中心になります。発注側は「AIBOM 相当の構成情報を納品物に含めてください」と求める立場です。発注時の要件に入れておくのが現実的です。
Q4. CISA/G7 の 7 クラスターを、全部そろえる必要がありますか？
A. 必須ではありません。CISA/G7 自身が「網羅的・義務的ではなく、広がっていくベースライン」と位置づけています。まずは Metadata・Models・Dataset Properties・Infrastructure あたりの基本から始めれば十分です。
Q5. 商用 LLM API（ChatGPT 等）を使っている場合も、AIBOMは要りますか？
A. あったほうがよいです。「どの API の、どのモデル・バージョンを、どんな用途で使っているか」を記録しておきます。API は仕様変更・値上げ・終了が起こりうるため、依存関係を見える化しておく価値は高いといえます。
Q6. 既に開発済みの AI システムでも、後からAIBOMは作れますか？
A. 作れます。開発会社に「現状の構成情報（使用モデル・データの流れ・依存サービス・実行環境）をドキュメント化してほしい」と依頼するのが第一歩です。後からでも遅くありません。
Q7. AIBOM があると、何が一番うれしいのでしょうか？
A. 脆弱性対応・モデル差し替え・監査対応・引き継ぎの 4 つの場面で、ぐっと動きやすくなります。「中身が分かっている」こと自体が、運用と事業継続のリスクを下げてくれます。
Q8. AIBOM の標準的なフォーマットはありますか？
A. SBOM の標準フォーマット（CycloneDX や SPDX など）が、AI 向けの記述にも対応を進めています。ただし中小企業は、まず「自社で説明できる構成ドキュメント」を整えることが先で、フォーマットは後から合わせていけば問題ありません。
Q9. 開発を外注する際、AIBOM を要件に入れると費用は上がりますか？
A. 多少の工数は増えることがありますが、後の保守・引き継ぎ・脆弱性対応のコストを大きく下げられます。長期的にはむしろ総コストを抑える投資と考えるとよいでしょう。
Q10. 結局、まず何から始めればよいでしょうか？
A. **「いま使っている（あるいは発注しようとしている）AI システムについて、モデル・データ・API・実行環境を一枚にまとめてみる」**ことです。これが AIBOM の出発点になります。書けない項目があれば、それが今の「見えていない部分」だといえます。
参考一次ソース
- CISA「Software Bill of Materials for AI - Minimum Elements」(2026-05-13、CISA/G7)
- CISA「Software Bill of Materials (SBOM)」トピックページ
- CISA「2025 Minimum Elements for a Software Bill of Materials (SBOM)」
- 経済産業省「ソフトウェアの脆弱性対策に関する取組（SBOM）」
- NIST「Secure Software Development Framework（SSDF, SP 800-218）」
まとめ
- AI SBOM（AIBOM）は、AI システムが「何でできているか」を可視化する部品表です。モデル・データ・API・インフラを一覧化します
- 2026 年 5 月 13 日、CISA と G7 が「AI SBOM 最小要素」を公表しました。「AI システムもソフトウェアである」を出発点に、通常の SBOM に AI 固有の要素を加える整理を示しています
- CISA/G7 は AI SBOM の 7 クラスター（Metadata / Models / Dataset Properties / System Level Properties / KPI / Security Properties / Infrastructure）を示しています
- AIBOM は 「任意の資料」から「調達要件」へ移りつつあります。発注側・提供側のどちらの立場でも備えておきたいところです
- AI 開発発注時のチェックポイント 7 項目で、モデル・データ・依存・実行環境・データの流れ・ログ・ドキュメント化を確認しましょう
- AIBOM がないと、脆弱性対応・モデル差し替え・監査・引き継ぎの場面で動きにくくなります
- 国内でも 経産省 SBOM 手引きや製造業の実務が先行しています。AI SBOM はその「AI 版」として広がっていくと見られます
「中身を説明できる AI」は、安心して使い続けられる AI です。AI 開発を発注するときは、機能や価格だけでなく、**「構成を説明できるか・ドキュメント化できるか」**を選定基準に加えてみてください。
AI開発の発注・構成整理を相談したい方へ
AI チャットボット・RAG・業務自動化の開発を検討している、あるいは既に導入済みのシステムの構成を整理したい方は、**「何のモデルで、どんなデータを使い、どこで動いているか」**を見える化しておくことで、安心して運用・改善を進めていただけます。
GXO株式会社では、中小・中堅企業向けに次のようなご相談を承っています。
- AI開発の発注前整理：要件・構成・データの扱いを、発注前に一緒に整理
- AIチャットボット・RAG開発：使用モデル・データの流れ・依存サービスを明確にした設計
- 既存AIシステムの構成可視化：すでに動いているシステムの構成ドキュメント（AIBOM 相当）の整備
- 保守・引き継ぎ体制の設計：「作った人しか分からない」を防ぐドキュメント化と運用設計
あわせて読みたい
著者: GXO株式会社 初回公開: 2026 年 5 月 23 日
