![]()
AI BOMとは?SBOMとの違いと作り方5ステップ、対応ツールの選び方 (2026年版)
この記事のポイント AI BOMとは、AIシステムに使われているモデル・学習データ・外部サービスを一覧にした管理表のことです。従来のSBOM(ソフトウェア部品表)では、モデルの重みや学習データの出所までは追えません。記載すべきは12項目。作成は棚卸しから始める5ステップで、初回さえ越えれば自動化が効きます。なお「AI BOM」には製造業の部品表をAIで作る話も混ざっているので、そこも切り分けて整理しました。
「うちの製品、結局どのAIモデルが何箇所で動いてるんだっけ」。この質問に即答できないまま、気づけばAI機能が5つも6つも増えている——2026年の開発現場でいちばん多い状態がこれです。
そして、答えられないのは怠慢だからではありません。追跡する仕組みがなかっただけ。
セキュリティ企業Cycodeが2026年に公開した製品セキュリティ調査では、開発プロセスの中でAIがどこでどう使われているかを完全に把握できている組織は19%にとどまっています。5社に4社は、自社のAIの中身が見えていない計算。
その空白を埋めるために出てきたのがAI BOMです。
AI BOMとは、AIシステムの「材料表」です

AI BOMとは、AIシステムに使われているモデル・学習データ・外部サービス・ライセンスなどの構成要素を一覧にした管理表です。英語ではAI Bill of Materials(AIBOM)と呼ばれます。
食品のパッケージ裏にある原材料表示を思い浮かべると早いです。何が入っているか、どこから来たか、アレルギー物質はあるか。それをAIシステムに対してやるのがAI BOM。
管理表と聞くとExcelの棚卸しシートを想像しますが、実務ではJSONなどの機械が読める形式で持ちます。人間が眺めるためではなく、CI(コードを自動でテストする仕組み)やセキュリティ検査に食べさせるためです。
対象になるのは、ざっくり次の4種類です。
- 生成AIのAPI(外部の提供元に問い合わせる形)
- 自社サーバーで動かすオープンモデルの重みファイル
- ライブラリに埋め込まれた小さな機械学習モデル
- 学習・微調整に使ったデータセット
4つ目のデータセットが曲者。ここが従来の管理表からごっそり抜け落ちていた部分です。
なぜ2026年にAI BOMが必要になった?

AI機能が「特別なプロジェクト」から「普通の実装」に降りてきたからです。承認プロセスを通らずにAIが増える状態になった時点で、台帳がないと制御できません。
2023年頃のAI導入は、稟議を通して専任チームが作る大仕事でした。数が少ないので、誰が何を使っているか記憶で管理できた。
いまは違います。開発者がコーディング支援ツールに指示を出せば、数分で外部APIを呼ぶコードが生まれる。ライブラリを1つ入れただけで、その中に別の小さなモデルが同梱されていることもあります。
増え方が速いのに、記録は追いついていない。ここに3つの実害が出ます。
1つ目は、脆弱性が出たときに影響範囲がわからないこと。 あるオープンモデルに問題が見つかったとして、自社のどのサービスがそれを使っているか。台帳がなければ、全リポジトリを手で探すしかありません。
2つ目は、ライセンス違反。 オープンモデルには商用利用を制限するものが混ざります。研究用途限定の重みを本番に載せたまま、誰も気づかない。これが後から発覚すると、機能ごと止める判断になります。
3つ目は、顧客からの質問に答えられないこと。 法人向けにサービスを売っていると、調達側から「入力データはどのモデルに渡りますか」「学習に使われますか」と聞かれます。ここで曖昧な回答をすると、それだけで選定から落ちる。
AI BOMは、この3つを同時に片付けるための土台になります。
SBOMとAI BOMは何が違う?

SBOMはソフトウェアの部品表で、ライブラリやパッケージの依存関係を記録します。AI BOMはその考え方をモデル・学習データ・推論の実行場所まで拡張したもの。守備範囲が違うだけで、思想は同じです。
両者の違いを整理した表がこちらです。読む前に一言だけ添えると、AI BOMはSBOMの置き換えではなく、上に積む層だと考えてください。
| 比較軸 | SBOM(ソフトウェア部品表) | AI BOM(AI部品表) |
|---|---|---|
| 主な対象 | ライブラリ、パッケージ、コンテナ | モデル、学習データ、推論エンドポイント |
| 記録するバージョン | パッケージのバージョン番号 | モデル名とバージョン、重みのハッシュ値 |
| ライセンス管理 | OSSライセンス | モデルライセンス+データセットのライセンス |
| 変化のきっかけ | 依存関係の更新 | 提供元によるモデル更新、微調整の実施 |
| 追跡できないもの | モデルの中身、学習データ | (AI BOM単体では)コード全体の依存関係 |
| 生成の自動化 | ほぼ完全に自動化できる | 一部は人の申告が必要 |
| 標準フォーマット | CycloneDX / SPDX | CycloneDXのML-BOM、SPDXのAI Profile |
つまり、SBOMを作っているなら基盤はもうある状態で、そこにモデルとデータの列を足す作業がAI BOM対応の実態です。
決定的な差はもう1つあります。SBOMの対象は、バージョンを固定すれば中身が変わりません。ところがAPI経由のモデルは、提供元の判断で挙動が変わる。バージョン番号を書いただけでは足りず、「いつ時点の確認か」を必ず併記する必要があります。
ここが運用でいちばん忘れられるポイント。
AI BOMに何を書けばいい?

記載項目は12個に絞れば実用に耐えます。全部を最初から埋めようとすると挫折するので、上から6項目だけで先に一周するのが現実的です。
必須度つきで整理しました。表の後に、埋めにくい項目の補足を書きます。
| # | 項目 | 内容 | 必須度 |
|---|---|---|---|
| 1 | モデル名 | 使用しているモデルの名称 | 必須 |
| 2 | バージョン | 版数、または重みファイルのハッシュ値 | 必須 |
| 3 | 提供元 | モデルを提供している組織 | 必須 |
| 4 | 利用形態 | 外部API / 自社ホスト / ライブラリ同梱 | 必須 |
| 5 | ライセンス | 商用可否と再配布条件 | 必須 |
| 6 | 用途 | どの機能で何をさせているか | 必須 |
| 7 | 学習データの出所 | 自社データ / 公開データセット / 不明 | 推奨 |
| 8 | 微調整の有無 | 追加学習をしたか、その元データは何か | 推奨 |
| 9 | 外部データ接続 | 社内資料を読ませる仕組みの接続先 | 推奨 |
| 10 | 入出力データの機密度 | 個人情報・機密情報を通すか | 推奨 |
| 11 | 推論の実行地域 | 処理が行われる国・リージョン | 任意 |
| 12 | 責任者と最終確認日 | 誰がいつ確認したか | 必須 |
12項目のうち、実際に手が止まるのは7番と8番です。
学習データの出所は、外部APIを使っている限り「提供元の非公開情報」としか書けません。それでいい。空欄にせず「提供元非公開」と明記することに意味があります。監査で聞かれたとき、調べた上でわからなかったのか、そもそも調べていないのか、この差は大きい。
11番の推論の実行地域は、金融・医療・公共に納品するなら必須に格上げしてください。データの越境移転を聞かれる業界では、ここが空欄だと商談が止まります。
12番の最終確認日を必須に置いた理由はシンプルで、日付のない台帳は3ヶ月で信用を失うからです。
もう一つの「AI BOM」— 製造業の部品表をAIが作る話
「AI BOM」で検索すると、まったく別のテーマが混ざって出てきます。製造業の部品表(Bill of Materials)をAIで作る・整えるという文脈です。同じ言葉で中身が違うので、最初に切り分けておくと迷いません。
製造業のBOMは、製品を構成する部品と数量を階層で管理する台帳です。設計変更のたびに更新が必要で、手作業だと転記ミスが積み上がります。
ここに入ってきたAIの役割は、図面データを読んで部品情報を抜き出す、仕様を既存データベースと突き合わせて検証する、欠品や高騰時に代替部品を提案する、といった作業の自動化です。従来のBOMツールの延長ではなく、作業の前提そのものを変える動きとして語られています。
2つの「AI BOM」を並べると、こうなります。
| 観点 | AI BOM(AI部品表) | AIによるBOM管理(製造業) |
|---|---|---|
| BOMが指すもの | AIシステムの構成要素 | 製品を構成する部品 |
| 目的 | セキュリティ・ガバナンス | 設計効率化・調達最適化 |
| 主な利用部門 | 開発、情報システム、法務 | 設計、生産技術、調達 |
| 主な担当者 | エンジニア、セキュリティ担当 | 設計者、購買担当 |
| 関連キーワード | SBOM、AI Act、サプライチェーン | PLM、ERP、CAD |
読者がどちらを探しているかは、所属部門でほぼ決まります。ソフトウェアを作っている側なら前者。ものづくりの現場なら後者。
この記事は前者を主軸に進めます。
AI BOMは誰が作る?社内の役割分担
作るのは開発チーム、運用するのはセキュリティまたは情報システム部門、というのが噛み合う形です。片方だけに任せると、必ず形骸化します。
理由は情報の非対称性にあります。どのモデルをどう呼んでいるかを正確に知っているのは実装した本人だけ。一方で、それを更新し続ける動機を持つのは監査や顧客対応に追われる管理部門です。
役割を切ると、こうなります。
- 開発チーム:新しいモデルや外部APIを追加したら、その場で1行足す
- セキュリティ担当:フォーマットの決定と、抜けの検出
- 法務・調達:ライセンス条件の判断
- プロダクト責任者:更新されているかの最終確認
現実的な落とし所は、プルリクエストのテンプレートに「AI関連の変更あり/なし」のチェック欄を1つ足すこと。あり側にチェックが入ったら台帳の更新を求める。
これだけで、初回棚卸し後の劣化が目に見えて遅くなります。
社内の統制設計そのものを考え直す段階なら、内部監査へのAI活用をまとめた記事を先に読むと、AI BOMを監査サイクルのどこに置くかが決めやすくなります。
AI BOMを作る5つのステップ
やることは、棚卸し・形式決め・記入・検査への組み込み・更新ルールの5段階です。1〜3が初回の山で、4〜5が継続の仕組み。
各ステップの所要感と成果物を並べました。人数はエンジニア5〜20人規模のチームを想定しています。
| ステップ | やること | 所要の目安 | 成果物 |
|---|---|---|---|
| 1. 棚卸し | AI利用箇所を全部洗い出す | 1〜2週間 | 対象一覧 |
| 2. 形式決め | CycloneDXなど記述形式を決める | 1日 | サンプルファイル |
| 3. 記入 | 12項目を埋める | 1〜2週間 | 初版のAI BOM |
| 4. 検査への組み込み | CIで自動チェックする | 2〜3日 | 検査スクリプト |
| 5. 更新ルール | 変更時の手順を決める | 1日 | 運用ドキュメント |
合計で1ヶ月前後。専任を置く必要はなく、既存のセキュリティ運用に相乗りさせるのが現実的です。
ステップ1の棚卸しには、機械的な探し方があります。ソースコード全体を対象に、AI提供元のドメイン名、SDKのパッケージ名、.safetensorsや.ggufといったモデルファイルの拡張子を検索する。これで7割は拾えます。
残り3割は、担当者への聞き取りでしか出てきません。管理画面の設定から呼んでいるもの、ノーコードツール経由のもの、検証用に置いたまま消し忘れているもの。この手のものが必ず出ます。
ステップ2で迷ったら、CycloneDXのML-BOMを選んでおけば無難です。ソフトウェア部品表としての実績があり、機械学習向けの拡張が用意されているため、SBOMと同じ道具で扱えます。SPDXのAI Profileも同種の目的を持ちますが、既存資産に合わせて選べば十分(2026年4月時点)。
ステップ4は、完璧を目指さないこと。「新しいAI関連の依存が増えたのに台帳が更新されていない」を検出するだけで、価値の8割が出ます。
ここまでの整理:AI BOMはSBOMの拡張版で、記載は12項目、作成は5ステップ、初回1ヶ月。ここから先は、道具選びと規制の話に移ります。
AI BOM対応ツールの選び方
専用ツールを買う前に、いま使っているセキュリティ基盤がAI BOMに対応しているかを確認してください。多くの場合、既存の延長で足ります。
選択肢は大きく3タイプ。判断軸つきで整理しました。
| タイプ | 向いているチーム | 費用感 | 注意点 |
|---|---|---|---|
| オープン標準+自作スクリプト | エンジニアリング主導、20人以下 | ほぼ無料 | 属人化しやすい |
| 既存のコードセキュリティ基盤に相乗り | すでにSBOM運用がある | 現行契約の範囲内が多い | AI項目の対応度に差がある |
| AIガバナンス専用ツール | 規制業界、監査対応が本業に近い | 商用契約 | 導入と運用の負荷が重い |
小さく始めるなら1タイプ目、SBOM運用があるなら2タイプ目が最短です。3タイプ目が要るのは、外部監査を定期的に受ける組織に限られます。
2タイプ目を選ぶ場合、コードのセキュリティ検査を担うSnykやAikido Securityのような基盤が候補になります。どちらもSBOMの生成・管理を軸にしており、AI関連の依存をそこに載せる発想と相性がいい。Snykの代替候補も比較してから決めると、機能の過不足が見えます。
似た領域の製品はカテゴリ単位でも眺められるので、AIセキュリティ関連ツールの一覧で全体像を掴んでから絞るのが早いです。
もう1つ、忘れられがちな観点。コーディング支援ツール自体もAI BOMの記載対象になり得ます。GitHub Copilotのような支援ツールが自社コードをどう扱うかは、顧客から聞かれる項目そのもの。開発環境まわりの選定はAIコーディングツールのカテゴリで比較できます。
規制と標準はどこまで来ているか
透明性の要求は、任意の取り組みから契約条件へ移りつつあります。細かい条文より、「聞かれたら答えられる状態」を先に作るほうが実利があります。
大きな流れは3つです(2026年4月時点の状況として整理しています)。
EUのAI規則(AI Act)では、リスクの高い用途に対して技術文書の整備と透明性の確保が求められます。AI BOMそのものを義務づける条文ではありませんが、要求される情報とAI BOMの記載項目は大きく重なります。
ソフトウェアサプライチェーンの流れでは、政府調達を起点にSBOMの提出が一般化しました。AIを含む製品に対して同種の説明を求める動きは、その延長線上にあります。
業界標準の側では、CycloneDXやSPDXといった既存フォーマットが機械学習向けの記述に対応しました。ゼロから独自形式を作る必要はもうありません。
実務への落とし方はシンプルです。法規制が固まるのを待たず、顧客のセキュリティチェックシートに即答できる粒度で台帳を持つ。それが結果的に、どの規制にも効きます。
規制は動きます。台帳は動かないほうがいい。
AI BOMがないと何が起きるか
起きるのは劇的な事故ではなく、静かな遅延です。答えられない質問が積み上がり、商談と障害対応の両方でじわじわ時間を失います。
典型的な3場面を挙げます。
場面1:モデルの脆弱性が公表された日。 影響範囲の特定に半日から数日。台帳があれば数分です。この差は、初動の速さがそのまま被害の大きさになる状況で効きます。
場面2:大手企業のセキュリティ審査。 「入力データが渡る先をすべて挙げてください」に答えられず、回答期限を延ばしてもらう。この時点で評価は下がっています。
場面3:ライセンスの後出し発覚。 研究用途限定のモデルを本番で使っていたと気づくのが、リリース半年後。機能停止か、モデル差し替えの緊急対応か。どちらも高くつきます。
3つとも、記録さえあれば避けられるか、少なくとも軽くなる話です。
画像生成のように重みファイルを直接扱う領域では、ライセンスの複雑さが一段上がります。ComfyUIとStable Diffusionの違いをまとめた記事を読むと、同じ「画像生成」でも配布形態によって管理すべき対象が変わることがわかります。商用利用の可否で選ぶ段階なら、イラスト生成ツールの比較側にライセンス条件の整理があります。
少人数チームの現実解と、よくある失敗
10人以下のチームなら、JSONファイル1つをリポジトリに置くところから始めれば十分です。ツールを買うより、更新が続く形にすることのほうが100倍大事。
現実解はこの3つ。
- リポジトリ直下に
ai-bom.jsonを1つ置く - 必須6項目だけ埋める(7〜11は空欄でよい)
- プルリクエストのテンプレートにチェック欄を1つ足す
これで初日から動きます。増えたら形式を寄せればいい。
一方、失敗パターンもはっきりしています。
失敗1:最初から完璧を目指す。 12項目すべてを全システム分埋めようとして、3週間で止まる。もっとも多い形です。必須6項目に絞れば一周できます。
失敗2:一度作って放置。 半年後に見ると、記載の3割が実態と違う。日付のない台帳は、あるほうが危ないことすらあります。信じて判断した結果が間違うので。
失敗3:管理部門が単独で作る。 実装を知らない側が推測で埋めるため、精度が上がりません。開発チームが1行足す仕組みに変えるほうが確実です。
どれも「小さく作って回す」で回避できます。
社内での情報収集や下調べを効率化したいなら、リサーチ用のAIをうまく挟む手もあります。仕様書やライセンス条文を読み解く場面では、Feloの使い方をまとめた記事が参考になります。自社の環境にどのAIが入っているかを把握する文脈では、SNSやOS標準に組み込まれたAIの挙動を整理したMeta AIの解説記事も、見落としがちな利用面を思い出す助けになります。
AI PICKS編集部の判定
AI BOMは、2026年時点で「やっておくと後で楽」ではなく「無いと商談で詰まる」段階に入りました。特に法人向けにサービスを提供しているなら、一択で作るべきです。
ただし、専用ツールの導入から入るのは正直イマイチ。AIガバナンス専用の製品は機能が豊富な反面、運用の重さに対して得られるものが釣り合わないケースが目立ちます。外部監査を定期的に受けているのでなければ、まだ早い。
現実的な最適解は、JSONファイル1つと必須6項目、そしてプルリクエストのチェック欄。この3点セットなら初期費用ゼロで、1ヶ月あれば一周できます。既にSnykなどのセキュリティ基盤を入れているチームは、そこに相乗りさせるのが圧倒的に速い。
そして最大の価値は、実はセキュリティではありません。「うちのAI、どこで何が動いてる?」に3秒で答えられる状態そのものが、意思決定の速度を上げます。モデルを乗り換えるとき、値上げに対応するとき、影響範囲がすぐ出る。この地味な効き目が、運用を続ける本当の理由です。
作らない理由が「面倒だから」なら、必須6項目版から始めてください。
関連する比較・代替を見る
AI BOMの受け皿になるセキュリティ基盤と、記載対象になりやすい開発ツールの比較です。
- Aikido SecurityとSnykの比較 — SBOM運用の乗せ替え先を選ぶとき
- GitHub CopilotとSnykの比較 — 生成と検査、どちらに投資するか
- CursorとSnykの比較 — 開発環境側とセキュリティ側の役割分担
- Claude CodeとGitHub Copilotの比較 — 台帳に載る支援ツールの選定
- CursorとGitHub Copilotの比較 — コード生成環境の乗り換え検討
- ClineとGitHub Copilotの比較 — 自社ホスト志向のチーム向け
- Snykの代替ツール — 費用や対応範囲で見直したいとき
よくある質問(FAQ)
Q. AI BOMとSBOMは両方作る必要がありますか?
はい、両方です。ただし別ファイルにする必要はありません。CycloneDXのように1つのフォーマットで両方を表現できる形式を使えば、既存のSBOMにAI関連の記述を足すだけで済みます。運用も1本にまとまるので、そのほうが続きます。
Q. 外部APIを使っているだけでも作る必要がありますか?
必要です。むしろ外部API利用こそ記録の価値が高い部類。データがどこへ渡るかは、顧客からもっとも聞かれる項目だからです。自社サーバーで完結している構成のほうが、説明はまだ簡単。
Q. 学習データの出所がわからない場合はどう書きますか?
「提供元非公開」と明記してください。空欄にすると、調べた結果なのか未着手なのか区別できなくなります。調べた上でわからなかった事実も、それ自体が記録として意味を持ちます。
Q. どのくらいの頻度で更新すべきですか?
定期更新より、変更時の都度更新をおすすめします。モデルを追加・変更・削除したタイミングで直す。そのうえで四半期に一度、全体の棚卸しを入れる二段構えが現実的です。日付の記録を忘れずに。
Q. 無料で始められますか?
始められます。CycloneDXもSPDXもオープン標準で、仕様の利用に費用はかかりません。生成ツールにもOSSが揃っています。有償になるのは、大規模な集中管理や監査レポートの自動生成といった上位の機能から。
Q. 製造業のBOM管理とは関係ありますか?
直接の関係はありません。同じ「BOM(部品表)」という言葉を使っているだけで、対象も担当部門も別物です。製造業側の文脈は、CADデータの読み取りや部品仕様の照合をAIで効率化する話になります。
Q. 小さなスタートアップでも必要ですか?
法人向けにサービスを売るなら必要です。むしろ小規模なうちに始めるほうが、対象が少なくて楽。従業員5人の段階で仕組みを作っておけば、50人になったときの棚卸し地獄を回避できます。
Q. ノーコードツールで作ったAI機能も対象ですか?
対象です。実装がコードに残らないぶん、棚卸しでいちばん見落とされます。管理画面の設定から呼んでいるAI、業務自動化ツールに組み込んだAI。これらは検索では出てこないので、担当者への聞き取りで拾ってください。
台帳の置き場所が決まったら、次はそれを監査サイクルにどう組み込むかが課題になります。内部監査へのAI活用をまとめた記事を読むと、AI BOMを年次の統制フローに載せる具体像が掴めます。
各ツールの公式サイト(一次情報)
料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。
- Snyk — 公式サイト(AI PICKSの詳細)
- Aikido Security — 公式サイト(AI PICKSの詳細)
- GitHub Copilot — 公式サイト(AI PICKSの詳細)
