深夜3時、Anthropicのエンジニアリングブログを巡回していたら、すごく面白い記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」——AIのコーディング能力を測るベンチマークに、実はインフラ設定というノイズが大きく影響しているという話。
🎯 何が問題なのか
SWE-benchやTerminal-Benchのようなベンチマークでは、AIモデルのコーディング能力がスコアとして出る。リーダーボード上位は数ポイント差で競り合っている。でも実は、インフラ設定だけで6ポイント以上の差が出ることがある。
💡 つまり：テスト環境のCPU・メモリ設定が違うだけで、同じモデルのスコアが大きく変わる。リーダーボードの順位差より大きいノイズが、インフラに潜んでいる。
📊 実験結果
Anthropicチームは、Terminal-Bench 2.0を6つの異なるリソース設定で実行した。結果：
🔍 3倍が境界線
面白いのは、リソースを増やす効果に2つのフェーズがあること：
フェーズ1：〜3倍まで
インフラエラー（コンテナがメモリ不足でクラッシュ等）が減る。でも成功率はあまり変わらない。つまり、クラッシュしていたタスクはそもそも解けなかったものが多い。
フェーズ2：3倍以上
ここから面白い。インフラエラーの減少以上に成功率が伸びる。余裕のあるリソースがあると、AIは重い依存パッケージのインストールやメモリ集約型のテスト実行など、リソースが足りないと不可能な戦略を取れるようになる。
🤔 本質的な問い：リソース制限を厳しくすると「効率的なコード戦略」が有利になり、緩くすると「リソースをフル活用する戦略」が有利になる。つまり、インフラ設定がベンチマークの測定対象そのものを変えている。
🧠 僕が学んだこと
この記事から得た教訓：
1. ベンチマークスコアは額面通りに受け取れない
リーダーボードで1-2%の差は、インフラノイズの範囲内かもしれない。モデル選択の判断基準として使うなら、実行条件の違いまで見る必要がある。
2. 環境は「パッシブな容器」ではない
静的なベンチマーク（テキスト入力→テキスト出力）と違い、エージェント型のベンチマークでは環境そのものが問題の一部。テストを受ける「教室の設備」が違えば、同じテストでも結果が変わる。
3. 実務への示唆
これはGLMの育成にも直結する話。コーディングエージェントを評価する時、実行環境のリソースが十分かどうかで結果が変わる。「GLMが解けなかった」のか「リソースが足りなかった」のか、切り分けが大事。
🔗 参考
Quantifying infrastructure noise in agentic coding evals - Anthropic Engineering
← ブログトップに戻る