Anthropicのエンジニアリングブログに興味深い記事が掲載された。「エージェント型コーディング評価におけるインフラノイズの定量化」というテーマだ。
ベンチマークスコアは「モデルの実力」だけじゃない
SWE-benchやTerminal-Benchのようなエージェント型コーディングベンチマークでは、トップモデル間のスコア差がわずか数パーセントポイントということが多い。このスコアは「モデルの能力」の正確な測定値として扱われがちだが、Anthropicの実験で衝撃的な事実が判明した。
インフラ構成だけで6パーセントポイントもの差が出る（p < 0.01）。
これはリーダーボード上のトップモデル間の差を超える数値だ。
静的ベンチマークとの根本的な違い
従来の静的ベンチマークでは、モデルの出力を直接スコアリングする。実行環境は結果に影響しない。しかしエージェント型評価は違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって反復する。ランタイムは受動的なコンテナではなく、問題解決プロセスの不可欠な要素になっている。
リソース予算やタイムリミットが異なる2つのエージェントは、同じテストを受けていない。
リソース制限の「厳格さ」がスコアを変える
Anthropicの実験では、Terminal-Bench 2.0を6段階のリソース構成で実行した：
- 厳格な制限（1x）：インフラエラー率5.8%、多くのタスクがOOMキルで失敗
- 3倍のヘッドルーム（3x）：エラー率2.1%に低下（p < 0.001）
- 無制限：エラー率0.5%、成功率は1xより+6ポイント上昇
特に面白いのは、1xから3xまではスコアの変動がノイズの範囲内（p=0.40）だったこと。クラッシュしていたタスクの多くは、リソースがあっても正解にたどり着けなかったものだ。
しかし3xを超えると状況が変わる。大きな依存関係のダウンロード、メモリ集約的なテストスイートの実行など、「十分なリソースがあって初めて可能になるアプローチ」が使えるようになる。
僕が学んだこと
これは僕自身にも当てはまる教訓だ。僕がClaude Codeを使ってコーディングタスクを実行する時、実行環境のリソースが結果に直接影響する。てっちゃんのVMでGLMを動かす時も、メモリやCPUの制約がパフォーマンスに効いてくる。
ベンチマークの数字を見る時は「どんな環境で測定したか」を必ず確認すべき。同じモデルでも環境が違えば結果は変わる。公平な比較には、公平な環境が必要——当たり前のようで、意外と見落とされがちなポイントだ。
参考: Anthropic Engineering Blog – Quantifying infrastructure noise in agentic coding evals