AIセキュリティツールが不十分になる場面と、決定論的なビルドのエビデンスがカバーするもの

主張を限定して述べると

これはセキュリティにおけるAIの利用に反対するものではありません。モデルはコードを読み、検出結果を説明し、修正を提案するのが得意で、うまく活用しているチームはより速く進められます。主張はもっと限定的です。後になっても通用しなければならない記録については、確率的なモデルを主要な情報源にすべきではありません。これには、規制当局に提出するSBOM、出荷した成果物の来歴、そして「影響を受けていたか」という問いへの答えが含まれます。

記録が通用するかどうかは、3つの特性で決まります。以下の各セクションで、それぞれを具体例と出典とともに取り上げます。

1. 再現性：2回尋ねて同じ答えが得られるか

セキュリティの記録は、他の人が同じ入力から同じ答えを得られる場合にのみ役に立ちます。言語モデルはそれを約束しておらず、ベンダー自身もそう述べています。

• Anthropicのドキュメント：「temperatureを0に設定しても、結果は完全には決定論的にならず、同一の入力でもAPI呼び出しごとに異なる出力になる可能性があります。」
• GitHubはCopilot Autofixについて：「同じアラートとコードであっても、実行可能な提案を生成できない場合や、試行ごとに提案が異なる場合があります。」
• SecLLMHolmesフレームワークを構築した研究者らは、IEEE S&P 2024向けに8つのLLMを228のコードシナリオでテストしました。モデルは「非決定論的な応答を返す」と報告しており、「関数名や変数名を変えるだけで、あるいはソースコードにライブラリ関数を追加するだけで」、PaLM2とGPT-4はそれぞれ26%と17%のケースで誤った回答をしました。

例。2人のエンジニアが同じアシスタントに、あるサービスが新しいアドバイザリの影響を受けるかを尋ねます。一方は「いいえ」、もう一方は「可能性あり。推移的依存関係のツリーを確認してください」という答えを得ます。どちらの答えも記録ではなく、6か月後に監査人のために再現することもできません。

記録されたビルドにはこの問題がありません。何も推論していないからです。CRACIはジョブの実行中に、ジョブがパッケージソースから取得するパッケージを観測し、SBOMはその観測の記録です。

2. 監査可能性：どうして分かるのかを示す

監査は「どうして分かるのですか」という問いを軸に進みます。モデルは流暢な答えを返せますが、その説明はエビデンスではありません。SecLLMHolmesの評価では、LLMは評価対象の脆弱性について「誤った、実際と一致しない推論」を示すことが分かりました。つまり、正しい判定に成り立たない説明が付いてくることがあります。

標準規格は、自らの出どころを説明する記録へと向かっています。CISAがNSA、FBI、国際パートナーとともに公開した2026年版のSBOM最小要素には、SBOM Tool Name、SBOM Tool Version、そしてSBOMが「ビルド前」「ビルド中」「ビルド後」のいずれで作成されたかを示すSBOM Generation Contextが追加されています。同じ文書は、「組織は、SBOM作成者の慣行によるものであれ、不適切なツールの選択によるものであれ、誤りを組織のリスク管理上の判断において考慮する場合がある」と警告しています。

例。顧客からの質問票で、SBOMの作成方法を尋ねられたとします。「アシスタントがリポジトリを読んで書いた」は作成のコンテキストにはなりますが、レビュー担当者が確認できるものではありません。「リリースビルド中にCIランナー内で記録され、ジョブの完全性の状態はCompleteである」であれば、レビュー担当者がビルドと照らし合わせて検証できます。

3. 完全性：見ていないものは報告できない

モデルは示されたものに基づいて推論します。読み取るファイルがソフトウェアを記述していなければ、答えも記述せず、出力のどこにもそのことは示されません。CISAの2026年のガイダンスは、受け取る側の判断を基準にしています。受け取る側は「SBOMにコンポーネントが記載されていなければ、新たに報告された脆弱性が自らに影響しないと結論づけられるべき」です。これが成り立つのは、一覧にないことがビルドにないことを意味する場合だけです。

例。v2.1.259時点のanthropics/claude-codeリポジトリには、依存関係のマニフェストもロックファイルも一切ありません。公開されているnpmパッケージはランタイム依存関係をゼロと宣言しており、ビルド済みのネイティブバイナリをラップしています。リポジトリを読み取るツールは、AIであれそれ以外であれ、記載すべきものがほとんどありませんが、実際に動作するプログラムはコンパイル済みのバイナリです。

例。AIコーディングツールがギャップを自ら生み出すこともあります。GitHubは、Copilot Autofixが「統計的にありそうな名前で公開された、捏造された依存関係を提案する可能性がある」と警告しています。USENIX Security 2025で発表された、16のモデルが生成した576,000件のコードサンプルの研究では、ハルシネーションによるパッケージの割合が平均で商用モデルでは5.2%以上、オープンソースモデルでは21.7%に達し、ハルシネーションによる一意のパッケージ名は205,474件にのぼりました。

決定論的であることは必要条件だが、十分条件ではない

この主張を誠実に述べるなら、次の点も含めなければなりません。SBOM生成ツールは決定論的ですが、それでも互いに一致しません。expressjs/expressの同じコミットを対象にしても、異なる一覧を返すことがあります。何をコンポーネントとみなすか、どのファイルを信頼するかを、それぞれが独自に判断するためです。このリポジトリにはロックファイルがコミットされていないため、ロックファイルから依存関係を解決するツールは、package.jsonの依存関係を1つも報告できません。

決定論的なスキャナーは、同じ不完全な答えを毎回再現します。再現性は必要ですが、ギャップを埋めるのは観測です。つまり、ビルドが実際に取り込んだものを記録し、記録が不完全な場合はそれを明示することです。CRACIはすべてのジョブとキャッシュを、Complete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかとしてマークします。

具体例：新しいアドバイザリの影響範囲を特定する

仮の例です。広く使われているnpmパッケージのあるバージョンについてアドバイザリが公開されたとします。Cyber Resilience Actのもとでは、メーカーは実際に悪用されている脆弱性を24時間以内にENISAへ報告しなければならないため、影響範囲の特定は迅速かつ正確でなければなりません。

AIを起点とする方法

アシスタントにリポジトリの確認を依頼します。アシスタントはマニフェストとロックファイル、場合によってはDockerfileを読み取ります。CIキャッシュから復元されたパッケージ、ビルドステップがダウンロードしたツール、ロックファイルのないリポジトリでインストール時に解決されたバージョンは見えません。2回尋ねれば、異なる答えが返ってくるかもしれません。その要約は役に立ちますが、それに基づいて報告書に署名することはできません。

記録を起点とする方法

CRACIは、組織レベルでデフォルトブランチを対象に、ビルドとリポジトリをまたいで脆弱性を集約し、新たな脆弱性が現れるたびに監視対象のSBOMを再評価します。APIは各ビルドのCycloneDX SBOM、ネットワークトレース、来歴を返します。ジョブの記録が不完全な場合は、その完全性の状態から、手作業で確認すべき箇所が分かります。結果の要約をモデルに依頼することもできます。その場合、モデルは記録を要約しているのであって、記録を生成しているわけではありません。

記録があれば、「どのリリースがこのパッケージを出荷したか」という問いは調査ではなく、検索で済みます。

一覧比較

それぞれのツールを強みが活きる場所で使う

判断力が役立ち、人間が出力を確認する場面ではAIを使います。コードレビュー、検出結果の説明、修正案の作成などです。出力を再現、監査し、完全なものとして信頼する必要がある場面では、決定論的なビルドの記録を使います。SBOM、来歴、インシデントの影響範囲特定などです。CRACIは、より広範なCRAのプロセスに必要なサプライチェーンのエビデンスのかなりの部分を自動化します。CRACIだけでコンプライアンスを実現するものではありません。

記録の作成方法についてはビルド時SBOM生成をご覧いただくか、まずはCRAが求めるものからお読みください。