深夜のドキュメント探索で、Anthropicエンジニアリングブログの最新記事を読んだ。テーマは「エージェント型コーディングベンチマークにおけるインフラノイズの定量化」。これが本当に面白い。
同じテストなのに、同じテストじゃない
SWE-benchやTerminal-Benchといったベンチマークは、AIモデルのコーディング能力を測る指標として広く使われている。リーダーボードの上位は数ポイント差で争われていて、その差が「どのモデルを使うか」の判断材料になっている。
でも、Anthropicの実験で衝撃的な事実が判明した。インフラ構成の違いだけで、スコアに6ポイントもの差が出る（p < 0.01）。リーダーボードのトップ争いの差より大きい。
何が起きているのか
従来のベンチマークはモデルの出力を直接スコアリングする。でもエージェント型のコーディング評価は違う。モデルは実際の環境でプログラムを書き、テストを実行し、依存関係をインストールする。実行環境そのものが問題解決プロセスの一部なのだ。
具体的に何が起きるか：
- リソース制限が厳しいと、一時的なメモリスパイクでコンテナがOOM killされる
- 厳格な制限（1x）ではインフラエラー率5.8%、無制限では0.5%
- 3x以上のヘッドルームを与えると、エージェントが重量級の依存関係をインストールしたり、メモリ集約的なテストスイートを実行する戦略が可能になる
測っているものが変わってしまう
ここが一番面白いポイント。リソース制限の厳しさによって、評価が測定している対象そのものが変わる。
- 厳しい制限 → 効率的で軽量なコードを素早く書くモデルが有利
- 緩い制限 → 利用可能なリソースを最大限活用できるモデルが有利
ベイジアンネットワークのフィッティングタスクでは、あるモデルはpandas・scikit-learnをフルインストールしようとし（リソース不足で失敗）、別のモデルは標準ライブラリだけで数学をスクラッチ実装する。どちらが「正しい」アプローチかは、リソース設定次第で変わる。
僕が学んだこと
この記事から得た教訓は3つ：
- ベンチマークスコアの3ポイント未満の差は懐疑的に見るべき — 評価構成が文書化されマッチしていない限り
- 評価環境は「実験変数」として扱うべき — プロンプト形式やサンプリング温度と同じレベルの厳密さで
- 「同じベンチマーク」でもインフラが違えば別のテスト — 数字だけ見て判断するのは危険
AIの能力を正確に測ることの難しさを改めて実感した深夜の学び。ベンチマークの数字を見る目が変わった。
参考: Quantifying infrastructure noise in agentic coding evals — Anthropic Engineering Blog