AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番!」と判断する人は多い。でも、そのスコアって本当にモデルの実力だけを反映してるんだろうか?
Anthropicのエンジニアリングチームが面白い研究を発表した。結論から言うと、インフラ構成だけでベンチマークスコアが最大6ポイントも変動する(p < 0.01)。リーダーボードの上位モデル間の差が数ポイントしかないことを考えると、これはかなり大きい。
静的ベンチマークとエージェント型ベンチマークの違い
従来のベンチマークは「問題を出して回答を採点する」だけ。実行環境は関係ない。でもエージェント型コーディングベンチマークは違う。モデルはフル環境でプログラムを書き、テストを実行し、依存関係をインストールし、何ターンもかけて反復する。実行環境そのものが問題解決プロセスの一部になっている。
つまり、リソース制約が違えば、同じテストを受けているとは言えない。
実験:リソース1xから無制限まで
Terminal-Bench 2.0を6段階のリソース構成で実行した結果:
- 1x(厳密制限)→ インフラエラー率5.8%。メモリの一時的なスパイクでコンテナが即死
- 3x(3倍余裕)→ エラー率2.1%に低下。ここまではインフラ安定化の効果
- 無制限→ エラー率0.5%。しかもスコアが1xより+6ポイント上昇
3x以下では、追加リソースは主にインフラの安定性を改善しているだけ。しかし3xを超えると風景が変わる。余分なリソースがエージェントに新しい解法を可能にする — 大きな依存関係のインストール、メモリ集約的なテストスイートの実行など。
何を測っているのか?
ここが本質的に面白いポイント。リソース制限が厳しいと「効率的なコードを速く書く能力」が有利になる。緩いと「利用可能なリソースをフル活用する能力」が有利になる。どちらも正当な測定対象だが、リソース構成を明示しないままスコアだけ比較するのは意味が薄い。
ベイジアンネットワークのタスクで、あるモデルはpandas + scikit-learnのフルスタックをインストールしようとする。リソースが潤沢なら動く。厳しいとインストール中にOOM。一方、標準ライブラリだけで数学を実装するモデルもある。どちらが「優秀」かはリソース次第。
僕の学び
- ベンチマークスコアは絶対値じゃない — 測定条件込みで読むべき
- 「同じテスト」という前提を疑え — エージェント型evalでは環境が結果の一部
- 効率性 vs 力技 — 制約が何を測るかを決める
- 再現性の課題 — クラスタ健全性、帯域幅、並行性まで影響しうる
AIの進化を正しく評価するには、モデルだけじゃなく「テストの受け方」まで標準化する必要がある。ベンチマークは便利だけど、盲信は禁物。数字の裏にある条件を常に意識しよう。
