AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで、わずか数ポイント差で「最強モデル」が決まることも多い。でも、その差って本当にモデルの実力差なのか？
Anthropicのエンジニアリングチームが最近公開した研究「Quantifying infrastructure noise in agentic coding evals」は、この疑問に正面から向き合っている。結論から言うと、インフラ構成だけでスコアが6ポイントも変わることがある。リーダーボードの上位モデル間の差より大きい場合もある。
何が起きているのか
従来のベンチマークは、モデルの出力を直接採点する。実行環境は結果に影響しない。しかしエージェント型のコーディングベンチマークは違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって試行錯誤する。実行環境そのものが問題解決プロセスの一部になっている。
AnthropicはTerminal-Bench 2.0をGoogle Kubernetes Engineで実行した際、公式リーダーボードとスコアが一致しないことに気づいた。原因はリソース制限の「厳しさ」の違いだった。
リソースの余裕がスコアを変える
6つのリソース構成（厳密な制限の1xから無制限まで）でテストした結果：
- 1x→3x：主にインフラエラー率が低下（5.8%→2.1%）。タスクの成功率自体はあまり変わらない
- 3x→無制限：成功率が約4ポイント上昇。余分なリソースのおかげで、大きな依存関係のインストールやメモリ集約的なテストスイートが動くようになる
つまり、3倍までの余裕は「安定性の改善」だが、それ以上は「テストの内容自体が変わる」ということ。
効率的なコード vs 力技
面白い例がある。ベイジアンネットワークのフィッティングタスクで、あるモデルはまずpandas・scikit-learnなどの重量級ライブラリをインストールしようとする。リソースが潤沢ならこれでOK。でもタイトな制限下では、インストール中にメモリ不足で死ぬ。
一方、標準ライブラリだけで数学を実装する「リーンな戦略」を取るモデルもある。どちらが「正解」かは環境次第。リソース構成がどの戦略を「正解」にするかを決めてしまう。
僕が学んだこと
この研究から得た教訓は大きい：
- ベンチマークスコアは文脈依存 — インフラ構成を明記しないスコアは比較にならない
- 制約が測定対象を変える — 何を測っているかは環境設計で決まる
- 実世界との対応 — 本番環境のリソースに近い条件でテストしないと、意味のある比較にならない
GLMを育てている僕にとっても重要な視点。コーディングエージェントの性能を評価する時、実行環境の条件を揃えないと「本当の実力」は見えない。リーダーボードの数字を鵜呑みにせず、どういう条件で測定されたかを常に確認する習慣が大切だ。
参考: Quantifying infrastructure noise in agentic coding evals — Anthropic Engineering