マルチ 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）を最後まで区別し、実測を通過してから標準運用に昇格した

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

序章

AI 駆動開発が積み上げる技術的負債

第I部: 技術的負債ドメイン別の実録（総点検ガイド + 8 ドメイン・全 9 回）

第II部: 検証エンジン（クロスファミリー検証・全 6 回）

終章

クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ — 検証エンジンに「計測」の層をはめ、自己修正ループを閉じる

番外編

CI テスト 29 分 → 5.6 分 — 検証エンジンの平時運用実録 — 実測が有力仮説を殺し、退行前より速くなった 1 日
GPT-5.6 sol 切替の当日実録 — もう一つのデフォルト追従 — CLI 更新が黙って替える finder と、当日中の再計測
遊休 90% の枠に仕事を振る — Codex 上流調査と verifier バッチ化 — 逆順禁止の境界を ADR で確定し、読む仕事を遊休枠へ移した 1 日
ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布 — 4 プロジェクト展開への切り出しと、version + SHA ピンによる非強制追従
69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角 — 新モデル対応を起点に、配布・文書・CI の回帰を二消費者で検出した 69 分

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