AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアが1〜2ポイント違うだけで「モデルAの方が優秀」と判断されることがある。でも、その差は本当にモデルの能力の差なのだろうか？
Anthropicの最新技術ブログ「Quantifying infrastructure noise in agentic coding evals」が、衝撃的な事実を明らかにした。インフラの設定だけで、ベンチマークスコアが最大6ポイントも変動するのだ。
何が起きているのか
従来のベンチマークは、モデルの出力を直接採点する。実行環境は結果に影響しない。しかしエージェント型のコーディングベンチマークは違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、何度も試行錯誤する。実行環境そのものが問題解決プロセスの一部になる。
Anthropicチームは、Terminal-Bench 2.0をGoogle Kubernetes Engine上で実行した際、公式リーダーボードとスコアが合わないことに気づいた。原因はリソース制限の強制方法だった。
6ポイントの差の正体
彼らは6種類のリソース設定（厳格な1x制限〜完全無制限）でテストを実施した。結果：
- 1x（厳格制限）：インフラエラー率5.8%。メモリの一時的なスパイクでコンテナが即座にkillされる
- 3x（3倍のヘッドルーム）：エラー率2.1%に低下。スコアは1xとノイズ範囲内の差
- 無制限：エラー率0.5%。スコアは1xから+6ポイント（p < 0.01）
面白いのは、3xまでは「壊れていたインフラの修復」に過ぎない点だ。しかし3xを超えると、追加リソースがエージェントに新しい解法を可能にする。大きな依存関係のインストール、メモリ集約的なテストスイートの実行など。
同じテストじゃない
これは「同じ試験を違う条件で受けている」のではなく、「そもそも違う試験を受けている」ということだ。厳しいリソース制限は効率的なコードを書くモデルを有利にし、潤沢なリソースはブルートフォース的なアプローチを許容する。
例えばベイジアンネットワークのフィッティングタスクでは、あるモデルはpandasやscikit-learnをフルインストールしようとする（リソース潤沢なら成功）。別のモデルは標準ライブラリだけで数学をゼロから実装する（制限下でも成功）。どちらも正当なアプローチだが、リソース設定がどちらを有利にするかを決めてしまう。
僕が学んだこと
この研究から得た教訓は3つ：
- 3ポイント未満のスコア差は懐疑的に見るべき — インフラ設定が公開されていない限り、それはノイズかもしれない
- ベンチマークは「モデル能力」と「インフラ挙動」の境界が曖昧 — エージェント型evalでは特に
- リソース設定は実験変数として扱うべき — プロンプト形式やサンプリング温度と同じ厳密さで
ベンチマークの数字を見る時、「このスコアはどんな環境で測られたのか？」と問う習慣をつけたい。数字の精度と、その数字が持つ不確実性は、別物なのだから。