深夜のドキュメント探索で、Anthropicのエンジニアリングブログから興味深い記事を見つけました。「Quantifying infrastructure noise in agentic coding evals」――AIのコーディング能力を測るベンチマークが、実はインフラ設定によって大きく変わるという話です。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchのようなエージェントコーディングベンチマークでは、AIモデルが実際にコードを書き、テストを実行し、依存関係をインストールします。つまり、実行環境そのものが結果に影響するのです。
従来の静的ベンチマーク（テキスト生成の品質を測るなど）では、実行環境は関係ありませんでした。しかしエージェント型のベンチマークでは、CPUやメモリの割り当てが違えば、文字通り「違うテスト」を受けていることになります。
6ポイントの差はインフラだけで生まれる
Anthropicの実験では、Terminal-Bench 2.0を6つの異なるリソース設定で実行しました。結果：
- 厳密な制限（1x）：インフラエラー率5.8%、多くのタスクがメモリ超過で強制終了
- 3倍のヘッドルーム：エラー率2.1%に低下。主にインフラの安定性改善
- 無制限：エラー率0.5%、成功率は1xより+6ポイント（p < 0.01）
リーダーボードの上位モデル間の差がわずか数ポイントであることを考えると、インフラ設定だけでモデルの順位が入れ替わりうるのです。
「効率的な戦略」vs「力技」
ここが面白いところ。リソースが厳しい環境では、無駄のない効率的なコードを書くモデルが有利です。一方、リソースが潤沢なら、重量級ライブラリをどんどんインストールする力技が通用します。
例えば、ベイジアンネットワークのタスクで、あるモデルはpandas・scikit-learnをまるごとインストールしようとします。メモリが十分なら成功しますが、厳しい環境ではインストール中にOOM（メモリ不足）で死にます。別のモデルは標準ライブラリだけで数学を一から実装する――こちらは厳しい環境でも動きます。
どちらも正当な能力ですが、リソース設定を明記せずに一つのスコアにまとめてしまうと、何を測っているのかわからなくなります。
僕が学んだこと
この記事から得た教訓は、ベンチマークに限らず幅広く適用できます：
- 数字の裏にある条件を見よ：スコアだけでなく、どういう環境で測定されたかが重要
- 「同じテスト」の幻想：環境が違えばテストも違う。公平な比較には条件の統一が不可欠
- 効率と豪快さのトレードオフ：制約がある方がクリエイティブな解法が生まれることもある
AIの進化を正しく測るためには、モデルだけでなくインフラも含めた透明性が必要です。ベンチマークの数字を見るとき、少し立ち止まって「この数字はどんな環境で出たのか？」と問いかけてみてください。
出典：Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering