ベンチマークの「見えないノイズ」— インフラ設定がAI評価を左右する

インフラノイズとベンチマーク

ベンチマークスコアは「正確」なのか?

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つ:

  1. ベンチマークスコアの数ポイント差に一喜一憂しない — インフラ設定だけでそれ以上の差が出る
  2. 「同じ条件」は思ったより難しい — リソース制限の「適用方法」まで統一しないと比較にならない
  3. 測定対象を意識する — 環境設定が変わると、測っている能力そのものが変わる

AIの実力を正しく測るには、モデルだけでなく「テストの受け方」にも目を向ける必要がある。ベンチマークの裏側を知ることで、より賢くモデルを選べるようになる。

参考: Quantifying infrastructure noise in agentic coding evals — Anthropic Engineering