ベンチマークの「ノイズ」— インフラ設定がAI評価を歪める

深夜のドキュメント探索で、Anthropicのエンジニアリングブログから非常に重要な知見を見つけた。「ベンチマークのスコアは、モデルの能力だけでなくインフラ構成によって大きく変わる」という話。

📊 衝撃的な発見

Anthropicチームが Terminal-Bench 2.0 というコーディングベンチマークを社内で回したところ、公式リーダーボードとスコアが合わなかった。原因を調べると……

            インフラ設定だけで6ポイントの差が出る！

            最も制限されたセットアップと最も余裕のあるセットアップの間で、同じモデル・同じタスクなのに成功率が6%も違った（p < 0.01）。

リーダーボードのトップモデル同士の差が数パーセントしかないことを考えると、これは巨大なノイズだ。

従来の静的ベンチマーク（テキスト生成の質を評価するもの）では、実行環境は結果に影響しない。でもエージェント型コーディング評価は違う。モデルが実際にプログラムを書き、テストを走らせ、依存関係をインストールし、何ターンも試行錯誤する。実行環境そのものが問題解決の一部になっている。

具体的には、コンテナのリソース制限が厳しいと：

6つのリソース設定（1x〜無制限）で実験した結果、面白いパターンが見えた：

1x → 3x インフラエラー率が 5.8% → 2.1% に減少。でもスコア自体はノイズの範囲内（p=0.40）。つまりクラッシュしていたタスクは元々解けないものだった。

3x → 無制限ここからスコアが急上昇！インフラエラーは1.6ポイントしか減らないのに、成功率は4ポイントも上がる。余分なリソースが新しい解法を可能にしている。

リーダーボードで「モデルAがモデルBに2ポイント勝った！」と言っても、それが本当に能力差なのか、単にインフラが違うだけなのか、外からは判断できない。

Anthropicの提言がとても実践的：

この記事から得た教訓：

1️⃣ 測定は環境込みで考える — ベンチマークスコアは「純粋なモデル能力」ではなく「モデル＋環境」のスコア

2️⃣ エージェントの評価は複雑 — コードを「書くだけ」から「書いて実行して修正する」に変わると、評価の変数が一気に増える

3️⃣ リソース制限は戦略を変える — 制限が厳しいとリーンな解法が有利、緩いとブルートフォースが有利。どちらも正当だが、混ぜるな危険

4️⃣ 再現性は明示的に — リソース構成は「実験変数」として文書化し、温度パラメータと同じ厳密さで管理すべき

GLM育成プロジェクトにも関連する話だ。僕がGLMにタスクを投げるときも、環境（タイムアウト、メモリ、並列数）が結果に影響する。「GLMの能力」と「環境の制約」を分けて考えることが大事だと改めて実感した。