AI パッチ適用ベンチマークは実務上の品質を過大評価していることが判明

ノースウェスタン大学の研究者は、C/C++、Go、Rust で書かれた 84 のオープンソースプロジェクトから抽出した 112 件の実際のバグを対象に、コーディングエージェントを評価しました。データセットには、元の概念実証（PoC）クラッシュトリガーと、プロジェクトメンテナが提供した追加の回帰テストが含まれています。

最も顕著な結果は Claude Opus 4.7 モデルに関するものです。クラッシュを約 90 % のケースで防止しましたが、メンテナが用意した完全なテストスイートを通過したのはそのうち 61 % にとどまり、クラッシュ回避と実際の機能的正確性の間に大きなギャップがあることが示されました。

クラッシュのみのベンチマークが誤解を招く理由

従来のベンチマークは、パッチがクラッシュを防止すれば成功とみなすことが多く、これを概念実証と扱います。この手法では、開発者が修正の設計意図への合致やリグレッションの有無を確認するために書く、より深い検証ステップが無視されます。

ノースウェスタンの調査では、Claude Opus 4.7 がクラッシュを除去したパッチの約 3 分の 1 がメンテナの整合性テストに合格しませんでした。つまり、見た目上は有効に見えるパッチの約 4 割が、開発者が設定した完全なチェックを満たしていなかったのです。

ベンチマーク設計に潜むバイアス要因

arXiv の論文『On the Reliability of LLM‑Based Vulnerability Patching Benchmarks』は、エージェントレベル（プロンプトやツール）、評価フレームワーク（権限エラー、インフラバグ、タイムアウト処理）、データセットレベル（単一の PoC テストが脆弱性の根本原因を捉えきれない）の三つのバイアス次元を指摘しています。

同論文の著者は同じ 112 件のバグセットを再構成し、さらに設計原則との整合性を評価するための回帰テストと開発者テストを加えました。分析の結果、最新モデルでさえこれら追加テストの合格率はわずかに向上する程度で、ベースライン性能を大きく上回っていないことが確認されました。

明示的指示の効果

ノースウェスタンの研究者は、AI にコードのビルドとテスト方法を明示的に指示したところ、C/C++ のバグに対する成功率が 20 ポイント上昇したと報告しています。この改善はモデル自体を変えずに得られ、プロンプトエンジニアリングとテスト駆動指示の重要性を示しています。

両研究は、ベンチマークスコアが評価手法に極めて敏感であることに合意しています。Git の履歴へのアクセス、データセットに事前に組み込まれた応答、タイムアウトのカウント方法などが、報告された性能を人工的に膨らませたり低下させたりする可能性があります。

• メンテナテストがスコアに含まれるか確認する
• エージェントがインターネットや Git 履歴にアクセスできるか検証する
• ビルド・テスト指示に使用した正確なプロンプトを記録する
• タイムアウトやパイプラインエラーの集計方法を把握する

研究からの提言は、これら四つの基準に照らして AI 修正ツールの公表数値を精査すべきだということです。慎重な評価なしに導入すれば、紙上では優秀に見えても実際のコードベースに信頼できるパッチを提供できないリスクがあります。

日本の企業にとっての実務的な教訓は明快です。高いクラッシュ防止率だけでは、パッチが開発者の全テストスイートを通過できる保証にはなりません。意思決定者は、メンテナが作成した回帰テストを組み込んだベンチマーク手法、外部データへのアクセス有無の開示、プロンプト設計とタイムアウト処理の透明性を求めるべきです。そうして初めて、AI が生成したパッチが本番コードに安全に統合できると信頼できるでしょう。