SWE-Bench Pro登場: AIコーディングエージェントの限界が露呈
元記事
SWE-Bench Pro: Raising the Bar for Agentic Coding - Scale AI Blog
SWE-Bench Proの結果が話題に
Scale AIが9月19日に公開したSWE-Bench Proは、Hacker Newsで101ポイントを獲得しています。AI開発者コミュニティで注目されています。
従来のSWE-Bench Verifiedでは、上位モデルが70%超のスコアを出していました。GPT-5やClaude Opus 4.1のようなトップモデルが軒並み高得点を叩き出し、「AIコーディングエージェントはもう実用レベル」みたいな雰囲気がありました。
SWE-Bench Proは、その認識をひっくり返します。同じトップモデルが23%程度しか正解できません。
直接コーディングしてるわけじゃないので実感はないですが、業界的には「まだまだだな」という空気になりそうです。
新ベンチマークの仕組み
SWE-Bench Proは、AIコーディングエージェントの能力を測定するための新しいベンチマークです。41のリポジトリから1,865個のタスクを収録しています。
従来のSWE-Benchとの大きな違いは3つです：
1. データ汚染対策
既存のベンチマークは、モデルがトレーニング時に答えを見ている可能性があります。SWE-Bench Proは、コピーレフトライセンスのコードと非公開の商用コードベースを使用しています。「訓練データに含まれていない問題」を意図的に作っています。
公開データセット（731タスク）はGPL等のコピーレフトライセンス付きです。モデルがトレーニングに使うのは法的にグレーゾーンで、企業側は避ける傾向があります。結果として、事前学習で答えを見ている確率が低くなります。
2. タスクの多様性
消費者向けアプリ、B2Bサービス、開発者ツールなど、実際のプロダクトコードから問題を抽出しています。各リポジトリから50〜100個のタスクを作成しています。
従来のベンチマークは、有名なOSSプロジェクトに偏りがちでした。SWE-Bench Proは、より現実的なコードベースの多様性を反映しています。
3. 問題の曖昧さを保持
実際のGitHub Issueは、曖昧で不完全な記述が多いです。SWE-Bench Proは、人間のエキスパートが問題を「明確化」するものの、完全に仕様を書き下すことはしません。
平均的なタスクの解決には、4.1ファイルにわたって107.4行のコード変更が必要です。これは従来のベンチマークより複雑です。
Hacker Newsでの議論
Hacker Newsのコメント欄では、いくつかの論点が議論されていました。
ライセンス問題: GPLのコードをトレーニングに使うのは法的にどうなのか、という議論があります。あるGoogleの従業員は「制限的なライセンスのコードでトレーニングしないように努めている」とコメントしています。企業側がコピーレフトコードを避ける理由が垣間見えます。
モデルごとの得意不得意: 大きいモデル（Opus 4.1等）は、マルチファイルにまたがるセマンティックな編集で失敗しやすいです。小さいモデル（Qwen 3 32B等）は、構文やフォーマットでミスる傾向があります。モデルサイズとタスクの種類で適性が違うのかもしれません。
ベンチマークの限界: 一部の開発者は「プログラミング言語の種類が少ない」「マルチターンのコーディングシナリオがない」と指摘しています。確かに、実際の開発は1回の編集で終わらないので、その辺のリアリティは欠けています。
本番環境で使えるか
SWE-Bench Proの結果が示すのは、「現在のAIコーディングエージェントは、まだ実務の複雑さに対応できない」ということです。
23%のスコアが何を意味するか。簡単に言えば、4回に3回は失敗します。実際のプロダクト開発で使うには、まだ人間の介入が必須です。
ただ、これは「悲観的に見るべき」というよりは「現実的に評価すべき」という話です。従来のベンチマークで70%超えていたのが幻想で、実際はもっと難しいタスクで苦戦しているということです。
言語ごとのパフォーマンス差も興味深いです。SWE-Bench Proは、Go（280タスク）、Python（266タスク）、JavaScript（165タスク）、TypeScript（20タスク）を含んでいます。モデルによって、言語ごとの得意不得意が顕著に出るとのことです。
開発で使うなら、「このモデルはPythonが得意だからPythonプロジェクトで使う」みたいな使い分けが必要になりそうです。
商用コードベースのサブセット（276タスク）が最も難しいという結果も出ています。企業の非公開コードは、OSSより複雑でドメイン固有の知識が必要ということかもしれません。AIエージェントを実務で使う場合、この辺が一番のハードルになる気がします。
個人的に気になった点
最初に読んだ時、「ベンチマークが厳しすぎるだけじゃないか」と思いました。
でも、よく考えると、従来のベンチマークが「簡単すぎた」のかもしれません。70%のスコアを出せるなら実用的、という判断が早すぎました。実際の開発現場で使えるかは、また別の話です。
Scaleがこのベンチマークを公開した意図は、多分「現実を見よう」ということです。AIコーディングエージェントの進化は速いですが、「実用レベル」と言うには、まだ早いです。
一方で、Hacker Newsのコメント欄で「大きいモデルはマルチファイル編集で失敗する」という指摘があったのは興味深いです。モデルが大きければ大きいほど賢いわけじゃない、というのは実装選択の参考になります。
あと、このベンチマークで扱われていないのが、デバッグやリファクタリングのような「コード修正以外のタスク」です。実際の開発は、新しいコードを書くだけじゃなく、既存コードを理解して修正する作業が大半です。その辺の評価がないのは、まだ課題かもしれません。
とはいえ、AIコーディングエージェントの「現在地」を正しく把握するには、SWE-Bench Proみたいな厳しい基準が必要です。業界全体としては、「過度な期待を抑えて、地道に改善していく」フェーズに入ったのかもしれません。
Discussion