技術要約: SWE-Bench ProMax

問題提起

AIコーディングエージェントが進歩するにつれ、既存のソフトウェアエンジニアリング・ベンチマークは急速に飽和状態にあり、スコアの上昇が真の能力向上を反映しているのか、それとも単に現在のベンチマーク設計の限界を反映しているのかという懸念が高まっている。SWE-bench Verifiedに対する最近の監査では、未解決のインスタンスの約60%に、欠陥のあるテストスイート（正解となるソリューションを拒絶する「過度に限定的なもの」、あるいは明示されていない要件をチェックしてしまう「過度に広範なもの」）が含まれていること、および最先端モデルが学習データ内のゴールドパッチを再現できてしまうことが明らかになった。さらに、現在のベンチマークは主に孤立したバグ修正や機能実装に焦点を当てており、多くの場合、単一ファイルの変更を伴う。これは、プロフェッショナルな開発における重要な長期的タスクである「コードのリファクタリング」——すなわち、多くのファイルにわたって整合性を保ちつつ振る舞いを維持した変更を行う複雑な作業——の性質を捉えきれていない。既存のリファクタリング・ベンチマークは、規模が限定的であるか、単一のプログラミング言語に制限されているか、あるいはテストの品質に関する厳格な人間による検証を欠いている。

手法

著者らは、以下の厳格な3段階の構築パイプラインを通じてこれらのギャップに対処するために設計された、専門家によるキュレーション済みの多言語ベンチマークであるSWE-Bench ProMaxを導入する。

1. データ収集: 著者らは、特定の基準（スター数500以上、承認されたオープンソースライセンス、主要言語がPython、Java、TypeScript、Go、C、C++、またはRustであること）を満たす候補リポジトリをGitHubから特定した。彼らは、キーワード「refactor」（「bug fix」は除外）を含み、かつテストファイルと非テストファイルの両方を変更した、2025年1月以降に提出されたコミットを抽出した。これにより、初期プールとして29,782個の候補が得られた。
2. 環境構築: 各候補に対し、依存関係がすべてインストールされた、リファクタリング前の状態のリポジトリを含む隔離されたDocker環境を構築した。ゴールドパッチ（ソースおよびテストの変更）を適用し、テストスイートを実行した。環境の構築に失敗した場合、またはゴールドパッチがすべてのテストに合格しなかったインスタンスは破棄された。
3. フィルタリングおよび問題文の書き換え: この段階では、品質を確保するためにLLMに補助された人間の専門家が介入した。
   • コミット分析: 専門家は差分（diff）を分析し、スコープと意図を理解した。
   • 品質フィルタリング: 複雑さが不十分なタスク（例：単一ファイルの変更、些細な行数）は削除された。極めて重要な点として、過度に限定的なテスト（特定の実装詳細を強制するもの）および過度に広範なテスト（タスクの範囲外の振る舞いをチェックするもの）を排除するために、テストスイートを手動でレビューした。
   • 問題文の書き換え: 元のコミットメッセージは、正確で曖昧さのない仕様を提供するためにゼロから書き直された。各記述は、ゴールドパッチにとって必要十分な条件であることが検証された。
   • 人間による検証: 最終的なレビューにより、問題の記述、テストスイート、およびゴールドパッチの間の整合性が確認された。

最終的なベンチマークは、7つのプログラミング言語にわたる70の異なるリポジトリから抽出された170のインスタンスで構成されている。

主な貢献

1. 高品質で専門家がキュレーションしたベンチマーク: 自動化されたベンチマークとは異なり、SWE-Bench ProMaxは多段階の専門家によるキュレーションを経ている。問題の記述は精密な仕様として書き直され、テストスイートは以前のベンチマークを悩ませていた欠陥を取り除くために手動で精査されている。
2. 前例のない規模と複雑さ: 本ベンチマークは大規模なリファクタリングを対象としており、インスタンスあたりの平均変更ファイル数は11.4ファイル、コード行数は261.6行である。これは既存のベンチマーク（例：SWE-bench Verifiedのインスタンスの86%は単一ファイルのみを変更する）を大幅に上回っている。
3. 多言語への対応: データセットは7つの多様な言語（Python, Java, TypeScript, Go, C, C++, Rust）に及んでおり、言語固有のパラダイム（例：Rustの所有権モデル、Cのメモリ管理）がエージェントの性能にどのように影響するかを分析することを可能にする。
4. 厳格な評価プロトコル: 本ベンチマークは、中間ステップや特定のコマンドに依存せず、エージェントの変更がスイート内のすべてのテストに合格した場合にのみインスタンスが解決されたとみなす、結果駆動型の評価を採用している。

結果と分析

著者らは、2つのエージェント・スキャフォールド（mini-swe-agentおよびOpenHands）の下で、6つの最先端モデル（プロプライエタリなモデル3つ、オープンウェイトモデル3つ）を評価した。

• 未飽和の課題: 最も優れた性能を示したモデルであるGPT-5.2は、SWE-Bench ProMaxにおいて41.2%の解決率を達成した。これはSWE-bench Verifiedで見られた75%を超える解決率よりも大幅に低く、大規模なマルチファイルのリファクタリングが依然として大きな未解決の課題であることを裏付けている。
• オープンウェイトモデルのコスト効率: オープンウェイトモデルは、わずかなコストでプロプライエタリなモデルに匹敵する競争力を示した。例えば、GLM-5は1インスタンスあたり0.24ドルで36.5%の解決率を達成したが、Claude Sonnet 4.6は4.77ドルで38.8%であった。
• 言語による差異: 単一のモデルがすべての言語で支配的になることはなかった。性能は言語によって大きく異なり（例：Claude Sonnet 4.6はRustとTypeScriptで優れていたが、GPT-5.2はPythonとCで最高の性能を発揮した）、モデルの強みが特定の言語の学習データやアーキテクチャに結びついていることを示唆している。
• 失敗モードの分析: トラジェクトリ分析により、2つの主要な失敗パターンが明らかになった。
  1. 不完全なリファクタリング: エージェントは、ゴールドパッチが要求するよりも一貫して少ないファイルを変更していた。コアとなるファイルは特定できていることが多いものの、周辺のコールサイト、ドキュメント、および設定ファイルへの変更の伝播に失敗し、その結果、ダウンストリームの依存関係の不一致によるテスト失敗を招いていた。
  2. 非生産的な探索: 失敗した試行は、成功した試行よりも大幅に多くのインタラクション回数を消費しており、修正の範囲を広げることなく、編集とリバートの反復サイクルに陥ることが多かった。

重要性

本論文は、SWE-Bench ProMaxが、現実的かつ大規模なソフトウェアエンジニアリングのタスクにおいて、AIコーディングエージェントを評価するための意味のある、未飽和のベンチマークを提供すると主張している。以前のベンチマークの品質欠陥（欠陥のあるテスト、曖昧な記述）に対処し、複雑さをプロダクションレベルのリファクタリングに合わせてスケールアップすることで、複数のファイルにわたって一貫した計画を維持するエージェントの能力に対して、より厳格なテストを提供している。結果は、最先端のモデルは向上しているものの、持続的なクロスファイル・コーディネーションの能力が依然として根本的なボトルネックであることを示唆している。さらに、本ベンチマークは、オープンウェイトモデルが非常に低いコストで最先端の性能に近づけることを強調しており、高いAPIコストが複雑なリファクタリングのシナリオにおいて比例して優れた結果を保証するという仮定に疑問を投げかけている。