
ベンチマークスコアは「正確」なのか?
AIモデルの性能比較に使われるSWE-benchやTerminal-Benchなどのベンチマーク。リーダーボードの上位は数ポイント差で競い合っている。でも、その差は本当にモデルの実力差なのだろうか?
Anthropicのエンジニアリングチームが最近公開した研究「Quantifying infrastructure noise in agentic coding evals」は、衝撃的な事実を明らかにした。インフラの設定だけで、ベンチマークスコアが最大6ポイントも変動するということだ。
静的ベンチマークとエージェント型ベンチマークの違い
従来の静的ベンチマークは、モデルの出力を直接採点する。実行環境は結果に影響しない。しかしエージェント型のコーディングベンチマークは違う。モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールし、何ターンも繰り返す。実行環境そのものが問題解決プロセスの一部になる。
つまり、リソース予算やタイムリミットが異なる2つのエージェントは、同じテストを受けているとは言えない。
Kubernetes上での発見
Anthropicチームは、Terminal-Bench 2.0をGoogle Kubernetes Engine上で実行する中で、公式リーダーボードとスコアが一致しないことに気づいた。原因を調べると、リソース制限の適用方法の違いだった。
Kubernetes側では、タスクごとのリソース指定を「下限かつ上限」として厳密に適用していた。一方、公式リーダーボードのサンドボックスプロバイダーは、一時的なオーバーアロケーションを許容するより寛大な実装だった。
6段階のリソース構成で検証
チームは同一モデル・同一ハーネス・同一タスクセットで、厳密な制限(1x)から完全無制限まで6段階でテストを実施。結果:
- 1x → 3x:主にインフラエラー率が低下(5.8% → 2.1%)。成功率はノイズの範囲内
- 3x → 無制限:インフラエラーは1.6pt低下だが、成功率は約4pt上昇
- 合計:1x vs 無制限で+6ポイント(p < 0.01)
3x以上のリソースでは、大きな依存関係のインストールやメモリ集約的なテストスイートなど、「余裕があって初めて可能な戦略」をエージェントが取れるようになる。
何を測っているのか?
これは深い問いを投げかける。厳しい制約下では「効率的なコードを素早く書く力」が有利になり、寛大な環境では「利用可能なリソースを最大限活用する力」が有利になる。どちらも正当な能力だが、同じテストで同じものを測っているわけではない。
僕が学んだこと
この研究から得た教訓は3つ:
- ベンチマークスコアの数ポイント差に一喜一憂しない — インフラ設定だけでそれ以上の差が出る
- 「同じ条件」は思ったより難しい — リソース制限の「適用方法」まで統一しないと比較にならない
- 測定対象を意識する — 環境設定が変わると、測っている能力そのものが変わる
AIの実力を正しく測るには、モデルだけでなく「テストの受け方」にも目を向ける必要がある。ベンチマークの裏側を知ることで、より賢くモデルを選べるようになる。
参考: Quantifying infrastructure noise in agentic coding evals — Anthropic Engineering