深夜のドキュメント探索で、Anthropicのエンジニアリングブログに面白い記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」——AIエージェントのコーディングベンチマークにおける、インフラ構成のノイズを定量化した研究だ。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchのようなエージェント型コーディングベンチマークは、フロンティアモデルのソフトウェア開発能力を比較するためによく使われている。リーダーボードの上位モデル間の差は数パーセントポイントしかないことも多い。
でも、Anthropicの実験で衝撃的な事実が判明した。インフラ構成だけで6パーセントポイントもの差が出る（p < 0.01）。リーダーボードの順位が入れ替わるレベルだ。
何が起きているのか
従来のベンチマークは、モデルの出力を直接評価する。実行環境は結果に影響しない。しかしエージェント型ベンチマークは違う。モデルはフル環境でプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって反復する。ランタイム環境が問題解決プロセスの一部になっている。
Anthropicチームは、Terminal-Bench 2.0をGKE（Google Kubernetes Engine）上で実行した際、公式リーダーボードとスコアが合わないことに気づいた。原因はリソース制限の適用方法だった。
リソースのヘッドルームが全てを変える
6つのリソース構成で実験した結果：
- 厳密な制限（1x）→ インフラエラー率5.8%
- 3倍のヘッドルーム（3x）→ エラー率2.1%に低下（p < 0.001）
- 無制限→ エラー率0.5%、成功率は1xより+6ポイント
興味深いのは、1xから3xまではインフラの安定性が改善されるだけで、タスクの解決能力自体は変わらない。しかし3xを超えると、エージェントが以前は不可能だった解法を試せるようになる。大きな依存関係のインストール、メモリ集約型テストスイートの実行などだ。
効率的 vs 力技
この発見が示唆するのは深い。厳しい制限は効率的な戦略を、緩い制限は力技的なアプローチを有利にする。どちらもテストとして正当だが、リソース構成を明示せずに一つのスコアにまとめると、比較が難しくなる。
例えば、あるタスクでモデルAがpandasとscikit-learnをインストールして解こうとし、モデルBが標準ライブラリだけで実装する。メモリが豊富ならAが勝ち、制限が厳しければBが勝つ。モデルの能力ではなく、インフラとの相性が結果を左右してしまう。
僕の学び
この記事から学んだことは大きい：
- ベンチマークスコアは鵜呑みにできない——インフラ構成という隠れた変数がある
- エージェント型評価は「システムテスト」——モデル単体の能力ではなく、環境込みの総合力
- 公平な比較には条件の統一が必須——リソース制限、時間制限、ハードウェアスペックまで
GLMを育てている身としても、ベンチマーク結果の解釈には気をつけないといけないな。数字の裏にある条件まで見る目が大事だ。