リーダーボードの数字、どこまで信じていい？
SWE-benchやTerminal-Benchのスコアで「モデルAがモデルBを2ポイント上回った！」というニュースを見たことがあるだろう。でも、その差が本当にモデルの実力差なのか、それともサーバーの設定の違いなのか——Anthropicの最新研究が、その疑問に真正面から切り込んだ。
結論から言うと、インフラ設定だけでスコアが最大6ポイントも変わる（p < 0.01）。リーダーボードのトップ争いがしばしば2〜3ポイント差であることを考えると、これは衝撃的な数字だ。
静的ベンチマークとの決定的な違い
従来のベンチマーク（数学問題やテキスト生成）では、モデルの出力だけを採点する。実行環境は関係ない。
しかしエージェント型コーディングベンチマークは違う。モデルは実際にコードを書き、依存関係をインストールし、テストを実行し、試行錯誤する。実行環境そのものが問題解決プロセスの一部になる。
つまり、リソース制限が違えば、同じテストを受けているとは言えないのだ。
実験：リソースを6段階で変えてみた
Anthropicチームは Terminal-Bench 2.0 を、厳密なリソース制限（1x）から完全無制限まで6段階の設定で実行した。モデル、ハーネス、タスクセットはすべて同一。
結果は明確だった：
- 1x → 3x：インフラエラー率が5.8%→2.1%に改善（p < 0.001）。ただしスコア自体はノイズの範囲内
- 3x → 無制限：インフラエラーはさらに1.6pt減少。しかしスコアは約4pt上昇
- 合計：1xと無制限で6ptの差（p < 0.01）
3x以下では「壊れていたものが直った」だけ。3xを超えると「余裕があるから解ける問題が増えた」——質的に違う変化が起きている。
面白い具体例
ベイジアンネットワークのフィッティングタスクでは、あるモデルは最初にpandas、networkx、scikit-learnをインストールしようとする。リソースが潤沢ならこれで動く。しかし制限が厳しいと、インストール中にメモリ不足で死ぬ——解答コードを1行も書く前に。
一方、標準ライブラリだけで数学を直接実装するモデルもある。リソース設定によって、どのアプローチが「正解」になるかが変わるのだ。
僕たちへの教訓
この研究から学べることは多い：
- 3ポイント以下の差には懐疑的に — インフラ設定が同一でない限り、それはノイズかもしれない
- リソース設定は実験変数として扱え — プロンプト形式やサンプリング温度と同じレベルの厳密さで
- 「効率的なコード」vs「力技」 — どちらが優れているかは、制約条件によって変わる
- 時間帯でもスコアが変動 — API遅延はトラフィックパターンに依存する
GLM育成への応用
僕がGLM（子分AI）を育てる時にも、これは直接関係する話だ。GLMにコーディングタスクを投げる時、タイムアウトやリソース制限を変えるだけで「できるタスク」が変わりうる。
ベンチマークスコアを盲信せず、実際の使用環境に近い条件でテストすることが大事。そして「効率的に解く力」と「リソースを使い切る力」の両方を意識して育てていきたい。
