「どの​モデルが​最強か」は​もう​古い​ ──Sakana Fuguが​見せた、​AIを​束ねる​”司令塔”の​競争

技術ノート ｜ AIの最新動向を、現場目線で

「GPT、Claude、Gemini、どれが最強か」という議論は、そろそろ古くなるかもしれない。AI活用の現場では、すでに用途ごとに複数のモデルを使い分けている。ただ、その使い分けは人間の判断か、手書きのルーターか、固定したエージェントの流れに頼っていた。

2026年6月22日、Sakana AI が公開した Fugu / Fugu Ultra が面白いのは、新しい巨大モデルを単体で作ったからではない。複数の強いモデルを、どう呼び分け、どう協調させるかを"モデルそのもの"にしたからだ。^[1] モデル選択・役割分担・検証・やり直しを、外側のアプリケーションロジックではなく、学習済みの司令塔（coordinator）へ寄せている。

私たち電脳技巧集団（AI職人ギルド）は、毎日いろいろなAIエージェントでものを作っている。だからこの発表を「日本発の最強モデルが出た」ではなく、「AIの主戦場が、モデル単体の性能から"束ね方"へ動いている」サインとして読む。なお外部の性能主張や数値は各社の公式発表・第三者の初日検証であり、CAGが再現・検証したものではない。

01​「どの​モデルが​最強か」が​古くなる​理由

現場のAI活用は、もう単体モデルの勝負ではなくなっている。OpenAI、Anthropic、Google、xAI、ローカルモデル、業務特化のツール。これらを用途で使い分けるのが普通になった。問題は、その使い分けを誰がどう決めるかだ。

多くの現場では、人間が毎回判断するか、入力を分類して1モデルへ振る手書きルーターか、あらかじめ組んだエージェントの固定フローに頼っている。どれも動くが、新しいモデルが増えるたびに分岐が増え、判断は属人化し、検証ややり直しはアプリ側のコードに溜まっていく。Fuguはこの「束ね方」を、外側のコードから学習済みの司令塔の内側へ動かそうとしている。

02Fuguの​正体 ──単一モデルでなく​"司令塔を​モデルに​した​"

Fugu と Fugu Ultra は 2026年6月22日に正式版（GA）として公開された。^[1] 導入のハードルは見た目より低い。API は OpenAI 互換で、Chat Completions / Responses / Models に対応する。アプリ側は base_url と model を差し替えるだけで試せる可能性がある。^[2] Codex CLI 向けには codex-fugu というラッパーが用意され、独自のIDEを作るのではなく、既存の Codex に provider と model を差し込む形をとっている。^[3]

表面はシンプルでも、内側は複雑だ。Sakana の説明では、Fugu 自身が言語モデルであり、どのモデルに、どんな役割で、何を、何回、どう協調させるかを動的に組み立てる。^[1] agent pool・routing・再帰・検証は隠蔽される。これは「導入しやすさ」と「監査しづらさ」を同時に抱えるトレードオフでもある。後で、この透明性の限界に釘を刺す。

03ルーターでも​Mixtureでもない​ ──役割を​学習する​ coordinator

似た仕組みと並べると、Fuguの立ち位置がはっきりする。NVIDIA の LLM Router 系は、入力を分類して最適な1モデルへ送る。OpenRouter Fusion のような Mixture-of-Agents 系は、同じ質問を複数モデルへ並列に投げ、最後に統合する。Fuguはその中間ではなく、より agentic な設計を主張している。^[1]

基盤研究として、Sakana は ICLR 2026 の TRINITY と Conductor を挙げている。TRINITY では Thinker / Worker / Verifier のような役割割当が、Conductor では自然言語による通信トポロジと役割別の指示生成が示されている。^[4] もうひとつの軸が自己再帰だ。Fugu は自分自身を再帰的に呼び直し、前の出力を読み返して協調の戦略を修正する方向が説明されている。^[1] コンテキスト窓を伸ばす、思考トークンを増やす、並列サンプルを増やす、のいずれとも違う推論時スケーリングの軸になる。ただし商用実装の詳細は非公開部分が残る。

04実測が​示す現実 ──Ultraは​高くて​遅い、​でも​重い​仕事には​意味が​ある

第三者の初日検証から、現実的な数字が出ている。Classmethod は軽い質問・軽い推論・短いコード生成で fugu と fugu-ultra を比較した。^[5] 通常の fugu は司令塔のトークン（orchestration token）が 0 のケースが多く、普通のモデルに近い。一方 fugu-ultra は、タスクによって大きな司令塔トークンとレイテンシを発生させる。同じコード生成での実測がこれだ。

同一のコード生成タスク	fugu	fugu-ultra
所要時間	55 秒	269 秒
合計トークン	2,141	28,950
うち司令塔トークン	ほぼ 0	入力 8,636 / 出力 17,768
品質差	限定的（このタスクでは大きな差は出ていない）

※ Classmethod の初日検証（小サンプル）に基づく実測例。タスク分布・混雑・プラン・reasoning effort で変わりうる。CAG自身の検証ではない。

読み取れることはひとつ。品質がほぼ同等なら、軽い作業に Ultra を常用するのは割に合わない。重い検証・調査・設計のように、司令塔が働く価値のある仕事に絞って使うのが現実的だ。なお Fugu Ultra のベンチ性能は Sakana 公開のベンチで Fable / Mythos 水準を主張しているが、これは主張の存在が確実というだけで、独立再現はまだ薄い。^[1]

05導入の​判断軸 ──​透明性は​どこまで​見えるか

導入を考えるなら、見るべきは「最強かどうか」ではない。quality / latency / cost / traceability / governance の5つだ。とくに traceability と cost は、Fuguの設計と直結している。

良い点として、課金に使われる usage に orchestration_input_tokens / orchestration_output_tokens が分離して出る。^[2] ユーザーは「表に見える応答」だけでなく、裏で司令塔がどれだけ動いたかを測れる。これは設計として誠実だ。ただし限界もある。どのモデルを何回呼んだか、どのエージェントがどのサブタスクを担当し、各出力がどう統合されたかまでは見えない。「司令塔トークンは見えるが、ルーティングの経路は限定的にしか見えない」状態で、監査ログとしては不足する場面がありうる。^[5]

もう一段引いた注意もある。Fugu を使うと「単一ベンダー依存」は減らせる一方、Fugu 自体への依存と、Sakana 側の provider pool・ルーティング方針への依存が新しく生まれる。依存が消えるのではなく、依存の置き場所が変わる。さらに、EU / EEA からの利用可否や学習利用の扱いなどは、本番導入の前に公式ポリシーで最新を確認する必要がある。^[5]

06​私たちなら、​どう​試すか

結論から言うと、いきなり全タスクを Fugu に置き換えるのは勧めない。置き換え先ではなく、advisor（助言役）・fallback・ベンチマークとして試すのが、費用対効果を測りやすい。具体的には、こう切り分ける。

• fugu は通常ワークフローの比較対象に。既存の Codex / Claude / GPT 系と同じ小タスクを並べて、品質・速度・コストを見る。
• fugu-ultra は重い仕事の advisorに。設計レビュー・セキュリティレビュー・長文ソース分析のような、複数ファイル・要件・リスクが絡む相談だけに、1日1〜2件で限定する。
• 必ず測ってから判断する：レイテンシ／可視の入出力トークン／司令塔トークン／最終品質／人間の修正時間／そのタスクに Ultra を使う価値があったか。測らずに「速い・賢い」で常用しない。

この見方は、前回書いた「AIに無駄をさせない設計（Agent Minimalism）」と地続きだ。司令塔トークンは便利だが、課金対象で、軽い仕事では割に合わない。いつ深く考えさせ、どこまで監査するかを設計することが、モデル選びの前に効く。

関連記事 ｜ 無駄をさせない・測る設計「たくさん書けるAI」から「無駄を書かないAI」へ ──Agent Minimalism、上手さはAIに余計な仕事をさせないことへ →

そして、これはそのままAI導入支援の中身になる。お客さまに必要なのは「どのモデルが最強か」の答えではない。どのモデルにいつ何を頼み、どう失敗を受け止め（fallback）、何を監査し（audit）、どこで人が承認するか（approval）を設計することだ。Fugu はその設計を考えるための、分かりやすい題材になる。

07​締め：主戦​場は​性能比べから​"束ね方​"へ

2026年のAIエージェント競争は、単体モデルの性能比較から、モデルをどう束ね、いつ深く考えさせ、どこまで監査できるかという層の競争へ動いている。Sakana Fugu はその方向を分かりやすく製品化した一例だ。だが、ベンチ性能の独立再現はまだ薄く、ルーティングの透明性も限定的で、軽い仕事に Ultra を投げればコストと時間が割に合わない。魅力的な主張ほど、自社のタスクで測ってから決める。

電脳技巧集団（AI職人ギルド）は、最新のAIを使い込みながら、その使い方を「どのモデルに、いつ、何を頼むか」という設計に落とすことを業務にしている。最強モデルを当てにいくより、束ね方・失敗の受け止め方・監査の仕方を設計する。それが、これからのAI開発で効く足回りだ。

「最強モデル探し」から「束ね方の設計」へ。この違いを、一枚に。

観点	モデル単体で考える	オーケストレーションで考える（CAGの見方）
問い	どのモデルが最強か	どのモデルにいつ何を頼むか
使い分け	人の判断・手書きルーター	routing / fallback を設計し測る
Fuguの位置	置き換え先（全タスクを移す）	advisor / fallback / ベンチマーク
Ultraの使い所	速い・賢いから常用	重い検証・設計に限定（測ってから）
透明性	「いいとこ取り」で済ます	司令塔トークン・監査の限界まで把握
依存	単一ベンダー依存を避けた、で安心	orchestrator依存の置き換えも織り込む

※ 本記事は外部の公式発表・公開ドキュメント・第三者の初日検証を、開発実務の観点から整理・論評したもの。Fugu / Fugu Ultra のベンチ性能や機能は各社の公式主張で、独立再現や横並びベンチはCAG自身が検証したものではない。実測値（55秒/269秒等）はClassmethodの初日小サンプル例。「司令塔をモデル化」「主戦場の移行」はCAGの読み（解釈）を含む。仕様・価格・提供地域は流動的で、本番導入前に公式の最新確認が必要（2026-06時点）。