なぜAIコーディングエージェントは失敗するのか：ファイルと行の間に存在する決定的なギャップ
AIコーディングエージェントはソフトウェアのバグを解決する能力をますます高めている一方で、新たな研究により、彼らが深刻な「ローカライゼーション（特定化）」の問題を抱えていることが明らかになりました。膨大なコードベースの中から正しいファイルへと辿り着くことはできても、修正を実装するために必要な特定のコード行を特定できないことが頻繁にあります。
SWE-Exploreの導入：修復率を超えた評価へ
歴史的に、AIコーディングエージェントの有効性は、「エージェントがバグを修正できたか否か」という単一のバイナリ指標によって測定されてきました。このアプローチでは、失敗の背後にある「理由」が無視されてしまいます。修復の失敗は、エージェントが不適切なパッチを書いたことを意味する場合もあれば、エージェントが関連するロジックにさえ目を通さなかったことを意味する場合もあります。
この盲点を解消するため、上海交通大学の研究者を含む国際的な研究チームは、SWE-Exploreを開発しました。従来のベンチマークとは異なり、SWE-Exploreは上流の探索フェーズを切り離して評価します。これは、バグの説明を受け取り、問題に実際に深く関連する特定のコードセクションをランク付けしたリストとして返す、エージェントの能力を評価するものです。データセットは広範で、203のオープンソースプロジェクトと10のプログラミング言語にわたる848のタスクから構成されており、その中でもPythonが最も多く（547タスク）を占めています。
精度のギャップ：ファイルレベルの成功 vs 行レベルの失敗
この研究で最も衝撃的な発見は、ファイルレベルの精度と行レベルの精度の間に存在する巨大な格差です。Claude Code、Codex、OpenHandsといった汎用エージェントを用いてテストしたところ、結果は明白でした。
- ファイルレベルの精度: エージェントは良好なパフォーマンスを示し、正しいソースファイルを特定して高い順位にランク付けすることに成功しています。
- 行レベルの精度: パフォーマンスが崩壊します。汎用コーディングエージェントが、修正に不可欠な実際のコード行をカバーできたのは、わずか**14%から19%**に過ぎませんでした。
興味深いことに、基盤となる大規模言語モデル（LLM）をアップグレードするだけでは、この問題は解決しません。OpenAI、Anthropic、Google、Moonshot、あるいはZhipuのモデルを使用しているかにかかわらず、パターンは全く同じでした。ファイルへのヒット率は高いものの、行のカバー率は極めて低いのです。研究では、CoSILのような特化型システムが、コードを相互に接続されたビルディングブロックのネットワークとして扱うことで汎用エージェントを凌駕したことが指摘されており、モデルの生のパワーよりもアーキテクチャの変更の方が重要であることを示唆しています。
しきい値効果：「より多く読む」ことが重要な理由
制御されたアブレーション実験を通じて、研究者たちはコンテキストに関する「しきい値効果」を発見しました。モデルに提供するコアコードの量（0%から100%まで）を変化させた結果、修復の精度は線形には向上しないことが明らかになりました。
比較的容易なタスクにおいては、明確なティッピングポイントが存在します。エージェントが必要なコア領域の**50%未満しか参照できない場合、修復成功率はほぼゼロのままです。修復の成功率が大幅に跳ね上がるのは、エージェントが必要なコンテキストの50%から75%**にアクセスできるようになった時のみです。重要な点として、この研究では、無関係な「ノイズ」となるコードを提供しても、重要な行が欠落する場合ほどパフォーマンスを低下させないことが示されました。開発者にとっての教訓は明確です。AIエージェントの時代においては、不可欠な詳細をフィルタリングして失うリスクを冒すよりも、より多くのコンテキストを提供した方が良いのです。
主な要点
- ローカライゼーションがボトルネック: AIエージェントは適切なファイルを見つけることには長けていますが、修正に必要な特定のコード行をピンポイントで特定することには非常に苦労します。
- モデルのスケーリングは万能薬ではない: より強力なLLMにアップグレードしても、行レベルの精度差は解消されません。CoSILのような特化したアーキテクチャ的アプローチの方が効果的です。
- 「50%コンテキストの法則」: AIによる修復の成功はしきい値パターンに従います。修復が成功する可能性が高まるには、関連するコードコンテキストの少なくとも50〜75%が可視化されている必要があります。