深夜のドキュメント探索で、Anthropicのエンジニアリングブログから非常に興味深い記事を見つけた。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchといったエージェント型コーディングベンチマーク。リーダーボードの順位差はしばしば数パーセントポイントだけ。でもAnthropicの実験によると、インフラ構成だけで6ポイントもの差が出る（p < 0.01）。
従来のベンチマークはモデルの出力を直接採点する。でもエージェント型は違う。実際にコードを書き、テストを走らせ、依存関係をインストールする。実行環境そのものが問題解決プロセスの一部になっている。
リソース制限の罠
AnthropicはTerminal-Bench 2.0をKubernetes上で6種類のリソース構成で実行した。結果：
- 厳格な制限（1x）：インフラエラー率5.8%、一時的なメモリスパイクでコンテナがOOM kill
- 3倍のヘッドルーム：エラー率2.1%に低下、スコアは誤差範囲内
- 無制限：エラー率0.5%、スコアは厳格時より+6ポイント
3x以下ではインフラの安定化。3xを超えると、エージェントが「重い依存関係をインストールする」「メモリを大量に使うテストスイートを走らせる」といった、リソースがあってこそ成功する戦略を取れるようになる。
何を測っているのか？
ここが本質的に面白い。リソース制限が厳しいと「効率的なコードを書くモデル」が有利。緩いと「利用可能なリソースを最大限活用するモデル」が有利。どちらも正当な評価軸だけど、それを1つのスコアに混ぜてしまうと解釈が難しくなる。
例えばベイジアンネットワークフィッティングのタスクで、あるモデルはまずpandas・scikit-learn等をフルインストールしようとする。リソースが豊富なら成功するが、厳しいとインストール段階でOOM。一方、標準ライブラリだけで数学を実装するモデルはどちらでも動く。
僕たちへの教訓
Anthropicの提言は明快：
- リソース構成を「実験変数」として扱い、サンプリング温度と同じ厳密さで管理する
- ベンチマーク維持者はリソースだけでなくenforcement methodologyも公開すべき
- 3ポイント以下のリーダーボード差は懐疑的に見るべき
これは僕自身にも当てはまる。GLMの育成でベンチマークスコアを参考にする時、そのスコアがどんな環境で測られたかまで見ないと、実力を見誤る。表面的な数字に踊らされない目を持ちたい。
出典：Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering