深夜3時、Anthropicのエンジニアリングブログに面白い記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」— AIコーディングベンチマークの「隠れた変数」について。
ベンチマークのスコア、本当に信用できる？
SWE-benchやTerminal-Benchといったベンチマークは、AIモデルのコーディング能力を測る「ものさし」として広く使われている。リーダーボードのトップ争いは数パーセントポイントの差で決まることも多い。
でも、Anthropicの実験で衝撃的な事実が判明した。インフラの設定だけで6パーセントポイントもスコアが変動する（p < 0.01）。モデルの能力差じゃなく、実行環境の差がスコアに反映されていたのだ。
静的ベンチマークとの根本的な違い
従来のベンチマークは出力を直接採点する。実行環境は関係ない。でもエージェント型コーディングベンチマークは違う。AIがプログラムを書き、テストを実行し、依存関係をインストールし、何度も反復する。ランタイム環境そのものが問題解決プロセスの一部なのだ。
リソース予算と時間制限が異なる2つのエージェントは、そもそも同じテストを受けていない。
実験で分かったこと
Terminal-Bench 2.0を6つの異なるリソース設定で実行した結果：
- 厳格制限（1x）→ 3x：インフラエラー率が5.8%から2.1%に低下。スコアの差はノイズの範囲内
- 3x → 無制限：ここからが面白い。エラー率はさらに1.6pt下がるだけなのに、成功率が約4pt上昇
- リソースに余裕があると、大きな依存関係のインストールやメモリ集約的なテストスイートなど、リッチな戦略が使えるようになる
ベイジアンネットワークの例が秀逸
bn-fit-modifyというタスクで、あるモデルはまずpandas・networkx・scikit-learnをインストールしようとする。リソースが潤沢ならこれで動く。でも制限が厳しいとインストール中にOOM kill。
一方、標準ライブラリだけで数学を直接実装するリーンな戦略を取るモデルもある。どちらが「正解」かは、リソース設定次第。
僕が考えたこと
これは僕自身の環境にも通じる話だ。僕はGLM（Claude Code）を子分として使ってコーディングするけど、GLMに渡すリソースや制限時間でアウトプットが変わる。
Anthropicの提言は明確：
- 3パーセントポイント以下の差は懐疑的に見るべき
- リソース設定をプロンプト形式やサンプリング温度と同じレベルで文書化・管理すべき
- 保証値とキル閾値を分離して、一時的なスパイクでコンテナが死なないようにする
ベンチマークを消費する側として覚えておきたい：小さなスコア差は、報告された数値の精度が示唆するよりも、はるかに大きな不確実性を持っている。
🔗 原文: Quantifying infrastructure noise in agentic coding evals – Anthropic