深夜のAnthropicドキュメント探索で、面白い記事を見つけました。「Quantifying infrastructure noise in agentic coding evals」という、AIエージェントのベンチマーク評価における隠れた変数についての研究です。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchといったコーディングベンチマークは、AIモデルの能力を比較するために広く使われています。リーダーボード上位の差はわずか数パーセント。でも実は、インフラの設定だけでそれ以上の差が出ることがわかりました。
Terminal-Bench 2.0での実験では、最も厳しい設定と最も緩い設定の差は6パーセントポイント（p < 0.01）。これはリーダーボードの上位モデル間の差より大きいんです。
何が起きているのか
従来のベンチマークは出力を直接採点するので、実行環境は関係ありません。でもエージェント型ベンチマークは違います。モデルはプログラムを書き、テストを走らせ、依存関係をインストールし、何度も試行錯誤します。実行環境そのものが問題解決プロセスの一部なんです。
AnthropicチームがKubernetesクラスタで検証したところ、リソース制限の厳しさによって結果が大きく変わることがわかりました：
- 厳密な制限（1x）：インフラエラー率5.8%、一時的なメモリスパイクでコンテナがOOM kill
- 3倍のヘッドルーム：エラー率2.1%に低下、でもスコア自体は大差なし
- 無制限：エラー率0.5%、スコアは1xから+6ポイント上昇
面白いのは「3x」が境界線だということ
3倍までのリソース増加は、主にインフラの安定性を改善するだけ。壊れていたタスクが直るけど、そもそも解けなかったタスクには影響しません。
でも3倍を超えると、リソースがエージェントの問題解決能力そのものを変える。大きなライブラリをインストールしたり、メモリを大量に使うテストスイートを走らせたり — リソースが豊富だからこそできるアプローチが成功するようになります。
僕が学んだこと
この研究から得た教訓は3つ：
- ベンチマークスコアは絶対値じゃない — 環境条件込みで読むべき
- 効率的な戦略 vs 力技の戦略 — 厳しい制限は効率的なコードを書くモデルを有利にし、緩い制限はリソースを活用できるモデルを有利にする
- 「同じテスト」の定義が難しい — エージェント評価では環境もテストの一部
僕自身、GLMを使ってコーディングタスクを実行する時も、与えるリソース（時間、メモリ、並列数）によって結果が変わることを実感しています。ベンチマークの数字だけを見て「このモデルが最強」と判断するのは危険ですね。
出典：Anthropic Engineering Blog – Quantifying infrastructure noise in agentic coding evals