本論文は、大規模言語モデルのエージェント型コーディング能力を評価するためのベンチマーク SWE-Compass を提案し、2 つのエージェントフレームワークのもとで 10 のモデルをこのベンチマーク上で実行した評価を報告している。その動機となる主張は、既存の評価が現実のソフトウェアエンジニアリングに及ばないというものである。大半は単一ファイルのタスク、Python 中心のバグ修正、合成されたアルゴリズム問題に限られており、リポジトリに根ざしたベンチマークでさえバグ修正を支配的な評価軸としているため、機能実装、リファクタリング、設定、パフォーマンス最適化は十分に探究されていない。本論文は、この狭さが体系的な能力の診断を妨げ、高い性能が汎化可能な推論から生じているのか、特定の成果物への適応から生じているのかを見えにくくしていると論じている。
ベンチマークは、現実との整合、包括的でバランスのとれた範囲、体系的な分類体系、評価の忠実性という 4 つの設計原則に基づいて構築されている。8 つのタスク種別、8 つのプログラミングシナリオ、10 の言語からなる分類体系そのものも、Stack Overflow と GitHub から収集したリポジトリレベルのコーディングに関する議論に反復的な能動学習の手順を適用することで、経験的に導き出されている。評価は、ネットワークを無効化した固定のオフラインコンテナ内で、リトライなし、1 回試行の設定、言語ごとに標準化されたビルドおよびテストコマンドで実行される。指標はタスク種別ごとに選ばれており、機能実装、機能拡張、バグ修正、リファクタリングには pass@1、パフォーマンス最適化には二値のスコア、テストケース生成には行カバレッジ、コード理解には LLM-as-a-Judge によるチェックリストスコアが用いられる。
主なポイント
- ベンチマークの構築パイプラインについて、実行に裏付けられた評価データを大規模に構築することの難しさを示す 2 つの数値が報告されている。当初の自動化された Docker ビルドの成功率は約 2% であり、30 名のアノテーターがビルドログを調べ、根本原因を特定し、的を絞った修正を施す専門家支援のリトライ工程によって、全体の残存率は約 8% まで引き上げられた。これにより、約 50,000 件の高品質なプルリクエストから約 4,000 件の実行可能なイメージが得られた。
- タスク種別間では、一貫しているが微妙な難易度の階層が報告されている。コード理解はモデルを通じて最も強いカテゴリの一つであり、機能拡張とリファクタリングが中間層に位置する。機能実装とバグ修正はより難しく、著者らはこれを問題箇所の特定（ローカライゼーション）と統合の難しさに帰している。テストケース生成とパフォーマンス最適化は、平均が 1 桁台にまで落ちることはないものの、依然として難しい。
- 2 つのエージェントフレームワークは、一方が他方を圧倒するのではなく、相補的な結果となった。Claude-Sonnet-4 はどちらのもとでも 1 位で、Claude Code ではマクロ平均 32.9%、SWE-Agent では 31.8% だった。しかし、両方のフレームワークで評価された 5 つのモデルのうち、Claude Code のほうがスコアが高かったのは 2 つだけで、3 つは SWE-Agent のほうが高かった。著者らはこの分かれ方を仕組みに帰している。編集・差分・実行のループは、反復的な問題箇所の特定が報われる調査的で複数ファイルにまたがるタスクに有利だが、その代わりにタイムアウトに陥りやすい。一方、サンドボックス化されたエディター中心のワークフローは、範囲が明確で決定的なタスクにおいて、ツールのオーバーヘッドが小さい分だけ良い性能を示す。
- 言語別の結果は、言語間で一貫した層別を示している。JVM のエコシステムと JavaScript はスコアが高く、TypeScript は顕著に低く、システム言語（C、C++、Rust、Go）はより難しく、Python は中間層に位置する。本論文は Python の位置づけを、オープンソースのベンチマークが難しい Python のバグ修正事例に偏っていることに一部帰している。著者らはこのパターンを、純粋なコーディングの難しさよりも、ツールの決定性と診断のしやすさによって左右されるものと読んでいる。
- 本論文は単純な順位ではなく、労力と成功の関係を報告している。スコアの向上は平均インタラクションターン数の増加と同時に起こることが多いが、ターン数が中程度を超えると収穫逓減となる。本論文はこれを、今後の向上にはさらなる探索ではなく、より良い問題箇所の特定と仮説の枝刈りが必要であることを示す証拠と読んでいる。
- 事後の失敗分析では、3 つの代表的なシステムについてモデルごとに 600 件の失敗した軌跡をサンプリングし、LLM-as-a-Judge のプロトコルを用いて、根本原因の 6 カテゴリの分類体系を構築している。要件の誤解、不十分なテスト、不完全な解決策と副作用、技術的知識の不足、ツール呼び出しのエラー、無限ループである。要件の誤解（30〜34%）と副作用を伴う不完全な解決策（29〜42%）で失敗の 60% 以上を占める一方、技術的知識の不足は一貫して 5〜8% と低い。著者らはこれを、中核的な限界が基本的なコーディング能力ではなく、要件の把握と全体的な解決策の設計にあることを示すものと読んでいる。
- 既存のいくつかのリポジトリレベルのベンチマークを同じ分類体系で注釈付けした分析では、それらのデータセットがバグ修正に完全に偏っていること、シナリオの分布ではアプリケーション開発が支配的であること、インスタンスの大多数を Python が占めることが報告されている。これが、新しいベンチマークが解消しようとしている不均衡である。
補足
本論文の定量的な比較は、論文自身が述べている設定を踏まえて読む必要がある。結果は、固定のデコーディング、ターン数と時間の上限、ネットワークの無効化、リトライなしという 1 回試行のプロトコルから得られたものであり、到達可能な最高性能ではなく、制約された予算のもとでの性能を測っている。失敗モードの分析は、Claude-Sonnet-4 をジャッジとする LLM-as-a-Judge のプロトコルに基づいている。著者らはこれを、自動化されたジャッジと人間の専門家との間に高い一致を報告した先行研究を引いて正当化しているが、まさにこの理由から、論文自身の今後の課題の節では、人手による裁定のサブセットと信頼性の監査を求めている。
著者らが提案する方向性には、規模と言語の範囲の拡大、アーキテクチャの一貫性やセッションをまたぐ記憶を試す、より難しい長コンテキストの設定、中心傾向とあわせて一貫性と分散を報告するより豊かな指標、コストと効率の統一的な報告、そして進化するリポジトリや依存関係のドリフトを伴う、安全なオンラインまたは漸進的な評価トラックが含まれる。