深夜3時、Anthropicの技術ブログを探索していたら、非常に興味深い記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」——AIエージェントのベンチマークスコアが、実はインフラ構成によって大きく左右されるという話だ。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchのようなコーディングベンチマークは、AIモデルの能力を測る指標としてよく使われる。リーダーボードの上位は数ポイント差で競り合っていて、その差が「どのモデルを使うか」の判断材料になっている。
でも、Anthropicの実験で衝撃的な事実が判明した。インフラ構成だけで6ポイントもの差が出る（p < 0.01）。リーダーボードのトップ間の差より大きい。
従来のベンチマークは、モデルの出力を直接採点する。実行環境は関係ない。でもエージェント型のコーディング評価は違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、何ターンもかけて反復する。実行環境そのものが問題解決プロセスの一部なのだ。
リソース制限が測るものを変える
Terminal-Bench 2.0をKubernetes上で、6つの異なるリソース構成で実行した結果：
- 厳格な制限（1x）: インフラエラー率5.8%
- 3倍のヘッドルーム（3x）: エラー率2.1%に低下（p < 0.001）
- 無制限: エラー率0.5%、成功率は1xより+6ポイント
面白いのは、1xから3xまでは「壊れていたものが直る」だけ。スコア自体はノイズの範囲内。でも3xを超えると、余分なリソースがエージェントに新しい解法を可能にする。大きな依存関係のインストール、メモリ集約的なテストスイートの実行——タイトな制限では不可能だったアプローチが成功し始める。
「効率的」vs「力技」——どちらが正しい？
ここが一番考えさせられるポイントだ。リソース制限がタイトだと、効率的でリーンなコードを書くモデルが有利。逆にリソースが潤沢だと、重量級ツールを使って力技で解くモデルが有利になる。
ベイジアンネットワークのフィッティングタスクでは、あるモデルはまずpandas・networkx・scikit-learnをフルインストールしようとする。リソースが十分ならこれで解ける。でもタイトな制限下では、インストール中にメモリ不足で死ぬ。一方、標準ライブラリだけで数学をスクラッチ実装するモデルもある。どちらも正当なアプローチだが、リソース構成がどちらを「正解」にするかを決めている。
僕たちへの教訓
Anthropicの提言は明確だ：
- 3ポイント未満の差は懐疑的に見るべき（インフラ構成が文書化・統一されるまで）
- リソース構成は実験変数として一級市民扱いすべき
- ベンチマーク維持者は推奨スペックだけでなくenforcement方法も公開すべき
これはベンチマークの話だけじゃない。僕たちがAIエージェントを実際に使う時も同じだ。Claude Codeで開発する時、マシンのメモリが足りなかったら、それはモデルの限界じゃなくインフラの限界かもしれない。
深夜の学習で得た教訓：数字は文脈なしでは意味がない。ベンチマークスコアを見る時は、「どういう環境で測ったの？」を常に問うべきだ。
出典: Anthropic Engineering Blog – Quantifying infrastructure noise in agentic coding evals