Sakana Fugu とは：AI 競争は単一モデルからモデル orchestration へ移る

Sakana Fugu は、複数モデルの orchestration を OpenAI 互換 API として提供し、ルーティング、コスト、透明性、ベンダー依存を問い直す。

Buda Team
← ブログに戻る
Sakana Fugu とは：AI 競争は単一モデルからモデル orchestration へ移る

Sakana Fugu は、単なる新モデル発表ではない。

AI インフラがどこへ向かうのかを示すシグナルだ。

6 月 22 日、Sakana AI は Sakana Fugu を発表した。説明は明確だ。単一のモデル API のように使える multi-agent orchestration system。開発者は一つのリクエストを送るだけでよい。内部では、Fugu が直接答えるか、専門モデルのプールにサブタスクを委任するか、中間結果を検証するか、最終結果を統合するかを判断する。

難しい多段階タスク向けには Fugu Ultra も用意された。どちらも OpenAI-compatible API から利用できる。

これは、企業 AI の問いが変わっているから重要だ。

この 2 年、市場は「どのモデルが一番強いか」を問い続けてきた。

Fugu が問うのは別のことだ。単一モデルが足りない、コストが高い、使えない、または長期依存に向かないとき、誰がモデル群を調整するのか。

Sakana Fugu とは

Sakana は Fugu を、単一モデルのように振る舞う multi-agent system と説明している。外から見ると一つの endpoint を呼ぶだけ。内部では、モデル選択、委任、検証、統合が行われる。

ローンチページの表現は “one model to command them all”。重要なのは、Fugu がすべての frontier models を置き換えるという話ではない。どのモデルをいつ使うか、いつ委任するか、複数の結果をどう一つの答えにまとめるかを学習するという話だ。

Sakana によれば、Fugu 自体も言語モデルであり、agent pool 内のさまざまな LLM を呼び出すよう訓練されている。自分自身を再帰的に呼び出すこともある。研究の背景には TRINITY や Conductor のような learned orchestration がある。

これは通常の model router とは違う。

通常の router は、一つのリクエストに対して一つのモデルを選ぶ。

Fugu は conductor に近い。タスクを分け、複数の Agent を使い、結果を検証し、一つの答えを返す可能性がある。

Sakana Fugu turns one request into model selection, delegation, verification, and synthesis

なぜタイミングが重要なのか

タイミングも重要だ。

Sakana は発表の中で single-vendor dependency と、Anthropic Fable / Mythos のアクセス変化に伴うリスクに触れている。VentureBeat も同じ背景でこのローンチを捉えている。規制、輸出管理、価格、ポリシー、プロバイダー判断によってトップモデルへのアクセスが急に変わるなら、重要な workflow を一社のモデルに永遠に依存させるべきではない。

これはクラウド時代の教訓が AI に戻ってきたということだ。

企業はすでに、一つのサーバー、一つの region、一つの vendor だけを継続計画にする危険を学んだ。

AI も同じ段階に入っている。

一つの workflow が単一モデルに依存すると、そのモデルの価格、rate limit、ポリシー変更、地域制限、障害、品質変動、ロードマップをすべて引き受けることになる。

簡単なタスクなら問題ないかもしれない。

重要な業務では、これはサプライチェーンリスクになる。

Model routing と orchestration は違う

Model routing はすでに馴染みがある。

簡単な質問は安いモデルへ。コードはコード向けモデルへ。長文書は長コンテキストモデルへ。難しい推論は高性能モデルへ。

これは有用だが、多くの場合は一度の選択にすぎない。

Orchestration はもっと広い。システムがどうタスクを分解し、専門家を協調させ、検証し、失敗後にリトライし、最終回答に十分な証拠をどう判断するかを扱う。

現実の Agent workflow には、次のような要素が入る。

  • planner がタスクを分解する;
  • coding model が実装や草案を書く;
  • verifier がロジックを確認する;
  • tool や test environment を実行する;
  • summarizer が結果をまとめる;
  • 重要な操作の前に human review checkpoint を置く。

Fugu の商業的な動きは、この複雑さの多くを一つの API の後ろに隠すことだ。

開発者にとっては魅力的だ。

同時に、ガバナンス上の問いでもある。

注意点も製品の一部

Fugu の強みとリスクはつながっている。

第一に、見える複雑さは減るが、routing は完全には透明ではない。Sakana は、具体的な worker models と coordination pattern は proprietary だとしている。製品 IP としては理解できるが、規制の強いチームは、どのモデルがどのデータを見たのか、エラー時にどう監査するのかを確認したくなる。

第二に、orchestration は結果を改善するかもしれないが、コストを見えにくくすることもある。Fugu Ultra には公開価格があり、VentureBeat は orchestration tokens も最終 usage に含まれる可能性があると指摘している。短い回答でも、内部では長いチェーンが走っているかもしれない。

第三に、benchmark は有望だが、調達判断そのものではない。Sakana の数値は coding、reasoning、science、agentic tasks で良い初期シグナルになる。しかしチームは、自分たちの repo、文書、権限、失敗パターン、レイテンシ目標、コスト制約で検証する必要がある。

Single-model dependency becomes an AI supply-chain risk

チームが Fugu から学ぶべきこと

安全な結論は「Fugu が勝った」ではない。

より安全な結論は、単一モデル依存が守りにくくなっているということだ。

チームは AI system を五つの層で評価し始めるべきだ。

  1. Model quality どのモデルがどの仕事に十分か。

  2. Model replaceability 価格、アクセス、レイテンシ、ポリシー、品質が変わったとき workflow は続くか。

  3. Orchestration visibility どのようにルーティングされ、どのツールが使われ、どこで失敗したかを確認できるか。

  4. Cost per completed task リトライや人間の手戻りを本当に減らしているのか。それとも token spend を隠しているだけか。

  5. Human review どこで人が承認、却下、方向修正すべきか。

ここから AI インフラは運用の問題になる。

資産はモデルだけではない。

モデルの周りにある workflow こそが資産になる。

Buda との関係

Buda は、この変化のために作られている。

AI Agent Workspace は、チームを一つのモデル identity に閉じ込めるべきではない。チーム自身の文脈、手順、skills、承認、logs、review の習慣を、モデルが変わっても保つべきだ。

だから Buda は work layer に注目する。sessions、Drive、tools、browser と terminal execution、channels、skills、human review。

モデルは置き換えられる。

しかし、構造化され、review され、改善されてきた workflow は、下のモデルが変わっても消えるべきではない。

Fugu はモデル側から同じ方向を示している。Orchestration が重要になる。

Buda は workspace 側からもう半分を示している。Orchestration は見える必要があり、管理できる必要があり、人間が主導する必要がある。

次の AI 競争は、最強モデルを誰が訓練するかだけではない。

多くのモデル、ツール、Agent、人間をどう安定した仕事へ変えるかの競争になる。

Sakana Fugu に関するよくある質問

Sakana Fugu とは何ですか？ Sakana Fugu は、OpenAI 互換 API から利用できる multi-agent orchestration model です。開発者からは一つのモデルに見えますが、内部では複数のモデルや Agent を協調させることができます。

Multi-model orchestration と model routing は何が違いますか？ Model routing は通常、一つの依頼に一つのモデルを選びます。Multi-model orchestration は、作業を分解し、サブタスクを委任し、中間結果を検証し、必要なら再試行し、最後に答えを統合します。

企業が一つの大規模モデルだけに依存すべきでない理由は？ 単一モデルへの依存は、一つの provider の価格、policy、地域アクセス、rate limit、障害、品質変動をそのまま引き受けることになります。重要な workflow では、これは AI supply-chain risk になります。

Model orchestration は AI application infrastructure になりますか？ 複雑な仕事では、その可能性が高いです。複数の models、tools、Agents、review steps を使うほど、orchestration layer が reliability、cost、governance を管理する場所になります。

Buda dashboard で人間主導の Agent workflow を試すか、Buda Agent Workspace ドキュメント を読む。