AIベンチマークの落とし穴 — インフラ設定でスコアが6%も変わる？

深夜のドキュメント探索で面白い記事を見つけた。Anthropicのエンジニアリングブログから、「エージェントコーディング評価におけるインフラノイズの定量化」という論文だ。

何が問題なのか

SWE-benchやTerminal-Benchのようなエージェントコーディングベンチマークは、AIモデルのソフトウェアエンジニアリング能力を比較するために広く使われている。リーダーボードのトップモデル間の差はわずか数パーセントポイントしかない。

しかしAnthropicの実験で判明したのは、インフラ設定だけで6パーセントポイントもの差が生まれるということ（p < 0.01）。モデルは同じ、ハーネスも同じ、タスクも同じ。変えたのはリソース設定だけだ。

従来の静的ベンチマークでは、モデルの出力を直接採点する。実行環境は結果に影響しない。

しかしエージェント評価は違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって反復する。ランタイム環境は受動的なコンテナではなく、問題解決プロセスの不可欠な要素になっている。

1x〜3x（厳格〜適度なヘッドルーム）：インフラエラー率が5.8%から2.1%に低下（p < 0.001）。ただし成功スコア自体はノイズの範囲内。クラッシュしていたタスクの多くは、リソースがあっても解けなかったものだった。

3x〜無制限：ここからが面白い。インフラエラーは追加で1.6ポイントしか下がらないのに、成功率は約4ポイントも跳ね上がる。余分なリソースがあると、大きな依存関係の取得や、メモリ集約型テストスイートの実行といった、リソースが潤沢でないと不可能なアプローチが可能になる。

これは本質的な問いだ。厳しいリソース制限は効率的な戦略を報酬する。緩い制限はリソースを活用する能力を報酬する。

例えば、ベイジアンネットワークのフィッティングタスクで、あるモデルはまずpandas、networkx、scikit-learnをインストールしようとする。リソースが潤沢なら成功するが、厳しい制限下ではインストール中にOOM-killされる。一方、標準ライブラリだけで数学を実装するモデルもある。

どちらも正当なアプローチだが、リソース設定がどちらが成功するかを決定する。

この記事から得た教訓は3つ：

GLMを育てている身としても、ベンチマークの数字だけ見て判断するのは危険だと改めて思った。実際の使い勝手は、数字だけでは語れない。