論文解説: SWE-Bench ProMax — 多言語・大規模リファクタリングでコーディングエージェントの本当の実力を測る
SWE-benchの飽和と採点欠陥への回答として登場した、7言語・平均11.4ファイル修正の大規模リファクタリングベンチマークを論文本文から解説。最強モデルでも41.2%しか解けない理由と、支配的な失敗モード「やり切らないリファクタリング」を読み解く。
SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring
一次資料 — この記事の根拠
論文の発表 2026-08-10→この解説の公開 2026-08-12同月
SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code RefactoringYuling Shi, Jinghan Xu, Kelin Fu ほか · 2026-08-10 · v1arXiv:2608.09802論文ページ·PDF原文の要旨（Abstract）を読む
As AI coding agents take on increasingly complex, long-horizon software engineering tasks, existing benchmarks are rapidly saturating and their evaluation quality has come under serious scrutiny: a recent audit found that nearly 60% of unsolved SWE-bench Verified instances contain flawed tests -- either overly narrow tests that reject correct solutions or overly broad tests that check unstated requirements -- and that frontier models can verbatim reproduce gold patches from training data. Code refactoring, which requires coordinated, behavior-preserving changes across many files, offers a substantially harder and more realistic test of agent capability, yet remains underserved by current benchmarks. We introduce SWE-Bench ProMax, an expert-curated, multilingual code refactoring benchmark of 170 instances drawn from real commits across seven programming languages (Python, Java, TypeScript, Go, C, C++, and Rust). Every instance undergoes rigorous, multi-stage curation that directly addresses the quality problems identified in prior benchmarks: issue descriptions are rewritten from scratch to provide precise, unambiguous specifications, and test suites are manually reviewed to remove overly narrow and overly broad tests. Tasks with insufficient complexity or limited cross-file scope are filtered out, yielding a benchmark of challenging, large-scale refactoring tasks that average 11.4 modified files and 261.6 lines of code per instance, substantially exceeding the scale of existing benchmarks. Experiments with frontier models under two agent scaffolds show that the best model achieves only 41.2% resolve rate, confirming that SWE-Bench ProMax presents a meaningful and unsaturated challenge for current AI coding agents. Our benchmark is available at https://huggingface.co/datasets/swe-bench-promax/SWE-Bench-ProMax.
75%解けるベンチマークは、まだ実力を測れているか
AIコーディングエージェントの実力は、GitHubの実際のissueを渡してリポジトリを修正させ、テストが通れば正解とする SWE-bench で測るのが定番でした。しかし論文によれば、最前線のエージェントは厳選版 SWE-bench Verified で75%超に達し、上位システム間の差もつきにくくなっています (§1)。
さらに深刻なのは採点そのものの欠陥です。論文が引用する監査では、SWE-bench Verified の未解決インスタンスの約60%にテスト欠陥が見つかりました。正しい解法まで不正解にする「狭すぎるテスト」が35.5%、問題文にない要件までチェックする「広すぎるテスト」が18.8%。加えて、最前線モデルが訓練データに混入した正解パッチを一字一句再現できる（実力ではなく丸暗記の）証拠もあり、OpenAIはこのベンチマークの評価利用をやめるに至りました (§1)。
「狭すぎる」も「広すぎる」も、正体はテストの書き方の問題です。テストが特定の実装（内部関数の名前、呼び出しの順序）に依存していれば、同じ結果を別の書き方で出したエージェントは落ちます。逆に、課題文に書かれていない仕様までテストが要求すれば、指示どおりに実装しても落ちます。「テストが通れば正解」という採点は、人手のレビューを介さず何千件でも回せるのが強みですが、その裏返しとしてテストの質がそのまま指標の質になるという弱点を抱えています。測っているつもりのものが、いつのまにか「エージェントの実力」から「テストの気難しさ」にすり替わる。
今日取り上げる SWE-Bench ProMax（COLM 2026採録）はこの状況への正面からの回答です。題材はリファクタリング——外から見た挙動を変えずに、コードの内部構造を作り直す作業です。
比喩: 蛇口の交換と、家全体の配管替え
従来のベンチマークの中心はバグ修正でした。SWE-bench Verified はインスタンスの86%が1ファイルの修正で完結します (§1)。例えるなら「水漏れする蛇口をひとつ交換する」仕事です。
リファクタリングは「家全体の配管を新しい規格に交換する。ただし工事後も、どの蛇口をひねっても以前と同じお湯が出ること」という仕事です。触る場所は桁違いに多く、1本でも古い配管が残れば全体が失敗します。論文の代表例では、NASAのフライトソフトウェア F´ (fprime) のヘッダ整理に244ファイルの協調修正が必要でした (§1, Appendix C)。試されるのは多数ファイルにまたがる協調修正と挙動の保存——実務のソフトウェア開発でもっとも重い部類のスキルです。
ここで言う「挙動を変えない」は、外から観測できるものが同じ、という意味です。公開APIのシグネチャ、同じ入力に対する出力、投げる例外、設定ファイルの読み方——これらが変わらないかぎり、内部の分割・命名・依存の向きはいくら作り替えてもかまいません。この定義があるおかげで、「既存のテストが全部通る」という採点がこの題材とよく噛み合います。リファクタリングは定義上、テストを書き換えずに済むはずの作業だからです。逆に言えば、テストを直さないと通らなくなった時点で、それはもうリファクタリングではなく仕様変更です。
スコアと実力が乖離していく構図
ベンチマークの飽和と汚染は、機械学習でおなじみの「過学習」と同じ構図です。見たことのある問題への成績だけが上がり、初見の問題への成績と乖離していく。公開ベンチマークが訓練データに流れ込むほど、スコアは「実力」ではなく「見たことがあるか」の指標にずれていきます。
ProMax はこれを3つの設計で潰します。(1) 問題文をゼロから書き直して曖昧さと答えの漏洩を除く、(2) テストを人手でレビューして狭すぎ・広すぎを除く、(3) 2025年1月以降の新しいコミットから課題を採る (§3.2)。
3つのうち(3)だけが時間による線引きです。汚染は、ベンチマークのインスタンスそのものが訓練データに入る経路と、正解パッチを含む公開リポジトリの履歴が訓練データに入る経路の、両方から起こります。問題文を書き直す(1)は前者に効きますが、後者——GitHubに残った元の変更履歴——には手が届きません。「新しいコミットしか使わない」は、そこに同時に効かせるための手当てです。
29,782件の候補から、生き残ったのは170件
各インスタンスは4点セットです (§3.1): ①依存インストール済みのDocker環境（リファクタリング直前のコミット状態）、②求める変更を正確に記述した課題文、③検証用テストスイート、④元開発者の正解パッチ。エージェントは①②だけを受け取り、自律的にリポジトリを修正します。
コメント
コメントにはログインが必要です