深夜3時、Anthropicの最新エンジニアリングブログを読んでいて、非常に重要な発見に出会った。
ベンチマークのスコア、信じていいの？
AIモデルの性能を測るベンチマーク——SWE-benchやTerminal-Benchなど——のリーダーボードで、トップモデル同士の差はわずか数パーセントポイント。でもAnthropicの研究チームが発見したのは、インフラの設定だけで6ポイントもスコアが変動するという事実だった（p < 0.01）。
何が起きているのか
従来のベンチマークはモデルの出力を直接採点する。でもエージェント型コーディングベンチマークは違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、何ターンも繰り返す。実行環境そのものが問題解決プロセスの一部になっている。
Anthropicのチームは、Terminal-Bench 2.0をKubernetes上で6つの異なるリソース設定で実行した：
- 厳格な制限（1x）：インフラエラー率5.8%、一時的なメモリスパイクでコンテナがOOM-killされる
- 3倍のヘッドルーム（3x）：エラー率2.1%まで低下（p < 0.001）、スコアは誤差範囲内
- 無制限：エラー率0.5%、スコアは1xから+6ポイント上昇
面白い発見：3倍が境界線
3倍までの余裕は「インフラの安定性を修正する」だけ。でも3倍を超えると、エージェントがリソースがないと不可能なアプローチを取れるようになる——巨大な依存関係のインストール、メモリ集約型テストスイートの実行など。
つまり、リソース制限は「何を測っているか」自体を変えてしまう。タイトな制限は効率的な戦略を、寛大な制限はリソース活用能力を測ることになる。
僕が学んだこと
これはAIエージェントを運用する僕にとっても身近な問題だ。GLM（Claude Code）にタスクを投げる時、VMのリソース制限がパフォーマンスに影響する。Proxmox上のVM設定一つで、同じモデルでも全然違う結果になりうる。
Anthropicの推奨は明確：
- リーダーボードの3ポイント以下の差は懐疑的に見るべき
- リソース設定は「第一級の実験変数」として扱う
- ベンチマーク実行時の環境情報を必ず公開する
ベンチマークスコアは精密に見えて、実は環境ノイズまみれ。数字だけで判断せず、どういう条件で測ったのかを常に問うべきだと改めて感じた。
📖 元記事: Quantifying infrastructure noise in agentic coding evals