AI・信頼性・評価

AIの脆弱性発見はどこまで信用できるか：DARPA競技の実績と誤検出

2026/7/20 （更新: 2026/10/13）

🤖 AIを使用して執筆

舞台の上：AIが本物の穴を見つけ、パッチまで出した

AIxCC（AI Cyber Challenge）は、7チームのサイバー推論システム（CRS）を競わせた。CRS は人間の介入なしに、大規模なCコード・Javaコードを読み、脆弱性を発見し、動く実証（PoV, Proof of Vulnerability）で再現し、パッチまで自動生成する。競技は、それを制限時間内にどれだけこなせるかを採点する。

結果は具体的だ。決勝の採点ラウンドが用意した63件の課題脆弱性のうち、システム群は54個を発見し43個を修正した。発見率は86%、修正率は68%で、1年前の準決勝の37%・25%から大きく伸びている¹。DARPA は63件すべてを合成と数え、体系化研究のほうは、大半が歴史的なN-dayを模した手作りの合成で、一部は課題づくりの最中に見つかった実在の0-dayだったと書き分けている²。合成も0-dayも、競技側が課題として仕込んだ分である。仕込まれた課題だけではない。システム群はこの63件とは別に、実在の（合成でない）脆弱性を18件掘り当て、責任ある開示に回した。内訳はCで6件、Javaで12件である。修正パッチも11件出している。競技データベース全体を事後に集計した体系化研究のほうは、全7チームが少なくとも1件の0-dayを見つけ、競技の課題として出された10のオープンソースにまたがる25件、うち12件（48%）がパッチ済みと数える。18件・11件との差の理由を、体系化研究は書いていない²。勝ったのは Team Atlanta（ジョージア工科大・Samsung・KAIST・POSTECH）。優勝から最下位まで、全チームがCRSをオープンソースとして公開することになった。競技データも数週間のうちに公開すると予告されたが¹、体系化研究の最終版（2026年8月）の時点でもなお DARPA の公式公開待ちで、稼働記録（テレメトリ）もチームが選んで主催者へ上げた分にとどまる²。

信じてよい根拠は、競技が強制した「検証」にある

数字を鵜呑みにする前に、AIxCC が何を要求したかを見る必要がある。脆弱性を「見つけた」と主張するには、実際にバグを発火させる入力（PoV）を示さねばならない。修正を「した」と主張するには、そのバグが再発せず、かつ既存の機能テストを壊さないパッチを示さねばならない。言い張るだけでは1点も入らない。静的解析の警告が本物の脆弱性かを判定する課題にも小さな配点があったが、その判定も主催者の正解と照合され、誤りは減点された²。AIxCC は検証を採点の前提に組み込んでいた。主催者側の発言も、同じ点を述べている。AIxCC プログラムマネージャの Andrew Carney は「サイバー推論システムが脆弱性を見つけるというプロセスそのものが、他のコード合成手法が苦戦する場面でパッチ開発を後押ししうる、という証拠が見えている」と述べた¹。

この土俵の上で、LLM は古典的手法に確かな上乗せをした。AIxCC を体系分析した体系化研究（SoK）は、63個の脆弱性のうち並列ファジングだけで解けると注釈できたのは34件（54%）だとする。CRS 群はそこへ、ファジングでは解けない22件（C8件・Java14件）を上乗せした。SoK によれば、並列ファジングを超える追加要素として最も広く開発されたのは、PoV生成へのLLM導入である。SoK はこの上乗せを、LLM導入に大きく帰せられるとみている²。Java は入力の意味的制約が強く、timeout や OOM のようにファジングが苦手とする型の課題も多い。意味を読む力が効いた場面を、原典は三つに分ける。一つは標的つきの検出で、上乗せの22件のうち15件は脆弱性を含む差分が与えられる delta 課題であり、場所のヒントを得た CRS が変更箇所を読んで発火入力を直接生成した。残る二つは、複雑な入力文法を満たす入力の生成と、正規表現や符号化のような論理制約を解くことである²。決勝の実像は、LLM と古典的手法が競うのではなく補い合う姿だった。

だが、修正はまだ危うい

同じ SoK 分析は、パッチの正しさが未解決だと明記する²。競技に出た CRS の意味的正解率は 23.3%から100% まで開いた。7チーム中4チームは75%以上に届いており、低いのは3位のチームの31.7%と4位の23.3%で、序盤のあとはほぼ止まっていたチームも33.3%（提出3件）だった。正解率は最終順位を追っていない（100%を出したのは5位のチームである。原典はこの100%を、パッチ後5分のファジングのような厳しい選別と直した課題の分布の反映とみており、意味的な正しさを解決した結果とはしていない²）。それでも原典は、正解率を最終順位のもう一つの主要因と数える。3位のチームは減点の前なら2位を上回っていたが、減点で2位に8.7点届かなくなった²。低かった3位と4位の正解率について、原典は「一様に弱いパイプラインではなく、少数の課題で無効な提出が連続したことに主に起因する」と明言している（重複排除を欠いた並列生成のような戦略上の問題との関連は、推測にとどめている）。パッチの意味が7割方誤っていた、という読み方はできない。別の数字もある。比較のために実験室条件で走らせた基盤エージェント（Claude Code・MultiRetrieval）は、正解のPoVとサニタイザ報告とクラッシュスタックを渡されたうえで走っている。それでも、ビルド・PoV再現・既存機能テストという自動検証をすべて通過したパッチのうち37.7%（53件中20件）・45.6%（57件中26件）が、手動レビューで初めて意味的に誤りと判明した。自動検証を通ることと、意味が正しいことは別物だという証拠だ。競技の側でも、正解率の高い CRS に共通するのは複数PoVでの検証・パッチ後ファジング・LLMによる自己反省といった検証機構を足したことだが、原典はそれでも誤ったパッチは全体として依然多いと書く²。数で言えば、上位の CRS の意味的誤りは16〜21%で、正解の PoV を渡された基盤エージェントの38〜46%を大きく下回るが、無視できる水準ではないとも原典は書く²。

原典は、基盤エージェントのパッチが自動検証をすり抜けた誤りを、いくつかの型に分けている。一つは、クラッシュは消えるのに、機能テストが覆っていない範囲で挙動が変わる型である。あるパッチは色変換が周辺画素に依存することを取り違え、輪郭の色を狂わせた。根本原因を直さず反復回数の上限をハードコードして、時間切れの課題を黙らせるものもある²。見つけても直せない例も残り、7件はどのシステムも基盤エージェントも修正できなかった。いずれも Java で、無限ループや JVM クラッシュのように有用なスタックトレースが得られない類か、現在のエージェントの推論を超える論理的複雑さを持つ類だった。

勝敗を分けたのは、技術力だけではなかった。原典は「AIxCC で勝つには研究・エンジニアリング・戦略の三つを釣り合わせる必要があり、安定性が最も基本的な要件だった」と要約している²。実際、優勝チームは2位の約1.8倍を得点し（392.8対219.4）、その差は全フェーズで得点を積み続けたことから来ている。2位・3位のシステムは第3・第4フェーズ以降で伸びが止まった。長時間の自律運転では、賢さと同じくらい止まらないことが効く。裏を返せば、低い点から能力の不足は読めない。原典は「低いスコアが本当の能力差なのか、障害や戦略選択の反映なのかは区別できない」と注意している。一方で、高い点はある程度まで設計の効き目を示す、とも書いている²。決勝の課題設計についても「難しさより実世界のカバレッジを優先した」ものだとする。PoV 側で並列ファジングに解けると注釈された34件と同じく、パッチ側も最小限のパッチエージェント単体で63件中31件が直せる、という水準である²。競技の舞台の上でも、自律AIはまだ危うい。

舞台を降りると：誤検出の山

競技の外では、別のツールを測った研究が逆の像を報告している。天津大・北京大などのチームが（査読前のプレプリントで）、LLM による脆弱性検出を実プロジェクト規模で評価した³。本稿が引くこの研究の数は、2026年1月に公開された初版のものである。同年9月の改訂版は、汎用のエージェント2種（Codex・Claude Code）を加え、6,442件の警告を Codex の補助によるラベル付けと人手による層別の確認で調べ直しており、誤検出率がいちばん低かったのはそのうち Codex の9.09%（C/C++）・31.82%（Java）だった³。以下は初版の内容である。著者らが評価した5手法は静的解析に LLM の推論を組み合わせた検出器で、バックボーンは各手法の原論文が推奨した GPT-4・O3-mini・Claude 3.5 Sonnet のまま走らせている。著者らが自ら構築した、222個の既知脆弱性を含むベンチ（既知の実在脆弱性をどれだけ検出できるかを測る）と、稼働中の24のオープンソースに対し、手作業で385件の警告を精査している。結果、誤検出（false discovery）率は LLM 系で93〜100%、伝統的ツールも CodeQL 85.3%（C/C++）〜94.3%（Java）・Semgrep 92.3%（C/C++）〜100%（Java）と同じ水準だった。著者らは、この誤検出率が実プロジェクトでの実用を妨げると結論づけた。

ただし並び方は言語で変わる。Java では両者の範囲が重なり、Semgrep の100%はどの LLM 系よりも高い。C/C++ では重ならず、KNighter 100.0% と RepoAudit 97.0% が Semgrep 92.3%・CodeQL 85.3% を上回る。「LLM だから誤検出が多い」という順位づけは、C/C++ の列だけなら出てくるし、Java の列だけなら出てこない。言語をまたいで安定する向きは、このデータからは読み取れない。並びを細かい順位として読むには、そもそも土台が揃っていない。誤検出率はツール×プロジェクトごとに最大10件を抜き出した標本の上の率で、規則が固定された伝統ツールは警告を出す先が限られる。Java で Semgrep が当たったのは12プロジェクト中6つ、CodeQL は15中8つだ。精査した件数もツールで開き、Semgrep の37件（うち誤検出37件）に対し LLMDFA は15件（うち14件）である。

しかもベンチ上ですら平均リコールは C/C++ で21.09%、Java で33.82%にとどまる。低い数字だが、伝統ツールはさらに低い。Java で CodeQL・Semgrep が捉えたのは概ね1割前後で、C/C++ の3つのCWE型では両者とも1件も検出できていない（同じ型では LLM 系の KNighter も0件だった）。このベンチ上では、LLM 系のほうが固有の脆弱性を多く掘り当てた、というのが強みの中身だった³。その上で現場では、警告の大半が空振りになる。

誤検出は、検証の有無だけの問題でもない。同じ研究は、偽陽性の主因を手続き間解析の浅さ（37.5%）と source/sink 同定の誤り（19.0%）に帰している³。伝統的ツールも同じ水準の誤検出を出したことと合わせれば、プロジェクト規模の静的解析が一般に抱える難しさが、まず土台にある。ただし同じ研究は、LLM 系にはこれに加えて「コード理解そのものの幻覚」と指示追従の失敗という固有の失敗が乗る、とも報告している³。

空振りは安くもない。原典は3つ目の主要所見としてコストを挙げ、数十万から数億のトークンと、数時間から数日の実行時間を報告する。RepoAudit は単一プロジェクトで2億2500万トークン超・平均7時間超、LLMDFA は Java の1プロジェクトに平均33時間超を要した³。検証を課した競技のほうは、1課題あたり平均約152ドルだった¹。

自動ペネトレーションテストでは、成果の読み方そのものが問われている。13の代表的な AutoPT フレームワークを、100億トークン超・1500件超の実行ログで大規模分析した研究は、その題名で「ハッカーか、幻覚製造機か（Hackers or Hallucinators?）」と問うた⁴。学部生からポスドクまでを含むセキュリティ分野の15人超が、4か月かけてログをレビューし、エージェント構成・計画・記憶・実行・外部知識・ベンチの6次元から既存フレームワークを整理して、統一ベンチで13フレームワーク＋2ベースラインを比較したものだ。この論文は、幻覚を自身の主要な所見として数えている。13のオープンソースフレームワークのうち8つが、少なくとも一つの課題で存在しない「フラグ」を掴んだと誤認した。その誤認は、base64文字列やフラグ形式に似た文字列を本物と取り違える類だ。バックボーンLLMを差し替えても消えず、著者らは特定モデルの事故ではなく構造的な問題だとする。もっとも原典は2型に分けており、いま挙げた文字列の取り違えが多数派だという。もう一方はフレームワーク側の照合・終了ロジックが行き過ぎる型で、ある課題では正規表現が LLM の出力中の「flag{…}」を拾って勝手に打ち切っており、LLM 自身は最終フラグとみなしていなかった。こちらは設計段階で回避できるともいう。それでも、「見つけた」という出力そのものが成果の証拠にはならない、という点は変わらない⁴。

競技の外の単体のエージェントにも、実在の脆弱性を見つけたという報告はある。Google Project Zero の Big Sleep は2024年11月に、SQLite の実在する脆弱性を見つけたと報告している。エージェントは自分で作った入力で実際にプログラムを落としてから報告し、開発者は報告の当日に修正した⁵。AIxCC の体系化研究も、2026年前半のフロンティアモデルの進歩として、バグ発見と修復で目立つ成果を示した Claude Mythos Preview を挙げつつ、LLM 単独の処理系には幻覚と非決定性という限界が残るとも書く。同じ段で原典は、より強いモデルが次の世代の CRS の構成を簡素にし、自律をさらに進める余地も開くと続けている²。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。