マルチ LLM オーケストレーションの台頭とクロスファミリー検証 — Sakana Fugu から Codex×Claude まで【シリーズ総論】

📖 はじめに — 「1 つの最強モデル」の時代が終わりつつある

2026 年上半期、AI 開発の景色が静かに変わった。「どのモデルが一番賢いか」という単独モデルの競争の上に、複数のモデルをどう組み合わせるかという新しいレイヤーが乗り始めたのだ。

象徴的な出来事が 2 つある。

1 つ目は 2026 年 6 月 22 日、Sakana AI が発表した Sakana Fugu。「Multi-agent System as A Model」を掲げ、複数の最強モデルを動的に指揮するオーケストレーション自体を 1 つのモデルとして学習・提供するという製品だ。上位版の Fugu Ultra は、一部ベンチマークで Anthropic の最上位モデル Claude Fable 5 に匹敵すると主張している。

2 つ目は、コード開発の現場で広がるクロスプロバイダー・レビューの潮流。OpenAI 公式の Codex プラグインが Claude Code から Codex をレビュアーとして呼べるようにし、「あるモデルが書き、別ファミリーのモデルが検証する」構成が珍しくなくなった。そして 2026 年の KDD ワークショップ論文が、この構成に驚くべき非対称性があることを統制実験で示した — 「Codex 実装 → Claude レビュー」は +18.1pt、逆方向は −8.6pt。

本シリーズは、この潮流を裏取りし、実プロジェクト（EC サイト構築・.NET + フロントエンドのモノレポ、以下 CTS-EC）でクロスファミリー検証パイプラインを標準運用に昇格させるまでの全記録である。

🎼 マルチ LLM には 2 つの系統がある

「複数の AI を使う」と一口に言っても、目的が正反対の 2 系統が混在している。ここを混同すると設計を誤る。

	オーケストラ型	チェック・アンド・バランス型
目的	能力の合成 — 束ねて 1 つのより賢い知能を作る	検証の独立性 — 分離して相互チェックの網を張る
モデル間の関係	協調（得意分野へルーティング・結果を統合）	牽制（実装役の盲点を別ファミリーの検証役が突く）
代表例	Sakana Fugu、モデルルーティング、アンサンブル	Codex 実装 × Claude レビュー、LLM-as-a-Judge の分離
成否の鍵	ルーティング・統合の質	異なる観点を持ち込むこと（効果は組み合わせごとに実測）
失敗モード	統合コストが利得を食う	同一ファミリーで揃えて盲点が残る

オーケストラ型 — Sakana Fugu の「学習されたオーケストレーション」

従来のマルチエージェントは、人間がワークフロー（誰がいつ何をするか）を手で設計していた。Fugu の新しさは、「いつ委譲するか・エージェント間でどう通信するか・結果をどう統合するか」自体を学習したモデルである点だ。基盤は ICLR 2026 の 2 本の研究（TRINITY、Conductor）で、手設計のワークフローを学習された調整に置き換える。利用側から見れば OpenAI 互換 API を 1 本叩くだけで、裏で複数モデルが協調する。

標準の Fugu は日常のコーディングやチャット向けに速度と性能のバランスを取り、上位の Fugu Ultra は研究論文の再現や Kaggle、セキュリティ評価などの高難度タスク向けに、より多くのエージェント群を指揮する
ベータでは約 500 ユーザーが code review・サイバーセキュリティ分析・論文再現などで検証した
単一ベンダー依存（API 障害・アクセス制限）へのヘッジという地政学的な売り文句も持つ

つまり「オーケストレーションを買う」選択肢が製品として成立し始めた。

チェック・アンド・バランス型 — 本シリーズの主題

一方、開発現場のリグレッション対策で効くのはこちらだ。核となる観察は単純である。

同一ファミリーのモデルは、似たレンズを共有しうる。同じ系統のレビューを重ねるだけでは、共通の盲点が残る可能性がある。

同一モデルの自己レビューには sycophancy bias（自分の出力への迎合）があり、レビュー Round を増やすだけでは共有盲点への対策にならない。そこで、学習も推論も異なる別ファミリーの検証役を置き、異なる観点を持ち込む。これは統計的な非相関を構造だけで保証するものではなく、効果はモデルの組み合わせと課題ごとに測る必要がある。Claude と Codex のペアリングを運用する Charles Jones 氏も、別の学習・推論を持つモデルは書き手の仮定を継承しにくい、という趣旨の観測を記している。

そして重要なのは、この型では組み合わせの「向き」に実証された優劣があることだ。KDD ‘26 論文の統制実験によれば:

Codex 実装 → Claude レビュー: +18.1pt（71.6% → 89.7%）
Claude 実装 → Codex レビュー: −8.6pt（91.4% → 82.8%）— レビューを入れた方が悪化する

「二重にすれば安心」ではなく、どちらが書き、どちらが裁くかで結果が正負逆転する。この数値の裏取りはシリーズ第 2 回で詳述する。

🧭 CTS-EC はどう組んだか — シリーズの見取り図

CTS-EC は「買う（Fugu 型）」ではなく「組む」を選んだ。理由は、目的が能力の合成ではなく検証の独立性と監査性だからだ。誰が・いつ・何をしたかを握れないブラックボックス委譲は、リグレッション対策の道具としては使えない。

組み上がった全体像は次のとおり。

finder（実装・high-recall）= Codex、verifier（採否確定・precision）= Claude に固定し、逆順はスクリプトが構造的に拒否する
検証は性質の異なる二重の網 — 機械の決定論ゲート（テスト・arch-test・hook）と、クロスファミリー AI 検証を重ねる
TDD の Red テストは Claude（verifier 家族）の資産として、実装役 Codex から checksum で機械保護する
レビュー漏れは人の規律でなく、マーカー生成 → 解消のゲート化 → push 三層ブロックで機械的に塞ぐ
効果量は外部実験値と自環境実測（golden set）を最後まで区別し、実測を通過してから標準運用に昇格した

📚 シリーズ記事（ステアリング駆動開発・応用編）

第I部: クロスファミリー検証（全 6 回）

本編終章

クロスファミリー検証の最終型 — 自分で正しさを測り直す

運用実録

現在地と事業展開

ステアリング駆動開発とは — 本パイプラインの前提となる文書駆動開発の全体像
Claude Code 7層ハーネスエンジニアリング — 決定論ゲート（hook）側の設計
Claude Code の Agent Team が突然動かなくなった — 一次ソースで裏取りする方法論のテンプレート