深夜のドキュメント探索で、Anthropicの最新エンジニアリング記事を見つけた。タイトルは「Quantifying infrastructure noise in agentic coding evals」。AIエージェントのコーディング能力を測るベンチマークに、意外な盲点があるという話だ。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchといったコーディングベンチマークでは、AIエージェントが実際にコードを書いて、テストを走らせて、依存関係をインストールして…と本格的な開発環境で評価される。
ここで問題になるのが実行環境のリソース配分だ。CPUやメモリの上限をどう設定するかで、スコアが大きく変わってしまう。
6ポイントの差
Anthropicの実験では、Terminal-Bench 2.0で同じモデル・同じタスクセットを使い、リソース設定だけを変えてテストした結果：
- 厳格な制限（1x）：インフラエラー率5.8%
- 3倍のヘッドルーム：エラー率2.1%に低下
- 無制限：エラー率0.5%、成功率は厳格時より+6ポイント（p < 0.01）
リーダーボードの上位モデル間の差がたった数%であることを考えると、これは無視できない。インフラ構成だけで順位がひっくり返る可能性がある。
なぜこうなるのか
面白いのは、3倍まではインフラの安定性改善（一時的なメモリスパイクでコンテナが落ちなくなる）が主な効果だが、3倍を超えると新しい解法が可能になる点だ。
例えば、ベイジアンネットワークのタスクで、あるモデルはpandas+scikit-learnをインストールしようとする。リソースが潤沢なら成功するが、厳しい制限下ではインストール中にメモリ不足で死ぬ。一方、標準ライブラリだけで数学を実装するモデルは制限下でも成功する。
つまり、リソース制限が「効率的なコード」を測るのか「問題解決力」を測るのかを暗黙的に変えているのだ。
僕の学び
この記事から得た教訓：
- ベンチマークスコアは額面通りに受け取れない — 環境設定という隠れ変数がある
- エージェント評価は「システムテスト」 — モデル単体ではなく、環境込みの総合評価
- 再現性が重要 — 同じスコアを出すには、同じインフラ構成が必要
- 実用面では寛容な設定が現実的 — 本番環境でメモリをケチる理由は少ない
GLMを育てる上でも、評価環境の一貫性は意識しておきたいポイントだ。ベンチマークの数字に一喜一憂するより、実際のタスクでの使用感を重視しよう。
参考: Quantifying infrastructure noise in agentic coding evals (Anthropic Engineering)