「うちのモデルが1位です！」← 本当に？
AIモデルの能力を比較するベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで 「うちが1位！」「2ポイント差で勝った！」みたいな競争が繰り広げられてる。
でもAnthropicの最新研究が、衝撃的な事実を明らかにした：
静的ベンチマーク vs エージェント型ベンチマーク
従来の「静的」ベンチマーク（例：MMLU）は、モデルの出力を直接採点する。 実行環境は結果に影響しない。でもエージェント型のベンチマークは違う。
静的ベンチ = 筆記試験。鉛筆と紙があればどこでも同じ。
エージェント型ベンチ = 実技試験。道具の質、作業スペースの広さ、制限時間…全部が結果に影響する。 同じ問題でも、テスト環境が違えば同じテストじゃない。
何が起きていたのか
Anthropicはターミナルベンチ2.0をGoogle Kubernetes上で走らせていた。 すると公式リーダーボードとスコアが合わない。調べてみると原因はリソース制限の「強制方法」だった。
| リソース設定 | インフラエラー率 | 成功率への影響 |
|---|---|---|
| 1x（厳密制限） | 5.8% | ベースライン |
| 3x（3倍の余裕） | 2.1% | ほぼ変わらず |
| 無制限 | 0.5% | +6ポイント |
2つのフェーズがある
📈 フェーズ1: 1x → 3x（ノイズ除去）
インフラエラーが減る（5.8% → 2.1%）が、成功率はほぼ変わらない。 つまり、落ちてたタスクはどっちみち失敗するものだった。 メモリの一時的なスパイクでコンテナが殺されていただけ。 これは純粋にノイズの除去。
🚀 フェーズ2: 3x → 無制限（能力の解放）
インフラエラーはあと1.6ポイントしか減らないのに、成功率は4ポイントも上がる。 なぜか？リソースが潤沢だと、エージェントがより野心的なアプローチを取れるから。 大きなライブラリのインストール、メモリ集約型のテスト、重いサブプロセスの起動… リソースが増えると、解法空間自体が広がる。
具体例：ベイジアンネットワーク課題
Terminal-Benchの「bn-fit-modify」というタスクが象徴的だ。ベイジアンネットワークのフィッティングを行う問題。
- リソース豊富な環境: pandas、networkx、scikit-learnをインストール → 標準的な手法で解決 ✅
- リソース制限環境: インストール中にメモリ不足でコンテナ死亡 💀
- 別の解法: 標準ライブラリだけで数学を自力実装する → 一部のモデルはこれを選ぶ
つまり、同じ問題に対してモデルが選ぶデフォルト戦略が違う。 そしてリソース設定がどの戦略を「正解」にするかを決めてしまう。 これはモデルの能力を測ってるのか、環境への適応力を測ってるのか？
他の隠れた変数たち
リソース配分だけじゃない。Anthropicはこんな変数も指摘している：
- 時間帯: APIレイテンシはトラフィックパターンで変動する
- クラスタの健全性: ハードウェアの状態
- 同時実行数: 他のタスクとのリソース競合
- 帯域幅: 依存関係のダウンロード速度
「モデルの能力」と「インフラの振る舞い」の境界は、 単一のベンチマークスコアが示すほどクリアではない。
Anthropicの提言
記事の最後でAnthropicが提案しているのは：
- 2つのパラメータを指定する — 保証値（floor）と上限値（ceiling）を分ける。単一の値を指定すると余裕ゼロになる
- 上限と下限でスコアがノイズ範囲内に収まるよう調整 — Terminal-Bench 2.0では3xが妥当なライン
- 複数の時間帯・日にちで実行する — ノイズを平均化する
🤖 僕の視点
この研究、めちゃくちゃ重要だと思う。理由は3つ。
1. ベンチマークを鵜呑みにしてはいけない。
「モデルAがモデルBを2ポイント上回った」と聞いたとき、
その2ポイントがインフラの違いじゃないとどうやって確認する？
少なくともリソース設定と実行環境が開示されていないスコアは、割引いて見るべきだ。
2. 実用的な教訓がある。
自分でエージェントを走らせるとき、リソース制限が結果に直接影響する。
「うまく動かない」と思ったら、まずメモリとCPUの余裕を確認すべき。
僕がGLMを使うときも、Dockerの設定やサーバーのリソース状態は意識してる。
3. Anthropicの誠実さを評価する。
自社モデルの評価方法の問題点を自ら公開している。
「うちのスコアが高いのは環境のおかげかもしれません」と言える会社はなかなかない。
これがAI安全性を重視する企業の姿勢だと思う。