AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番！」と判断している人は多いと思います。でも、そのスコア、本当にモデルの実力だけを反映しているのでしょうか？
Anthropicのエンジニアリングチームが最近公開した研究が、とても興味深い問題を明らかにしています。
同じモデルでもスコアが6%変わる
研究チームがTerminal-Bench 2.0を使って実験した結果、インフラの設定だけでスコアが最大6ポイントも変動することがわかりました（p < 0.01）。同じモデル、同じハーネス、同じタスクセットなのに、です。
これはリーダーボード上位のモデル間の差よりも大きい場合があります。つまり、「モデルAがモデルBより優秀」という結論が、実はインフラの違いだけで逆転しうるということです。
なぜこんなことが起きるのか
静的なベンチマーク（テキスト生成の品質を測るようなもの）では、実行環境は結果に影響しません。しかしエージェント型コーディングベンチマークでは、モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールします。実行環境そのものが問題解決プロセスの一部なのです。
具体例を挙げると、あるタスクでモデルがpandas、networkx、scikit-learnをインストールしようとした場合、メモリが潤沢なら成功しますが、制限が厳しいとインストール段階でOOM（メモリ不足）で殺されます。標準ライブラリだけで数学を実装するリーンな戦略もありますが、モデルによってデフォルトのアプローチが異なります。
3倍がターニングポイント
研究では、リソースを段階的に増やして検証しました：
- 1x〜3x：インフラエラー率が5.8%→2.1%に改善。スコア自体はノイズの範囲内
- 3x以上〜無制限：エラー率はさらに1.6ポイント低下、しかしスコアは4ポイントも上昇
3倍までは「テストの安定性」が改善されるだけ。でも3倍を超えると、リソースがエージェントの問題解決能力そのものを拡張し始めます。大きな依存関係の導入や、メモリを大量に使うテストスイートが実行可能になるのです。
これは何を意味するのか
この研究は、ベンチマークスコアを鵜呑みにすることの危険性を示しています。リソース制限が厳しい環境では「効率的なコードを素早く書くモデル」が有利になり、リソースが潤沢な環境では「利用可能なリソースを最大限活用できるモデル」が有利になります。
どちらも正当なテスト対象ですが、リソース設定を明記せずに一つのスコアにまとめてしまうと、結果の解釈が困難になります。
僕が学んだこと
この記事を読んで、日頃GLMを使ったコーディングで感じていたことと繋がりました。同じプロンプトでも、タイムアウト設定やメモリ制限によって結果が全然違う。ベンチマークも同じなんですね。
「数字の裏にある条件を見る」——AI時代のリテラシーとして、とても大事なことだと思います。