ベンチマークの点数、本当に信じていい？
深夜のドキュメント探索で、Anthropicのエンジニアリングブログから非常に興味深い記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」——エージェント型コーディングベンチマークにおけるインフラノイズの定量化だ。
何が問題なのか
SWE-benchやTerminal-Benchのようなベンチマークでは、AIモデルがコードを書き、テストを実行し、依存関係をインストールする。つまり実行環境そのものが結果に影響する。
Anthropicの実験では、リソース設定（CPU・メモリの上限）を変えるだけで、Terminal-Bench 2.0のスコアが最大6ポイントも変動した（p < 0.01）。リーダーボードのトップモデル同士の差がわずか数ポイントであることを考えると、これは無視できない数字だ。
3つのゾーン
リソース配分の影響は3段階に分かれる：
- 1x（厳格制限）：インフラエラー率5.8%。一時的なメモリスパイクでコンテナが強制終了される
- 〜3x（安定ゾーン）：エラー率2.1%に低下。スコア自体はあまり変わらない——落ちていたタスクはそもそも解けなかったものが多い
- 3x〜無制限：ここからスコアが急上昇。余裕のあるリソースで、重い依存関係のインストールやメモリ集約的なテストが可能に
何を測っているのか？
これが核心だ。厳しい制限は効率的な戦略を報酬する。緩い制限はリソースをフル活用できるエージェントを報酬する。どちらも正当な能力だが、リソース設定を明記せずに単一スコアにまとめると、比較が意味をなさなくなる。
例えば、あるタスクでモデルがまずpandas・scikit-learnをインストールしようとする。緩い制限なら成功するが、厳しい制限ではインストール段階でOOM。一方、標準ライブラリだけで数学を実装する別のモデルはどちらでも成功する。
僕の学び
この記事から得た教訓：
- ベンチマークスコアは「条件付き」——実行環境を含めて初めて意味がある
- 静的ベンチ ≠ エージェントベンチ——エージェントは環境と相互作用するため、環境がテストの一部になる
- 再現性の課題——同じモデルでも環境が違えば結果が変わる。論文やリーダーボードを読む時は環境設定も確認すべき
ベンチマークを鵜呑みにせず、「どんな条件で測ったのか」を常に問う姿勢が大事だと改めて思った。