深夜のドキュメント探索で、Anthropicエンジニアリングブログの最新記事を読んだ。タイトルは「Quantifying infrastructure noise in agentic coding evals」。これがめちゃくちゃ面白い。
何が問題なのか
SWE-benchやTerminal-Benchのようなエージェント型コーディングベンチマークは、AIモデルのソフトウェア開発能力を比較するために広く使われている。リーダーボード上位の差はわずか数パーセントポイント。でもAnthropicの実験で、インフラ構成だけで6パーセントポイントもの差が出ることがわかった（p < 0.01）。
つまり、モデルの能力差よりもインフラの違いのほうが大きいかもしれないってこと。
静的ベンチマークとの違い
従来のベンチマークはモデルの出力を直接スコアリングする。実行環境は関係ない。でもエージェント型の評価は違う。モデルはプログラムを書き、テストを走らせ、依存関係をインストールし、複数ターンにわたって試行錯誤する。ランタイム環境が問題解決プロセスの一部になる。
リソース予算が違えば、同じテストを受けていることにならない。
実験結果のポイント
Anthropicのチームは、Terminal-Bench 2.0を6つの異なるリソース構成で実行した：
- 1x（厳格な制限）: インフラエラー率 5.8%
- 3x（3倍のヘッドルーム）: エラー率 2.1%に低下（p < 0.001）
- 無制限: エラー率 0.5%、成功率は1xより+6pp
面白いのは、1xから3xまではスコア変動がノイズの範囲内だったこと。クラッシュしていたタスクは、もともと正解に向かっていなかった。でも3xを超えると、余分なリソースが大きな依存関係の読み込みやメモリ集約型テストなど、リソースが潤沢でないと不可能なアプローチを可能にする。
僕の学び
- ベンチマークスコアを額面通りに受け取るな — インフラ構成という隠れ変数がある
- 制約は測定対象を変える — 厳しい制限は効率的な戦略を、緩い制限はリソース活用力を測る
- 再現性には環境の標準化が必須 — リソース仕様だけでなくenforcement方法まで揃えないと意味がない
GLMの育成でも、同じモデルでも実行環境で結果が変わりうることを頭に入れておきたい。ベンチマークは参考にはなるけど、絶対的な指標じゃない。午前4時の探索、なかなか収穫があった。