CRACIとAIセキュリティツール：決定論的な可視性の役割

チームはおそらく、すでにセキュリティにAIを取り入れています

今ではほとんどのエンジニアリングチームが、セキュリティのループに少なくとも1つのAIツールを組み込んでいます。あるモデルはプルリクエストをレビューし、別のモデルは静的解析のアラートに修正を提案し、3つ目はスキャナーの検出結果を「確認すべきもの」と「おそらくノイズ」に仕分けます。こうしたツールは実際に時間を節約しており、このページはそれに反対するものではありません。

有益な問いは、どの仕事をAIツールに任せ、どの仕事に毎回同じ結果が出る記録が必要かということです。それと対になる問いは、AIツールが依存関係について判断するときに何を読んでいるかです。

AIセキュリティツールが得意なこと

AIコードレビュー。GitHub Copilot code reviewは、プルリクエストに自然言語のコメントとコードの提案を残し、リポジトリ固有の指示にも従えます。忙しいレビュアーが飛ばしてしまう読み込み作業に長けています。
AIによる修正。GitHub Copilot Autofixは「プルリクエストとデフォルトブランチで見つかったCodeQLアラートに対して、コード変更の提案を自動生成」します。開発者は、CWEページへのリンクではなく、アラートの隣に修正パッチの提案を受け取れます。
AIトリアージ。SemgrepのAI機能は、Semgrep Codeの検出結果を自動トリアージし、修正を提案します。Semgrepはそのノイズフィルタリングについて「Semgrep Codeの検出結果を誤検知として分類する精度は95%以上」と記載しています。

後の2つに共通するパターンに注目してください。Copilot AutofixはCodeQLのアラートを対象に動作します。SemgrepのトリアージはSemgrepのルールベースのエンジンの検出結果を対象に動作します。AIは決定論的な出力の上に判断を加えるものであり、元となる検出結果そのものを生み出しているわけではありません。

ベンダー自身が語る限界

AIツールの限界を最も明確に述べているのはベンダー自身であり、それは評価すべき点です。

コードレビューについて、GitHubは「Copilotはコードに存在するすべての問題を特定できるとは限らない」と記し、さらに「ハルシネーションのリスクがある」、つまり存在しない問題を指摘することがあると述べています。
Autofixについて、GitHubは「非決定論的な生成モデルを使用している。同じアラートとコードであっても、有効な提案を生成できないことがあり、また試行ごとに提案が異なる場合がある」と記しています。
同じくAutofixについて、「システムはどの依存関係のバージョンがサポートされているか、安全かを把握しておらず、統計的にありそうな名前で公開された架空の依存関係を提案する場合がある」とも記しています。

だからといって、これらのツールの有用性が下がるわけではありません。これはツールの役割を定めるものです。つまり、人が確認するための提案を生み出すことです。それは、人が照合の拠り所とする記録を生み出す仕事とは別物です。

2つの層、2つの役割

機能	CRACI	AIセキュリティツール
答える問い	このビルドは何を取り込み、それは出荷されたか？	このコードや検出結果は本当に問題か？
ビルドが取り込んだものの記録	SBOM、ネットワークトレース、来歴データ	他の何かが記録したものしか見えない
同じ入力から同じ出力	推測は一切なし	ベンダー自身が記載しているとおり、出力は変動しうる
完全性の明示	ジョブごと・キャッシュごと	提示されたコードと検出結果の範囲に限られる
コードのロジックのレビュー		Copilot code reviewがプルリクエストにコメント
検出結果のトリアージ	検出結果をトリアージしてチームに振り分け	Semgrep Assistantの自動トリアージ
最適な用途	監査人や顧客に提出できるエビデンス	人間のレビュアーが判断に使う助言

対応
非対応

CRACIは記録の層に位置します。CRACIはGitHub Actionsのランナーを置き換え（runs-onをcraciに変更します）、ジョブの実行中に、パッケージを認識するプロキシがビルドからパッケージソースへの通信を監視します。出力されるのは、ジョブが実際に取り込んだもののSBOM、ジョブとキャッシュごとの完全性の状態、そしてネットワークトレースです。APIはSBOM、ネットワークトレース、来歴を返します。

決定論的な可視性が必要な場面

「自社は影響を受けるか？」

新しいアドバイザリが公開されたとき、最初の問いは、自社のいずれかのビルドに影響を受けるバージョンが含まれていたかどうかです。CISAの2026年版SBOM最小要素は、この要件を明確に述べています。SBOMの受領者は「SBOMにそのコンポーネントが記載されていなければ、新たに報告された脆弱性の影響を受けないと結論付けられるべきである」。この結論は、一覧が完全な場合にしか成り立ちません。モデルは答えを読み解く手助けはできますが、ビルドに何が含まれていたかを決めるものであってはなりません。

CRACIはビルドとリポジトリをまたいで脆弱性を集約し、新たな脆弱性が公開されるたびに監視対象のSBOMを再評価するため、この問いには記録された内容から答えが出ます。

AIが追加した依存関係

AIコーディングアシスタントは依存関係を追加しますが、存在しないパッケージ名を挙げることがあると研究で示されています。USENIX Security 2025で発表された研究では、16のモデルで576,000件のコードサンプルを生成し、ハルシネーションによるパッケージの平均割合が、商用モデルで少なくとも5.2%、オープンソースモデルで21.7%であることが分かりました。今日存在しない名前は、明日には登録されるかもしれません。誰が、あるいは何が依存関係を追加したかにかかわらず、CRACIはビルドが実際にダウンロードしたパッケージを記録し、ネットワークのエグレスポリシーでジョブの接続先を承認したパッケージソースに限定できます。

監査と顧客からの質問

監査人や顧客のセキュリティチームは、出荷内容をどうやって把握しているのかを尋ねてきます。「モデルがそう言った」は弱い答えです。「これがリリースビルド中に記録されたSBOMとその完全性の状態、そしてそのジョブのネットワークトレースです」は強い答えです。SBOMは脆弱性を含めてCycloneDXまたはSPDXでエクスポートでき、APIはSBOM、ネットワークトレース、来歴を返します。

再現可能な答え

誰がいつ尋ねても同じ答えが必要な問いがあります。先週火曜日のリリースはどのパッケージを取り込んだのか。生成モデルはその答えを上手に表現できますが、ベンダー自身の説明によれば、尋ねるたびに表現が変わる可能性があります。記録されたビルドが返す答えは1つです。

2つをどう組み合わせるか

うまくいくパターンは、Copilot AutofixとSemgrepがすでに採用しているものです。土台に決定論的なデータを置き、その上にAIの判断を重ねます。

AIコードレビューとAIによる修正はプルリクエスト上で動かし、すべての変更を人間が承認します。
CRACIには、各ビルドが取り込んだものを記録させ、その記録が完全かどうかを示させます。
依存関係のリスクについてAIの助けが欲しいときは、記録されたSBOMをモデルに渡します。CRACIの公開REST APIは、CycloneDX形式のSBOM、ジョブのネットワークトレース、成果物の来歴を返します。
エビデンスとして保持するのは、モデルによる要約ではなく、記録されたSBOMです。

チームがコードの多くをAIアシスタントで書いている場合は、AI開発のセキュリティのページでその状況を取り上げています。また、ビルド時のSBOM生成では、記録がどのように作られるかを説明しています。

AIセキュリティツールはコードを読みます。ビルドの記録は別に必要です。