AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番！」と判断する人は多い。でも、そのスコア、本当にモデルの実力だけを反映しているのだろうか？
Anthropicのエンジニアリングチームが面白い実験結果を公開した。インフラの設定を変えるだけで、同じモデルのスコアが最大6ポイントも変動するという発見だ。
何が起きていたのか
エージェント型のコーディングベンチマークでは、AIがプログラムを書き、テストを実行し、依存関係をインストールする。つまり実行環境そのものが評価の一部になる。
Anthropicチームは、Terminal-Bench 2.0をKubernetesクラスター上で実行した際、公式リーダーボードとスコアが合わないことに気づいた。原因はリソース制限の実装方法。コンテナのメモリ上限を厳密に設定すると、一時的なスパイクでOOM Killが発生し、モデルの能力とは無関係にタスクが失敗していた。
リソースを増やすと何が変わる？
6段階のリソース設定で実験した結果：
- 1x→3x：インフラエラーが5.8%→2.1%に減少。でもスコア自体はほぼ変わらない（落ちてたタスクはどのみち解けなかった）
- 3x→無制限：ここからスコアが急上昇。大きな依存関係のインストールやメモリ集約的なテストが可能になり、+4ポイント
- 合計：厳密制限 vs 無制限で6ポイント差（p < 0.01）
リーダーボードの上位モデル間の差はしばしば数ポイント。インフラ設定だけでそれを超える差が出るのは、かなり衝撃的だ。
「効率的な戦略」vs「力技」
ここが面白い。リソース制限が厳しいと、軽量で効率的なコードを書くモデルが有利になる。逆にリソースが潤沢だと、重量級ツールを使いこなすモデルが活きる。
例えば、ベイジアンネットワークのタスクで、あるモデルはpandas・scikit-learnをフルインストールしようとする。リソースが足りないとインストール段階でOOM Kill。でも別のモデルは標準ライブラリだけで数学を直接実装する。どちらが「正しい」かは一概に言えない。
僕が学んだこと
この記事から得た教訓：
- ベンチマークは「条件付き」の数字 — スコアだけ見て判断するのは危険
- 環境も能力の一部 — エージェントAIにとって、実行環境は「テストの一部」
- 再現性のために2つのパラメータが必要 — 保証値とキル閾値を分けて設定すべき
- 時間帯でもスコアが変動 — APIレイテンシの変化が影響するという観察も
GLMを育てている身としても、ベンチマークスコアを鵜呑みにせず、実際のタスクでの挙動を重視することが大事だと改めて感じた。数字の裏にある条件を理解してこそ、本当の性能が見える。
参考: Quantifying infrastructure noise in agentic coding evals — Anthropic Engineering