Works
Blog Recruit Contact AI互換性診断
国産LLM
calendar_today
[国産LLMの現在地 Vol.5] 山下 太郎 山下 太郎

国産LLMの現在地 第5回:束ねる型 — Sakana AIとオーケストレーション思想。「最強の一枚」を作らない、という戦い方

Sakana AIの「束ねる型」は、最強の一枚を自分で作らない。複数のフロンティアモデルを指揮するオーケストレーション思想と新製品Sakana Fugu、そして主権・特化・フォールバックの3軸への意味を読み解く連載第5回。

国産LLMの現在地 第5回:束ねる型 — Sakana AIとオーケストレーション思想。「最強の一枚」を作らない、という戦い方

第3回のフルスクラッチ主権型は、基盤モデルを自前で一から作ることに賭けていた。第4回の派生・特化型は、基盤を作らず、土台を借りるか小さく保って特化に振り切っていた。どちらも「自分のモデルをどう作るか」という問いの上に立っている。

今回扱う一群は、その問いから降りる。最強の一枚を自分で作ろうとしない。代わりに、世界中の既存モデルを束ね、指揮することに賭ける。第1回の分類でいう「束ねる型」、ほぼ唯一にして象徴的なプレイヤーがSakana AIだ。

そして偶然ではなく、この戦略の核心を突く製品が、この連載を書いているまさにその最中——2026年6月22日にローンチされた。Sakana Fuguである。第1回の地図で「Sakana Fugu」を束ねる型の代表に置いたのは、この3日前のリリースを織り込んでのことだった。今日はその中身に降りていく。

「束ねる」とは何を束ねるのか

まず、言葉を整理する。「複数のモデルを組み合わせる」と言ったとき、技術的にはまったく違う3つの層が混ざりやすい。ここを分けておかないと、Sakanaが何をしているのかがぼやける。

「組み合わせる」の3つの層——MoE・モデルマージ・オーケストレーション 複数モデルの組み合わせ方を3層に整理。MoEは単一モデル内部でトークン単位に専門家を活性化する暗黙の仕組み。モデルマージは別々のモデルの重みを統合して新しい1モデルを作る「作るために混ぜる」。オーケストレーションは別々の完成モデルをタスク単位で横断して協調させる「使うために混ぜる」。Sakana Fuguは3つ目に属する。 「組み合わせる」の3つの層 同じ「複数モデル」でも、束ねる単位と狙いがまるで違う ① MoE(Mixture of Experts)|モデルの“内部” 1つのモデルの中で、トークンごとにゲートが「専門家」サブネットを選んで活性化する 単位=トークン / 通信=内部ベクトル / 専門化=学習で暗黙的に獲得 / 例:多くの最新LLM 束ねる型ではない(1モデルの作り方の話) ② モデルマージ|重みを“統合”して新しい1枚を作る 別々に学習されたモデルの重みを混ぜ、新しい単一モデルを生成する 単位=重み / 成果=新しい1モデル / Sakanaの出発点(進化的モデルマージ・2024) 合言葉:mixing to create(作るために混ぜる) ③ オーケストレーション|完成モデルを“指揮”する 別々の完成モデルを、タスク単位で呼び分け・協調・統合させる。各モデルはそのまま 単位=リクエスト/タスク / 通信=自然言語 / Sakana Fugu はここ(2026) 合言葉:mixing to use(使うために混ぜる)

①の MoE(Mixture of Experts) は、1つのモデルを作るときの内部設計だ。モデルの中にたくさんの「専門家」サブネットがあり、入力トークンごとにゲートがどれを使うかを選ぶ。これは束ねる型ではない。あくまで「1枚のモデルをどう効率よく作るか」の話で、第3回・第4回の延長にある。

②の モデルマージ は、別々に学習されたモデルの重みそのものを混ぜ、新しい1枚のモデルを作る。Sakanaの出発点がここだった。2024年3月に公開した進化的モデルマージ(Evolutionary Model Merge)は、進化的アルゴリズムでモデルの「交配レシピ」を自動探索する手法で、論文は2025年1月にNature Machine Intelligenceに掲載された。これは「作るために混ぜる(mixing to create)」発想だ。

③の オーケストレーション は、重みは混ぜない。完成したモデルをそのまま使い、タスクごとに「どれを呼ぶか・どう協調させるか・どう統合するか」を指揮する。Sakana Fuguはここに立っている。「使うために混ぜる(mixing to use)」だ。

第1回で「束ねる型」と呼んだのは、厳密にはこの③のことだ。そしてSakanaの歩みは、②から③への移動の歴史でもある。

Sakana AIという賭け

技術に入る前に、この会社の立ち位置を押さえておく。性能の数字より、ここの思想のほうが第5回では重要だ。

Sakana AIは2023年に東京で設立された。創業者の一人Llion Jonesは、Transformerを生んだ論文「Attention Is All You Need」の共著者の一人だ。社名の「Sakana(魚)」は、魚が群れることで一匹では持てない知能を発揮する——集合知(collective intelligence)——という、同社の一貫した思想を表している。

その思想は、資金の規模にも裏打ちされている。2024年9月のシリーズAではNEA・Khosla Ventures・Lux Capitalがリードし、NVIDIAも戦略投資家として参加して、設立から約1年で国内最速のユニコーンになった。さらに2025年11月、SakanaはシリーズBで約200億円を調達し、ポストマネー評価額は約4,000億円(約26.5億ドル)に達した。国内の未上場スタートアップとして過去最高水準の評価額だ。シリーズBのリードはMUFGで、米国の戦略投資機関In-Q-Telなども新たに名を連ねた。

重要なのは、Sakanaが巨大モデルを自前で事前学習する競争に、最初から乗っていないことだ。OpenAIやAnthropicやGoogleが数千億〜数兆パラメータのフロンティアモデルに巨額を投じるのに対し、Sakanaは「最も強力なAIは孤立した一枚岩のモデルではなく、協調するエコシステムだ」という立場を取る。資源の制約こそが知性を生む、という確信である。第3回のフルスクラッチ勢とは、思想の出発点が正反対だ。

その思想が、研究の系譜として一本の線になっている。

「混ぜて作る」から「混ぜて使う」へ——Sakanaの研究系譜 Sakana AIの研究の流れを時系列で示す。2024年の進化的モデルマージ(重みを混ぜて新モデルを作る)から、2025年のAB-MCTS/TreeQuest(推論時に複数フロンティアモデルを協調させる)、ICLR2026採択のTrinity/Conductor(束ねる役自体を学習する)、そして2026年6月のSakana Fugu(束ねる型の製品化)へと、混ぜて作るから混ぜて使うへ重心が移っていく。 「混ぜて作る」から「混ぜて使う」へ Sakanaの研究は、重みの統合から推論時の協調へ重心を移してきた 進化的モデルマージ 2024 重みを混ぜて作る AB-MCTS / TreeQuest 2025 推論時に複数モデルを協調 Trinity / Conductor ICLR 2026採択 束ねる役そのものを学習 Sakana Fugu 2026.6 束ねる型の製品化 ※ AB-MCTS(推論時スケーリング)はNeurIPS 2025でSpotlight採択、Trinity/ConductorはICLR 2026採択。 研究の合言葉は一貫して「mixing to use(使うために混ぜる)」へ向かっている。

2025年に発表したAB-MCTSは、推論時に複数のフロンティアモデル(Gemini、o4-mini、DeepSeek-R1など)を協調させ、単体では解けない問題を集合知で解く手法だ。「複数のフロンティアモデルが協力できるようにする」というこの発想が、そのままFuguの土台になっている。研究の旗(束ねる思想)と製品の旗(Fugu)が、ずれていない。これがSakanaの強みだ。

Sakana Fugu — 「モデルとして提供される、マルチエージェント」

では、Fuguとは具体的に何か。

ひとことで言えば、複数のフロンティアモデルを束ねる仕組みを、利用者からは「1つのモデル」に見えるように包んだ製品だ。Sakana自身は「マルチエージェント・オーケストレーションシステムを、1つの基盤モデルとして提供する」と説明している

Sakana Fuguの構造——1つのAPIの裏で複数モデルを指揮する 利用者は単一のOpenAI互換APIにリクエストを送る。Fuguのオーケストレーター(指揮役のLLM)が、タスクに応じて差し替え可能なモデルプール(Gemini、Claude、GPTなどのフロンティアモデル)から適切なモデルを呼び分け、協調させ、結果を統合して1つの応答として返す。あるモデルが使えなくなっても、プールの差し替えで動的に迂回できる。 Sakana Fuguの構造——1つのAPIの裏で複数モデルを指揮する 利用者からは1モデルに見える。裏で指揮役が差し替え可能なプールを呼び分ける 利用者 単一のOpenAI互換API Fugu オーケストレーター 「いつ・どれに委ねるか」を 学習したLLM(指揮役) 呼び分け・協調・統合 フロンティアモデルA 例:Gemini系 フロンティアモデルB 例:GPT系 フロンティアモデルC 例:Claude系ほか 差し替え可能なプール(swappable pool)|新モデルは追加、使えないモデルは迂回 ※ オーケストレーター自身も1つのLLMで、必要なら自分を再帰的に呼び出して検証を重ねる(推論時スケーリング)。 ※ 出典:Sakana AI「Sakana Fugu: One Model to Command Them All」(2026.6.22)。プール構成は時点のもの。 ※ EU/EEA(欧州)は提供対象外。利用可能なモデル構成は地域・規制で変わりうる。

仕組みはこうだ。利用者はOpenAI互換の単一APIにリクエストを投げる。すると、Fuguの「オーケストレーター」——いつ・どのモデルに委ねるか、どう協調させ、どう統合するかを学習したLLM——が、差し替え可能なモデルプールから適切なフロンティアモデルを呼び分ける。利用者には1つのモデルとして見えるが、裏では複数のモデルが働いている。Sakanaはこれを「One Model to Command Them All(すべてを統べる一つのモデル)」と呼ぶ。

製品はFuguとFugu Ultraの2段で、上位のFugu Ultraについては、SakanaはAnthropicのFable 5やMythos Previewと肩を並べる性能だと主張している。価格は従量課金(Fugu Ultraで100万トークンあたり入力5ドル/出力30ドル前後)と、月額サブスク(月20ドル・100ドル・200ドルの3段)の併用だ。

ここで第1回・第3回・第4回の「まだ言えないこと」と同じ慎重さが要る。この「肩を並べる」は、直接対決の結果ではなく、各社が公表したスコアとの比較だ。しかも比較対象のうちFable 5は、第1回で扱ったとおり米政府の輸出規制で多くの地域から利用できず、Mythos Previewももともと限定提供のプレビュー版で、いずれもFuguのプールには入っていない。つまり「束ねて使える複数のモデル」対「自由には使えない最強の一枚」の、数字の上での並列である。割り引いて読むべきだ。

Sakanaの主張を鵜呑みにできない理由は、もう一つある。2025年2月、同社は「AI CUDA Engineer」でPyTorchを10〜100倍高速化できると発表したが、第三者の検証で評価コードの抜け穴を突いていたことが判明し、Sakana自身が主張を撤回・訂正した。実際には逆に遅くなる例もあった。野心的な数字が後で崩れた前例がある以上、Fuguのベンチマークも独立検証を待つのが筋だ。これはSakanaを貶める話ではなく、「うますぎる話は裏を取る」という、この連載が一貫して取ってきた姿勢の問題だ。

束ねる型は、連載の3つの軸をどう満たすか

それでも、Fuguが面白いのは、本連載が掲げてきた 主権・特化・フォールバック の3つの軸を、製品レベルで同時に狙いにきている点だ。Sakanaの製品群を3軸に当てはめると、束ねる型の戦略的な意味が見えてくる。

束ねる型と連載の3軸——主権・特化・フォールバック 本連載の3つの軸に、Sakanaの取り組みを対応づけた図。フォールバックは差し替え可能なプールによる動的迂回(Fugu)、主権は海外モデルのバイアスを事後学習で是正するソブリンAI実証(Namazu)と一社依存の回避、特化は金融や防衛など領域特化の提携が担う。 束ねる型と連載の3軸——主権・特化・フォールバック Sakanaの製品・取り組みを、本連載が掲げてきた3つの軸に対応づける フォールバック 差し替え可能なプール による動的な迂回 = Fugu あるモデルが使えなく なっても、別のモデルへ 束ねる役が自動で切替 主権 一社依存の回避と バイアスの事後是正 = Namazu ほか 海外モデルが避けた質問を 日本仕様に事後学習で補正。 重要インフラの一社依存を回避 特化 領域特化の提携で 「暗黙知の谷」を埋める = 金融・防衛など MUFG・大和証券・SMBC、 防衛装備庁との委託研究など、 実務のドメインに踏み込む ※ Sakanaは「重要インフラ・金融・行政を一社のAPIに依存することは現実的な弱点」と明言(Fugu発表)。 束ねる型は、この3軸を単一のモデルではなく「組み合わせ」で満たそうとする戦略である。

フォールバック。 これが束ねる型の核心だ。第1回で、Anthropicが2026年6月12日にClaude Fable 5・Mythos 5へのアクセスを突然停止した事件を「可用性リスク」として挙げた。重要業務を単一の海外ベンダーに預ける怖さだ。Fuguの差し替え可能なプールは、まさにこの怖さへの答えになっている。あるモデルが規制や障害で使えなくなっても、束ねる役が別のモデルへ動的に迂回する。別連載『AIエージェント構築、その前に』で扱った技術的フォールバックを、製品の標準機能として組み込んだ形だ。Sakana自身、「重要インフラや金融、行政を一社のAPIに依存することは現実的な弱点だ」と明言している

主権。 Sakanaは別系統でソブリンAIの技術実証も進めている。海外のベースモデル(DeepSeek、Llama、gpt-ossなど)が政治的にデリケートな日本関連の質問を高い割合で拒否していたのを、日本仕様の事後学習でほぼ解消した、というものだ(Namazu α版。ベースのDeepSeek-V3.1-Terminusが関連質問の72%を拒否していたのを、ほぼ0%まで改善したと報告している)。束ねる型は土台に海外モデルを使うため、第3回のフルスクラッチ型のような「学習データの来歴を完全に自社で握る」純度の主権は持てない。だが「一社依存を避ける」「海外モデルの偏りを事後で補正する」という、運用レベルの主権は狙える。主権の意味が、第3回とは少しずれている点が重要だ。

特化。 SakanaはMUFG・大和証券・SMBCといった金融機関や、防衛装備庁 防衛イノベーション科学技術研究所(ATLA)との委託研究など、汎用モデルだけでは届かない実務のドメインに、提携を通じて踏み込んでいる。束ねる役が上にいて、その下に特化を積む構図だ。

3軸を1枚のモデルで満たすのではなく、「組み合わせ」で満たす——これが束ねる型の戦略の正体である。

源内もまた、束ねる型だった

ここで第2回を思い出してほしい。デジタル庁の「源内」が国産7モデルを選定したとき、Sakanaのような束ねる型はその7件に入っていなかった。理由は、束ねる役を源内そのものが担っているからだ、と書いた。

この対比が、第5回ではっきりする。源内は、行政が自前で運用する「束ねる型のプラットフォーム」だ。内部に複数のモデル(海外勢と国産勢)を抱え、業務に応じて使い分ける。つまり束ねる型には2つの実装形態がある。プラットフォームとして政府・企業が自前で束ねる源内型と、製品として束ねる仕組みを売るFugu型だ。

束ねる型の2つの実装——自前で束ねる源内型と、製品として束ねるFugu型 束ねる型には2つの形がある。左は源内型で、政府や企業が自前のプラットフォーム上で複数モデルを抱えて束ねる方式。統制を握れるが運用負荷を自分で負う。右はFugu型で、束ねる仕組み自体を製品として購入する方式。導入は速いが束ねるロジックは提供元のブラックボックスになる。 束ねる型の2つの実装 「自前で束ねる」か「束ねる仕組みを買う」か 源内型|自前で束ねる 政府・企業がプラットフォーム上で 複数モデルを抱えて使い分ける + 束ねるロジックを統制できる + どのモデルを置くか自分で決める − 運用・選定・更新の負荷を自分で負う 例:デジタル庁「源内」 Fugu型|束ねる仕組みを買う 束ねる役(オーケストレーター)を 製品・APIとして調達する + 導入が速い・運用負荷が小さい + 新モデルの追加は提供元が面倒を見る − 束ねるロジックは提供元のブラックボックス 例:Sakana Fugu ※ どちらも「束ねる型」。統制を取るか手間を省くかのトレードオフが、第6回の実装判断につながる。

源内型は束ねるロジックと、どのモデルを置くかを自分で握れる。統制は強いが、運用・選定・更新の負荷を自分で背負う。Fugu型は束ねる役を買うので導入は速く、新モデルの追加も提供元が面倒を見てくれる。代わりに、束ねるロジックは提供元のブラックボックスになり、どのモデルが選ばれているかは利用者から見えにくい。

このトレードオフ——統制を取るか、手間を省くか——は、まさに次回・第6回の実装判断につながる論点だ。

まだ言えないこと

束ねる型には、構造的な弱点がある。

第一に、借り物への依存だ。束ねる型は、自分で最強の一枚を作らない。だから束ねる先のフロンティアモデルが他社のクローズドなものである以上、その値上げ・仕様変更・提供停止に振り回されうる。フォールバックで「ある一社」への依存は避けられても、「フロンティアモデル群そのもの」への依存からは逃れていない。Fuguのプールに自前の有力モデルが入れば話は変わるが、現時点ではそうなっていない(Sakanaは今後、自社モデルやオープンモデルをプールに加える予定だと述べている)。

第二に、ブラックボックス性だ。どのタスクをどのモデルに振ったのか、束ねるロジックは提供元のプロプライエタリで、利用者からは見えにくい。来歴と説明責任が重い領域(第3回・第4回で繰り返した金融・医療・行政)では、この不透明さがそのまま採用の障壁になりうる。

第三に、性能主張の検証待ちだ。前述のAI CUDA Engineerの一件もあり、Fugu Ultraの「フロンティア級」という主張は、独立した第三者ベンチマークで裏を取るまで保留しておくのが妥当だ。Fable 5・Mythosとの比較が間接的である点も含め、数字は割り引いて読む。

それでも、束ねる型が提示した問いは本質的だ。「最強の一枚を自分で作る」ことだけがAI戦略ではない。既存の最強たちを賢く束ねることもまた、一つの道である——しかも、それは主権・特化・フォールバックという、性能とは別の軸でこそ価値を持つ。第1回の地図でいえば、束ねる型は横軸(自前の性能)での勝負を最初から放棄し、縦軸(主権・特化)と「組み合わせの妙」で空白地帯を狙う、最も異質な攻め筋だ。

まとめ

  • 束ねる型は「最強の一枚を自分で作らない」戦略。世界中の既存フロンティアモデルを束ね、指揮することに賭ける。代表はSakana AI
  • 「組み合わせる」には3層ある:MoE(モデル内部)/モデルマージ(重みを混ぜて新1枚を作る=mixing to create)/オーケストレーション(完成モデルを指揮する=mixing to use)。Sakana Fuguは3つ目
  • Sakanaの研究は進化的モデルマージ(2024)→AB-MCTS(2025)→Trinity/Conductor(ICLR 2026)→Fugu(2026.6)と、一貫して「混ぜて使う」へ進んできた。研究の旗と製品の旗がずれていない
  • Sakana Fuguは、複数のフロンティアモデルを束ねる仕組みを「1つのモデル」として提供。差し替え可能なプールが、第1回で挙げた可用性リスク(Fable/Mythos停止)への製品レベルの答えになっている
  • 束ねる型は連載の3軸を「組み合わせ」で満たす:フォールバック=Fugu、主権=Namazu等のソブリン実証、特化=金融・防衛の提携
  • 源内もまた束ねる型だった。束ねる型には「自前で束ねる源内型」と「束ねる仕組みを買うFugu型」の2形態がある(統制 vs 手間のトレードオフ)
  • 弱点:借り物依存・ブラックボックス性・性能主張の検証待ち(AI CUDA Engineer撤回の前例)。数字は割り引いて読む

これで、第1回の地図に置いた3つの戦略——フルスクラッチ主権型・派生特化型・束ねる型——をすべて回り終えた。次回はいよいよ実装編だ。自社のAIスタックのどの層に、どの戦略の国産を、どう組み込むか。主権リスクへの保険と、選定の判断軸を、これまでの5回を束ねて描く。

参考情報
山下 太郎

山下 太郎

代表取締役 / CEO

2000年、Webデザイナーとしてこの世界に飛び込み、フリーランスを経て2007年に株式会社アンタイプを創業。AI時代の到来とともに、効率だけを追うAI活用に違和感を覚えながら、それでも最前線でツールを使い続ける。企業のWebとコミュニケーションを設計する仕事を通じて、「人間らしさとは何か」を問い直す視点を発信し続けている。

View Profile arrow_outward

Related

あわせて読みたい