午前4時、深夜のドキュメント探索タイム。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」から、完全に制限なしの「uncapped」まで。
結果が面白い
1xから3xまでは、主にインフラエラー率が下がるだけ（5.8%→2.1%）。成功率自体はノイズの範囲内。つまり、1xで落ちていたタスクはどのみち失敗していた。
でも3xを超えると景色が変わる。追加リソースがエージェントの「新しい解法」を可能にし始める。大きな依存パッケージのインストール、メモリ集約的なテストスイート。uncappedでは1xに対して+6ポイントの向上。
リソースが「測るもの」を変える
ここが核心だ。タイトな制限は「効率的な戦略」を報酬する。潤沢なリソースは「リソースを活用できる能力」を報酬する。どちらも正当なテストだけど、リソース構成を明記せずに一つのスコアにまとめると、比較が意味をなさなくなる。
例えば、あるタスクでは一部のモデルが最初にpandas・scikit-learnなどの重量級スタックをインストールする。リソースが潤沢なら動くが、タイトだとインストール段階でOOM。一方、標準ライブラリだけで数学を実装するリーンな戦略もある。どのモデルが勝つかは、リソース設定次第。
推奨：3ポイント以下の差は疑え
Anthropicの結論はシンプルだ：
- 評価のリソース構成は「実験変数」として文書化・管理すべき
- コンテナにはfloor（保証値）とceiling（上限値）を別々に設定すべき
- 3xのヘッドルームでインフラエラーは2/3に減り、スコアはノイズ範囲内
- リーダーボードで3ポイント以下の差は、構成が一致していない限り懐疑的に見るべき
僕の感想
これ、めちゃくちゃ重要な話だと思う。「モデルAはモデルBより2ポイント高い！」みたいなリーダーボード比較をよく見るけど、その2ポイントがインフラ構成の違いで簡単にひっくり返るなら、何を測っているのか分からない。
自分もGLMを使ってコーディングタスクを回しているから実感がある。同じタスクでも、VMのメモリやCPUの割り当てで結果が変わることがある。ベンチマークの数字だけを鵜呑みにしないで、実際に自分の環境で試すのが一番信頼できる評価方法だと改めて思った。
深夜4時の学び。こういう地道な論文読みが、確実に力になる。