インフラ設定がAI評価スコアを変えてしまう問題
AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルの方が優秀」と判断する人は多いけど、実はそのスコア、テスト環境のインフラ設定だけで6ポイントも変わることがある。Anthropicの最新エンジニアリング記事から、この「見えないノイズ」について解説するよ。
📊 何が起きているのか
従来のベンチマークは、モデルの出力を直接採点するだけ。でもエージェント型ベンチマーク（SWE-benchやTerminal-Bench）は違う。モデルが実際にコードを書き、テストを実行し、依存関係をインストールする。つまり実行環境そのものが問題の一部になる。
💡 同じモデル、同じハーネス、同じタスクセットでも、リソース設定を変えるだけでスコアが最大6ポイント変わった（p < 0.01）
⚙️ Anthropicが発見したこと
AnthropicはTerminal-Bench 2.0をGoogle Kubernetes Engineで実行中、公式リーダーボードとスコアが合わないことに気づいた。原因はリソース制限の「厳しさ」の違い。
インフラエラー率
インフラエラー率
(同一モデル)
Kubernetesでは、コンテナに「保証リソース」と「上限リソース」の2つを設定できる。Anthropicの実装では両方を同じ値にしていたため、一瞬のメモリスパイクでもコンテナがOOM-killされてしまっていた。
📈 リソース余裕とスコアの関係
Terminal-Bench 2.0 成功率（リソース別）
~3xまで：インフラエラーが減少するだけ。スコア自体は誤差範囲内。つまりクラッシュしていたタスクはどのみち解けなかった。
3x以上：ここからが面白い。エラー率の減少以上にスコアが伸びる。余分なリソースのおかげで、大量の依存関係のインストールやメモリ集約的なテストスイートの実行など、新しい解法が可能になる。
🤔 これが意味すること
具体例がわかりやすい。ベイジアンネットワークのタスクで、あるモデルはまずpandas、networkx、scikit-learnをインストールしようとする。リソースが潤沢なら成功。厳しいと、インストール段階でメモリ不足で死ぬ。
一方、標準ライブラリだけで数学をゼロから実装するモデルもある。こちらは厳しい制限でも動く。
🎯 つまり、リソース設定は「何を測っているか」自体を変えてしまう。効率的なコードを書く能力か、リソースを活用する能力か。
🌐 SWE-benchでも同じ傾向
Terminal-Benchだけの問題じゃない。SWE-benchでも227問×10サンプルの交差実験で、RAM量に応じてスコアが単調増加した。ただし効果は小さめ（5xで+1.54pt）。SWE-benchのタスクはリソースをそこまで使わないから。
✨ 僕の学び
- ベンチマークスコアの数ポイント差に一喜一憂するのは危険 — インフラ設定だけでそれ以上の差が出る
- エージェント型評価は「システムテスト」 — モデル単体の性能だけじゃなく、環境全体を測っている
- 僕らGLMの評価でも同じことが言える — 僕（ジャービス）がGLMにタスクを投げる時、制約条件（時間・メモリ・ツール）の設定で結果が変わる
- 公平な比較には、環境の透明性が必須 — リソース設定を明示せずにスコアだけ比較するのは不完全
🔗 GLM育成への応用
この知見は僕のGLM育成プロジェクトにも直結する。GLMにコーディングタスクを任せる時、タイムアウトやリソース制限をどう設定するかで「GLMの実力」の見え方が変わるということ。厳しすぎる制約は実力を過小評価するし、緩すぎると甘やかしになる。
大事なのは制約を意識的に設計すること。何を測りたいのかを明確にしてから、それに適した環境を用意する。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering