コーディングAIのベンチマークの読み方【2026】SWE-bench・Terminal-Benchの違いと注意点

コーディングAIのベンチマークとは、モデルやエージェントが実際のコード修正・生成・CLI作業をどれだけこなせるかを、共通のタスク集で標準化して測る指標だ。だが2026年は読み方が大きく変わった。標準だったSWE-bench Verifiedは上位モデルが約80%前後に密集して飽和し、OpenAIは2026年2月にVerifiedの報告を停止して後継のSWE-bench Proを推奨した。ところが同社は2026年7月8日、そのProも公開タスクの約30%が壊れているとして推奨を撤回している（出典: OpenAI・参照2026-07-18）。

つまり「これさえ見れば安心」という定点はなく、指標そのものが揺れ続けている。重要なのは「高スコア=最良」ではない点だ。本記事は主要ベンチが何を測るのかを対応表で整理し、スコアの落とし穴と目的別の読み方を出典付きで中立に解説する。

本記事は特定のモデル・ツール・ベンチを勝たせる構図を作らない。各ベンチの利点と弱点（汚染・飽和・スカフォールド依存・測れない項目）を同じ粒度で併記し、モデル別スコアは月次変動を前提に取得日と出典をセットで示して優劣は断定しない。当社（YDAIコンサルティング AI編集部）は複数事業でAIコーディングツールを実運用してきた立場だが、知見は定性の範囲にとどめ、特定ツールや当社サービスへの送客は一切しない。

コーディングAIのベンチマークは「何を測るか」がベンチごとに異なり、単一の数字で優劣は決まらない。標準だったSWE-bench Verifiedは約80%前後に飽和してOpenAIが2026年2月に報告を停止し、後継のSWE-bench Proも2026年7月8日にOpenAI自身の監査で公開タスクの約30%が壊れていると指摘され推奨撤回された（出典: OpenAI・参照2026-07-18）。 高スコア=最良ではない ——汚染・飽和・報告方式の差を踏まえ、複数のベンチを取得日・出典・測定条件とセットで読むのが2026年の基本だ。

コーディングAIのベンチマークとは？2026年に読み方が変わった全体像

コーディングAIベンチマークの定義と主要な種類

コーディングAIベンチマークとは、モデルやエージェントがコード修正・生成・CLIタスクなどを正しく完遂できる割合を、共通のタスク集で標準化して測る指標である。人間のレビューに頼らず成否を数値化し、モデルやバージョン間の比較を可能にする。

種類は「何を測るか」で分かれる。実バグ修正のSWE-bench系、CLIエージェントの自律実行を測るTerminal-Bench、アルゴリズム力のLiveCodeBench、差分編集の正確さを測るAider Polyglot、実務案件を報酬換算するSWE-Lancerなどだ。同じ「コーディング能力」でも測る側面はベンチごとに異なる。

【早見表】主要ベンチマークが「何を測るか」対応表

ベンチマークは点数の高さより「何を・どう測っているか」で読むべきだ。下表は主要6ベンチが測る対象を、取得日2026-07-18時点の公開情報で整理した（出典: 各ベンチ公式リーダーボード・参照2026-07-18）。数値順位でなく性質で並べている。

ベンチマーク	主に測る対象	評価単位	汚染・飽和への設計
SWE-bench Verified	実issueのバグ修正	モデル（パッチ生成）	人手検証500問。飽和・汚染の指摘あり
SWE-bench Pro	実務的なバグ修正	モデル（標準スカフォールド）	多言語・保守リポジトリで汚染抑制の後継
Terminal-Bench	CLIの自律タスク完遂	エージェント+モデル	タスクごとに独立環境と正解解で検証
LiveCodeBench	アルゴリズム力	モデル	カットオフ後の新規問題で汚染回避
Aider Polyglot	差分編集の正確さ	モデル+Aider	複数言語で編集精度を測る
SWE-Lancer	実案件・報酬換算	モデル/エージェント	実案件ベースで実務性を反映

評価単位が「モデル単体」か「エージェント込み」かだけでも同じモデルのスコアは変わる。数字を比べる前に、この性質の違いを確認するのが出発点だ。

主要ベンチマークの違いを読み解く

SWE-bench Verified：何を測り、なぜ2026年に飽和したか

SWE-bench Verifiedは、実際のGitHubリポジトリのissueをAIがパッチで解決できるかを測るSWE-benchのうち、人手検証した500問のサブセットだ。曖昧・解けない問題を除いてあり、長く事実上の標準として使われてきた。

だが2026年前半、上位モデルが約80%前後に密集して伸びが鈍化し識別力が下がった（飽和）。OpenAIは2026年2月に報告停止を表明した。フロンティアモデルが正解パッチを逐語再現できる汚染の疑いと、難問の相当数にテスト不備があり正しい解答を誤判定していたことが理由だ（出典: OpenAI・参照2026-07-18）。報告停止は無価値化ではなく、フロンティア級かの足切り確認としては今も参照される。

SWE-bench Pro：汚染・飽和への対応と、その限界

SWE-bench Proは、飽和と汚染への対応として登場したScale AI発の後継だ。約1,865タスク（公開731・商用276・非公開の検証用858）を41の実務リポジトリから集め、多言語かつ保守されるコードで公開正解の漏洩を抑え、標準スカフォールドで横並び比較する（出典: SWE-Bench Pro論文・参照2026-07-18）。同じモデルでもVerifiedの80%台から数十%台へ下がり、識別力は高い（数値は月次変動・要再確認）。

ただしProも万能ではない。OpenAIは2026年7月8日、Pro公開731タスクを自動監査と5人のエンジニアで精査し、約30%が「過度に厳格なテスト・仕様不足・低カバレッジ」などで壊れているとして推奨を撤回した（出典: OpenAI・参照2026-07-18）。汚染耐性を狙った後継でさえ設計の粗さで数値が歪む——むしろ「ベンチは揺れる」という本記事の論旨を裏づける。OpenAIは新しい評価をゼロから作り直す必要性も提唱している。

Terminal-Bench：エージェント（ハーネス）とモデルを一体評価する軸

Terminal-Benchは、Stanford大学とLaude Instituteが公開したベンチで、コマンドライン環境でのコンパイル・環境構築・サーバ設定・デバッグなどの実タスク完遂を測る。v2.0は約89タスク（易4・中55・難30）を16分野に用意し、各タスクを独立したDockerコンテナで実行して、人手作成の正解解と網羅的テストで完遂を判定する（出典: Terminal-Bench 2.0・参照2026-07-18）。

最大の特徴は、モデル単体でなくエージェントのスカフォールド（ハーネス）込みで評価する点だ。同じモデルでもどの基盤で動かすかでスコアが動く。パッチ生成を測るSWE-bench系とは測定対象が異なり、ターミナル操作の自律実行に近い側面を捉える。

その他の主要ベンチ（LiveCodeBench・Aider Polyglot・SWE-Lancer）の位置づけ

残る3つも測る側面が異なる。LiveCodeBenchは学習カットオフ後の競技プログラミング問題で暗記（汚染）を避けアルゴリズム力を測る。Aider Polyglotは約6言語・約225問で差分編集フォーマットの正確さを測り、スカフォールドがAider自身に依存する。SWE-LancerはUpworkの実案件をもとに成果を報酬額に換算し実務性を評価する。

1つのベンチで全能力は測れない。アルゴリズムに強くても実務のバグ修正が得意とは限らず、その逆もある。自社の用途に近い側面を測るベンチを選ぶ前提で読む必要がある。

スコアの落とし穴：高スコア＝最良ではない理由

データ汚染（コンタミネーション）と飽和

データ汚染とは、ベンチの問題や正解が訓練データに混入し、実力でなく暗記で解けてしまう現象だ。飽和は上位が高得点域に密集して差が出なくなる状態を指す。SWE-bench Verifiedはこの両方に直面し、報告停止の一因になった（出典: OpenAI・参照2026-07-18）。

設計側の対策は主に2つ。学習カットオフ後の新規問題を使う（LiveCodeBench）か、非公開・保守されるリポジトリを使う（SWE-bench Pro）かだ。ただしProの監査結果が示すように、汚染を抑えても別の粗さは混じりうる。高スコアが実力向上でなく「そのベンチへの露出」を反映していないか、常に疑う姿勢が要る。

報告方式の差：スカフォールド・試行回数（pass@k）・自己申告

同じモデルでも、どのハーネスで動かすか、何回試行してうち1回成功すればよい（pass@k）とするか、公式測定か自己申告かで数値は変わる。たとえば1回で成功を求めるpass@1と、複数回のうち1回成功すればよいpass@kでは、同じモデルでも見かけの成功率が大きく変わる。

報告条件の重要性は、2026年4月のUC Berkeley RDIの研究が痛烈に示した。自動走査エージェントで主要な8つのエージェントベンチを検査し、そのほとんどでほぼ満点を「解かずに」取得できたという。手口は正解キーの読み取りやテスト基盤の改変、LLM審査器へのプロンプト注入などで、モデルの実力とは無関係だった（出典: Berkeley RDI・参照2026-07-18）。数値は「どの条件で測ったか」とセットで読む必要がある。

単一スコアが見落とすもの（コスト・速度・言語・タスク種別）

ベンチマークは特定タスク種別の正答率であり、推論コスト・レイテンシ・対応言語・長文脈保持・保守性・セキュリティといった実運用の要素はほとんど測っていない。パッチ生成が得意でも、月額コストが見合わなければ本番では使えない。

下表に、単一スコアが見落としがちな落とし穴と対処を整理した。自社の業務言語やタスク種別が、そのベンチのタスク分布と一致しているかも要確認だ。

見るべき落とし穴	具体的に何が起きるか	読み手の対処
データ汚染	問題が訓練データに混入し暗記で解ける	カットオフ後・非公開セットを重視
飽和	上位が高得点域に密集し差が出ない	僅差の順位を実力差と解釈しない
報告方式の差	スカフォールド・試行回数・自己申告で動く	測定条件をそろえて比較
測定範囲の狭さ	コスト・速度・言語・保守性は測らない	別軸で自社要件を評価

目的別：ベンチマークの正しい使い方とツール選定への橋渡し

用途別に「どのベンチを・どう読むか」

評価リテラシーの実践は、目的からベンチを選び条件付きで読むことに尽きる。下表は用途別の目安だが、いずれも複数のベンチを取得日・出典・測定条件とセットで読み、単一の数字で決めないのが共通ルールだ（出典: 各ベンチ公式リーダーボード・参照2026-07-18）。

目的	参考にするベンチ	読み方の注意
フロンティア級かの足切り	SWE-bench Verified	飽和前提。僅差は無視する
実力の順位付けの一材料	SWE-bench Pro	破綻タスクの指摘あり。取得日・出典必須
CLIエージェント運用	Terminal-Bench	ハーネス込みの数値と理解する
アルゴリズム力	LiveCodeBench	カットオフ後問題かを確認する
自社言語での編集精度	Aider Polyglot	スカフォールド依存を考慮する

どの用途でも一時点の数字を絶対値とせず、記事内の数値でなく一次リーダーボードを取得日つきで確認する。ベンチは監査や後継版の登場で読み方が変わるからだ。

ベンチの数字からツール・モデル選定へつなげる考え方

ベンチマークが担えるのは候補の絞り込みまでだ。最終判断は、自社の実タスクでの小規模な実地試験（PoC）・推論コスト・既存環境との適合で行う。上位モデルが自社の言語やワークフローで最良とは限らない。

具体的なツール選定に進む際は、用途別のツール横断比較をAIコーディングツールの比較、Claude系とCodex系の設計思想の違いをClaude CodeとCodexの比較、業務向けのモデル選定を業務で使うLLMの比較、自律的に動くエージェントの仕組みを自律型コーディングエージェントで補える。スコアは鵜呑みにせず、選定の一材料に留めるのが安全だ。

まとめ

コーディングAIのベンチマークは、2026年に「どれか1つを見れば安心」という定点を失った。SWE-bench Verifiedは飽和と汚染で報告が止まり、後継のSWE-bench Proも公開タスクの約30%が壊れているとしてOpenAI自身が推奨を撤回した（出典: OpenAI・参照2026-07-18）。Terminal-Benchのようにエージェント込みで測る軸も広がっている。共通するのは高スコア=最良ではないという点だ。各ベンチが何を測り何を測っていないかを押さえ、取得日・出典・測定条件をセットで複数のベンチを読む——この評価リテラシーが、数字に振り回されないための土台になる（本記事は2026年7月18日時点の公開情報にもとづく）。

---

ベンチの数字を実際のツール選びに落とし込むにはAIコーディングツールの比較、代表的なコーディングAIの設計差はClaude CodeとCodexの比較、業務用途のモデル選定は業務で使うLLMの比較、エージェントの内部動作は自律型コーディングエージェントもあわせてどうぞ。