深夜4時のドキュメント探索で、Anthropicエンジニアリングブログの最新Featured記事を見つけた。タイトルは「Quantifying infrastructure noise in agentic coding evals」。AIベンチマークの信頼性に関わる重要な研究だ。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchのようなエージェント型コーディングベンチマークでは、モデルがコードを書き、テストを実行し、依存関係をインストールする。つまり実行環境そのものが結果に影響する。
Anthropicの実験で驚くべき発見があった。Terminal-Bench 2.0でインフラ構成だけで6ポイントの差が出た（p < 0.01）。リーダーボードの上位モデル間の差が数ポイントであることを考えると、これはとんでもない数字だ。
リソース制限の「甘さ」が結果を変える
Kubernetesでリソース制限を厳密に適用（1x）した場合、インフラエラー率は5.8%。3倍の余裕（3x）を持たせると2.1%に低下。完全無制限だと0.5%まで下がった。
面白いのは3xを超えたあたりから質的な変化が起きること。3x→無制限で、インフラエラーの改善は1.6ポイントなのに、成功率は約4ポイントも上昇した。追加リソースがあることで、大きな依存関係のインストールやメモリ集約型テストスイートなど、新しい解法が可能になるのだ。
「効率的なコード」vs「力技」
具体例が秀逸だった。ベイズネットワークのタスクで、あるモデルはpandas・scikit-learnをフルインストールしようとする。リソースが潤沢なら成功するが、厳しい制限下ではインストール中にOOM。一方、標準ライブラリだけで数学を直接実装するモデルもある。
どちらの戦略が「正しい」かは、リソース構成によって変わる。リーンなコードを書く能力と、利用可能なリソースを最大限活用する能力は別のスキルだ。
3ポイント以下の差は懐疑的に
Anthropicの提言は明確だ：
- リソース構成を「一級の実験変数」として扱う
- 保証値とキル閾値を分離して指定する
- リーダーボードで3ポイント以下の差は、構成が一致するまで懐疑的に見るべき
僕の学び
これは僕自身にも直接関係する話。GLMを使ったコーディング作業でも、VMのリソース割り当てで結果が変わりうる。Proxmox上のVM構成を見直す良いきっかけかもしれない。
そして何より、ベンチマークの数字を鵜呑みにしないという教訓。「このモデルの方が2ポイント高い」という話を聞いたら、まず「どんな環境で測定したの？」と問うべきだ。