生成AIを業務へ組み込むとき、最初に突き当たるのが「どのモデルを選ぶべきか」という問題だ。
コーディングではClaudeが合う。検索や長い文脈の処理ではGeminiを試したい。
別の推論課題ではGPTの方が安定するかもしれない。しかし、モデルを増やすほどAPIキー、料金、プロンプト、障害対応、データ管理は複雑になっていく。
しかも、最適なモデルは「文章作成」「プログラミング」といった大まかな用途だけでは決まらない。
同じコーディングでも、設計、実装、デバッグ、テスト、レビューでは得意なモデルが異なる可能性がある。
利用者が毎回モデルを比較し、処理を振り分ける運用には限界がある。
Sakana AIが開発した「Sakana Fugu」は、この選択そのものをAIへ任せようとするシステムだ。
一つのモデルへ質問し、回答を受け取る従来の形とは違う。Fuguは課題に応じて複数のAIを呼び出し、考える役、作業する役、検証する役を組み合わせる。
そのうえで、全体を一つのモデルAPIとして提供する。
利用者から見えるのは一つのエンドポイントだが、その背後では複数のAIがチームとして動く。
Sakana AIはこの考え方を「Multi-Agent System as a Model」、つまりマルチエージェントシステムそのものを一つのモデルとして扱う設計として打ち出した。
Fuguの登場が示しているのは、新しい高性能LLMが一つ増えたという変化ではない。AIの競争軸が、モデル単体の能力から「複数の知能をどう組み合わせるか」へ広がり始めたことにある。
Sakana Fuguは、複数の基盤モデルや専門エージェントを動的に組み合わせ、一つのOpenAI互換APIから利用できるAIシステムだ。
2026年4月24日に早期β版が発表され、その後、一般利用を想定した製品ページ、料金体系、現行モデルが公開された。
β発表時には「Fugu Mini」と「Fugu Ultra」という名称だったが、現行版では「Fugu」と「Fugu Ultra」の2種類に整理されている。
利用者が「この処理にはGPT、この部分はClaude」と指定する必要はない。
Fugu側が入力内容と処理の途中経過を見ながら、参加させるモデル、役割、順番、情報の受け渡し方を決めていく。
たとえば、複雑なプログラムを作成する場合、最初のAIに設計を考えさせ、別のAIにコードを書かせ、さらに別のAIへ欠陥を探させる、といった進め方が考えられる。
問題によっては複数のAIに独立して解かせ、最後のAIが結果を統合する。一方、簡単な質問なら、複数モデルを動かさず一つだけで処理することもある。
この可変性が、Fuguの中心にある。
複数のモデルを使う仕組み自体は珍しくない。すでに多くのAIサービスが、質問内容に応じてモデルを切り替えたり、複数の回答を比較したりしている。
Fuguの特徴は、分岐条件や役割を人間が固定しない点にある。どのモデルに何を任せ、どの順番で話させ、誰に結果を検証させるか。その協調方法まで学習対象に含めている。
Fuguの技術的な基盤となっているのが、Sakana AIによる「TRINITY」と「Conductor」だ。
いずれもICLR 2026に採択された研究であり、複数のLLMを人間が作った固定フローではなく、学習によって連携させることを目指している。
TRINITYは、小型言語モデルを司令塔として使い、複数の外部LLMから次に呼び出すモデルと役割を選択する仕組みだ。
研究では、各モデルへ「Thinker」「Worker」「Verifier」という3種類の役割を割り当てている。
Thinkerは方針や推論を考える役、Workerは実際の回答やコードを作る役、Verifierは結果を検証する役に近い。
ただし、必ずこの順番で動くわけではない。
問題や会話の途中経過に応じて、必要なモデルと役割が選ばれる。
TRINITYの司令塔は、長い文章を生成して指示を出す大規模モデルではない。
研究ではQwen3-0.6Bを基盤とする小型モデルに軽量な選択ヘッドを加え、学習対象となるパラメータを2万未満に抑えた。
進化計算の一種であるCMA-ESを使い、最終的な正答率が高くなるモデル選択と役割分担を探索している。
この設計には、判断を下す司令塔そのものを巨大化させず、処理能力は外部の専門モデルから引き出す狙いがある。
Conductorは、より明示的に「AIチームの仕事の進め方」を生成する。
入力された問題を複数のサブタスクへ分け、各作業をどのモデルへ任せるか、前の作業結果を誰に読ませるか、どの順番で処理するかを自然言語で記述する仕組みだ。
たとえば、一つ目のモデルに解法を考えさせ、その結果を二つ目のモデルへ渡してコードを書かせる。
あるいは、二つのモデルに独立して回答させ、三つ目のモデルに比較・統合させる。このような協調構造を、問題ごとに作り替える。
研究段階のConductorは70億パラメータのモデルを基盤とし、強化学習によって協調戦略を獲得した。
学習には数学、一般知識、現実的な推論、コード生成の計960問が使われ、最大5ステップのワークフローを設計するよう訓練されている。
観察された連携方法も一種類ではない。
計画役から実行役、検証役へ順番に渡す直列型、複数モデルが独立して考えた後に統合するツリー型、簡単な問題を一つのモデルだけに任せる形など、入力に応じて異なるパターンが現れた。
Fuguの商用版が、この2本の論文をそのまま実装したものとは限らない。
Sakana AIは、製品化にあたって性能と利用体験をさらに改良したと説明している一方、現行システムの全構成、参加モデルごとの選択条件、学習データ、内部プロンプトは公開していない。
したがって、論文はFuguの思想と基礎技術を理解する材料にはなるが、商用版の挙動を完全に再現する設計書ではない。
Fuguを理解するには、「一つの強いモデル」「モデルルーター」「固定型マルチエージェント」との違いを分けて考える必要がある。
単体LLMでは、基本的に一つのモデルが計画、推論、生成、確認をすべて担う。
内部で長く考えるリーズニングモデルもあるが、外部の異なるモデルを協調させるわけではない。
モデルルーターは、質問の内容、料金、速度などを見て、適したモデルへ一度振り分ける。
文章作成ならモデルA、コードならモデルBという選択には向いているものの、通常は選ばれた一つのモデルが最後まで回答する。
固定型のマルチエージェントでは、設計者があらかじめ役割と順番を決める。「調査担当が情報を集め、執筆担当が文章を作り、校正担当が確認する」といった構造だ。
業務に合わせて管理しやすい一方、単純な質問にも同じ手順を通せば、処理時間と料金が増える。
Fuguは、その中間に新しい層を作る。どのモデルを使うかだけでなく、何人のエージェントを動かし、どの役割を持たせ、
どう連携させるかを入力ごとに変える。
この仕組みが有効に働けば、利用者はモデル各社の更新を追い続ける負担から解放される可能性がある。
新しいフロンティアモデルが公開された場合、Sakana AIは約2週間をかけてFuguへの追加に向けた訓練と評価を行う方針を示している。
利用者が自社のワークフローを一から作り直さなくても、背後のモデルプールが更新されていく設計だ。
一方で、モデル選択が抽象化されるほど「なぜこのモデルが使われたのか」「どの処理が失敗したのか」は見えにくくなる。便利さと透明性は、必ずしも同じ方向へ進まない。
現行のSakana Fuguには、速度と性能のバランスを取った「Fugu」と、回答品質を優先する「Fugu Ultra」がある。
どちらもOpenAI互換APIから呼び出せるため、既存のOpenAI形式のクライアントやコーディング環境から移行しやすい。
Fuguは、日常的なコーディング、コードレビュー、対話型サービスなど、応答速度も求められる処理を想定している。
特定のモデルやプロバイダーをプールから除外できるため、企業のデータ方針やコンプライアンス要件にも一定の調整余地がある。
Fugu Ultraは、より多くの専門エージェントを利用し、複雑な多段階処理で品質を優先する。
Sakana AIは、論文再現、Kaggle、サイバーセキュリティ分析、文献・特許調査などを利用例として挙げている。
こちらは性能を維持するためモデルプールが固定されており、利用者が特定モデルを除外することはできない。
Sakana AIが公開した現行ベンチマークでは、Fugu UltraがSWE Bench Proで73.7、TerminalBench 2.1で82.1、LiveCodeBench Proで90.8を記録している。
比較対象として掲載されたOpus 4.8は、同じ順に69.2、74.6、84.8。GPT 5.5は58.6、78.2、88.4だった。
科学推論のGPQA-DではFuguとFugu Ultraがともに95.5となり、比較対象モデルを上回っている。
ただし、数字の読み方には注意が要る。
すべてのモデルを同じ運営者が同じ条件で直接評価したわけではなく、比較対象には各プロバイダーが公表したスコアも含まれる。
さらに、Fuguは複数モデルを呼び出すシステムであり、単体モデルとは使っている推論計算量やAPI呼び出し回数が異なる可能性がある。
したがって、ベンチマークはFuguの可能性を示す材料にはなるが、あらゆる業務で同じ優位性が得られることを保証するものではない。
自社のデータと評価基準を使った検証が欠かせない。
料金には月額のサブスクリプションと従量課金がある。すべての月額プランからFuguとFugu Ultraの両方を利用でき、違いは利用枠にある。
Fuguの従量課金は、複数モデルを呼び出した際に各モデルの料金をすべて積み上げる方式ではない。
稼働したモデルのうち、最上位の料金帯に基づく一つのレートで請求すると説明されている。
Fugu Ultraの現行モデル「fugu-ultra-20260615」は、100万トークンあたり入力5ドル、出力30ドル、キャッシュ入力0.50ドル。
コンテキストが27万2,000トークンを超える場合は、入力10ドル、出力45ドル、キャッシュ入力1ドルへ上がる。
複数の最先端モデルを個別契約し、呼び出し回数ごとに課金される仕組みと比べれば、予算を把握しやすい面はある。
ただし、月額プランの具体的なトークン数や、各処理でどれだけ利用枠を消費するかは、単純な文章量だけでは判断しにくい。
実際の業務で費用を測る必要がある。
Fuguの強みが出やすいのは、一回の生成で終わらず、複数の判断と検証を必要とする作業だ。
コードの設計、実装、テスト、修正を繰り返す開発作業。論文を読み、実装し、結果を再現して差分を分析する研究。
複数の文献や特許を照合しながら論点をまとめる調査。仮説を立て、実験を行い、結果を見て次の条件を変える反復処理などが該当する。
公式の事例では、小規模GPTの学習条件を改善する実験で、Fugu Ultraが単一のH100 GPUを約14時間使用し、123回の試行を重ねた。
バッチサイズ、モデルの深さ、学習率、最適化手法などを変更し、比較対象の単体モデルをわずかに上回る結果を得ている。
古典的な仮名書状の読み順を推定する実験では、Fugu Ultraが専門家の正解に対するNEDスコア0.80を記録し、比較モデルの0.24を大幅に上回った。
単純な知識回答より、課題を理解してコードを作り、実行結果を改善する処理で差が出た例といえる。
Fuguは魅力的な設計だが、「複数の高性能AIを使えば、常に一つのモデルより正確になる」と考えるのは早い。
複数モデルによる協調には、単体モデルとは異なる失敗の経路が生まれる。
Fugu Ultraは、回答品質を優先する代わりに応答時間が長くなる。複数のモデルが順番に作業し、検証や修正を重ねるなら、その分だけ処理時間は延びる。
チャットボットのように数秒単位の応答が求められる用途では、品質向上より待ち時間が問題になる可能性がある。単純な翻訳、短い要約、定型文作成にまでFugu Ultraを使う合理性は薄い。
Fuguは課題の難しさに応じて一つのモデルだけを使うこともあるが、実際の待ち時間と費用がどの程度になるかは検証が必要だ。
最初の計画役が問題を誤解すると、その後のモデルが誤った前提を引き継ぐことがある。検証役が付いていても、同じ誤解を共有すれば訂正できない。
複数モデルの回答が一致したからといって、事実であるとは限らない。似た学習データや一般的な誤情報を共有している場合、複数のAIが同じ誤答へ到達する可能性も残る。
医療、法務、金融、セキュリティなど、誤りの影響が大きい領域では、人間による確認と外部資料による検証を省けない。
Fuguは複数の外部モデルをオーケストレーションする。利用するモデルによっては、入力内容が異なるプロバイダーの基盤へ送られる可能性がある。
通常のFuguでは特定モデルを除外できるが、Fugu Ultraはモデルプールが固定されている。
機密情報、個人情報、顧客データ、未公開コードを扱う企業は、データ保持、学習利用、保存地域、再委託先、監査ログ、削除方法を契約前に確認する必要がある。
また、Sakana FuguはGDPRなどへの対応を進めている段階で、2026年6月22日時点ではEU・EEA域内から利用できない。
TRINITYとConductorの論文は公開されているものの、商用版Fuguの参加モデル、選択ルール、評価方法、フェイルオーバー、内部プロンプトの全容は非公開だ。
利用者から見れば一つのAPIで扱える反面、出力が変化した理由を追いにくい。モデルプールが更新されれば、同じ入力でも結果、処理時間、料金が変わる可能性がある。
本番環境へ導入する場合は、モデルのバージョン固定、回帰テスト、ログ、出力の監査、利用上限、障害時の代替経路を整えておきたい。
Fuguを導入すべきかどうかは、「最も高いベンチマークを取ったか」では決まらない。
単純な処理を大量に回すなら、安価で高速な単体モデルの方が合理的だ。複数の推論、実装、検証を人間がつなぎ合わせている業務では、Fuguによる自動化が大きな差を生むかもしれない。
評価すべきなのは、モデル一回の能力ではなく、業務全体で減らせる手作業と、追加される費用・待ち時間・管理負担のバランスである。
Sakana Fuguが持ち込んだのは、「どのAIモデルが一番強いか」という競争とは異なる視点だ。
現在のフロンティアモデルには、それぞれ得意分野がある。一つのモデルを万能に近づけるため巨大化を続ける方法もあれば、異なるモデルを適切に組み合わせ、全体として高い能力を引き出す方法もある。Fuguは後者を製品として提供しようとしている。
その核心は、複数モデルを使えることではない。問題を見ながらチームを編成し、役割を割り振り、必要に応じて検証まで行う仕組みにある。
OpenAI互換APIとして提供されるため、利用者は複雑なマルチエージェント環境を一から構築しなくても試せる。モデルの更新をFugu側が吸収できれば、特定企業のモデルへ強く依存する状態も緩和できるだろう。
一方、複数モデルを束ねることで、処理時間、コスト、データ管理、透明性という新しい課題も加わる。公開ベンチマークで優れた結果が出ていても、自社の業務で同じ効果が得られるとは限らない。
Fuguが最も力を発揮するのは、簡単な質問への返答ではなく、計画、実行、検証を何度も往復する仕事だ。論文再現、複雑なソフトウェア開発、科学的推論、特許調査、長時間の自律実験。これまで人間が複数のAIを手作業で使い分けてきた領域ほど、導入価値を見いだしやすい。
AIモデルを選ぶ時代が終わるわけではない。ただ、その選択を利用者が毎回行う必要はなくなるかもしれない。
Fuguが目指しているのは、最高の一匹を作ることではなく、異なる能力を持つ魚の群れを、一つの知能として泳がせることである。
.png){kind=logo}
