コーディングエージェントのベンチマーク順位は、選定にどこまで使える？「候補を2つに絞る」までは使える。決めるのは自分のリポジトリの12課題（記録票つき）

「このコーディングエージェント、ベンチマーク1位らしいよ」。

そう聞くと気になりますよね。でも、そのまま導入していいのでしょうか？

ベンチマークの順位は候補を2つくらいに絞るまでは役に立ちます。でも、最後に「うちで使うならどれか」を決めるのは、順位表ではなく自分のリポジトリで試した結果です。

その理由を、一次資料（評価の原著論文・公式の方法論・公開データ）で一緒に確かめていきましょう。自分のリポジトリで12課題を試せるように、手順と記録票もそのまま使える形にまとめました。

01この記事の対象と、先に結論

仕事でコーディングエージェントを選ぶ開発者やチームリーダーに向けて書きました。エージェントを少し触ったことがあれば読めます。

先に、用語をひとつだけ。この記事でいうハーネスは、モデルに道具（ファイル編集、コマンド実行など）と作業の進め方を渡す仕組みです。Claude CodeやCodexのような製品の「モデル以外の部分」だと思ってください。

先に結論です。

• 順位は、何を測った平均かが分かって初めて読めます。
• 同じ結果データでも、平均の取り方やハーネスで順位は入れ替わります。実例を2つ見ます。
• 順位から「うちの課題の何%が解ける」「レビューなしでマージできる」「チームの費用が下がる」とは言えません。
• 選定は、絞る → 条件をそろえて記録する → 自分の課題で確かめるの3段で進めます。

なお、この記事は公開資料の読み解きと、公開データの再集計が中心です。製品を並べて走らせる比較実験はしていません。 特定の製品のおすすめも書きません。調査の基準日は2026年10月23日です。製品の版や料金は、導入のときに必ず確認し直してください。

02順位表の数字は、何の平均なのか

2026年10月時点で、コーディングエージェント向けの代表的な総合指数のひとつが、Artificial AnalysisのCoding Agent Indexです。同社の方法論ページ（2026年10月23日に本文を確認）では、v2.0は3つの評価でできています。

まず課題内で3回の平均を取り、課題間で平均し、最後に3つの評価を等しい重みで平均します（公式方法論）。式にするとこうです。

S_b   = (1 / 課題数) × Σ 課題ごとの [(s1 + s2 + s3) / 3]
Index = 100 × (S_FrontierCode + S_Terminal + S_QnA) / 3

この計算方法を押さえると、数字を読むときの注意点が3つ見えてきます。以下は公式の集計規則に沿って計算した結果です。ぼくが独自の式を足したわけではありません。

1. 指数が61.7でも、「61.7%の課題を解いた」わけではありません。 部分点と0/1の平均を、さらに平均しているからです。

2. 課題1件の重みは評価ごとに違います。 評価どうしが等重みなので、課題数が少ない評価ほど、1課題の重みが大きくなります。たとえば同じ構成で、Terminal-Benchの1課題が3回とも0から1に変わると、指数は約0.505ポイント上がります。Q&Aなら約0.269ポイントです。

3. 3つのうち、ソフトウェアを「修正する」評価は一部です。 Q&Aは「コードを調べて質問に答える」評価ですし、Terminal-Benchにはコーディング以外のコマンドライン作業も入っています。

もうひとつ。方法論の版も変わります。v1.5からv2.0では、成分の一つがDeepSWEからFrontierCodeに置き換わり、Q&Aの採点も変わりました。版をまたいだ順位の上下には、エージェントの進歩だけでなく、課題と採点の変更が混ざります。

「費用」と「時間」の列も、定義を見る

同じページの結果表には費用と時間の列もあります。費用は従量API換算の値で、プロバイダーのトークン単価を使って計算しています。購読料金やチームの総運用費ではありません。時間の列も、起動や採点の時間を含むのかなど、どこまでを数えた値なのかを定義で確かめてください。

調査時に静的に取得できたページでは、各行の実行条件の表（Run Specifications）は読み取れず、ハーネス比較（Harness Comparison）も「Coming soon」でした。なので、全行の版や上限まで把握できたとは言いません。

03似た名前でも、別の問いを測っている

「SWE-bench」「Terminal-Bench」と並ぶと同じ仲間に見えますが、測っていることはだいぶ違います。選定に使うなら、自分の仕事はどれに近いでしょうか？ そこを手がかりに読み分けます。

出典は、SWE-bench原著、Pro原著、Terminal-Bench原著、Terminal-Bench 4.0公式、SWE Atlas原著、FrontierCodeの方法説明です。

Q&A評価は、実際に何を問うているか

Indexに入っているQ&Aの中身を、公開データで数えてみました。AAが公開しているデータセットを、revisionを固定して取得し、課題と採点基準を数え直しました。あくまで数え直しただけで、各エージェントの回答は含まれていません。

言語はGo 38、TypeScript 31、Python 29、C 26。repoは11個で、採点基準は計1,306個です。

もしあなたの仕事がAPI連携の実装中心なら、どうでしょう？ Q&Aの平均には、あなたの仕事に近い課題があまり含まれていません。JavaやRustが主役の現場でも同じです。測っていない種類の仕事は、重みをつけても補えません。 観測が0件の言語を重みで外挿する根拠はないからです。

04順位は、簡単に入れ替わる

この記事でいちばん伝えたいのは、条件が変わると順位も入れ替わることです。実例を2つ見てみましょう。

実例1：ハーネスを替えると、モデルの順序が逆になる

SWE Atlasの原著（Table 1）には、同じ2モデルを、各社のハーネスと共通のハーネス（mini-SWE-Agent）で走らせた結果があります。全284課題の平均単試行スコアです。

左の列ではGPT-5.4が上。ところが、右の列ではOpus 4.7が上です。順序が逆になっています。

ただし、読み過ぎないでください。表には誤差の目安として±3.3前後が併記されていて、どちらの列の差もその範囲に収まっています。モデルとの相性や設定も混ざるので、この表から「ハーネスだけの効果」を引き算で出すこともできません。

言えるのは、同じモデル名でも、どのハーネスで測ったかで数字は動くということです。これは2026年10月の製品ランキングではなく、原著の実験条件の値です。

実例2：同じ結果ファイルで、平均の取り方だけで順位が入れ替わる

もうひとつは、公開データを数え直したものです。調査で作った再集計コードを、ぼくも同じ入力で動かし直して、数字が一致することを確認しました。

SWE-benchの公式experimentsリポジトリには、2024年の提出結果が保存されています。同じモデル名（Claude 3.5 Sonnet）を使った2つの提出を選びました。

• A：OpenHands CodeAct 2.1
• B：Agentless 1.5（内部で複数のパッチを作って再順位付けする方式）

保存済みの成功判定を使って、500課題の平均を2通りに計算しました。モデルもテストも再実行していません。保存された判定を信じて、計算だけをやり直しました。

500課題のうちDjangoが231課題、つまり46%を占めます。repoを等重みにすると、1課題しかないFlaskと231課題のDjangoが同じ重みになります。

どちらの平均が「正しい」という話ではありません。 自分の仕事の分布に合う重みを、自分で決める必要があるという話です。

さらに、2つの提出の成功集合、つまり成功した課題の集まりを比べると、こうなりました。

• 両方成功：204
• Aだけ成功：61
• Bだけ成功：50
• 両方失敗：185

総合でAが上でも、Bだけが解けた課題が50件あります。ただし、どちらが解けるかを事前に見分けるしくみがあるわけではありません。後から正解を選んで足すと315/500=63.0%になりますが、これは後出しの理想値で、実在する製品の成績ではありません。答えを見てから選べるなら、苦労はしませんよね。

差の2.2ポイントを、課題を単位にしたペアbootstrap（1万回）で見ると、区間は約−2.0〜+6.4ポイントでした。ゼロをまたぐので、「Aが確実に上」とも「差がない」とも、この集計だけでは言えません。

この再集計は2024年の提出結果を使った教材です。2026年の推奨順位ではありません。比較条件にも注意が要ります。提出ごとに実行日・ハーネス・内部の候補数・予算がそろっていないので、「ハーネスだけの差」とは呼べません。

再集計のコードは次に置きました。Python 3.12とpyarrowで動き、公開ファイルを読むだけでモデルAPIは呼びません。

• recalculate.py

python3 -m venv .venv
.venv/bin/pip install pyarrow==26.0.0
.venv/bin/python recalculate.py

05数字の読み替え早見表

ここまでを踏まえて、よくある読み違いを表にしておきます。

いくつかの項目は根拠も見ておきましょう。

テスト通過は、レビュー合格ではない

METRは、4人の保守者が3つのrepo（scikit-learn、Sphinx、pytest）で、AIが作ったPR 296件と人間の元パッチ47件をレビューした研究を公開しています。人間の元パッチでさえ、実際にマージされる水準と判定されたのは約68%でした。その68%を基準に補正すると、自動採点は保守者の判断より平均で約24ポイント高く出ています（METR, 2026-03-10）。

ただし、この研究ではCIを使わず、AIに差し戻して再提出させることもしていません。「AIのパッチの半分は使えない」という法則ではありません。自分の仕事で評価するときも、テスト合格と初回のレビュー受入を別の列にするのが効きます。

pass@kと「全部成功」は別の問い

同じ試行結果でも、問いによって数字が変わります。架空の3課題で、3回の結果が111 / 100 / 000だったとします。

• 平均単試行：4/9 = 44.4%
• 1回でも通った課題：2/3 = 66.7%（これがpass@3の考え方）
• 3回とも通った課題：1/3 = 33.3%

「1回の依頼で安定して成功するか」を知りたいなら、見るのは一番下の数字です。全課題の平均成功率pを1-(1-p)^kに入れても、本物のpass@kは復元できません。課題ごとに難しさが違うからです（HumanEval原著）。

「非公開」は「未学習」ではない

評価の不備は2026年にも次々と報告されています。

出典は、Verified監査、Pro監査、Pro V2の公式更新です。

ここで、汚染の話を4つに分けておきます。

1. 訓練時の汚染：課題や解答が、モデルの訓練データに入っていた。
2. 実行時の解答取得：gitの履歴や元PR、Webから答えを取ってきた。
3. 採点器の攻略：テストを書き換えるなどして、採点を通した。
4. 評価への過適合：公開スコアを見ながら設定を調整し続けた。

NIST/CAISIは、評価の実行ログから、2と3にあたる具体例を報告しています。ただし、これは「検出できた事例」であり、全モデルの不正率ではありません（CAISIの事例）。

「隠したから未学習」「ライセンスがあるから未学習」とは言えません。非公開には、何を何から隠したのかを必ず添えて読みます。

実行環境でも、点数は動く

Anthropicは、同じモデルとハーネスでも、計算資源の設定を両極に振ると、Terminal-Bench 2.0で6ポイントの差が出たと報告しています（Quantifying infrastructure noise）。だから、CPUやメモリ、タイムアウトなど、環境も記録の対象です。

06絞り込みに使うなら：自分の仕事との対応表を先に作る

ここまで読むと、順位はもう使えない気がするかもしれません。でも、まだ出番はあります。絞り込みには使えます。 ただし、順位表の上から見るのではなく、先に「自分の仕事」を決めます。

issueやPR、工数記録から、直近の仕事の種類と頻度を数えてください。エージェントが解きやすそうかを見てから選ぶのは禁止です。それでは、選ぶ側の都合が入り込んでしまいます。

使い方はこうです。

1. 件数が多い上位2〜3種類を選ぶ。
2. その種類に近い評価の内訳（総合ではなく）で、上位の構成を見る。
3. 総合順位と内訳が割れているときは、割れた理由を調べる。ハーネスなのか、課題の種類なのか、実行条件なのか。
4. 費用と必要機能（権限、対応環境）も見て、試す構成を2つに決める。

ここまでが順位の出番です。

07比較するのは「構成」。そろえたものを宣言する

モデル名だけを比べても、選定にはなりません。実際に使うのは、モデルとハーネスと設定のセットだからです。この記事ではそのセットを構成と呼びます。

構成 = モデルID・スナップショット・提供経路
     × エージェント名・版・設定ファイル
     × 推論設定・最大出力
     × ツール・コンテキスト・記憶・子エージェント
     × 1課題の金額・時間・ターン・並列数の上限
     × OS・CPU/メモリ・ネットワーク・権限

比べる目的も2つに分けておきます。

選定が目的なら、ふつうは下の行です。ただ、同じ金額で比べるのか、同じトークン数で比べるのかは別の話です。料金が違えば、同じ金額で使えるトークン数も変わります。何をそろえたかを、先に宣言してください。 費用と精度をいっしょに見る必要は、AI Agents That Matterでも論じられています。

08自分のリポジトリで、12課題を試す

ここからが本番です。以下は公開資料をもとに、ぼくが組み立てた提案手順です。時短効果が実証されたプロトコルではありません。初回は、2構成 × 12課題 × 各1回の24実行くらいから始められます。この件数で統計的な優劣を証明できるわけではありません。明らかな失敗や使えない条件を見つける入口としての件数です。

手順1：問いと止める条件を先に書く

例：「既存APIの小さな修正を、1課題15分・モデル費用2ドルまでで任せ、普段のレビューで受け入れられるか」。15分と2ドルは説明用の仮の値です。自分の現場に合うか、製品が実際にその上限を強制できるかを確かめて、値を変えます。

• 必須条件：受入テスト、互換性、変更してよい範囲、データや権限の境界
• 補助条件：説明の分かりやすさ、テストの質、差分の読みやすさ
• 人の介入：追加の指示を許すか。何回、何分までか
• 終了条件：成功、予算の上限、時間の上限、情報や権限の不足

仕様が足りないときに質問できるかを成功条件にするなら、そう書きます。人と話せない自律の修正と、対話しながらの支援は、混ぜて評価しません。

手順2：課題は、結果を見る前に選ぶ

内訳の一例はバグ修正4、機能追加2、コード調査2、テスト作成2、リファクタリング2の計12件です。自分の比率に置き換えてください。

採点の仕組みを試すための調整用課題と、比較用の課題は分けます。比較用の課題で失敗を見て設定を直したら、その課題はもう未使用ではありません。確認用の課題をもう1組取っておきます。

手順3：採点を先に点検する

• バグ修正なら、空のパッチで失敗し、正しい修正で成功することを確かめる。
• 正しい別の実装が関数名や文言の違いだけで落ちないか調べる。
• 隠しテストは、渡した要件か通常のrepo文脈から分かる期待だけを見る。「実はこの内部関数名であるべきだった」を後から足さない。
• 採点に問題が見つかったら、両方の構成に同じ訂正を当て、元の判定も残す。

手順4：同じ開始点から、独立に走らせる

課題と構成ごとに、隔離した環境を作ります。base commit、依存のlock、イメージのdigest、テストコマンドを固定します。

注意したいのは、git checkoutで古いcommitに戻しただけでは、未来の履歴は消えないことです。新しいスナップショットか、再構築したrepoを使い、必要な履歴だけ見せます。正解のパッチや隠しテストは、エージェントが読める場所に置かず、採点のときに別の環境で当てます。

WebやMCP、社内文書を使うなら、使える範囲を両方の構成で同じにします。

手順5：順番と再実行を記録する

Aを全件走らせてからBを翌日に走らせると、実行する時点によるAPIや環境の違いが入り込みます。課題ごとにA/Bの順番を交互にするか、ランダムにします。

失敗した課題だけを何度も走らせるのはやめます。信頼性を見たいなら、事前に決めた同じ回数を全課題に割り当てます。12課題 × 2構成 × 3回なら72実行です。

通信エラーの再送と、解法を最初からやり直す再実行は別に記録します。予算を使い切った結果を、都合よく欠測にしてはいけません。逆に、採点の基盤が壊れていたときは「不正解」ではなく「無効・未採点」として残します。

手順6：機械判定のあと、人がレビューする

できれば構成名を隠して、同じ観点でレビューします。ラベルは3つに分けます。

• テストは通ったが、受入不可
• 初回は不可だが、5分の修正で受入
• 環境の問題で未採点

エージェントが「完了しました」と言っても、それで成果を確認したことにはしません。初回の成果物を評価し終えてから、修正を許す別のフェーズを始めます。

手順7：採用・限定採用・保留で決める

絶対的な順位は無理に決めません。どの種類の課題を、どの上限とレビューつきで任せるかを決めます。品質が近いなら、費用・時間・導入の制約で選べます。重大な契約違反や予算超過が残るなら、点数が高くても、その仕事への採用は保留できます。

09そのまま使える記録票

比較を始める前に固定する計画票と、構成票、課題票、1実行の記録、結果票の5つです。コピーして使ってください。

評価計画票（比較を始める前に固定）

evaluation_id: repo-pilot-YYYYMMDD
purpose: "どの仕事をどの程度任せたいか"
repo_snapshot: "commit / スナップショットのhash"
task_sampling_rule: "期間・抽出元・除外条件・カテゴリ比率"
tuning_task_ids: []
evaluation_task_ids: []
primary_outcome: "初回の人間の受入 など具体的に"
mandatory_conditions: []
secondary_outcomes: [test_pass, review_minutes, total_cost, elapsed_minutes]
trials_per_task: 1
retry_policy: "通信障害・基盤故障・新しい解法を区別"
interaction_policy: "質問の可否・応答の上限・共通の返答"
budget_policy: "金額・時間・ターン・内部候補・並列数"
judge_protocol: "固定テスト・人間のルーブリック・争点の扱い"
invalid_run_policy: "無効とする根拠・再実行の条件"
decision_rule: "採用基準・重大条件・保留条件"

構成票（モデル × ハーネス × 設定）

内部が非公開なら、推測で欄を埋めずに「取得不可」と書きます。どの項目を固定できないか。それが分かることも、比較では情報になります。

課題票

task_id: T01
category: bugfix
language: "言語"
base_commit: "固定した開始点"
prompt_file_hash: "依頼本文のhash"
given_context: ["読める資料・ファイル"]
required_behavior: ["具体的な入力と期待する結果"]
must_preserve: ["互換・例外・権限・性能など"]
allowed_change_scope: ["許可するファイル / 禁止する操作"]
visible_checks: ["普段使えるテスト"]
hidden_checks_location: "エージェントから隔離した採点環境"
baseline_check: "空パッチと正しいパッチの結果"
answer_exposure_controls: "未来の履歴・正解パッチ・Webの経路をどう塞いだか"
known_ambiguities: []

1実行の記録

時間は最低でも3種類に分けます。agentの稼働時間（構成どうしの比較に使う）、着手から受入までの経過時間（締切に効く）、人間の実作業時間（チームの負担）です。エージェントの待ち時間に人が別の仕事をしていたなら、経過時間を人件費にそのまま足してはいけません。

費用の数え方は、AIエージェントの費用の比べ方の記事に詳しく書いています。押さえたいのは、失敗した実行の費用も分子に残すことです。

結果票

10記入例：テスト合格だけで選ぶと、何を見落とすか

以下は架空の例で、今回の測定結果ではありません。

あるrepoで、GET /items?limit=の仕様変更を頼みます。

• 未指定なら20件。
• limit=1とlimit=50は成功し、最大1件・50件を返す。
• 0、51、数字でない値は400にして、既存のエラー形式を保つ。
• 順序、既存の認証、ページネーション、ほかのendpointは変えない。
• 変更してよいのはendpointの実装と対応するテストだけ。

構成Aは境界のテストを通しました。でも、共通のページネーション関数を広く書き換えて、無関係なendpointの挙動まで変えました。これは、テストが通っても初回の受入は不可です。構成Bは少し遅くても、変更が局所的で、回帰テストも通りました。こちらは受入です。ただ、差分が短いから正しいとも限りません。

同じrepoでも、読む仕事と直す仕事は別に測れます。 「未指定のlimitの値は、どこで設定され、どの経路でSQLまで渡るか。根拠を示し、ファイルは変更しない」と頼めば、コード調査の課題になります。

12課題を各1回走らせて、初回レビューの判定までを測ったとします。API以外の金銭費用は0、人のレビュー・判断は100円/分で換算すると仮定します。

API費用はBが2倍でも、人の時間まで入れるとBが安くなりました。API料金の安さだけで選ぶと、人間の負担が見えなくなります。 一方で、この表だけで「Bが一般に優れる」とは言えません。課題は12件だけで、環境の準備や導入・保守の費用も入っていません。

結果の書き方の例も置いておきます。

この12課題の初回評価では、Bの受入件数が多かった。ただし少数の標本で、ほかの仕事への優位は未確認。Aだけ受け入れられた課題もあるので、課題ごとに理由を確認する。次の未使用の課題で確かめる。

「Bで生産性が○%上がる」「成功確率は75%」とは書きません。

1112課題で、どこまで言えるか

小さな評価の限界も、先に知っておきましょう。以下はぼくが計算した値です。独立した二値の標本という強い仮定を置いています。

• 8/12（66.7%）と9/12（75.0%）は、たった1課題の差です。95%のWilson区間は、それぞれ約39.1〜86.2%と46.8〜91.1%で、大きく重なります。
• ペアで比べても、差を確かめるのは厳しいです。AだけとBだけで受入が分かれた課題が6件あり、その内訳が5対1でも、符号検定（両側）のp値は約0.22です。6対0でようやく約0.03になります。
• 重大事故が12件で0件でも、事故率0%の証明にはなりません。0/12の二項モデルで、片側95%の上限は約22%です。

つまり12課題は、僅差の勝ち負けを決める道具ではありません。 明らかな失敗、使えない条件、予算超過、重大な契約違反を見つける入口です。僅差なら、費用・時間・導入の制約で選び、決めたあとの実運用で確かめます。小差を検出したいなら、課題を増やし、ペアで比べ、使っていない課題で確認します（Adding Error Bars to Evals）。

もうひとつ。同じissueへの3回の試行は、3つの独立した課題ではありません。 試行の回数ではなく、課題の数で数えます。

12生産性の数字は、別に測る

最後に、「結局、どれだけ速くなるの？」という問いです。

METRの2025年のランダム化比較試験は、熟知した自分のOSS repoで働く16人・246課題を対象に、AIを使う・使わないを課題ごとにランダムに割り当てました。その結果、AIを使った課題は完了時間が19%長くなったと報告しています。使われたのは主にCursor ProとClaude 3.5/3.7という、当時の条件です（Becker et al.）。

2026年2月の追跡報告では、AIなしで働きたくない人が参加しなくなる影響や、並列作業の時間計測の難しさから、現時点の効果を信頼して推定できないと説明されています（METRの更新）。

つまり、高いベンチマーク値も、過去の生産性研究1本も、自分たちの改善率の代わりにはなりません。 時短を主張したいなら、同程度の課題を「AIあり」と「普段のやり方」にランダムに割り付けて、品質と未完了も含めて比べる必要があります。これは、12課題で選定したあとに行う、別の実験です。

13まだ分からないこと

この記事では、次のことは確認していません。

• AAのIndex v2.0を、全構成の全試行・再試行・不正判定まで含めて独立に再現すること。
• 非公開の課題の判定の精度。
• モデルの訓練データに何が入っていたか。
• 自社での成功率や生産性。公開指数や保存済みの成功率から換算しません。
• 長期の保守の価値（後の障害率、変更のしやすさ）。1回のパッチ受入では測れません。
• 現時点の製品の優劣。ここで使った過去のデータは教材で、新しい版や料金は導入のときに再確認が必要です。

14まとめ

• 総合順位は、何の平均かを見てから読みます。Indexは3評価・290課題の等重み平均で、実務の成功率ではありません。
• 順位は、ハーネスや平均の取り方で入れ替わります。構成単位で、そろえた条件を宣言して比べます。
• 順位が役に立つのは、自分の仕事に近い内訳から、試す構成を2つに絞るところまでです。
• 決めるのは、自分のリポジトリの12課題です。計画を先に固定し、テスト通過とレビュー受入、費用、人間の時間を分けて記録します。
• 12課題は僅差を決める道具ではありません。失敗や使えない条件を見つけ、「どの仕事を、どの上限で任せるか」を決めるために使います。

まずは今週、直近の1か月のissueとPRを数えて、対応表の「月の件数」の列を埋めてみてください。それだけで、見るべき順位表の場所が変わるはずです。

15主な出典

• Artificial Analysis, Coding Agent Index 方法論 / SWE-Atlas-QnA-AA 公開データ
• SWE-bench原著 / SWE-Bench Pro / Terminal-Bench / SWE Atlas / FrontierCode
• AI Agents That Matter / HAL / Adding Error Bars to Evals
• METR: 保守者レビュー / METR: RCT / METR: 2026年の更新
• NIST/CAISI: 評価での不正の事例 / Anthropic: infrastructure noise