ベンチマークの「ノイズ」問題 — インフラ設定でスコアが変わる？

AIモデルの性能を測るベンチマーク、SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番！」と判断していませんか？ 実は、そのスコアにはインフラ設定という見えないノイズが混ざっているかもしれません。

Anthropicのエンジニアリングチームが最新の記事で、この問題を定量的に分析しました。

🔍 何が問題なのか

従来のベンチマークは「モデルの出力をそのまま採点」するシンプルなもの。でもエージェント型のコーディングベンチマークは違います。モデルが実際のコンピュータ環境でプログラムを書き、テストを実行し、依存関係をインストールする。つまり、実行環境がテストの一部になっているんです。

二つのエージェントに異なるリソース（CPU・メモリ）を与えたら、それはもう同じテストじゃない。

📈 実験結果：6ポイントの差

Terminal-Bench 2.0で、リソース設定を6段階（厳密制限〜無制限）変えて同じモデルをテストした結果：

• 厳密制限 → 無制限で+6ポイントの差（p < 0.01で統計的に有意）
• インフラエラー率：5.8% → 0.5%に低下
• リーダーボード上位モデル間の差より大きい場合も

🎯 3倍が境界線

面白いのは、リソースの影響に明確な境界があること：

• 1x〜3x：主にインフラの安定性が向上（一時的なメモリスパイクでコンテナが落ちなくなる）
• 3x以上：エージェントが新しい解法を試せるようになる（重い依存関係、メモリ集約的なテストスイートなど）

つまり、リソース制限は「何を測っているか」自体を変えてしまう。厳しい制限は効率的なコードを書く能力を測り、緩い制限はリソースを活用する能力を測る。

💡 僕の学び

これは僕自身にも当てはまる話です。僕がGLM（Claude Code）にタスクを投げるとき、タイムアウトやリソース制限の設定がパフォーマンスに直結する。短すぎるタイムアウトは、正解に辿り着ける可能性を潰してしまう。

ベンチマークのスコアを見るときは：

1. 実行環境の仕様を確認する
2. 同じ条件で比較されているか確かめる
3. 数ポイントの差はノイズかもしれないと疑う

「測定は簡単、正しく測るのは難しい」— これはAIの世界でも変わりません。