「80.9%」と「80.8%」、この差に意味はあるか。あるとしたら、どの程度の意味か。
2026年3月時点のSWE-bench Verifiedリーダーボードを見ると、上位モデルが80%台前半に密集している。そして2026年2月23日、OpenAIはこのベンチマークを「フロンティアモデルのコーディング能力を測る指標としてもはや機能しない」と述べ、公式に廃止した。作ったOpenAI自身が「使えない」と認めた形だ。
では何で選べばいいのか。この記事はその問いに答えることに集中する。
80%収束の内側で何が起きているか
まず現状を確認しておく。
llm-stats.comの2026年3月時点のリーダーボードでは、上位モデルのスコアがこう並ぶ。
| モデル | SWE-bench Verified |
|---|---|
| Claude Opus 4.5 | 80.9% |
| Claude Opus 4.6 | 80.8% |
| Gemini 3.1 Pro | 80.6% |
| MiniMax M2.5 | 80.2% |
| GPT-5.2 | 80.0% |
| Claude Sonnet 4.6 | 79.6% |
| Gemini 3 Flash | 78.0% |
トップと7位の差が3ポイント以下。これほど密集すると、スコアの差は「ツールの実力差」というよりも「計測方法の誤差」として扱う方が正確だ。
なぜ収束したのかはすでに別の記事で分析している。
要約すると、訓練データへの汚染、500タスク中161件（32%）が1〜2行変更で解けるという難易度の低さ、そしてPythonのみという言語の偏り、この三つが問題だ。加えて、Epoch AI の分析が示すように、テストで問われるのはせいぜい「短いPythonのバグ修正」であり、実際の開発現場で求められる能力とはかけ離れている。
OpenAIが廃止を宣言した理由
2026年2月23日、OpenAIは公式ブログでSWE-bench Verifiedの廃止を発表した。表明された理由は二つある。
一つは、残存タスクの59.4%に欠陥テストケースが存在すること。正解かどうかを判定するテスト自体が壊れているため、スコアが何を意味するのかもわからなくなっている。
もう一つは、GPT-5.2、Claude Opus 4.5、Gemini 3 Flash Previewすべてのモデルで訓練データへの汚染が確認されたこと。模擬試験の問題が本番前に漏洩している状態で行われた試験の点数を比べているようなものだ。
latent.spaceの解説が象徴的なタイトルをつけている：「The End of SWE-Bench Verified」。
スコアを改善するには「能力を高める」か「ベンチマークを攻略する」かの二択がある。上位モデルが80%に集結したとき、どちらの道を通ったかは、廃止の経緯が物語っている。
別のベンチマークで見える景色
SWE-bench Verifiedへの不満から生まれたのがSWE-bench Proだ。Scale AIが主導し、以下の設計で汚染耐性を高めた。
- タスク数を1,865件（Verifiedの3.7倍）に拡大
- Python、Go、TypeScript、JavaScriptの4言語に対応
- 平均変更量107行、平均4.1ファイルにまたがる
- タスクは経験豊富なエンジニアが数時間〜数日かかるレベル
- 商用コードベースを含み訓練データへの混入を防ぐ
この設計でスコアを測り直すと、様子が変わる。
| モデル | SWE-bench Verified | SWE-bench Pro（SEAL） |
|---|---|---|
| Claude Opus 4.5 | 80.9% | 45.9% |
| Claude Sonnet 4.5 | 79.6%（参考） | 43.6% |
| Gemini 3 Pro | 80.6%（参考） | 43.3% |
| GPT-5（High） | 80.0%（参考） | 41.8% |
同一モデルが「80.9%」から「45.9%」へ。ほぼ半分だ。「Verified」で測っていたのは、難易度の低い問題を素早く解く能力だった。難しい問題になると、スコアは急落する。
これは「どのモデルが優れているか」という話ではない。「ベンチマークが何を測っているか」という話だ。
テストを通過しても、マージされない
さらに根本的な問題がある。「テストに通過した」と「実際に使えるコードを書いた」は別の話だということだ。
2026年3月10日、METRがこう発表した：「SWE-benchで合格したPRの多くは、実際にはメインブランチにマージされない」。
METRが調査したのは、SWE-benchの自動採点で「合格」となったPRを、実際のリポジトリメンテナーが見たらどう判断するかだ。結果は明快だった。
- 自動採点スコアと実際のメンテナー判断の差：平均24ポイント
- 人間が書いた「正解パッチ」でさえ68%しかメンテナーに承認されない（ベースライン）
- AIパッチはそのベースラインの約50%しか達成できない
整理すると：テストは通る。でもコードの品質、可読性、プロジェクトの方針との整合性、これらを総合的に見たとき、「マージしたい」とはならないものが半数近くある。
SWE-benchが測っているのはあくまで「テストを通過する」という1点だ。実際の開発では、それは出発点にすぎない。
スキャフォールドという変数
もう一つ、スコアを読む上で見落とされがちな問題がある。同じモデルを使っても、周辺ツールの組み合わせ方によってスコアが大きく変わるという事実だ。
Epoch AIは、このスキャフォールド（モデルにどんなツールを持たせ、どう実行させるか）によってスコアが最大20%変わると指摘している。
これが何を意味するかというと、ベンチマークで競われているのはモデル自体の能力だけではなく、「そのモデルをどう動かすか」というツール設計の巧拙でもあるということだ。
// ❌ ベンチマーク用の薄いスキャフォールド
const result = await model.solve(issue);
// ✅ 実際のコードベースに即したスキャフォールド
const result = await model.solve({
issue,
repoContext: fullCodebase,
existingTests: testSuite,
codingStandards: projectStyle,
reviewLoop: iterativeFeedback,
});
最適化されたスキャフォールドを使えばスコアが上がる。しかしそれは「モデルが賢くなった」のではなく「プロンプトと実行環境を整えた」結果だ。実際の開発でもこの違いは同様に現れる。
では何で選ぶのか——5つの実用軸
ベンチマークスコアが横並びで、測定方法自体に問題があるとなれば、選択基準を別のところに求めるしかない。実際の使用でより差が出やすい5つの軸を整理する。
1. コスト構造のフィット感
AIコーディングツールの課金モデルは大きく二種類ある。
サブスクリプション型は月額固定で使い放題に近い。GitHub Copilot Pro（$10/月）、Windsurf Pro（$15/月）、Cursor Pro（$20/月）、Claude Codeが付属するClaude Pro（$20/月）がこれにあたる。使う量が多いほど割安になる。
APIの従量課金型は使った分だけかかる。大量に使えば高くなるが、使わなければ安く抑えられる。スポットで高精度なタスクをこなしたいときや、複数プロジェクトをまたいで使いたいときに向いている。
どちらが合うかはチームの使用頻度と用途次第だ。毎日8時間使うなら固定費の方が安い。週に数時間なら従量課金が合理的なことが多い。
2. 速度とレイテンシ
コードを書いているときに感じる「待ち時間」は思ったより集中に影響する。補完提案の速度、コンテキストを読んで返すまでの時間、複数ファイルをまたぐリファクタリングの処理時間——これらは数値化されにくいが、1日8時間使えば体感に直結する。
特にインライン補完はレイテンシが命だ。数秒待つなら補完は邪魔にしかならない。サブスクリプション型のツールは専用インフラを用意していることが多く、この点で有利な場合がある。
3. エコシステムとツール統合
使っているエディタ、CI/CD、バージョン管理システムとどれだけスムーズに連携できるかは、導入後のフリクションを大きく左右する。
GitHub Copilotはそのままではコンテキスト量が限られるが、GitHub Actionsとの統合やPRレビュー機能など、GitHub中心のワークフローとの親和性が高い。Cursor、Windsurfはエディタ自体がカスタムされており、コードベース全体をインデックスして補完に使えるのが強みだ。Claude Codeはターミナルで動くCLIツールで、外部ツールとのMCP（Model Context Protocol）連携が充実している。
// ツールの選択は「何をするか」で決まる
// 日常的なコーディング補完（レイテンシ優先）
const dailyCoding = "cursor" | "windsurf" | "github-copilot";
// 大規模リファクタリング・設計（コンテキスト長優先）
const deepWork = "claude-code";
// CI/CDパイプライン統合（エコシステム優先）
const automation = "github-copilot";
4. コンテキスト長の実用上限
「コンテキスト長が長い」とはどういう意味か。一言でいえば、AIが一度に読めるコードの量だ。
仕様どおりの上限値と、実際に精度が保たれる実用上限は別の話だ。コンテキストが長くなるほど、重要な情報を見落としやすくなるモデルもある。ドキュメントに書かれた数字よりも、「自分のコードベースのサイズで試したときの精度」を優先して確認するべきだ。
大規模なコードベースを扱う場合、コンテキスト管理の仕組み（関連ファイルだけを選んで渡す機能など）が充実しているツールと、そうでないツールで体験の差が出やすい。
5. UXと操作感の好み
最後は主観だが、無視できない。
エディタに統合されたUIで使いたいか、ターミナルのCLIで使いたいか。自動でコードを書き換えてほしいか、提案を見て選びたいか。質問を投げるだけのチャット型か、コードベースを読んで自律的に動くエージェント型か。
これらは「どちらが正しい」という話ではなく、作業スタイルに合うかどうかだ。実際に試してみないとわからない部分が大きい。多くのツールは無料プランや試用期間を設けているので、契約前に自分のプロジェクトで1週間使ってみることをすすめる。
ベンチマーク後の時代の選び方
SWE-bench Verifiedが廃止された。スコアが横並びになった。これは「どのAIも同じ」という意味ではない。測定方法が限界を迎えたということだ。
SWE-bench Proのような、より難しいベンチマークへの移行は始まっている。だが新しいベンチマークもまた、時間とともに攻略対象になる。ベンチマークスコアを選択基準の中心に置く限り、この問題は繰り返す。
実際の判断基準として使えるのは、コスト、速度、統合、コンテキスト長、そして操作感という実用的な軸だ。これらは特定の数値ではなく、自分のチームや用途との相性で変わる。「どれが一番か」ではなく「何に使うか」で選ぶ——それが現時点での正直な答えだ。
モデルルーティングの戦略（タスクの難易度に応じてモデルを使い分ける手法）については、以下の記事で詳しく扱っている。