「AnthropicのFable 5に肩を並べる」——そううたわれる新しいAI、Sakana Fuguが2026年6月22日に発表されました。ただし、その正体は1社が鍛え上げた単一の巨大モデルではありません。複数のAIを束ねて1つのAPIで指揮する「オーケストレーション基盤」という、これまでとは異なる発想の製品です。なぜ単一の最前線モデルに肩を並べられるのか、そして自分で組むのと比べて何が得で何が見えにくくなるのか——この記事はそこを解きほぐしていきます。
複数のAIモデルを協調させる仕組みを「自分で組むか」「できあいの基盤を買うか」で迷っているなら、その判断材料になるのがSakana Fuguです。マネージドな協調基盤を選ぶと、モデル選びやルーティングの保守から解放される代わりに、内部で複数モデルを呼ぶぶんトークンが積み上がります。逆にClaudeやCodexを自前で束ねれば、制御もコストの内訳も手元に残りますが、構築と保守の手間を抱え込むことになる。どちらが上というより、何を手放して何を得るかの選択です。
- Sakana Fuguは1つのAPIで複数のフロンティアAIを自動で使い分けるオーケストレーション基盤（Sakana AIが2026年6月22日に一般提供開始）
- 「自前で束ねる」と比べ、構築・保守の手間が消える。内部では複数モデルを呼ぶが、課金は最上位モデルの単一レートやサブスク枠に収まり、複数モデル分を重ねて請求しない設計（2026年6月時点）
- 用途は2バリアント（低レイテンシのFugu／高品質のFugu Ultra）で選び分ける
- Sakanaの自社ベンチでは、上位版Fugu UltraがAnthropicのFable 5と肩を並べる水準だと主張（同社発表で第三者検証は未了）。そのFable 5はプールに入っておらず、公開モデルだけで最前線に匹敵を狙う構図
Sakana Fuguとは何か（オーケストレーションモデルの定義）
Sakana Fuguは、東京を拠点とするAI企業Sakana AIが提供する、複数のAIモデルを束ねて1つのモデルのように振る舞わせるシステムです。Sakana AI公式の発表によれば、2026年6月22日に一般提供を開始し、それ以前は約500人規模のベータ運用を経ています。ここでいうオーケストレーション（orchestration＝複数の処理を指揮者のように束ねて全体を制御すること）が、この製品の中心にある考え方。
普段ChatGPTやClaudeを使うとき、ユーザーは1つのモデルに話しかけています。Fuguが変えるのはまさにそこで、利用者から見れば1つの窓口（API）に投げるだけなのに、その裏では複数のフロンティアモデルが状況に応じて呼び出され、協力して1つの答えを返す構造になっています。フロンティアモデルとは、各社が最前線で開発している高性能な大規模言語モデル（LLM＝大量のテキストで訓練され、文章生成や推論を行うAI）のこと。Sakana AIが性能比較に用いた公開モデルには、GPT-5.5やClaude Opus 4.8、Gemini 3.1 Proといった各社のフロンティアモデルが並びます。ただしこれらは「ベンチで比べた相手」であって、プールに実際に組み込まれているモデルの正確な一覧を公式が明示しているわけではありません。プールは差し替え可能な設計とされるため、ある時点の構成を固定の事実として読むものではない、と捉えておくのが安全です。
初心者がまず押さえておきたいのは、Fuguが「新しい単体のAIモデル」ではない点です。世の中の多くのAIサービスは、自社で訓練した1つのモデルを提供します。Fuguはそうではなく、すでにある複数の優秀なモデルを取りまとめる立場に回る。料理にたとえると、自分で新しい食材を作る人ではなく、複数の専門店から最適な料理を取り寄せて1皿に仕上げる調整役に近い、と考えると掴みやすいでしょう。
「1つのモデルのように振る舞う」とはどういうことか
利用者が意識する操作は、あくまで「質問を1回送って、答えを1回受け取る」だけです。内部で2つのモデルが使われようと5つが使われようと、返ってくるのは統合された1つの回答。この「複雑さを隠す」性質がFuguの分かりやすさを支えています。
たとえばコードのバグ修正を頼む場面を想像してください。あるモデルは原因の推測が得意で、別のモデルは修正後の検証が得意、という具合に強みが分かれることは珍しくありません。Fuguは内部でそうした役割分担を組み立て、最終的に1つの修正案としてまとめて返す方針をとります。利用者は「どのモデルにどの工程を任せるか」を考えずに済む、というのが体験上の核心です。
単体LLMやAPIアグリゲータ（ルーター）との違い
似た仕組みに「APIアグリゲータ」や「LLMルーター」と呼ばれるサービスがあります。これは、リクエストの種類に応じて「このタスクはモデルA、あのタスクはモデルB」と振り分ける交通整理の役割を担うもの。ただし多くのルーターは、1リクエストにつき1モデルを選んで丸投げする形です。
Sakana AI公式の説明では、Fuguはそこからもう一歩踏み込みます。単に振り分けるだけでなく、Fugu自身が判断主体となって、必要なら複数モデルに分担させ、その結果を検証し、統合してから返す。つまり「どのモデルに渡すか」を決める層と、「複数の出力をまとめ上げる」層の両方を内部に持つ点が、従来の単純なルーターとの違いとして位置づけられます。1モデルに固定されないので、特定の提供元が混雑や制限で応じにくいときも、別の経路へ切り替えやすいという耐障害性の方針も示されています。
じつは、司令塔役のAIが小さなエージェントへ作業を振り分ける構造そのものは、目新しいものではありません。わかりやすいのがClaudeの例です。Anthropicの開発ツールClaude Codeには、メインのAIが調べものや検証といった作業を別のサブエージェントに任せ、その結果を受け取ってまとめる仕組みがあります。親のAIが「この調査はサブエージェントへ」と振り分けて統括する——まさに司令塔型の指揮そのもの。CodexにもOpenAIのモデルで同様の仕組みがあります。これらと比べると、Fuguの位置づけが掴みやすくなります。違いは呼ぶ先です。これらのサブエージェントは同じベンダーのモデル系列内で動き（Claude系のツールならClaudeのモデルを使い、他社製モデルは呼びません）、役割はプロンプトで切り替えるのが基本。対してFuguは、別ベンダーのモデルを横断して束ねる点に新しさがあります。「司令塔がモデルを選んで指揮する」骨格は共通でも、自社のモデル内で役割を割り振るのか、他社のモデルまで指揮下に置くのかが、両者の分かれ目だと整理すると見通しが良くなります。
Fuguの仕組み——選択・委譲・検証・統合の流れ
ここからは、1つのリクエストがFuguに入ってから答えが返るまでを、入口から出口まで順に追っていきます。仕組みが腹落ちすると、後半で扱う「トークンがなぜ増えるのか」も自然に理解できます。
Sakana AI公式によれば、Fugu自体も1つの言語モデルとして動きます。まず受け取ったリクエストを見て、自分だけで解けそうな単純な依頼ならその場で答え、難易度が高い依頼なら他のモデルへ委譲する、という分岐をFugu自身が判断する。この「自分で解くか、誰かに任せるか」を最初に決める振る舞いが出発点です。
委譲が必要だと判断すると、次に「どのモデルに、どの役割を割り当てるか」を組み立てます。Sakana AI公式は、この協調のしかたがICLR 2026で発表された研究を土台にしていると説明しており、役割を分けて処理するTRINITY（思考役・作業役・検証役に分担する枠組み）と、協調のしかたそのものを学習するConductorという仕組みが紹介されています。役割名や枠組みの呼称は公式の記述に沿ったもので、内部アルゴリズムの細部までは公開されていません。ここでは「役割分担と、その分担のしかたを学習で最適化する」という大枠を掴めば十分です。
処理の流れを整理すると、おおよそ次の4段階に分けられます。
- 1. 選択
- リクエストの内容と難易度を見て、自分で解くか、どのモデル群へ委譲するかを決める
- 2. 委譲
- 選んだモデルに役割を割り当てて処理を任せる。複数モデルへ並行・段階的に渡す場合もある
- 3. 検証
- 返ってきた出力をそのまま信じず、矛盾や誤りがないかをチェックする
- 4. 統合
- 複数の出力やチェック結果を1つの回答にまとめ上げて返す
この4段階を1リクエストの中でこなすため、利用者には1往復に見えても、内部では複数回のモデル呼び出しが走っているわけです。便利さの裏でトークンが積み上がる理由が、ここにあります。
モデル選択と役割分担（協調トポロジの自動構築）
Fuguの特徴は、役割分担の形をあらかじめ固定せず、依頼ごとに組み替える点にあります。Sakana AI公式の説明では、協調のしかた（どのモデルにどの役割を割り当て、どう連携させるか）をConductorが学習によって最適化するとされています。
初心者向けに言い換えると、こうなります。簡単な質問なら1つのモデルにさっと答えさせ、込み入った調査なら「下調べ役」「執筆役」「検証役」のように複数のモデルを段階的につなぐ。この組み立て方をタスクの性質に合わせて自動で変える、という方針です。自前で同じことをやろうとすると、どのケースでどう分担するかの条件を人間が設計し続けなければなりません。その設計負担を内側に取り込んでいるのがFuguの立ち位置といえます。
加えて、内部で使うモデル群は差し替え可能な設計だと公式は説明しています。あるモデルの提供元が一時的に応答しにくくても、別のモデルへ経路を寄せることで処理を継続しやすい。単一モデルに依存しない構成が、安定性の面でも効いてくる場面があるという位置づけです。
検証と統合——なぜ単体呼び出しより安定しうるのか
単体のLLMに直接質問すると、返ってきた答えが正しいかどうかは利用者側で確かめるしかありません。AIは事実と異なる内容をもっともらしく出力すること（ハルシネーション＝もっともらしい誤りの生成）があるため、検証工程の有無は実用性を左右しやすいポイント。
Fuguは内部に検証の段を持ち、出力をいったんチェックしてから統合する流れをとります。ある出力を別の観点で見直し、矛盾があれば調整したうえで最終回答にまとめる。これにより、単純に1モデルへ投げて即返すよりも、結果が安定しやすい可能性があるとされています。ただし、ここで注意したいのは「安定しうる」という表現にとどめている点です。検証段があるからといって誤りがゼロになるわけではなく、どの程度安定するかはタスクや設定で変わります。本記事の段階で断言できるのは仕組みの存在までで、品質の保証ではありません。
この「複数を束ねることで、単体では届きにくい水準に手が届きうる」という見方は、Fuguが掲げる主張の核心にもつながっています。Sakanaは自社のベンチマークで、上位版のFugu UltraがAnthropicのFable 5やMythos Previewと肩を並べる水準だと位置づけています。興味深いのは、そのFable 5自身はFuguのモデルプールに入っていない（非公開のため）点。つまり、アクセスできる公開モデルだけを束ねて、アクセスできない最前線モデルに匹敵する、という構図です。
なぜそんなことが起こりうるのか。最前線の単一モデル（Fable 5のような）は単体で非常に強力で、プールに入る公開モデルが単体でそこに並ぶとは限りません。それでも束ねたほうが効く場面があるのは、単一モデルにはない工程を挟むからです。役割分担で各モデルを得意な工程に集中させ、検証で出力を相互にチェックして誤りを削り、統合で複数の答えのいいとこ取りをする。一人に一発で答えさせるより、複数の視点を突き合わせたほうが結果として安定し、精度が上がりうる——複数の判断を集める「集合知」に近い発想です。ただしこれはあくまでSakana自身の評価で、ベンチマークによっては単一モデルのほうが上回る場合もあり、第三者による独立検証はこれからだという点は変わりません。
もう一歩踏み込むと、この底上げの鍵は束ねるモデルの「多様性」にあります。集合知が力を発揮するのは、集める意見が互いに異なる視点を持つとき。同じモデルをいくつ並べても、同じ訓練に由来する似た偏りや盲点を共有するため、一つが間違えると他も同じように間違えやすく、相互チェックがすり抜けがちです。Fuguが束ねるのは別ベンダーの異種モデルで、訓練データもクセも異なるぶん、一方が見落とした点を別系統のモデルが拾いやすい。Sakana自身も、多様なモデルのプール（diverse pool）を協調させることで単一の働き手を上回る、と説明しています。対照的に、Claude Codeのサブエージェントのように同じモデル系列内で役割を分ける構成は、一貫性や扱いやすさに利点がある反面、モデルの偏りという面では多様性が生まれにくい。同じ系統だけで検証し合うと、見落としも揃いやすいわけです。Fuguがあえて異種モデルを横断する設計を選んだ背景には、この多様性で精度を底上げする狙いが読み取れます。
似た発想は、手作業の運用でも見かけます。Claudeに書かせた答えを、Codexや別のモデルにクロスチェックさせる——そうした使い分けは珍しくありません。Fuguがやっているのは、いわばその「複数のモデルで相互に確かめ合う」動きを、1つのモデル（API）の内側で自動的に回すこと。そう捉えると、検証や統合をわざわざ内側に持つ意味が、すっと飲み込めるかもしれません。
FuguとFugu Ultra、2つのバリアントの違い
Fuguには用途の異なる2つのバリアントがあります。Sakana AI公式の位置づけに沿って整理すると、次のように分かれます。
ひとつは標準の「Fugu」で、応答の速さ（低レイテンシ＝待ち時間の短さ）を重視した日常向け。チャットでのやり取り、コーディング中の補完やレビューといった、軽快な反応が欲しい場面に合わせた想定です。もうひとつが「Fugu Ultra」で、難しい多段の推論を要するタスク向けに最高品質を狙ったバリアント。研究の補助、論文の再現確認、セキュリティ分析のような、時間をかけてでも深く詰めたい用途が公式の想定として挙げられています。
両者の違いを、用途の軸で並べると見通しが良くなります。
| 軸 | Fugu | Fugu Ultra |
|---|---|---|
| 応答の速さ | 速い（低レイテンシ重視） | 遅め（品質優先） |
| 想定タスク | チャット・コード補完・レビュー | 研究・論文再現・分析 |
| 重視する点 | テンポよく回す日常利用 | 難しい多段推論の品質 |
速度と品質はしばしばトレードオフ（一方を取ると他方が犠牲になる関係）になります。素早い反応が要る作業に重い処理を回すのは過剰ですし、逆に深い分析を速さ優先のバリアントに任せれば物足りなくなりかねません。どちらが優れているという話ではなく、目の前のタスクがどちらを求めているかで選ぶもの。なお、どちらもOpenAI互換のAPIで提供されるため、CodexのようなOpenAIのAPI形式に対応したツールへ組み込みやすい点も公式に示されています。
どちらをどの場面で使うか
判断の目安はシンプルです。テンポよく何度も往復したい作業はFugu、1回の答えに時間をかけてでも精度を上げたい作業はFugu Ultra、と振り分けるのが基本線。
具体的には、コードを書きながら補完や軽いレビューを頼む流れではFuguのテンポが活き、未知の問題を腰を据えて調べたり、複数の資料を突き合わせて検証したりする場面ではFugu Ultraの品質が効いてきます。料金や速度の具体的な数値はバリアントによって変わり、更新も速いため、選ぶ前に公式の最新情報を確認するのが安全です。本記事のトークンコストの話（後半）も、この2バリアントのどちらを多用するかで実感が変わってくる点を覚えておいてください。
自分でオーケストレーションを組む場合との比較（判断軸）
ここが、この記事でいちばん持ち帰ってほしい部分です。複数AIの協調は、Fuguのようなマネージド（提供側が運用を肩代わりしてくれる方式）の基盤を使わなくても、ClaudeやCodex、複数のLLMを自分で束ねれば実現できます。自前で組む場合は、LangGraphやCrewAIといったマルチエージェント構築フレームワーク（複数のAIエージェントを連携させる土台となるライブラリ）を使うのが一般的。役割ごとにモデルを切り替える型や、AI同士にクロスチェックさせる型といった組み立て方そのものは、マルチオーケストレーションの設計パターンで詳しく整理しています。では、Fuguを買うのと自前で組むのとで、何が変わるのでしょうか。
結論を先に言えば、Fuguは「構築と保守の手間を手放す代わりに、内部の動きとコストの内訳が見えにくくなる」方式、自前構築は「手間を抱える代わりに、制御もコストの内訳も完全に握る」方式です。優劣ではなく、トレードオフの方向が逆を向いている、と捉えるのが正確。クラウドAPIのモデル選定そのものをどう考えるかは、当サイトの別記事「DeepSeek V4はクラウドで使うべきか｜料金・コーディング精度・データ取扱いをClaude・GLM-5.2と比較」でも、Claude や Codex を含めた選び方を整理しています。
比較表（マネージド vs 自前構築）
判断軸は、値の高い・低いが一方向に決まる言葉で揃えました。
| 判断軸 | Sakana Fugu（マネージド） | 自前構築（Claude・Codex等を束ねる） |
|---|---|---|
| 初期構築コスト | 低い（APIに繋ぐだけ） | 高い（ルーティング・役割設計が必要） |
| 運用保守の手間 | 低い（提供側が更新） | 高い（モデル更新・障害対応を自分で） |
| モデル選択の自由度 | 低い（提供側のプール内） | 高い（任意のモデルを組める） |
| コストの透明性 | 低い（内部消費が見えにくい） | 高い（各APIの実消費が見える） |
| デバッグのしやすさ | 低い（内部処理が隠れる） | 高い（各段の入出力を追える） |
| 本番投入までの速さ | 速い | 遅い（設計・検証に時間） |
表を眺めると、Fuguの長所がそのまま短所の裏返しになっているのが分かります。手間がかからないのは、裏側を提供側に任せているから。逆に自前構築は、手間がかかるぶん、どのモデルをどう繋ぐかもコストの内訳もすべて手元に残ります。「早く動かしたい」を取るか、「細かく握りたい」を取るかの線引きが、選択の分かれ目です。
自前構築で発生する隠れコスト（プロンプト設計・ルーティング保守・検証ロジック）
自前構築を「フレームワークを入れれば終わり」と見積もると、あとで負担が膨らみがちです。実際に手を動かすと、表に出にくいコストがいくつも積み上がります。
まず、どのタスクをどのモデルに振るかを決めるルーティング条件の設計。これは一度書いて終わりではなく、新しいモデルが出るたびに見直しが要ります。次に、各モデルへの指示を整えるプロンプト設計。モデルごとに得意な指示の出し方が違うため、複数モデルを束ねるほど調整箇所が増えます。さらに、複数の出力を突き合わせて正しさを確かめる検証ロジックも、自分で書いて保守し続けることになる。
こうした作業は、AIエージェントの構築で精度を左右する「情報の渡し方」（コンテキストエンジニアリング）の設計とも地続きで、軽く見ると後から効いてきます。Fuguはこの設計・保守の部分を内側に取り込んでいるため、利用者は表に出るコストだけを払えばよい代わりに、内側で何が起きているかは見えにくくなる。自前なら隠れコストを払うかわりに全部見える、Fuguなら隠れコストを払わないかわりに中身も隠れる、という対称の関係です。どちらの隠れコストを引き受けるのが自分の体制に合うか——これが次に見ていくトークンコストの話に直結します。
トークンコストはどう変わるか
オーケストレーションを使ううえで、いちばん見えにくいのがトークンの増え方ではないでしょうか。単体のモデルに1回投げて1回返ってくる使い方と違い、Fuguのような仕組みは内部で複数のモデルを何度も呼びます。その呼び出し1つ1つに入力と出力のトークンが発生する。つまり、利用者から見れば「1リクエスト」でも、裏側では何リクエストぶんもの計算（トークン）が動いている、というのが構造上の前提です。ただし後で見るように、この内部の積み上がりが、そのまま利用者の請求額になるわけではありません。そこにSakana独自の課金設計が効いてきます。
まずは、どの段階で内部のトークンが増えるのかを分解し、そのうえで「では実際の課金はどうなるのか」を見ていきます。
委譲・検証・統合で増える消費の内訳
Fuguのオーケストレーションは、大きく分けて「自分で判断する」「別のモデルに委譲する」「結果を検証する」「複数の出力を統合する」という流れで動きます。Sakana AI公式の説明によれば、Fugu自身が言語モデルとして振る舞い、まず自分で解くか他モデルに任せるかを判断する。この判断の段階で、すでに入力トークンが消費されます。
次に委譲。あるタスクを別のモデルに渡すとき、そのモデルへ渡す指示文（プロンプト）と、元の文脈をまとめて送ります。元の質問が長ければ、委譲先にもその長さぶんのトークンが乗る。複数のモデルに振り分ければ、その数だけ入力トークンが増えていきます。
そして検証と統合。委譲先から返ってきた出力が妥当かを確かめ、複数の答えを突き合わせて1つの回答にまとめる。この検証・統合の処理も、内部的にはモデルへの問い合わせとして行われることが多く、ここでも追加のトークンが発生します。
整理すると、消費が増える箇所は次のように積み重なります。
- 入口での判断（自分で解くか委譲するかの選択）
- 委譲先への文脈の受け渡し（モデルごとに発生）
- 委譲先からの出力（内部処理として発生）
- 検証・統合の問い合わせ
単体モデルなら「入力1回＋出力1回」で済むところが、オーケストレーションでは「判断＋委譲分×モデル数＋検証＋統合」になる。これが内部でトークンが膨らみやすい根本の理由です。難しいタスクほど委譲と検証の回数が増えるため、内部の計算量も大きくなります。ただし大事なのは、これはあくまで内部で動く計算の話で、次に見るように、利用者の請求がそのまま比例して増えるわけではないという点です。
課金の見え方の違い（隠れる消費 vs 見える消費）
ここで効いてくるのがSakanaの課金設計です。公式の料金ページ（2026年6月時点）には、従量課金について「複数のモデルが関与しても料金を重ねず、関わった最上位モデルの単一レートで課金する」と明記されています。つまり内部で何モデルを呼ぼうと、請求は最上位モデル1つ分のレートに収まる設計。上位版のFugu Ultraは入力100万トークンあたり$5・出力$30という固定単価（コンテキストが272Kを超えると$10／$45）で、サブスクならStandard $20・Pro $100・Max $200の月額枠の中で使う形です。内部の複数呼び出し分は、この単一レートや月額枠の中に提供側が吸収する。便利な反面、自分のリクエストが裏で実際に何トークン回したのかは見えにくくなります。
一方、自前でClaudeやCodex、その他のモデルを束ねる場合は、各APIの利用明細がそのまま手元に届きます。どのモデルを何回呼び、入力と出力で何トークン使ったかが分単位で見える。コストの可視性という点では自前のほうが上です。ただし、その可視性は「自分で計測し、自分で最適化する」前提とセット。見えるからこそ、無駄な呼び出しを削る運用も自分の仕事になります。
なお、上記の料金は2026年6月時点で公式の料金ページに公開されているものです。料金体系は更新されうるため、実際に使う際の確定値は公式の最新情報で確認してください。料金にまつわる注意書きはここで一度まとめておき、以降の章では繰り返しません。
どんなときにFuguを選び、どんなときは自前か
選び分けの軸は、突き詰めると「制御と透明性を取るか、構築と保守からの解放を取るか」の一点に集約されます。性能の優劣ではなく、自分の体制とゴールに合うのはどちらか、という判断です。ここでは具体的な状況を思い浮かべながら、向き・不向きを整理します。
Fuguが向くケース
複数モデルの協調を、できるだけ早く本番に乗せたい場面。これはFuguの得意領域です。OpenAI互換のAPIに繋ぐだけでオーケストレーションが動くため、ルーティングや検証ロジックをゼロから書く時間を節約できます。少人数のチームや、AI機能を素早く試したいプロダクトでは、この立ち上がりの速さが効いてきます。
モデル選択の保守から解放されたい場合も向きます。新しいモデルが出るたびに「どのタスクをどれに振るか」を見直す作業は、地味に手間がかかる。Fuguはそのモデルプールの差し替えを内側で吸収する方針を取っているため、利用者は個々のモデルの入れ替わりをあまり気にせず使い続けられます。
逆に言えば、Fuguが向くのは「中身を細かく握る必要がない」ケース。協調の仕組みそのものを作ること自体が目的でないなら、できあがった基盤を借りるほうが合理的です。
自前構築が向くケース
ルーティングの条件を細かく制御したい場合は、自前に軍配が上がります。「このタスクは必ずこのモデル」「コストが一定を超えたら安いモデルに落とす」といった独自ルールを作り込みたいなら、自分で束ねるほうが自由度が高い。
自由度は、呼ぶモデルの選択だけにとどまりません。自前で組むなら、各モデルに与えるシステムプロンプト——役割・禁止事項・出力形式を書いた指示書で、Markdownファイルなどで管理することが多い——も自分で設計して注入できます。たとえば「このエージェントは検証専門、根拠のない指摘はしない」「出力は決めたJSONのみ」といった役割定義を、モデルごとに細かく作り込める。先に触れたClaude Codeのサブエージェントが、Markdownで書いた役割プロンプトで動くのも同じ発想です。一方Fuguでは、内部で各モデルにどんな指示が渡っているかは提供側が握るため、利用者がそのプロンプトを直接書き換えることはできません。モデルの選択だけでなくプロンプトのレベルまで握って挙動を作り込みたいなら、自前構築の自由度が効いてきます。
コストの内訳を完全に把握したい運用も自前向きです。前章で触れた通り、各APIの実消費が直接見えるため、どこに無駄があるかを数字で詰められます。予算管理が厳しいプロジェクトや、コスト最適化自体が腕の見せ所になる現場では、この透明性が武器になります。
クラウドで使うか自前で組むかという論点は、個別のモデル単位でも判断材料になります。たとえば特定のモデルをクラウドAPI経由で使うか手元で動かすかを料金とコーディング精度で比べた検討は、GLM-5.2をクラウドで使うべきかといった記事でも、Claude・Codexを含めた料金とコーディング精度の観点で整理しています。Fuguを選ぶか自前で束ねるかを考える前段として、こうしたモデル単位の比較に目を通しておくと判断の軸が定まりやすくなります。
一方で、判断を誤りやすい境界もあります。タスクが単一で、扱うモデルも1つで足りるなら、そもそもオーケストレーション自体が不要です。複数AIを束ねる仕組みは、複数のモデルを使い分ける必然があって初めて意味を持つ。小規模・単一用途のうちは、Fuguも自前構築も過剰投資になりかねません。まず単体モデルで回し、限界が見えてから協調を検討する——この順番のほうが、無駄な複雑さを抱えずに済みます。
導入前に押さえる注意点と未公表な情報
ここまでFuguの仕組みと損得を見てきましたが、導入を判断する前に、はっきりさせておきたい前提がいくつかあります。新しく提供が始まったばかりの製品ということもあり、公式が数値を出していない領域が残っている点を、正直に押さえておきましょう。
公式が明らかにしていない点の整理
執筆時点でも、公式が詳細を公開していない領域は残ります。料金そのものは公式の料金ページに掲載されていますが（更新されうるので、確定値は使う直前に確認するのが安全）、むしろ開示が限られるのは、次に挙げる内部構成のほうです。
次に、内部で使われるモデルプールの正確な一覧と、ルーティングを担うモデルの厳密なパラメータ。Fuguが「複数のフロンティアモデルを束ねる」ことは公式が説明していますが、その時点でどのモデルがどんな役割で組み込まれているかは、限定的な開示にとどまる場合があります。プールが差し替え可能な設計である以上、ある時点のモデル構成を固定的な事実として扱わないほうが無難です。
ベンチマークの評価についても注意が要ります。性能に関する数値や比較は、提供元であるSakana AIが示したものであり、第三者による独立検証とは性質が異なります。「公式の比較では高い水準」という事実は、そのまま「どんなタスクでも優れている」という一般化にはなりません。自分の用途で実際に試し、手元のタスクで使えるかを確かめる工程は省けない、と考えておくのが現実的です。
最後に、OpenAI互換APIという点。互換とはいえ、既存のコードをそのまま繋ぎ替えるだけで挙動まで完全に一致するとは限りません。モデルの応答の傾向や、エラー時の振る舞いには差が出ることがあります。移行する際は、互換性に頼り切らず、主要なケースで実際に動かして検証するコストを見込んでおいてください。
- 提供元
- Sakana AI（日本のAI企業）
- 種別
- 複数AIを束ねるオーケストレーション基盤
- API
- OpenAI互換
- バリアント
- Fugu（低レイテンシ）／ Fugu Ultra（高品質・多段推論）
- 課金体系
- サブスク（Standard $20／Pro $100／Max $200・月額）＋従量（複数モデルが関与しても最上位モデルの単一レート、Fugu Ultraは入力$5／出力$30 per 100万トークン）。2026年6月時点・公式料金ページ
- 提供開始
- 2026年6月22日（一般提供開始）
まとめ
Sakana Fuguは、複数のAIモデルを束ねて1つのモデルのように振る舞わせる、マネージドなオーケストレーション基盤です。利用者は1つのAPIに投げるだけで、内部のモデル選択・委譲・検証・統合を任せられる。手間のかかる協調の設計を提供側が引き受けてくれるのが最大の利点でした。
その裏返しとして、中身は見えにくくなります。どのモデルがどう呼ばれ、トークンを何回消費したかは内部に隠れる。逆に自前でClaudeやCodexを束ねれば、構築と保守の手間を負うかわりに、ルーティングもコストの内訳もすべて手元に残ります。選択の本質は「制御と透明性を取るか、構築と保守からの解放を取るか」という線引きにある、というのが本記事を通して見えてきた構図です。
トークンコストは、どちらを選んでも単体モデルより増えやすい構造を持ちます。委譲・検証・統合の各段で消費が積み上がるからで、Fuguはそれを料金プランに織り込み、自前は明細として見せる。見え方が違うだけで、総消費を見積もる必要があることは共通です。
まず試すなら、扱うタスクが本当に複数モデルの協調を必要としているかを確認するところから始めると、過剰投資を避けやすくなります。単一モデルで足りるうちは、FuguもDIYも見送ってよい。複数AIを使い分ける必然が出てきた段階で、本番投入の速さを買うか、制御とコスト可視性を握るかを、自分の体制に照らして決めるのが現実的な進め方です。料金やモデル構成は変動しうるため、導入を決める前に公式の最新情報で裏を取ってください。
よくある質問
Q. Sakana Fuguの料金はいくらですか？
公式の料金ページに公開されています（2026年6月時点）。サブスクはStandard $20／Pro $100／Max $200の月額。従量は複数モデルが関与しても料金を重ねず、関わった最上位モデルの単一レートで課金され、上位版Fugu Ultraは入力$5／出力$30（100万トークンあたり、コンテキスト272K超で$10／$45）です。料金は更新されうるため、導入前に公式の最新を確認してください。
Q. FuguはどのAIモデルを束ねているのですか？
複数のフロンティアモデルをプールとして持ち、タスクに応じて使い分ける設計だとSakana AI公式は説明しています。プールは差し替え可能な方針のため、ある時点の構成を固定的な事実として捉えず、公式の開示範囲で把握するのが安全です。
Q. CodexやOpenAI向けのコードでそのまま使えますか？
FuguはOpenAI互換のAPIを提供しているため、既存のSDKやツールにエンドポイントとモデル名を差し替える形で組み込めます。ただし互換であっても応答の傾向やエラー時の挙動に差が出ることがあるため、移行時は主要なケースで実際に動かして検証してください。
Q. 自分でマルチエージェントを組むのと何が違いますか？
Fuguはモデルの選択・委譲・検証・統合を内部で完結させるマネージド型で、構築と保守の手間が小さい反面、中身は見えにくくなります。自前構築はルーティングやコストの内訳をすべて自分で握れますが、設計と運用の負担を引き受けることになります。
Q. FuguとFugu Ultraはどう選び分けますか？
低レイテンシで日常的な処理やコーディング、チャット用途に向くのがFugu。難しい多段の推論や研究・分析など高い品質が要る場面に向くのがFugu Ultraです。まずFuguで試し、品質が足りない場面でUltraを検討する順番が無駄を抑えやすくなります。
