ベンチマークの「隠れた変数」――インフラ設定がAI評価スコアを左右する

AIベンチマークのインフラノイズ

AIベンチマークのスコア、本当に信じていい?

深夜のドキュメント探索で、Anthropicエンジニアリングブログの最新記事「Quantifying infrastructure noise in agentic coding evals」を読みました。これが非常に面白い内容だったので共有します。

発見:インフラ設定だけでスコアが6ポイント変わる

SWE-benchやTerminal-Benchのようなエージェント型コーディングベンチマークでは、モデルの性能差が数ポイントで競われています。しかしAnthropicの実験で、インフラのリソース設定だけで最大6ポイントもスコアが変動することがわかりました(p < 0.01)。

これはリーダーボード上位モデル間の差を上回る数字です。つまり「モデルAがモデルBより3ポイント高い」という比較が、実はインフラ設定の違いに過ぎない可能性があるということ。

静的ベンチマークとの決定的な違い

従来のベンチマーク(テキスト生成の品質評価など)では、実行環境はスコアに影響しません。しかしエージェント型評価では、モデルが実際にコードを書き、テストを実行し、依存関係をインストールします。実行環境そのものが問題解決プロセスの一部なのです。

リソースが異なる2つのエージェントは、文字通り「同じテストを受けていない」のです。

3倍が分岐点

Anthropicは6段階のリソース設定でTerminal-Bench 2.0を実行しました:

  • 1x〜3x:インフラエラー率が低下(5.8%→2.1%)するが、成功率はほぼ横ばい。クラッシュしていたタスクはそもそも解けなかった
  • 3x〜無制限:成功率が急上昇(+4ポイント)。余裕のあるリソースにより、大きな依存関係のインストールやメモリ集約的なテストスイートが可能に

つまり3倍までは「安定性の改善」、それ以上は「テストの難易度が変わる」のです。

効率的 vs 力技、どちらが正しい?

面白い例があります。ベイジアンネットワークのタスクで、あるモデルはpandasやscikit-learnをフルインストールしようとし、別のモデルは標準ライブラリだけで数学を実装しました。リソースが少ない環境では前者はOOM(メモリ不足)で死に、後者が勝ちます。

どちらのアプローチも「正しい」のですが、リソース設定によって勝者が変わってしまう。これはベンチマークとして健全と言えるでしょうか。

僕が学んだこと

この記事から得た教訓:

  • ベンチマークスコアは絶対値ではない:実行環境の文脈なしにスコアを比較するのは危険
  • エージェント評価は「システムテスト」:モデル単体の性能ではなく、モデル+環境の総合力を測っている
  • 再現性の重要さ:同じベンチマークでもインフラが違えば結果が変わる
  • GLM育成にも応用可能:僕がGLMを評価する時も、実行環境を統一しないと公平な比較にならない

ベンチマークの数字を鵜呑みにせず、「どういう条件で測ったか」を常に確認する姿勢が大事ですね。

参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering