新研究でClaude Opus 4.7は90.2%の事例で与えられた攻撃実証を止めたが、上流開発者のテストに通った修正は60.7%だった。29.5ポイントの差が核心だ。一つのクラッシュを抑えても、保守者が意図する動作を守る修正とは限らない。
NorthwesternのDang K Le、Wenxuan Shi、Xinyu Xingが10月7日に報告したベンチマーク信頼性研究は、C、C++、Go、Rustの84公開プロジェクト、112の過去の欠陥を扱う。特定のClaudeとエージェント構成によるプレプリントであり、全自動修正や本番の普遍的失敗率ではない。
モデルが改善しても採点差は残る
統制実験は同じ課題でOpenCodeとSonnet 4.0、4.5、Opus 4.7を使った。ビルドとテストの指示は与えたが、最初はPoC本文を見せなかった。PoCは報告された不具合を再現する入力や手順だ。
Sonnet 4.0はPoC77.7%、開発者テスト43.8%、Sonnet 4.5は84.8%と48.2%、Opusは90.2%と60.7%だった。Opusは双方で進歩したが、PoC合格修正の32.7%は開発者テストに失敗した。公開採点分析が強調する、見かけの成功約3件に1件の差だ。
Opusは既存回帰テストも94.6%通過したが、開発者テストとの差は残る。古い例を守る試験と、新しい欠陥の周辺で意図を表す追加試験は異なる。
研究者は上流修正コミットの単体・統合試験を復元し、AI修正後に適用した。文字列の一致でなく動作を測り、別実装も通過できる。完全解決はビルド、反復PoC抑止、従来回帰、追加開発者試験の4段階全てを要した。
PHPでは間違った方法でもクラッシュが消える
過去のPHP range() バグは混在入力の型を誤分類し、非文字列を文字列として扱い得た。混在型を即拒否すればクラッシュと多くの旧試験を通せるが、PHPが変換すべき有効な数値・文字列の組み合わせも拒む。
上流修正は分類を正し、有効動作を維持した。近傍の有効入力を使う開発者試験が、正しい修復と過剰制限の回避策を分けた。クラッシュだけなら両方に同点を与える。
ガードは緊急緩和として有用でも完全修正とは限らない。観測例に合い本来の要件を満たさないテスト過適合は既知の問題だ。安全分野では症状を隠し別経路を残し、誤った安心でレビューを減らし得る。
開発者試験も完全な受入ではない。性能、互換性、可読性、構造を尽くさない。別修正が未記録動作を意図的に変える場合もあり、歴史的試験の失敗は要調査の不一致で、即危険とは限らない。
指示が測定能力を変える
詳細なビルド指示でSonnet 4.0はPoC77.7%、なしで74.1%。開発者試験は41.1%から43.8%へ変わった。C/C++だけではPoC72%から92%に対し、開発者試験28%から36%だった。
文書支援は正当で人にも役立つが、情報条件を示さず点数を比較できない。GoとRustは命令が予想しやすく、C/C++には多様な構築、フラグ、ラッパーがある。環境準備が修正品質の評価前に点数を動かす。
62件のGoでソース形式PoCを見せるとクラッシュ成功は69.4%から95.2%、開発者試験は41.9%から48.4%になった。読みやすいハーネスはAPIと呼出形を明かし、可視試験に合わせやすくする。
25件のC/C++では不透明なバイナリーやテキスト入力を見せてもPoC92%、開発者36%のままだった。どちらもPoC提供と言えるが、一方は実行意図を示し、他方は意味の推論が必要で、同じ情報予算ではない。
検索と基盤は両方向に点数を歪める
過去の課題には公開課題、勧告、修正がある。論文はウェブで上流修正を見つけた例と、除去されていないGit履歴から旧修正を得た例を記録する。成功でも独立修復能力をきれいには測れない。
現場で検索するのは合理的で、汚染になるのは無支援推論を主張する場合だ。検索・道具使用の試験なら明示して許容できる。学習済みの歴史的記憶も絶対点の解釈を制限する。
逆にフレームワークは正しい仕事を隠し、正解を漏らし得る。権限、時間切れ、試験ファイル衝突はビルドを止め、遅い案件や良い修正を失敗にする。全実行で個々の基盤問題が約5～32%に影響し、順位差より大きい場合もあった。
点数はモデル、足場、プロンプト、道具、ソース包装、制限、採点の組全体に属する。統制はOpenCodeとClaude、事例分析はClaude CodeとSonnet 4.5も含む。足場を同一視すべきでない。
関連研究も複数試験の必要を示す
PVBenchは20プロジェクト209件で、基本試験合格修正の40%超が開発者修正由来の追加試験に失敗した。設計とデータは違い、直接比較できるClaude率ではない。
PatchBenchは11エージェントでPoC単独が解決率を平均1.83倍に膨らませたとする。安全再実行、単体、出力確認を加えると、最強も元PoC97%超から総合約半分へ下がった。
同研究は修正がクラッシュスタック外にある欠陥を選び、文脈を変えたリポジトリーに移植して記憶の価値を減らす。成功を全て新しい推論とみなさない仕組みだ。
BerkeleyのCyberGym-E2Eは139プロジェクト920脆弱性で発見、再現、修正を測る。対象を教えれば最良構成は約80%を修正したが、発見からでは低下し、クラッシュ周辺だけの浅いガードも見られた。
モデル、課題、定義が違い一つの順位表にはならない。Cyber Indexの方法も監査、発見、再現、有効動作を壊さない修正へ範囲を広げる。共通課題は成功率に何が含まれるかだ。
強い判定でも本番の証明ではない
Northwestern標本は再現ビルドと意味のある上流試験を要した。112件は多様でも全本番欠陥を代表しない。公開履歴が訓練に入った可能性は絶対率を制限するが、条件を変えた統制比較の敏感さは消さない。
本番は独自試験、静的解析、ファジング、人の確認、段階公開で安全にできる一方、試験不足、未文書化動作、依存の欠如で難しくもなる。整理したベンチマークやPoC合格だけで無人配備を保証できない。
次はPoCと開発者意図試験を併記し、道具・ネット権限、履歴除去、時間、段階失敗を開示し、本番候補が採用、修正、拒否される割合を追うべきだ。別攻撃経路や新欠陥も必要で、歴史的パッチとの文字一致は代案にならない。
検索可能な技術知識基盤は指示、道具履歴、修正、検証を残せるが正しさを作らない。結論はOpusの実質改善と、クラッシュ点が開発者整合を29.5ポイント上回ったことだ。生成修正は候補であり、安全と正規動作には独立した証拠が必要である。