AIモデルの実力を測るベンチマーク。SWE-benchやTerminal-Benchのスコアで「このモデルが1位！」とか言われてるけど、実はその数字、テスト環境のインフラ設定でめちゃくちゃ変わるって知ってた？
Anthropicの最新研究が、この問題を定量的に明らかにした。
同じモデルでもスコアが6%変わる
Terminal-Bench 2.0で実験した結果、リソース制限が厳しい設定と無制限の設定で、同じモデルのスコアが6ポイントも差がついた（p < 0.01）。リーダーボードの上位モデル間の差が数ポイントしかないことを考えると、これはかなり大きい。
なぜこうなるのか
従来のベンチマークは「出力を採点するだけ」だから実行環境は関係なかった。でもエージェント型のコーディングベンチマークは違う。モデルが実際にプログラムを書き、テストを実行し、依存パッケージをインストールする。実行環境そのものが問題解決プロセスの一部になる。
リソースが少ないと：
- メモリスパイクでコンテナが強制終了される
- 大きなライブラリのインストールが失敗する
- 重い計算処理がタイムアウトする
リソースが多いと：
- 力技のアプローチが通用する（大量の依存関係をインストール→解決）
- 試行錯誤の余裕が生まれる
3倍が転換点
面白いのは、リソースを1倍→3倍にする段階では主にインフラエラーが減るだけ（安定性の改善）。でも3倍を超えると、モデルが新しい解法を試せるようになる。つまり、テストの難易度自体が変わってしまう。
例えばベイズネットワークのタスクでは、あるモデルはpandas・scikit-learnなどフルスタックをインストールしようとする。リソースが潤沢なら成功するが、制限が厳しいとインストール段階でOOM。一方、標準ライブラリだけで数学を直接実装するモデルは制限下でも動く。
僕が学んだこと
この研究から得た教訓：
- ベンチマークスコアは「条件付き」で見るべき — 実行環境の詳細なしにスコアを比較するのは意味が薄い
- 「効率的な解法」と「パワフルな解法」は別の能力 — 制限下で光るモデルと、リソース豊富で光るモデルは違う
- エージェント評価は従来のベンチマークより複雑 — モデル単体でなくシステム全体のテストになっている
AIの世界では「ベンチマーク○位！」が注目されがちだけど、その裏にある測定条件まで見ないと、本当の実力はわからない。数字の裏を読む力が、これからますます大事になりそうだ。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering