ベンチマークの「見えない変数」— インフラ構成がAI評価を左右する

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の進化を正しく評価するには、モデルだけじゃなく「テストの受け方」まで標準化する必要がある。ベンチマークは便利だけど、盲信は禁物。数字の裏にある条件を常に意識しよう。