2026-08-12·無料·論文·13分で読めます

論文解説: SWE-Bench ProMax — 多言語・大規模リファクタリングでコーディングエージェントの本当の実力を測る

SWE-benchの飽和と採点欠陥への回答として登場した、7言語・平均11.4ファイル修正の大規模リファクタリングベンチマークを論文本文から解説。最強モデルでも41.2%しか解けない理由と、支配的な失敗モード「やり切らないリファクタリング」を読み解く。

#agents #benchmark #swe-bench #refactoring #coding-agent

対象textタスクagents

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のシグネチャ、同じ入力に対する出力、投げる例外、設定ファイルの読み方——これらが変わらないかぎり、内部の分割・命名・依存の向きはいくら作り替えてもかまいません。この定義があるおかげで、「既存のテストが全部通る」という採点がこの題材とよく噛み合います。リファクタリングは定義上、テストを書き換えずに済むはずの作業だからです。逆に言えば、テストを直さないと通らなくなった時点で、それはもうリファクタリングではなく仕様変更です。

スコアと実力が乖離していく構図

ベンチマークの飽和と汚染は、機械学習でおなじみの「過学習」と同じ構図です。見たことのある問題への成績だけが上がり、初見の問題への成績と乖離していく。公開ベンチマークが訓練データに流れ込むほど、スコアは「実力」ではなく「見たことがあるか」の指標にずれていきます。

FIG 1多項式の次数を上げると訓練誤差だけが下がり、テスト誤差と乖離していく。公開ベンチマークのスコアが実力から乖離していく構図のアナロジーとして

ProMax はこれを3つの設計で潰します。(1) 問題文をゼロから書き直して曖昧さと答えの漏洩を除く、(2) テストを人手でレビューして狭すぎ・広すぎを除く、(3) 2025年1月以降の新しいコミットから課題を採る (§3.2)。

3つのうち(3)だけが時間による線引きです。汚染は、ベンチマークのインスタンスそのものが訓練データに入る経路と、正解パッチを含む公開リポジトリの履歴が訓練データに入る経路の、両方から起こります。問題文を書き直す(1)は前者に効きますが、後者——GitHubに残った元の変更履歴——には手が届きません。「新しいコミットしか使わない」は、そこに同時に効かせるための手当てです。

29,782件の候補から、生き残ったのは170件

各インスタンスは4点セットです (§3.1): ①依存インストール済みのDocker環境（リファクタリング直前のコミット状態）、②求める変更を正確に記述した課題文、③検証用テストスイート、④元開発者の正解パッチ。エージェントは①②だけを受け取り、自律的にリポジトリを修正します。

4つが揃って初めて自動採点が成立します。Docker環境がなければ「手元では動く」が再現できず、課題文が曖昧なら解けたかどうかが運任せになり、テストがなければ挙動の保存を機械で判定できません。④の正解パッチは、その課題が人間の手で実際に完了した変更であることの証拠として置かれています——解けるかどうか分からない人工課題ではない、という保証です。

構築は3段階 (§3.2)。GitHub APIでスター500以上のOSSから2025年1月以降の「refactor」コミットを収集し、Docker環境で正解パッチがテストを通ることを機械検証したうえで、人間の専門家が（LLM補助つきで）簡単すぎる課題を除外し、テストの狭すぎ・広すぎを除去し、課題文をゼロから書き直します。課題文は「正解パッチの必要十分条件」であることまで検証されます。初期候補29,782件から残ったのは170件、約175分の1の選別率です。

この工程でいちばん地味で、いちばん効いているのが「課題文を正解パッチの必要十分条件まで詰める」部分です。必要条件とは、課題文の要求を満たさないかぎり正解パッチにはならないこと。十分条件とは、課題文どおりに実装すればテストが通ること。必要条件が欠ければ、課題文に書いていない要求でエージェントを落とすこと（＝広すぎるテスト）になり、十分条件が欠ければ、何を作ればいいのか読み取れない課題になります。29,782件から170件という選別率の低さは、裏を返せば「refactor」というコミットメッセージの緩さでもあります——単一ファイルの整形や機械的な改名は、この基準では課題になりません。

生き残った170件の規模は既存ベンチマークと質的に違います (§3.3)。正解パッチは平均11.4ファイル・261.6行（最大182ファイル）、テスト修正込みで平均15.9ファイル。30%が10ファイル超、32%が200行超を修正します (§1)。言語はPython・Java・TypeScript・Go・C・C++・Rustの7つ、供給元はDjango、Kubernetes、Angular、OpenSSLなど70リポジトリです (§3.3, Appendix A)。

平均11.4という数字より、分布の裾のほうが効いてきます。10ファイル超が30%、200行超が32%ということは、およそ3件に1件は「関連する箇所を全部見つけ、全部直し切る」持久力を正面から要求する課題だということです。1ファイルで完結する課題なら、エージェントは読んで直してテストを走らせれば終わります。数十ファイルに散った課題では、直し終えるまで自分の計画を覚えていられるかどうかが、そもそもの前提条件になります。

採点は完全な結果主義で、手順は見ずに最終状態だけを評価します (§3.1)。

\mathrm{resolved}(i) = \mathbb{1}\Big[\,\forall\, t \in T_i:\ \mathrm{pass}\big(t,\ \mathrm{repo}_i^{\mathrm{final}}\big)\Big]

(1)

言い換えると「インスタンス $i$ のテストスイート $T_i$ のすべてのテスト $t$ が修正後リポジトリで通ったときだけ1（解決）、1本でも落ちたら0」。 $\mathbb{1}[\cdot]$ は中身が真なら1、偽なら0を返す指示関数です。

\mathrm{Pass@1} = \frac{1}{N}\sum_{i=1}^{N} \mathrm{resolved}(i), \qquad N = 170

(2)

「1回勝負で解決できた割合」で、これが論文の主指標です (§4.1)。

結果: 最強モデルでも41.2%

評価対象はGemini-3-Pro・Claude Sonnet 4.6・GPT-5.2・GLM-5・Kimi-K2.5・Qwen3.5の6モデル (§4.2)。各モデルを2種類の足場（scaffold）——ミニマルな mini-swe-agent とツールの豊富な OpenHands——で走らせ、300ステップ・$10/インスタンスを上限としました (§4.1)。発見は4つです (§5.1)。

① 全モデルが苦戦。 最高は OpenHands 上の GPT-5.2 で 41.2%。Verified の75%超との落差が、多ファイル・挙動保存の難しさを物語ります。

② オープンウェイトがコスト20分の1で肉薄。 Claude Sonnet 4.6 は平均 $4.77/件で38.8%、GLM-5は**$ 0.24で36.5%**。「高い＝比例して強い」は成立しませんでした。

③ 足場で結果が激変。 GPT-5.2 は mini-swe-agent で21.8%、OpenHands で41.2%とほぼ倍。Gemini-3-Pro 以外の全モデルがリッチな足場で改善しました。

④ 言語の得意不得意がバラバラ。 OpenHands 下で Claude Sonnet 4.6 はTypeScript 53.6%・Rust 63.6%、GPT-5.2 はPython 48.3%・C 75.0%でトップ。一方 Gemini-3-Pro はTypeScriptで0.0%。論文はこの分散を、言語固有の難しさより訓練データ構成の違いの反映と見ています (§5.1)。

失敗の解剖: エージェントは「最後までやり切らない」

一番示唆に富むのは失敗の中身の分析です (§5.2)。エージェントが修正したファイル数を正解パッチと比べると、5ファイル程度までは一致しますが、正解パッチの分布が20ファイル付近でようやく90%に達するのに対し、エージェント（Claude Sonnet 4.6とKimi-K2.5で分析）は約10ファイルで頭打ちになります。重要なのは、これが「直すべきファイルを見つけられない」失敗ではないこと。中核ファイルは正しく特定・修正するのに、周辺の呼び出し箇所・設定・テストフィクスチャ・ドキュメントへの波及を途中でやめてしまう。下流の不整合が残るためテストは落ちます。論文はこれを incomplete refactoring（不完全なリファクタリング） と呼び、支配的な失敗モードと結論づけました。

もうひとつの症状は挙動面です。成功した試行は少ないやり取りで収束するのに対し、失敗した試行は読む→編集→テスト失敗→差し戻しのサイクルを繰り返し、修正範囲を広げないままステップを消費します——論文の言う unproductive exploration（不毛な探索） です (§5.3)。ステップ数最多のQwen3.5（mini-swe-agent で平均155.4）が同足場で最下位の20.6%だった事実は、「長く粘る＝進捗」ではないことの端的な例です。

FIG 2入力規模nに対する各オーダーの伸び。修正対象ファイルが線形に増えても、保つべき整合性の組合せははるかに速く増える——多ファイルの協調が難しさの質を変えることの直感として

ボトルネックは個々の推論力ではなく、多数ファイルにまたがる一貫した計画を保持し、構造変更の連鎖的影響を最後まで処理し切る持続力——というのが論文の見立てです (§5.2)。

論文の限界と読むときの注意

TypeScriptの28件はわずか2リポジトリ（うちAngularが25件）由来で、言語別スコアというよりAngularスコアに近い偏りがあります (Appendix A)。言語別の母数は20〜29件で、1件の成否で3〜5ポイント動く粗さです。課題文の書き直しはLLM補助つきの人手作業、タスク分類はClaude Sonnet 4.6によるもの（分析用で採点には非影響）です (Appendix B)。評価はPass@1のみでリトライの効果は未測定 (§4.1)。また私の補足ですが、2025年以降の公開コミット採用で汚染リスクは下がるものの、公開リポジトリ由来である以上、将来のモデルへの汚染耐性は保証されません。なお Appendix B によれば課題の41.2%はバグ修正、43.5%は新機能追加を併発しており、「純粋なリファクタリング能力」だけの測定でもありません。

現場ではこう使う

エージェントに大規模リファクタリングを任せるとき（テックリードが命名変更やAPI移行を Claude Code / Cursor / OpenHands 系に投げる場面）は、支配的な失敗が「不完全なやり切り」だと知るだけで運用が変わります。実務上は、着手前に grep や LSP の参照検索で影響箇所の全リストを列挙させ、チェックリストとして課題文に埋め込むのが論文の観察への直接の対策です。取り残されやすいテストフィクスチャ・設定ファイル・ドキュメントは、そのまま点検項目になります。

モデルと道具の選定では、①足場の豊かさがモデル選び以上に効きうる、②高価なモデルが常に得ではない（ $0.24のGLM-5が$ 4.77のClaude Sonnet 4.6に2.3ポイント差）、③言語ごとに得意なモデルが違う、の3点が実測から言えます。社内評価では必ずステップ上限とコスト上限（論文は300ステップ・$10）を設定してください。失敗する試行ほどステップを浪費するため、上限なしは「失敗にいちばん課金する」構造になります。

評価者・研究者には、「テストは狭すぎ・広すぎをレビュー済みか」「課題文は正解の必要十分条件か」「何ファイル規模か」を確認する習慣そのものが、この論文の方法論 (§3.2) から持ち帰れる道具です。

次に読む

LLMエージェントの基礎 — 観測→思考→行動のループと足場（scaffold）の正体。mini-swe-agent と OpenHands の差が腑に落ちます
過学習と評価 — 「スコアと実力の乖離」を機械学習の基本から
プロンプトエンジニアリングの科学 — 課題文の書き方が結果を左右するのは、ベンチマーク構築でも日々の運用でも同じ