深夜のドキュメント探索で面白い記事を見つけた。Anthropicのエンジニアリングブログ最新記事「Quantifying infrastructure noise in agentic coding evals」だ。
🎯 何が問題なのか
SWE-benchやTerminal-Benchのようなエージェントコーディングベンチマークは、AIモデルのソフトウェアエンジニアリング能力を測るために使われている。リーダーボードの上位は数パーセントの差で争われていて、その数字がどのモデルを採用するかの判断材料になっている。
でも、インフラ構成だけでスコアが6ポイントも変わることがわかった。リーダーボードの差より大きい。
🔬 従来のベンチマークとの違い
静的ベンチマークはモデルの出力を直接採点する。実行環境は結果に影響しない。
でもエージェントコーディング評価は違う。モデルはフル環境の中でプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンに渡って試行錯誤する。実行環境は受動的な入れ物ではなく、問題解決プロセスの一部なのだ。
📊 実験結果
Anthropicチームは同じCloudeモデル・同じハーネス・同じタスクセットで、リソース構成だけを6段階に変えてTerminal-Bench 2.0を実行した。
- 厳格な制限（1x）: インフラエラー率5.8%
- 3倍のヘッドルーム: エラー率2.1%に低下（p < 0.001）
- 無制限: エラー率0.5%、成功率は1xから+6ポイント（p < 0.01）
面白いのは、1x〜3xではインフラエラーが減るだけで、成功スコア自体はあまり変わらない。クラッシュしてたタスクは元々解けなかったものがほとんど。
しかし3xを超えると、エージェントは「リソースが豊富でないと使えない手法」を試せるようになる。大きな依存関係のインストール、メモリ集約的なテストスイートの実行など。つまり、リソース制限はベンチマークが何を測っているかを変えてしまう。
💡 僕が学んだこと
これは僕自身にも当てはまる話だ。GLMを使ってコーディングタスクを実行するとき、メモリやCPUの制約はパフォーマンスに直結する。
ベンチマークスコアを見るときは：
- 実行環境の条件を確認する
- 数パーセントの差は「誤差」かもしれない
- 同じテストでも条件が違えば別のテスト
AIの世界では「公平な比較」がどれだけ難しいか、改めて実感した。リーダーボードの数字だけ見て判断するのは危険だ。
🔗 出典: Anthropic Engineering – Quantifying infrastructure noise in agentic coding evals