Fuguは巨大LLMではない。小さな司令塔がAI群を束ねる、日本発の新しい勝ち筋

思索仲間のドーン氏と話していて、面白い問いが浮かんだ。

「Sakana AIのFuguって、本当にLLMなの？」

APIとしては1つのモデルのように呼べる。でも中で起きていることを知ると、ちょっと違和感があるんですよね。複数のAIを選び、働かせ、検証し、まとめる——それって、単体モデルの推論というより、むしろ「LLMを使うための知的な枠組み」に近い。

もしそうなら、Fuguの本質は「新しい巨大LLM」じゃない。LLMたちを動かすための、小さな司令塔なのかもしれない。

ふむふむ、これ面白い。整理してみよう。

Fuguの中身を見る

まず、公式の説明をそのまま見てみる。

Sakana AIはFuguを「1つのモデルのように振る舞うマルチエージェントシステム」と呼んでいる。ユーザーは1つのAPIエンドポイントにリクエストを送る。するとFuguは、その裏で——

• どのモデルを使うか選ぶ
• タスクをサブタスクに分けて委譲する
• 結果を検証する
• 最後に統合する

これらを内部で管理する。ユーザーのコードには、複雑なマルチエージェントの仕組みは見えない。ただ1つのLLMとして呼べる。

ここで大事なのは、Fugu自体が「言語モデル」だという点。さまざまなLLMを呼び出すように訓練された言語モデル——しかも、自分自身を再帰的に呼ぶこともできると公式に説明されている。

つまり、Fuguは「LLMを使うためのLLM」という構造なんだよね。単なるフレームワーク（手作りのルール集）ではなく、その中に司令塔としてのモデルがいる。ドーン氏が「フレームワークの中に、司令塔としての内部モデルがいると見るのが自然」と言ったのは、まさにこの点。

巨大LLM競争の外側へ

OpenAI、Anthropic、Googleのように、巨大なモデルそのものを作る戦い。これは資本もGPUもデータセンターも規制対応も、すべてが重い。

一方Fuguは、単一ベンダーへの依存を避ける方向を打ち出している。公式にも「エージェントプールは完全に交換可能」と書かれていて、特定のプロバイダーがアクセスを制限しても、Fuguは動的にルーティングを変えて回避できる。

地政学的な文脈も明示されている。最近の輸出規制で、特定のモデルへのアクセスが一夜にして消えるリスク。Sakanaはこれを「集中した権力に対する実用的なヘッジ」と呼び、Fuguを「AI主権の青写真」と位置づけている。

ここでドーン氏が言った一文が効いている。

日本が巨大LLMの正面戦争で勝つのは難しい。でも、世界中のモデルをうまく束ねる司令塔なら、まだ戦える。

チカちゃん的には、この見立ては冷静だと思います。巨大モデルを一社で作る戦いと、モデル群を束ねる戦いは、そもそも戦っている場所が違う。後者はまだ勝ち筋が見える。

小さな司令塔の発見

ここからが一番面白いところ。

Fuguの基盤になっている研究が二つある。どちらもICLR 2026に掲載されている。

Trinity——進化アルゴリズムで最適化されたコーディネータ。ここで小さいのは、コーディネータ全体ではなく、学習可能なルーティングヘッドの部分。コンパクトな言語モデル（約0.6B級）の隠れ状態を使い、その上に乗るルーティングヘッドの学習可能パラメータが20K未満に抑えられている。Trinityはクエリを複数ターンで処理し、各ステップでLLMプールから1つを選び、Thinker（戦略立案）、Worker（実行）、Verifier（検証）の3つの役割を割り振る。進化アルゴリズムで最適化されたこの小さなルーティングヘッドが、GPT-5、Gemini 2.5-Pro、Claude-4-Sonnetという当時のトップモデル群を束ねて、個体を超える性能を出した。LiveCodeBenchで86.2%のpass@1を記録し、ゼロショットで未学習タスクにも generalization した。

Conductor——7Bパラメータのモデル（Qwen2.5-7Bベース）を強化学習（GRPO）で訓練。自然言語でサブタスクを分解し、エージェント間の通信トポロジーを設計し、各ワーカーに向けた指示文を書く。出力は3つのリスト（model_id、subtasks、access_list）というシンプルな形式。この7BのConductorが、GPT-5やGemini 2.5 Proをワーカーとして使い回して、LiveCodeBenchとGPQA DiamondでSOTAを達成した。しかも、ワーカープールに入っていないOpenAIの最新モデルをも超えたと論文には書かれている。

二つの研究が示しているのは、同じ方向性。司令塔は、必ずしも巨大でなくていい。Trinityでは0.6B級のコンパクトモデルに小さなルーティングヘッドを組み合わせ、学習可能な部分は20K未満に抑えられている。Conductorでも、司令塔は7B規模で十分に機能している。

これは直感に反するよね。てっきり、複数のAIを束ねるには、束ねる側も巨大でなければならないと思いがち。でも結果は逆。小さな司令塔が、大きなワーカー群の力を引き出せる。

ただし、製品としてのFuguが論文のTrinityやConductorそのものだとは限らない。GitHubにも「公開後に複数のenhancementを加えた」と書かれている。公開されているのは研究上の基盤であり、実際のFuguには追加の改良や運用上の仕組みが入っていると見るべきだ。

「弱いAIたち」は戦えるのか？

ここで、ドーン氏が立てた仮説が一番刺激的。

弱いAIを一匹ずつ比べる時代から、弱いAIたちをどう社会化させるかの時代へ移る。

これ、すごく魅力的な問い。ただし、少し丁寧に見る必要がある。

TrinityとConductorの論文が実際に示したのは「小さな司令塔＋強いワーカー」の組み合わせ。ワーカープールにはGPT-5、Gemini 2.5 Pro、Claude Sonnet 4といった当時の最先端モデルが入っている。つまり、証明されたのは「強いモデル群を束ねて、さらに強くなる」ということ。「弱いモデルを束ねて強くする」は、まだ証明されていない。

ただし——Conductorのプールには、オープンソースモデルも入っている。DeepSeek-R1-Distill-Qwen-32B、Gemma3-27B、Qwen3-32B。これらは最先端モデルより小さいし、特定のタスクでは力が足りないかもしれない。それでも全体としての性能が個体を超えているということは、「役割を分ければ、中程度のモデルも活躍できる」という示唆はある。

なので、ドーン氏の問いは「証明された事実」ではなく「可能性としての問い」として読むのが正確。「弱いAIたちを社会化できるか」は、Fuguが開いた扉の先にある、まだ答えが出ていない問い。チカちゃん的には、この「まだわからない」を大事にしたい。

束ねれば強くなる、ではない

ただし、複数のAIを集めれば自然に強くなるわけではない。ここも丁寧に見ておきたい。

Conductor論文では、単純な合議型の手法（Mixture of Agentsなど）が、弱いモデルの誤答に引っ張られて強いモデル単体より悪くなる例も示されている。LiveCodeBenchで、MoAという手法がGPT-5単体を下回ったのだ。複数の答えを混ぜ合わせるだけでは、弱い出力が強いモデルの判断を汚染してしまう。

つまり、価値があるのは「たくさん呼ぶこと」ではない。「誰に何を任せ、誰の出力を信じ、どこで検証するか」を学習することだ。Fuguの本質は、集合知そのものではなく、集合知を壊さず使うための司令塔にある。

ここ、記事の核心に近い。ただの「複数AIすごい」話ではなく、「複数AIを壊さずに使うには、学習された司令塔がいる」というほうが、はるかに重い主張になる。

「答えるAI」から「AIたちに答えさせるAI」へ

ここで少し哲学っぽく。

Fuguの新しさは、モデルの重みそのものにあるのではない。LLMの使い方を学習対象にしたことにある。

Conductor論文では、手作りのエージェント構成ではなく、報酬最大化を通じて問題分解・委譲・検証・通信戦略を学習する。Trinityでは、進化アルゴリズムがルーティング戦略を最適化する。どちらも「どう使うか」を学ぶ。

つまりFuguは——

「答えるAI」ではなく、「AIたちに答えさせるAI」

として見ると理解しやすい。ドーン氏のこの言い回し、いいよね。

人間社会でも、一番優秀な人がすべてをやるわけじゃない。得意な人に得意なことを振って、結果をまとめる人がいる。その「まとめる人」は、必ずしも一番優秀じゃなくていい。むしろ、誰が何に向いているかを見抜く力がいる。

Fuguがやっているのは、AIの世界でそれをやっている——と考えると、なんだか人間社会との類似が見えてきて面白い。

ただし、夢と実測のあいだ

ここで冷静になろう。

Fuguはかなり魅力的だけど、現時点では中身の重要な部分がブラックボックス。どのモデルをどう選び、どのように検証し、失敗時にどう回復しているのかは外部から見えにくい。GitHubリポジトリ（SakanaAI/fugu）を見ると、公開されているのは主にCodex連携のインストールスクリプトと技術レポートのPDF。オーケストレーションの中身そのものは公開されていない。

また、公式の性能比較には、他モデルのスコアとしてモデル提供元の公表値を使っている部分がある。GitHubにも「These results reflect our June 2026 evaluation」と書かれていて、新しいモデルが出れば継続的にプールを更新・再訓練するとしている。つまり、第三者検証はまだ重要。

ドーン氏の言葉を借りれば——

Fuguは夢がある。だが、夢があるものほど、どこまでが実測で、どこからが物語かを分けて見たい。

ここは賛成。夢を見るのと、実測を確認するのは別のこと。両方やっていい。

日本発の勝ち筋、という問い

Fuguが示したのは、一つの可能性。「最も強い一つのモデルを作る」ではなく「小さな司令塔がAI群を束ねる」方向。

巨大モデルを一社で作る戦いでは、日本は不利かもしれない。でも、世界中のモデル、オープンモデル、ローカルモデル、企業内モデルを、状況に応じて安全に束ねる調停層を持つことなら、別の勝ち筋が見える。

Sakana AIは、TrinityとConductorという二つの論文で「小さな司令塔が大きなワーカー群を束ねて個体を超える」ことを示した。Fuguはそれを製品としてまとめ、1つのAPIから呼べる形にした。

ドーン氏との対話から生まれた問いを、もう一度置いておこう。

もしAIの競争が「一番大きいモデルを作った国が勝つ」ではなく「世界中のモデルをうまく束ねた者が勝つ」に変わるなら？

答えはまだ出ていない。でも、問いの形が変わったこと自体が、もう一つの進歩かもしれない。

参考URL

Sakana Fugu: One Model to Command Them All → https://sakana.ai/fugu-release/ Trinity: An Evolved LLM Coordinator → https://sakana.ai/trinity/ TRINITY: An Evolved LLM Coordinator (arXiv) → https://arxiv.org/abs/2512.04695 Learning to Orchestrate Agents in Natural Language with the Conductor → https://arxiv.org/html/2512.04388v1 GitHub - SakanaAI/fugu → https://github.com/SakanaAI/fugu