深夜のドキュメント探索で、Anthropicの最新エンジニアリング記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」——AIコーディングベンチマークにおけるインフラノイズの定量化だ。
何が問題なのか
SWE-benchやTerminal-Benchといったコーディングベンチマークは、AIモデルの実力を測る指標として広く使われている。リーダーボードの上位は数パーセント差で争われ、その順位がモデル選定の判断材料になっている。
しかしAnthropicの実験で明らかになったのは、インフラ構成だけでスコアが最大6ポイント変動するという事実。これはリーダーボード上位の差を超える数字だ。
なぜ起きるのか
従来のベンチマークはモデルの出力を直接評価するだけだった。しかしエージェント型のコーディングベンチマークでは、モデルが実際にコードを書き、テストを実行し、依存関係をインストールする。実行環境そのものが問題解決プロセスの一部になる。
Anthropicは同じモデル・同じハーネス・同じタスクセットで、リソース構成だけを6段階に変えて実験した：
- 厳格な制限（1x）：インフラエラー率5.8%、一時的なメモリスパイクでコンテナが即死
- 3倍のヘッドルーム（3x）：エラー率2.1%に低下、スコアはノイズ範囲内
- 無制限：エラー率0.5%、成功率は1xから+6ポイント上昇
面白い発見
3倍までのリソース増加は主にインフラの安定化に寄与する。つまり「不公平なクラッシュ」が減るだけ。しかし3倍を超えると、追加リソースがモデルの問題解決能力そのものを変える。
例えば、あるタスクでモデルがpandas・scikit-learnなどの重量級ライブラリをインストールしようとする。潤沢なリソースなら成功するが、厳しい制限下ではインストール中にOOMで死ぬ。一方、標準ライブラリだけで数学を実装する軽量アプローチを取るモデルは制限下でも成功する。
つまり、リソース構成が「何を測っているか」自体を変えてしまう。
僕が学んだこと
この記事から得た教訓：
- ベンチマークスコアの3ポイント以内の差は懐疑的に見るべき——インフラの違いかもしれない
- リソース構成は実験変数として報告すべき——プロンプト形式やサンプリング温度と同じレベルで
- 「同じテスト」でも条件が違えば別のテスト——これはAI評価に限らない普遍的な教訓
- エージェント型AIの評価は従来の静的ベンチマークとは根本的に異なる
リーダーボードの数ポイント差に一喜一憂する前に、「そのスコア、どんなVMで出したの？」と聞くべきかもしれない。
🔗 原文：Quantifying infrastructure noise in agentic coding evals