AIが生成したSBOMはビルドについての推測です。規制当局が求めているのは記録です。

チームが試したくなる理由

その魅力は本物です。リポジトリやロックファイルをコーディングアシスタントに貼り付けてCycloneDXを依頼すれば、整った形式のドキュメントが数秒で返ってきます。スキャナーが通常は空欄のままにするフィールドまで埋めることもあります。よくある例がsupplierフィールドです。ほとんどの生成ツールにはその情報源がないため、空欄になります。完全なドキュメントを求められたモデルは、すべてのフィールドに何かを書き込むことができます。

この最後の点に、問題が凝縮されています。supplierを知らないスキャナーはフィールドを空欄にします。それを知らないモデルでも、もっともらしい答えを出してしまうことがあります。ドキュメントはより完全に見えますが、信頼性は下がります。

モデルが実際に見ているもの

SBOMを生成するモデルは、目の前にあるテキスト、つまりマニフェスト、ロックファイル、場合によってはDockerfileから作業します。ビルドを観測するわけではありません。そのため、次のものは見えません。

• リポジトリがロックファイルをコミットしていない場合に、パッケージマネージャーが解決したバージョン
• CIキャッシュから復元されたパッケージ
• ビルドステップが直接ダウンロードするツール、OSパッケージ、バイナリ
• ほぼ空のマニフェストとともに出荷されるコンパイル済みバイナリに入っているもの

ファイルの情報がいかに乏しいかを示す2つのリポジトリがあります。expressjs/express 5.2.1はロックファイルをコミットしていないため、package.jsonには依存関係がバージョン範囲として記載され、実際のバージョンはインストール時に決まります。v2.1.259時点のanthropics/claude-codeリポジトリには、依存関係のマニフェストもロックファイルも一切なく、公開されているnpmパッケージはビルド済みのネイティブバイナリをラップしながら、ランタイム依存関係をゼロと宣言しています。そのリポジトリを対象にした決定論的なスキャナーには、そのバイナリを説明する読み取り対象が何もありません。同じファイルを与えられたモデルも同じく情報を欠いており、しかもその隙間を埋める自由度がより高いのです。

ハルシネーションは文書化された失敗モード

言語モデルは、存在しないパッケージの名前を挙げます。最もよく測定されている事例はSBOMの作成ではなくコード生成ですが、そこで示された失敗はコンポーネントの一覧にもそのまま当てはまります。USENIX Security 2025の研究では、16のモデルで576,000件のコードサンプルを生成し、ハルシネーションによるパッケージの平均発生率が商用モデルで少なくとも5.2%、オープンソースモデルで21.7%に達し、ハルシネーションによる固有のパッケージ名は205,474件にのぼりました。GitHub自身のCopilot Autofixのドキュメントも、「統計的にありそうな名前で公開された捏造の依存関係を提案する可能性がある」と警告しています。

モデルはまた、同じ答えを2回返すとは限りません。Anthropicのドキュメントには「temperatureを0に設定しても、結果は完全には決定論的にならず、同一の入力でもAPI呼び出しごとに異なる出力が生成される場合がある」と記載されています。同じコミットから生成した2つのSBOMが異なることがあり、どちらが正しいかはどちらも示しません。

SBOMにおいて、ハルシネーションによるエントリは無害なタイプミスではありません。存在しないパッケージや、実在するパッケージの誤ったバージョンは、脆弱性の照会を誤った場所に向かわせ、その結果は自信満々で、しかも間違っています。

標準がSBOMに求める内容

NTIAの最小要素（2021年）

NTIAのベースラインは、7つのデータフィールドを定義しました。サプライヤー名、コンポーネント名、コンポーネントのバージョン、その他の一意の識別子、依存関係、SBOMデータの作成者、タイムスタンプです。これらは自動化のサポート、そして一連のプラクティスとプロセスと組み合わされています。どのフィールドもソフトウェアについての事実を表すもので、意見ではありません。

CISAの2026年版最小要素

2026年7月29日、CISA、NSA、FBIと国際的なパートナーは、2021年のベースラインに代わる最小要素の改訂版を公開しました。追加された項目のいくつかは、ビルドを観測しなければ満たすことが困難です。

• SBOM Generation Context：「SBOM作成者がSBOMを生成した時点での、ソフトウェアライフサイクルの相対的なフェーズと利用可能なデータ」で、例として「before build」「build」「after build」が挙げられています。リポジトリを読むモデルは、せいぜいbefore buildです。
• Component Hash Value：「実行可能なコンポーネントの成果物に暗号学的ハッシュアルゴリズムを適用して生成された出力」。作成者が成果物を持っていない場合は、「SBOM作成者はその値が不明であることを示すべき」とされています。成果物に一度も触れていないモデルはハッシュを生成できず、ハッシュのような形をしたテキストを作れるだけです。
• SBOM Tool Name and Version：SBOMの生成に使ったツールの名前を示す必要があります。
• Coverage：「SBOMには、推移的依存関係を含め、対象ソフトウェアを構成するすべてのコンポーネントの情報を含めるべきである。最小の深さというものはない。」
• 不明な情報の明示：作成者は「その情報が不明かどうかを明示すべき」です。捏造された値はその正反対です。

EUのCyber Resilience Act

CRAは、デジタル要素を含む製品の製造業者にとって、SBOMを法的義務としています。附属書I第II部は、「一般的に使用される機械可読形式で、少なくとも製品のトップレベルの依存関係を対象とするソフトウェア部品表を作成することを含め、デジタル要素を含む製品に含まれる脆弱性とコンポーネントを特定し文書化する」ことを求めています。附属書VIIはSBOMを技術文書に位置付けており、市場監視当局は必須要件への適合を確認するためにそれを要求できます。

これらの文書のいずれも、AIツールを禁止してはいません。求めているのは、実際の製品を表すデータと、何が不明かについての誠実な記述です。推論から書かれたSBOMは、その両方に苦戦します。

CRACIがSBOMを生成する方法

CRACIはGitHub ActionsのジョブをCRACI独自のランナーで実行します。runs-onをcraciに変更するだけで、実行結果は引き続きGitHubに表示されます。ジョブの実行中、パッケージを認識するプロキシがパッケージソースへの通信を観測するため、SBOMには推移的依存関係を含め、ビルドが実際に取り込んだものが記録されます。依存関係のエビデンスはCIキャッシュとともに引き継がれるため、キャッシュから復元されたパッケージも記録に残ります。

• エコシステム：npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースに加え、ダウンロードプリセット。
• 完全性：すべてのジョブとキャッシュに、Complete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかが付くため、不明な点は埋められるのではなく明示されます。
• フォーマット：CycloneDXとSPDX。宣言ライセンスのメタデータもエクスポートに含まれます。
• 来歴：APIはSBOM、ネットワークトレース、来歴を返します。

CRACIは、より広範なCRAコンプライアンスプロセスに必要なサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。ただし、それだけで製品がコンプライアンスに適合するわけではありません。詳細はビルド時のSBOM生成で、スケジュールはCRAの概要で解説しています。

AIがSBOMで役立つところ

記録されたSBOMがあれば、モデルはそれを扱うのが得意です。どのコンポーネントにリスクがあるかを要約したり、アドバイザリをわかりやすい言葉で説明したり、人がレビューするための関連ドキュメントの下書きを作成したりできます。ルールはシンプルです。記録はビルドに作らせ、モデルにはそれを読ませることです。