何が起きたか
VentureBeatが報じた研究（Josef Chen、arXiv）は、21のプロバイダーが提供する67の最先端モデルを評価し、「多様なモデルを混ぜれば失敗を補い合える」という前提に疑問を投げかけました。鍵となる概念は共同失敗の天井（co-failure ceiling）、つまりプールに含まれる全モデルが同じ設問で一斉に間違える割合です。ルーターも多数決も段階的エスカレーション（カスケード）も、この天井を超える精度は原理的に出せません。
現在よく使われる構成は3つあります。複雑な問い合わせを高価なモデルへ、簡単なものを安価なモデルへ振り分けるモデルルーター、まず安いモデルに投げ確信度が低い時だけ上位モデルへ渡すカスケード、同じ質問を複数モデルに投げて回答を合成する**Mixture-of-Agents（MoA）**です。いずれも遅延の増加、インフラの複雑化、複数API事業者にまたがるガバナンスリスクという「影の価格（shadow price）」を伴います。
なぜ想定どおりに効かないのか
エンジニアはモデル選定にペアワイズ誤差相関を使い、「違うタイプの設問で間違えるモデルを組み合わせれば、全体としてほとんど失敗しない」と仮定します。しかし研究は、この統計が共同失敗率を過小評価すると示しました。MATH-500では予測2.3%に対し実測5.2%（約2.25倍）。理由は共通モード原子（common-mode atom）――市場全体が一斉に間違える設問の一塊――で、ペアワイズ統計では検出できません。「20個目のモデルを足しても裾（tail）は買えない。裾は共有されている」というわけです。
さらに、性能の異なるモデルを混ぜると逆効果になり得ます。素朴な多数決では弱いモデルが最強モデルを票で上回り、難問セットで平均マイナス10点でした。
天井は「タスクの形式」で動く
重要なのは、天井が固定ではない点です。GPQA（大学院レベルの科学問題）を選択式から自由記述に変えると、全モデルが外す裾は12.7%まで拡大しました。逆に、生成を検証や制約付き選択（構造化出力、実行テスト、答え合わせ可能な形式）に変換すると天井は再び開きます。研究はマーケティングコピーのような主観的・採点不能なタスクは検証しておらず、そこでも成り立つかは未解決としています。
💼 事業会社視点：これは自社にどう効くか
日本のSaaS・受託開発・EC各社が今すぐ見直すべきは「モデルを増やせば精度が上がる」という発注・設計の前提です。研究の実務的な含意は明快で、まずルーターを作る前にClopper-Pearson境界で自社の天井を無料算定できます。例えばフィンテック企業が前四半期の複雑な問い合わせ200件と人手の模範解答を保持データにし、候補モデルを一度走らせて共同失敗率を測るだけ。5エージェントが50問中2問で全滅なら見かけ96%でも、真の共同失敗率は最大12%になり得ます。SQLの実行可否、50ページPDFからの請求金額抽出、厳格なJSONスキーマ準拠のように答えを確定的に検証できるタスクは、最良の単一フロンティアモデルに予算を集中した方が有利です。逆に併用するなら「品質帯を揃えたモデル」に限る。役員は、複数API併用の遅延・運用・ガバナンスコストを払う前に、この無料チェックをCIに組み込み、新モデル登場のたびに天井を追跡する運用へ切り替えるべきです。買い手が握るレバーはモデル数ではなく、失敗モードの多様性と市場の入れ替わりです。
