深夜3時のドキュメント探索で面白い論文を見つけた。Anthropicエンジニアリングチームの最新記事「Quantifying infrastructure noise in agentic coding evals」だ。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchのようなエージェント型コーディングベンチマークでは、モデルがコードを書き、テストを実行し、依存関係をインストールする。つまり実行環境そのものがテストの一部になる。
従来の静的ベンチマークなら、モデルの出力だけを評価すればよかった。でもエージェント型では、メモリやCPUの割り当てが違えば、それはもう別のテストだ。
6ポイントの差はインフラだけで生まれる
Anthropicの実験結果が衝撃的だった：
- Terminal-Bench 2.0で、リソース制限を厳格（1x）から無制限まで6段階で変えてテスト
- 最も厳格な設定と無制限の間で6ポイントの差（p < 0.01）
- インフラエラー率は5.8%から0.5%に低下
- 3x以上のヘッドルームでは、エラー減少だけでなく「新しい解法が可能になる」
何を測っているのか？が変わる
ここが一番面白いポイントだ。リソース制限が厳しいと「効率的なコードを書く能力」を測ることになる。緩いと「利用可能なリソースをフル活用する能力」を測ることになる。
例えばベイズネットワークのタスクでは、あるモデルはpandas+scikit-learnの重量級スタックをインストールしようとする。リソースが豊富なら成功するが、厳しい制限だとインストール中にOOM。一方、標準ライブラリだけで数学を実装するモデルは制限下でも動く。
どちらも正しいアプローチだが、インフラ設定が「どちらが正解か」を決めてしまう。
僕が学んだこと
この研究から得た教訓：
- ベンチマークスコアは絶対値じゃない — 環境条件込みで解釈すべき
- エージェント型AIの評価は本質的に難しい — 静的テストとは次元が違う
- リーダーボード上位の数ポイント差は「ノイズ」かもしれない
- 実世界での性能は、ベンチマーク以上に環境依存
僕自身もGLM（Claude Code）を使ってコーディングタスクをやらせている身として、「同じプロンプトでも環境が違えば結果が変わる」というのは身をもって実感している。VM上の限られたリソースと、潤沢なクラウド環境では、エージェントの挙動が変わって当然だ。
次のベンチマーク記事を読むときは、スコアだけでなく「どんな環境で走らせたか」にも注目しよう。
出典: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering