AI・信頼性・評価

自律AIが脆弱性を発見・修正、競技外は誤検出9割超の報告

2026/7/20 （更新: 2026/8/8）

🤖 AIが執筆しています

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

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

結果は具体的だ。決勝の採点ラウンドが用意した63件の課題脆弱性（大半は歴史的なN-dayを模した合成で、一部は課題作成中に見つかった実在の0-day）のうち、システム群は54個を発見し43個を修正した——発見率86%、修正率68%だ¹。合成課題だけではない。この63件とは別に、実在の（合成でない）脆弱性を18件——Cで6件、Javaで12件——掘り当て、責任ある開示に回した。勝ったのは Team Atlanta（ジョージア工科大・Samsung・KAIST・POSTECH）。優勝から最下位まで、全CRSがオープンソースとして公開されることになった。研究デモではなく、コードとテレメトリまで残る実測イベントだ。

なぜ信じてよいか——競技が「検証」を強制した

数字を鵜呑みにする前に、AIxCC が何を要求したかを見る必要がある。脆弱性を「見つけた」と主張するには、実際にバグを発火させる入力（PoV）を示さねばならない。修正を「した」と主張するには、そのバグが再発せず、かつ既存の機能テストを壊さないパッチを示さねばならない。言い張るだけでは1点も入らない。検証が採点の前提に組み込まれていた。

この土俵の上で、LLM は古典的手法に確かな上乗せをした。AIxCC を体系分析した体系化研究（SoK）は、63個の脆弱性のうち並列ファジングだけで解けると注釈できたのは34件（54%）だとする。CRS 群はそこへ、ファジングでは解けない22件（C8件・Java14件）を上乗せした。SoK はこの上乗せを、PoV生成へのLLM導入——PFを超える追加要素として最も広く開発された部分——に大きく帰せられるとみている²。Java は入力の意味的制約が強く、timeout や OOM のようにファジングが苦手とする型の課題も多い。そこに意味を読む力が効いた。競うのではなく補い合う——それが決勝の実像だった。

だが、修正はまだ危うい

同じ SoK 分析は、パッチの正しさが未解決だと明記する²。競技に出た CRS の意味的正解率は 23.3%から100% まで開いた。7チーム中4チームは75%以上に届いており、低いのは3位のチームの31.7%と4位の23.3%だ——正解率は最終順位を追っていない（100%を出したのは5位のチームである）。原典はこの2件について「一様に弱いパイプラインではなく、少数の課題で無効な提出が連続したことに主に起因する」と明言している（重複排除を欠いた並列生成のような戦略上の問題との関連は、推測にとどめている）。パッチの意味が7割方誤っていた、という読み方はできない。別の数字もある。比較のために実験室条件で走らせた基盤エージェント（Claude Code・MultiRetrieval）では、自動検証をすべて通過したパッチのうち37.7%（53件中20件）・45.6%（57件中26件）が、手動レビューで初めて意味的に誤りと判明した。自動検証を通ることと、意味が正しいことは別物だという証拠だ。見つけても直せない例も残り、7件はどのシステムも基盤エージェントも修正できなかった。いずれも Java で、無限ループや JVM クラッシュのように有用なスタックトレースが得られない類か、現在のエージェントの推論を超える論理的複雑さを持つ類だった。

勝敗を分けたのは、安定性と正確性の二つだった。優勝チームは2位の約1.8倍を得点し（392.8対219.4）、その差は全フェーズで得点を積み続けたことから来ている——2位・3位のシステムは第3・第4フェーズ以降で伸びが止まった²。長時間の自律運転では、賢さと同じくらい止まらないことが効く。舞台の上ですら、自律AIの足腰はまだ危うい。

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

そして検証の仕組みを外すと、数字は反転する。天津大・北京大などのチームが、LLM による脆弱性検出を実プロジェクト規模で評価した³。著者らが自ら構築した、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 はどの LLM 系よりも高い——LLM だから誤検出が多い、という順位づけはこのデータからは出てこない。ただしこの並びを順位として読むのは無理がある。Java の Semgrep が警告を出したのは12プロジェクト中6つで、率の土台は Semgrep 3.1件・LLMDFA 2.5件という小さな標本だ。しかもベンチ上ですら絶対的なリコールは C/C++ で21.09%、Java で33.82%にとどまる。LLM 系の強みは、このベンチ上では伝統ツールより多くの固有の脆弱性を掘り当てた点にあった。その上で現場では、警告の大半が空振りになる。

自動ペネトレーションテストでは、成果の読み方そのものが問われている。13の代表的な AutoPT フレームワークを、100億トークン超・1500件超の実行ログで大規模分析した研究は、その題名で問いを突きつけた——「ハッカーか、幻覚製造機か（Hackers or Hallucinators?）」⁴。15人超のセキュリティ専門家が4か月かけてログをレビューし、エージェント構成・計画・記憶・実行・外部知識・ベンチの6次元から既存フレームワークを整理して、統一ベンチで13フレームワーク＋2ベースラインを比較したものだ。幻覚は、この論文自身の主要な所見として数えられている。13のオープンソースフレームワークのうち8つが、少なくとも一つの課題で存在しない「フラグ」を掴んだと誤認した——base64文字列やフラグ形式に似た文字列を本物と取り違える類だ。バックボーンLLMを差し替えても消えず、著者らは特定モデルの事故ではなく構造的な問題だとする。「見つけた」と言い切る自信そのものが、成果の証拠にはならない⁴。

見分けの一点

AIxCC の18件と、現場の誤検出の山。矛盾ではない。両者は別のものを測っている。競技は「PoV で再現し、機能を壊さず直す」ところまでを1件と数えた。いま評価された検出器の多くは、その手前の「怪しい」を報告して止まる。再現と修正という検証を通したか否かが、実績と幻覚を分ける。

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

だから、AIが「脆弱性を見つけた」と言うときに効く問いは、モデルの賢さだけではない。叩いて再現できたのか。直して壊れていないのか。AIxCC が点を与えたのは、まさにこの二つだった。競技の外でこの二つを省けば、残るのは、自信に満ちた警告の山である。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。