SWE-Exploreが測るのは「修正」ではなく「探索」
SWE-Exploreは、AIコーディングエージェントの第1段階である「コード検索・特定（ローカリゼーション）」工程だけを切り出して評価する新ベンチマークです。従来のSWE-bench系ベンチマークは最終的な修正成功率しか測らず、エージェントが本当に関連コードを読めていたのかは見えませんでした。SWE-Exploreはバグ記述とプロジェクトを与え、エージェントが返す「関連コード箇所のランク付きリスト」を評価します。
データセットは203のオープンソースプロジェクトから集めた848問、10言語にわたり、うち547問がPythonです。正解は手作業で定義するのではなく、強力なモデルによる成功した解決過程の読み取り痕跡から導出され、複数の独立した解法が共通して参照した箇所が「有用な文脈」として認定されます。
ファイルは当たる、行は外す
結果は明確です。ファイル単位では各エージェントとも適切なソースファイルを早期に上位ランクへ持ち込めるのに対し、行単位では一般的なコーディングエージェントが本当に必要な行を14〜19%しかカバーできていません。Claude Code、Codex、OpenHands、Mini-SWE-Agent、AweAgentはほぼ同じスコアで横並びとなり、GPT-5.4やGemini 3 Pro、Claude Sonnet 4.6、Kimi K2.6など6モデルを試してもこの傾向は変わりません。モデルを強くしても解消しない構造的な問題だということです。
キーワード検索はバグ記述の語がテンプレートやドキュメントに偏在するため、ほぼ偶然と変わらない精度しか出ません。エージェントが優位なのは、全件を一気にソートするのではなくプロジェクトを段階的に探索するためです。
「核となる領域」の50〜75%が境界線
アブレーション実験では、修正モデルに核となる領域の0、25、50、75、100%だけを見せる条件が比較されました。成功率は段階的に伸びるのではなく、50〜75%の被覆率の間で急激に跳ね上がります。修正には「最低限の手がかり量」が必要で、それを下回るとほぼ通らないということです。一方、必要な箇所さえ含まれていれば余計なコードが混ざっても害は小さい。研究チームの結論は「Filter less, read more（絞り込みすぎず、もっと読め）」です。CoSILのようにコードを相互接続されたネットワークとして走査するシステムは、行レベルでも大きく上回るスコアを記録しています。
💼 事業会社視点：これは自社にどう効くか
この結果は、AIコーディング導入を進める日本の事業会社にとって、ROI設計の前提を見直す材料です。第一に、受託開発・SIerやSaaSのプロダクト組織が「Claude CodeやCodexを入れれば工数が何割削れる」と試算している場合、行レベルで14〜19%しか当たらないという事実は、自動修正よりも「該当箇所探索の人間レビュー」をどう残すかが歩留まりを決めることを意味します。エンジニアの工数削減目標は、修正生成ではなく「読むべき箇所の特定」に再配分すべきです。
第二に、レガシーコードを多く抱える金融・製造業の内製化部門では、CoSILのようにコード全体をグラフ構造として扱う探索手法が今後の差を生みます。短期的にはRAGや静的解析と組み合わせた「文脈供給パイプライン」の内製が、エージェント単体導入より費用対効果が高い領域が広がるでしょう。
第三に、METRの「半分は機能的欠陥で却下」という指摘と合わせれば、PoCの評価指標を「PR通過率」ではなく「人間レビュー後の採用率」に置き直す必要があります。経営者は今、ベンダーの修正率KPIを鵜呑みにせず、ローカリゼーション精度を別建てで問うべき局面にあります。
