SWE-Bench ProMax、リファクタリング評価を7言語に拡大—最高性能のエージェントでも解決率は41.2%

8月10日に公開されたSWE-Bench ProMaxは、コーディングエージェント評価の焦点を局所的なデバッグから、動作の一貫性を維持する必要がある大規模なリファクタリングへと移した。データセットはPython、Java、TypeScript、Go、C、C++、Rustを対象とし、70のリポジトリから計170問を収録している。各問題にはベースラインコミット、参照パッチ、テストパッチ、評価スクリプト、コンテナイメージ情報が付属し、Hugging Faceのデータセットとして直接読み込める。

構築プロセスでは、まず29,782件の実際のコミットから候補を自動収集し、次に環境を検証したうえで、専門家が問題記述を書き直し、テストを人手で確認した。この工程は、よくある2種類の欠陥を避けることを目的としている。1つは、テスト範囲が狭すぎるため、機能的には正しいものの実装が異なるパッチを誤って不正解と判定すること。もう1つは、テスト範囲が広すぎるため、問題で要求されていない動作まで検査してしまうことだ。論文の表によると、1問当たりの変更ファイル数は平均15.9件で、そのうち11.4件がテスト以外のファイルだった。コードの変更量は平均261.6行に達する。

6つのモデルを、それぞれmini-swe-agentとOpenHandsのハーネス上で実行した。OpenHandsではGPT‑5.2が41.2%で首位となり、Claude Sonnet 4.6が38.8%、GLM‑5とQwen3.5がともに36.5%だった。同じモデルでもハーネスによって結果は大きく変動する。GPT‑5.2はmini-swe-agentでの21.8%から、OpenHandsでは41.2%へ上昇した。これは、ツール、コンテキスト管理、実行ループが、依然として評価結果を左右する重要な変数であることを示している。

失敗時の実行軌跡では、読み取りや再試行の回数が多い一方、実際に変更されたファイル数は参照パッチより少ない傾向が見られた。エージェントは中核となるインターフェースを正しく変更しても、その変更を周辺の呼び出し箇所、ドキュメント、設定、テストfixtureまで波及させられないことが多い。エンジニアリングチームは、このデータセットを使って複数ファイルにまたがる計画立案や依存関係の追跡能力を測定できる。ただし、41.2%を純粋なモデル能力の指標とみなすべきではない。サンプルは170問に限られ、参照パッチとテストもすでに公開されているため、今後もデータ汚染の監視と再実行時の再現性確認が必要になる。