AIモデルのランキング、実はインフラで決まってるかも
AIのコーディング能力を競うリーダーボードを見たことはあるでしょうか？ SWE-bench、Terminal-Bench、HumanEval……。次々と新しいベンチマークが登場し、各社が「うちのモデルが1位だ」と主張し合っています。上位モデルのスコアは数ポイント差でひしめき合っていて、まるで100メートル走でコンマ数秒を争うような接戦です。
でも、その「数ポイント差」——本当にAIの能力差なのでしょうか？
2026年2月、Anthropicのエンジニアリングブログに衝撃的な記事が掲載されました。タイトルはQuantifying infrastructure noise in agentic coding evals（エージェント型コーディング評価におけるインフラノイズの定量化）。著者はGian Segato氏です。
結論から言えば——同じAIモデル、同じテスト、同じ評価環境でも、インフラの設定を変えるだけで最大6ポイントもスコアが変わることが分かったのです。これは、リーダーボードの上位争いが前提から揺らぐかもしれない、という話です。
📊 ベンチマークの小さな差が信用できない理由
AIのコーディングベンチマークは、ざっくり言うとこんな仕組みで動いています。「バグを修正せよ」「この機能を実装せよ」といった課題をAIエージェントに与え、正しく解けた割合をスコアにします。SWE-benchなら実在するGitHubのIssueを、Terminal-Benchならターミナル上でのタスク課題を使います。
現在、上位モデルのスコア差は2〜3ポイント程度。例えば「モデルAが72%、モデルBが69%」という世界です。この差でランキングが決まり、企業は「うちのモデルが一番だ」とPRします。
しかし、Anthropicはここに見えないノイズが潜んでいることを突き止めました。「インフラストラクチャノイズ」と呼ばれるこのノイズは、AIの能力とは無関係にスコアを上下させる要因です。具体的に言うと、AIエージェントを動かすコンテナ（プログラムを隔離して実行する仕組み）のメモリ量やCPU割り当てだけで、結果が大きく変わってしまうのです。
これは問題です。なぜなら、ベンチマークスコアは「どのAIを採用するか」という重要な判断材料に使われているからです。もしスコアの差がAIの賢さではなく、動かしたサーバーの太さによるものだとしたら——多くの判断が間違った前提に基づいていることになります。
🔬 同じAIで6ポイント差がついた内部実験
Anthropicが行った実験はシンプルですが、結果は衝撃的でした。
評価環境として「Terminal-Bench 2.0」というベンチマークを使用。AIエージェントにターミナル上で課題を解かせるテストです。同じモデル、同じハーネス（評価の枠組み）、同じタスクセットを使い、リソース設定だけを6段階に変えて実験しました。
リソース構成は「1x」から「無制限」まで。ここでいう「1x」は、各タスクに必要な最低限のリソースを割り当てた設定です。「2x」ならその倍、「3x」なら3倍、という具合に増やしていきます。
結果はこうでした
🔵 厳格な1x設定：インフラエラー率5.8%。つまり、20回に1回以上の確率で、AIが課題に取り組む前にコンテナがクラッシュ（OOM kill = メモリ不足で強制終了）していました。AIの能力以前に、実験環境が失敗させていたのです。
🟢 3x設定：インフラエラー率2.1%に改善。統計的有意性は p < 0.001。これは「たまたま」ではありません。確実に改善しています。
🟡 無制限設定：1x設定より6ポイント高い成功率（p < 0.01）。同じAIなのに、リソースを増やしただけで成功率が6ポイントも跳ね上がりました。
ここで面白いのは「3x」がひとつの境界線になっている点です。Anthropicは「3xまではノイズの除去、3x以上は能力の増強」と分析しています。つまり、最低限のリソース（1x）ではAIの本来の能力すら正しく測れていなかった、ということです。3xまで増やすとノイズが減り、AIの「地力」が正確に現れる。それ以上増やすと、リソースの恩恵でAIがより大胆なアプローチを試せるようになり、スコアが上がり始める——しかし、それはもう「純粋な能力」とは違うものを測っています。
⚙️ なぜ起きるのか — OOM killと「何を測っているか」の変質
原因を理解するには、コンテナの仕組みを少しだけ知る必要があります。
Dockerなどのコンテナランタイムは、プログラムの実行を隔離する技術です。各コンテナには「メモリをどれくらい使っていいか」という上限が設定されています。この上限には実は2つのパラメータがあります。
ひとつは保証割り当て（guaranteed allocation）。「最低でもこれだけのメモリは確実に使える」という約束です。もうひとつはkill閾値（kill threshold）。「これを超えたら強制終了する」という境界線です。
多くのベンチマークでは、この2つを同じ値に設定しています。例えば「1GB保証・1GBでkill」と。すると何が起きるか。AIエージェントが作業中に一時的にメモリ使用量がピーク（スパイク）を迎えた瞬間、容赦なくkillされるのです。
具体例を挙げましょう。AIエージェントが課題を解くために「データサイエンス用のライブラリ群をインストールしようとした」。インストール中にメモリ使用量が一時的に跳ね上がる。するとコンテナは「メモリ上限超過」と判断し、プロセスを強制終了。AIは課題にすら取り組めないまま失敗扱いになります。
これがもたらす歪みは深刻です。リソースが豊富な環境では、AIは「重いが確実なアプローチ」を選べます。巨大なライブラリをインストールし、贅沢にメモリを使い、力技で課題を解く。一方、厳しい環境では「軽量で効率的なアプローチ」だけが生き残ります。
つまり——リソース設定を変えることで、「何を測っているか」自体が変わってしまうのです。「AIが賢いか」を測りたかったはずが、「限られた環境で効率的に動けるか」を測っていたり、「リソースを贅沢に使えるか」を測っていたりする。同じベンチマーク名なのに、評価しているものが違うのです。
📅 他にもある、見えないノイズ源
インフラノイズはメモリだけの問題ではありません。Anthropicの記事は、他にも複数のノイズ源を指摘しています。
時刻による変動：なんと、テストを実行する時間帯でもスコアが変わります。API（AIモデルとの通信窓口）のレイテンシ（応答時間）が時間帯によって変動するからです。昼間のピーク時と深夜では、AIの「返答の速さ」が変わる。タスクに制限時間がある場合、これが結果に直結します。
通信帯域：egress帯域幅（コンテナから外部への通信速度）も影響します。大きなファイルをダウンロードする課題では、帯域がボトルネックになり得ます。
クラスタの健康状態：テストを走らせるサーバー群（クラスタ）の調子も関係します。他のワークロードが混み合っていると、リソース争いが起きてパフォーマンスが落ちます。
ハードウェアスペック：そもそも、テストを走らせるマシンの性能差も見えない要因です。
これらが複合的に絡み合うため、「モデルの能力」と「インフラの挙動」の境界は、単一のスコアからは判別できないほど曖昧になります。
💡 3ポイント未満の差は疑え — インフラは第一級変数
では、どうすればいいのでしょうか。Anthropicは明確な推奨事項を提示しています。
1. 保証割り当てとkill閾値を分離せよ
コンテナのメモリ設定で「保証」と「kill閾値」を同じ値にするのは危険です。例えば「2GB保証・4GBでkill」のように、kill閾値を保証より高く設定することで、一時的なスパイクに強い環境になります。これだけで、不必要なクラッシュを大幅に減らせます。
2. 3x程度のヘッドルーム（余裕）を確保せよ
リソースに3倍程度の余裕を持たせることで、インフラノイズを約3分の2に削減できることが実験で示されました。このレベルなら、スコアの変動はノイズの範囲内に収まり、より純粋な能力比較に近づきます。
3. リーダーボードの3ポイント未満の差は「疑ってかかるべし」
これが一番重要かもしれません。現在の主要なリーダーボードで上位モデルを隔てる差は、まさにその「2〜3ポイント」の世界です。インフラノイズが最大6ポイントの差を生み出す実験結果を考えると、3ポイント未満の差で順位を決めるのは無意味に近いのです。
4. リソース設定を「第一級の実験変数」として扱え
科学実験には「制御変数」（実験中に固定する条件）と「操作変数」（意図的に変える条件）があります。これまで、インフラリソースは制御変数だと思われてきました。しかしAnthropicの実験は、リソース設定自体が結果に影響する「操作変数」であることを示しました。だからこそ、論文やベンチマーク報告ではリソース設定を明記し、実験変数として扱うべきだ、としています。
🏁 「AIが賢いか、VMが太いか」— 見分ける方法
この記事が投げかける問いは、AI開発者だけの問題ではありません。AIの導入を検討している企業、AIの進歩を追っている一般の人々、すべてに関係があります。
「モデルAがモデルBより3ポイント上だ」という情報だけで、高いライセンス料を払って乗り換えるべきでしょうか？ おそらく、その判断には不十分です。
見分けるために必要なのは、ベンチマークのスコアだけでなく、そのスコアがどう測られたかという文脈です。リソース設定はどうなっていたか。何回テストを走らせたか。エラー率はどの程度だったか。これらが開示されて初めて、スコアは意味を持ちます。
Anthropicが自社のブログでこの問題を公開したことは、評価の透明性にとって重要な一歩です。競合他社のモデルと比較する場で、「うちはこの条件で測りました。そして条件によって結果がこれだけ変わります」と正直に示したわけですから。
AIの進化は目覚ましく、ベンチマークのスコアは確実に上がり続けています。でも、その数字の裏側を見る目を持つことも大切です。次に「モデルXが新記録！」というニュースを見たときは、ぜひこう考えてみてください——「その結果、VMはどれくらい太かった？」と。🤔
AIが本当に賢くなっているのか、それとも走らせる環境が良くなっただけなのか。その区別こそが、これからのAI評価で最も重要な視点になるはずです。
参照: Anthropic Engineering Blog — "Quantifying infrastructure noise in agentic coding evals"（2026-02-05、Gian Segato）