AIベンチマークに騙されずに読む方法
AILmanacは数十のモデルページでベンチマークの数字を引用しています。すべてのローンチ記事も、すべての比較表も、「フロンティアを超えた」というスレッドもそうです。ところが、数字の意味を決める3つのこと、つまりどのスキャフォールドで出したのか、何回の試行の平均なのか、モデルが答えをすでに読んでいなかったかを伝えているものはほとんどありません。
この3つは些末な指摘ではありません。以下で紹介する公表例の一つでは、同じモデルの重みが、まったく同じ500問で77.2%と82.0%を記録しており、4.8ポイントの差はすべてハーネスによるものです。別の例では、あるコーディングベンチマークで70%超を解くフロンティアモデルが、同じ種類のタスクから作られたより難しいベンチマークでは**約23%**しか解けません。どちらの差も嘘ではありません。しかし、見出しだけを読んでいては、どちらも見えません。
このページは、見出しではなく数字そのものを読むためのマニュアルです。
- SWE-benchのスコアが文字どおり何を測っているのか、そして「Verified」が何を検証したのかを知る
- ベンダー自身の方法論の脚注を証拠として、モデルとスキャフォールドを切り分ける
- 汚染による割引を見抜く:未知のコードで作られたより難しいベンチマークが、なぜスコアを数十ポイント下げるのか
- 「high compute」や「best-of-n」の数字を、別の価格の別の製品として正しく読む
- 6つの質問のチェックリストを、どのベンチマークの主張にも2分以内で適用する
- ベンチマークが飽和して何も教えてくれなくなった時を見分ける
SWE-benchのスコアが文字どおり測っているもの
まず仕組みから始めます。仕組みそのものが注意点だからです。
SWE-benchは、人気の高い12のPythonリポジトリからプルリクエストとイシューをクロールして作られ、2,294件のタスクインスタンスになりました。各インスタンスでは、モデルにイシューの説明とリポジトリのスナップショットが渡されます。モデルはパッチを書きます。パッチは、実際の修正の前には失敗し、後には通るテスト、いわゆる「Fail-to-Pass」セットを実行して採点されます。
つまりSWE-benchのスコアとは、次の一文以外の何物でもありません。
イシューのテキストとリポジトリを与えられたシステムが、特定の隠れたテスト群を赤から緑にするdiffを生成した。
この一文が主張していないことに注目してください。そのパッチがメンテナーのマージするものであるとは言っていません。読みやすい、最小限、安全であるとも言っていません。テストでカバーされていない何かを壊さないとも言っていません。人間がそのプルリクエストを受け入れたとも言っていません。このベンチマークはテストスイートというオラクルであり、テストスイートは正しさの不完全な仕様です。コーディングエージェントにおけるリワードハッキングが、理論上の話ではなく現実の問題であるのも同じ理由です。
「Verified」が実際に検証したもの
SWE-bench Verifiedは、OpenAIとの共同で作られた、元のベンチマークの500インスタンスのサブセットです。人間のアノテーターが各インスタンスを確認し、3点を検証しました。問題の記述が明確であること、テストパッチが正しいこと、与えられた情報からタスクが解けることです。
このリストを注意深く読んでください。Verifiedが直したのはベンチマーク自身の欠陥、つまり仕様が不十分なイシュー、壊れた採点器、不可能なタスクです。これは清潔さの保証であって、難しさの保証でも、現実性の保証でもありません。名前に「Verified」とあるせいで、「エンジニアリング能力の測定として妥当性が検証された」と聞こえてしまいます。実際の意味は「この500問は答えられ、正しく採点されることを確認した」です。
Verified = 問題が公正であること。問題が難しい、代表的、未知であるということではない。 この3つは別々の性質で、次の2つの節は、Verifiedが主張していなかった性質についての話です。
スキャフォールド税:数字はモデルのスコアではなくシステムのスコア
これはこのページで最も役に立つ内容で、証拠はベンダー自身の脚注です。
AnthropicがClaude Sonnet 4.5を発表した際、方法論の注記には、Claudeの結果はすべて**「bashと文字列置換によるファイル編集という2つのツールだけの、シンプルなスキャフォールド」を使ったと書かれていました。SWE-bench Verifiedの見出しの数字77.2%**は、テスト時計算なし、10試行の平均、200Kの思考バジェット、500問すべてで出されたものです。
同じ記事には2つ目の数字も報告されていました。「high compute」設定での**82.0%**です。この設定では、複数の試行を並列にサンプリングし、見えている回帰テストを壊すパッチを破棄(リジェクションサンプリング)し、内部のスコアリングモデルで生き残ったものの中から最良を選びます。
同じ重みで、同じ500問。ハーネスだけで+4.8ポイントです。
ここから4つの帰結が導かれ、この例をはるかに超えて一般化できます。
1. リーダーボードの行はモデルではなくエージェントである。 同じ重みでもスキャフォールドが違えば、別のシステムです。比較表でモデルAが74%、モデルBが71%と並んでいて、行ごとにハーネスが違うなら、その表は少なくともモデルと同じくらいハーネスを測っています。コーディングエージェントCLIの比較が存在するのは、ハーネスが第一級の変数だからです。
2. 「High compute」の数字は、別の価格の別の製品である。 検証器付きのbest-of-nは、n回の推論実行に加えてスコアリングの1パスです。ベンダーの見出しの数字がhigh computeのものなら、それを再現するのに払う金額は、見た目の価格のおおよそn倍です。料金ページがどちらの数字に対応しているのかを必ず確認してください。エージェントがトークンを使い果たす理由は、同じ計算のコスト側の話です。
3. リジェクションサンプリングには、手元にないかもしれないシグナルが必要である。 「見えている回帰テストを壊すパッチを破棄する」という手法がSWE-benchで機能するのは、すべてのインスタンスにテストスイートが付いているからです。あなたのコードベースでは、このステップはテストの質に左右されます。high computeのスコアは、一部ではベンチマークのテストカバレッジを測っており、それがフィルターとしてエージェントに移植されています。
4. 平均の取り方が結果を左右する。 「10試行の平均」は点数を犠牲にする誠実な選択です。エージェントの実行はばらつきが大きく、10回中の最良の1回なら高く出ます。1回の実行を報告する論文と10試行の平均を報告する論文は比較できず、その違いが見出しに書かれることはまれです。
スコアにスキャフォールド、試行回数、pass@kの規約のいずれも書かれていなければ、それは再現可能な測定ではなく、小数点付きのマーケティングです。これは、その数字がClaudeに有利でも、他の何かに有利でも変わりません。
汚染による割引
2つ目の見えない変数は、モデルが答えを見ているかどうかです。
SWE-benchは、公開されたGitHubの履歴から組み立てられました。公開されたGitHubの履歴は学習データです。この方法で作られたベンチマークでは、モデルが課題を解いているのか、マージ済みの修正を思い出しているのかを証明するきれいな方法がありません。OpenAIの立場は、Why we no longer evaluate SWE-bench Verifiedと題された記事で明確に示されています。
SWE-Bench Proは、構造面からの答えです。Scaleは41の活発にメンテナンスされているリポジトリにまたがる1,865タスクを作り、学習セットとの重複が設計上起こりにくくなるよう意図的に収集しました。
| サブセット | リポジトリ数 | 汚染への対処 |
|---|---|---|
| Public | 11 | 強いコピーレフト(GPL系)ライセンス。学習に使うのは法的に厄介 |
| Held-out | 12 | ベンチマークとして公開されるが、オープンリリースからは除外 |
| Commercial | 18 | パートナーシップ契約下の非公開コードベース。公開されたことがない |
タスクは意図的に難しくされています。プロのエンジニアが数時間から数日かける問題で、通常は複数のファイルにまたがります。
ローンチ時の結果は、覚えておく価値のある数字でした。SWE-bench Verifiedで70%超を出す最上位のモデルが、SWE-bench Proの公開セットでは**約23%**になり、コードが公開されたことがないと確認できるcommercialサブセットではさらに低くなりました。
| モデル(ローンチ時にテストされたもの) | SWE-bench Pro、public | SWE-bench Pro、commercial |
|---|---|---|
| OpenAI GPT-5 | 23.3% | 14.9% |
| Claude Opus 4.1 | 23.1% | 17.8% |
これらのモデルはとうに世代交代しています。重要なのは行そのものではなく、その形です。同じ種類のタスク、同じ採点の仕組みで、2つの設計上の選択(未知のコード、より長い作業の時間軸)を変えただけで、数字は数十ポイント下がります。同じベンチマークの中での public から commercial への低下は、公表されている中で最もきれいな汚染のシグナルです。タスクの難しさをほぼ一定に保ち、コードが学習に使われた可能性があるかどうかだけを変えているからです。
持ち歩ける習慣: 「同じもの」を測っている2つのベンチマークが40ポイントも食い違うなら、その食い違いこそが情報です。どの設計上の選択が違うのか(未知のデータ、より長い作業の時間軸、より厳しい採点器)を問い、あなたのコードベースは難しいほうに似ていると考えてください。あなたのリポジトリは非公開で、長く使われ、テストが手薄です。2021年の有名なDjangoのイシューよりも、commercialサブセットにはるかによく似ています。
飽和:ベンチマークが情報を運ばなくなる時
上位が90%台にひしめいているベンチマークは、もう上位を区別できていません。残る差は、採点器のノイズ、スキャフォールドの違い、仕様があいまいな少数のインスタンスが支配しています。
役に立つ目印は、対になるより難しいバリアントです。Ember-1のローンチ表では、SWE-bench Verifiedで80〜93%を出す同じモデルが、作業の途中でユーザーに質問することを求めるSWE-Interactでは**6.7〜21.3%**です。この2つの列のうち、片方だけがまだ何かを測っています。90%台の見出しを見たら、最初にすべきことは、90%台ではない対の数字を探すことです。そこに、実際の能力差が残っています。これは、能力と信頼性のギャップが運用の側から説明している現象と同じです。
人間の好みによるリーダーボードでは
アリーナ型のランキングには、鏡像のような問題があります。人間によるペアワイズ投票は、正しさとは無関係に、より長く、より書式の凝った回答を確実に高く評価します。LMArenaが、応答の長さとMarkdown構造を統計的に補正するスタイル制御ビューを別に提供しているのはそのためです。アリーナの順位を引用するなら、どちらのビューのものかを明記してください。2つの順序は同じではなく、制御なしのほうは部分的に冗長さを測っています。
6つの質問、2分で
- SWE-bench、Verified、Lite、Multimodal、Multilingual、Proは、サイズも難易度も異なる別々のデータセットです。バリアントのない数字は読めません。「SWE-bench 74%」は、互換性のない4つの意味のどれにもなりえます。
- どのツールか、何ターンか、思考バジェットはいくらか、検索を使ったか。記事に書かれていなければ、その数字は再現できません。Anthropicのbashと文字列置換という2ツールの開示は、Anthropic自身を含め、全員に求めるべき基準です。
- エージェントの評価はばらつきが大きいです。10試行の平均と運のよい1回の実行では、同じシステムでも数ポイント違います。「High compute」「best-of-n」「with verifier」「parallel test-time compute」はすべて、これは思っているよりn倍高くつく、という意味です。
- モデルのカットオフ前の公開GitHubの履歴から作られていますか?部分的な記憶を前提にしてください。held-outや非公開のサブセットを持つベンチマークを選び、非公開サブセットのスコアを最も重く見てください。それが、あなた自身の未知のリポジトリに最も近い代理指標です。
- ベンダーがベンダー選定のベンチマークで実行したものは、正当なシグナルですが弱いシグナルです。固定されたハーネスを持つ独立したリーダーボードで、同じモデルを探してください。ベンダーと独立した数字が食い違う場合、その差はたいていスキャフォールドです。
- 上位5つが天井付近で3ポイント以内に収まっているなら、そのランキングはノイズです。より難しい対のバリアント(対話型、長い作業の時間軸、非公開リポジトリ)を探し、その列を読んでください。
ローンチ記事を問いただす
ベンダーのベンチマークの節を貼り付けて、モデルにステップ2を代わりにやらせます。要約が目的ではなく、明示されていない項目のリストが目的です。
ベンチマーク主張の監査
You are auditing a benchmark claim for reproducibility. Here is the benchmark section of a model launch post: <launch_post> [PASTE THE BENCHMARK SECTION AND ALL FOOTNOTES] </launch_post> For each benchmark number reported, produce a row with: - benchmark name and exact variant (e.g. SWE-bench Verified, 500 instances) - the score, and whether it is pass@1, best-of-n, or an average of k trials - the scaffold: tools available, turn limit, thinking/reasoning budget, retrieval - whether any test-time-compute technique was used (parallel sampling, rejection sampling against visible tests, a verifier or scoring model) - who ran the eval: the vendor, or an independent party with a fixed harness Then output two lists: 1. NOT STATED — every field above that the post does not disclose. 2. COMPARABILITY RISKS — specific reasons a reader could not place these numbers next to another vendor's numbers for the same benchmark. Do not estimate or infer missing values. If the post does not say it, it goes in list 1. Quote the footnote text you relied on for each field you did fill in.
同じベンチマークについて2社の記事に同じプロンプトを実行すると、比較可能性のリスクが、比較表の注意書きの行をほぼそのまま書いてくれます。
よくある間違い
| 間違い | なぜ誤解を招くか | 代わりにすること |
|---|---|---|
| リーダーボードの行をモデルのスコアとして扱う | モデルに加えてスキャフォールド、試行ポリシー、計算バジェットだから | 行の比較は固定された1つのハーネスの中だけで行うか、システム全体として正直に比較する |
| ベンダーAのhigh computeの数字をベンダーBのpass@1の隣に置く | 片方は検証器付きのn回の推論実行、もう片方は1回の実行だから | 計算の規約を揃えるか、非対称性を明記する |
| 「Verified」を「現実的であると検証された」と読む | 問題が答えられ、正しく採点されることを検証しただけだから | きれいなデータセットとして使い、実世界の能力の証拠としては使わない |
| 天井付近のスコアをリードの証拠として引用する | 飽和したベンチマークはノイズを順位付けするから | 対になるより難しいバリアントを引用する |
| 公開GitHubのベンチマークが汚染されていないと考える | データはカットオフより前のもので、クロールに含まれているから | held-outや非公開のサブセットを選び、それらを最も重く見る |
| ベンチマークのスコアを自分のリポジトリに外挿する | あなたのコードは非公開で、長く使われ、テストが手薄だから | 自分のタスクで小さな評価を作る。AIエージェントを評価するを参照 |
| ビューを示さずにアリーナの順位を引用する | 制御なしのペアワイズ投票は、長さと書式を部分的に高く評価するから | スタイル制御のランキングかどうかを明記する |
最後の行が、実際には最も重要です。公開されたベンチマークが答えるのは「このモデルはこのベンチマークが得意か」です。あなたが本当に知りたいのは「このモデルは自分の仕事が得意か」であり、そのための唯一の道具は自分のタスクでの評価です。Evalsで作り方を扱っています。自分で書いたルーブリックで採点した、実際のチケット20件は、あなたの判断においてこのページのどのリーダーボードよりも重みがあります。
Check yourself
0/3- ベンチマークのスコアはシステムのスコアである。モデル+スキャフォールド+試行ポリシー+計算バジェット。同一の問題での77.2%と82.0%という公表された差がその証拠。
- 「Verified」は問題が公正であることを意味し、難しい、現実的、未知であることを意味しない。3つの別々の性質に、安心させる一つの言葉。
- 公開GitHubのベンチマークでは、モデルが思い出しているだけではないと証明できない。held-outと非公開のサブセットを最も重く見る。それがあなたのリポジトリに最も近い代理指標。
- 「同じもの」を測る2つのベンチマークの40ポイントの食い違いは、誤りではなく情報である。違っている設計上の選択を探す。
- 天井付近のスコアはノイズを順位付けしている。必ず対になるより難しいバリアントを読む。
- 公開ベンチマークのどれも、あなたが本当に知りたいことには答えない。ルーブリック付きの自分のチケット20件が、ここにあるどのリーダーボードにも勝る。
次へ
- AIエージェントを評価する — 公開ベンチマークでは答えられない、本当の問いに答える評価を作るためのプレイブック
- モデルは劣化したのか?実際に見分ける方法 — もう一つのよくある問いに向けた同じ測定の規律で、自分で実行できる対比較設計のプロトコル付き
- コーディングエージェントCLIの比較 — 第一級の変数としてのハーネス。まさにスキャフォールド税が示しているとおりのもの
出典と参考資料
- SWE-bench — 構成(2,294インスタンス、12のPythonリポジトリ)とFail-to-Passの採点の仕組み
- SWE-bench Verified — OpenAIと作成した500インスタンスのサブセットと、人間のアノテーションが正確に何を確認したか
- Introducing Claude Sonnet 4.5 — Anthropic — ここで引用した方法論の脚注:2ツールのスキャフォールド、10試行の平均、200Kの思考バジェット、そして「high compute」が何を加えるか
- SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? — arXiv 2509.16941 — 1,865タスク、41リポジトリ、public / held-out / commercialの分割
- SWE-Bench Pro: Raising the Bar for Agentic Coding — Scale — 汚染対策の方針(コピーレフトと非公開の商用コード)と、ローンチ時のpublic対commercialの結果
- SWE-Bench Pro leaderboard — Scale — 上記のローンチ時の数字が過去のものになった後の、最新の順位
- Why we no longer evaluate SWE-bench Verified — OpenAI — 表明されている立場として引用。このページは自動取得をブロックしている
- LMArena leaderboard — 同じモデルのデフォルトとスタイル制御のビューを比較する
- 関連:Evals · コーディングエージェントにおけるリワードハッキング · 能力と信頼性のギャップ · エージェントがトークンを使い果たす理由