Sakana AIが新たに公開したSakana Fuguとは？注目の最新LLMを徹底解説

この記事のまとめ

Sakana Fuguは、Sakana AIが公開したマルチエージェント型のオーケストレーション基盤モデルです。1つのAPIから指示を送るだけで、処理内容に応じて複数の専門モデルを動的に組み合わせ、複雑な多段階タスクに対応します。私がこのプロダクトに注目したのは、「モデルをさらに大きくする」という従来の競争とは違う方向性を打ち出している点です。ポイントは以下のとおりです。

Sakana Fuguは単一のエンドポイントで複数のAIモデルを自動的に連携させるマルチエージェントシステムであり、日常業務向けのFuguと高負荷業務向けのFugu Ultraの2種類が提供されています。
技術面では、強化学習で訓練されたConductorがThinker・Worker・Verifierの3役割を各モデルに割り当て、再帰呼び出しによる推論時スケーリングで回答品質を高めます。
料金プランはサブスクリプション（月額20～200ドル）と企業向け従量課金の2本立てで、OpenAI互換APIにより既存環境への導入が容易です。
Fugu Ultraは主要ベンチマークで高いスコアを示す一方、オーケストレーションの深さに起因するレイテンシの大きさや、外部モデル再販に伴う利用規約上の課題も指摘されています。

Sakana Fuguの概要

Sakana Fuguは、複数のAIモデルを動的に組み合わせて処理を行うマルチエージェント型のオーケストレーションモデルです。1つのエンドポイントから指示を送ると、Sakana Fuguが処理内容に応じて単独モデルで対応するか、複数の専門モデルを連携させるかを判断し、複雑で多段階のタスクに取り組みます（参照*1）。

1回のAPI呼び出しだけでタスクの難易度に合った処理パイプラインが自動的に組み上がるため、利用者はモデルの選定や組み合わせを自分で設計する必要がありません。私がこれまで複数のAIモデルを業務で使い比べてきた経験からすると、「どのモデルをどの用途に使うか」を毎回判断する手間は想像以上に重く、それ自体がボトルネックになりやすい。その判断をシステム側に委ねられる点は、実務上の価値として見逃せません。

マルチエージェントシステムの定義

マルチエージェントシステムとは、複数のAIモデル（エージェント）を協調させ、1つのモデルだけでは難しいタスクを分業で解く仕組みを指します。Sakana Fuguの説明では、さまざまなプロバイダーから提供される大規模言語モデルがそれぞれ異なる領域に特化していることに着目し、それらの個別の専門性をまとめ上げるオーケストレーションの考え方が示されています（参照*1）。

問い合わせの種類や難易度に応じて最適なモデルへ処理を振り分ける点が、従来の単一モデル利用との大きな違いです。Sakana Fuguはこのマルチエージェントオーケストレーションの仕組みそのものを1つの基盤モデルとして提供しており、利用者側がエージェント間の通信設計やプロンプト設計を行う必要がありません。

開発元Sakana AIの背景

Sakana AIは、2023年に設立された東京拠点のAI研究開発企業です。CEOのDavid Ha氏、会長のRen Ito氏、CTOのLlion Jones氏が共同で創業しました。同社はThe AI Scientist、マルチエージェントオーケストレーション基盤モデル、日本語向けLLMであるNamazu、Darwin Gödel Machineなどの技術を手がけています（参照*2）。

Sakana Fuguは、こうした研究の延長線上に位置づけられています。同社がこれまで蓄積してきたマルチエージェント協調と進化的手法の知見を、1つの商用プロダクトに結実させたものと言えます。研究成果を商用サービスへ転換するスピードは早く、この点でも注目に値します。

登場の背景と課題

モデル巨大化路線の限界

単一モデルの巨大化だけでは、あらゆる領域で最高性能を出すことが難しいという課題があります。異なるプロバイダーの大規模言語モデルはそれぞれ異なる領域に特化しており、高コストで訓練・微調整されているという構造が指摘されています（参照*3）。

Sakana Fuguは、1つのモデルをさらに大きくする方向ではなく、すでに存在する複数の専門モデルを協調させることで全体の性能を引き上げるという、異なるアプローチでこの課題に向き合っています。私はこのアプローチを「合理的な分業」と見ています。人間の組織でも、万能な一人に頼むより、役割を分けたチームのほうが複雑な課題を解けることがある。それと同じ発想がモデル設計に持ち込まれています。

輸出規制と単一ベンダー依存リスク

単一ベンダーへの依存リスクが、Sakana Fuguの提供背景として挙げられています。具体例として、米国時間で6月12日にFable 5およびMythos 5モデルへ輸出規制が課されたことが示されました。規制や各国政策の変更によってAIモデルへのアクセス条件は変わり得るため、重要インフラや金融、行政を一社のAPIに頼って動かすことが現実的な弱点になると指摘されています（参照*1）。

Sakana Fuguは複数のモデルプロバイダーを束ねるオーケストレーション構造を採用しているため、特定のモデルが利用できなくなった場合でも、別のモデルへ処理を振り替えられる余地が生まれます。こうした柔軟性は、地政学リスクや規制変更に対する備えとして、企業や公共機関にとって無視できない検討材料です。単一ベンダーへの依存リスクは、AIに限らず私がコンサルティング現場でも繰り返し指摘してきた課題で、分散させる設計をシステム側が担ってくれるのであれば、導入側の負担は減ります。

技術的な仕組み

TRINITYの進化的コーディネーター

TRINITYは、軽量なコーディネーターを用いて複数の大規模言語モデル間の協調を制御するフレームワークです。このコーディネーターは、約6億パラメータのコンパクトな言語モデルと、約1万パラメータの軽量ヘッドで構成されています。最適化には進化的戦略が採用されており、効率的かつ適応的なタスク委任を可能にしています（参照*4）。

コーディネーター自体が非常に小さいモデルである点が特徴です。巨大なモデルをさらに別の巨大なモデルで制御するのではなく、コンパクトなモデルが「指揮者」として振る舞うことで、オーケストレーション自体の計算コストを抑えながら、各専門モデルの力を最大限引き出す設計になっています。約6億パラメータという規模は、現代のLLMとしては非常に軽量です。この軽さが実用上のコスト構造にどう影響するかは、実際の業務導入で確かめる価値があります。

Conductorの強化学習による戦略獲得

Conductorは、Sakana Fuguのオーケストレーションを司る強化学習で訓練されたモデルです。Conductorはエージェント同士の効果的な協調のための通信構造を設計するだけでなく、各大規模言語モデルの能力を最大限に活かすためのプロンプト指示も自動生成します。7Bパラメータ規模のConductorが、個々のWorkerモデル単体を上回る大幅な性能向上を達成したことが報告されています（参照*3）。

Conductorは、どのモデルにどの処理を振るか、どのような指示文を渡すかといった設計プロセス自体を強化学習で自動化しているため、タスクごとに最適な連携パターンを自律的に発見できます。ここで重要なのは、「プロンプト設計をAI自身が行う」という点です。私自身、日々プロンプトの設計と改善を繰り返していますが、このプロセスをConductorが肩代わりしてくれるなら、利用者側の負担は大きく下がります。

Thinker・Worker・Verifierの役割分担

TRINITYは複数ターンにわたってクエリを処理し、各ステップで利用可能なモデルプールの中から1つのモデルに3つの役割のいずれかを割り当てます。Thinkerは高レベルの戦略立案と現状分析を担い、Workerは具体的な問題解決のステップを実行し、Verifierは現在の解が完全かつ正確かどうかを評価します（参照*5）。

この3つの役割が分離されていることで、「考える」「実行する」「検証する」というプロセスが明確に切り分けられます。たとえばWorkerが出した回答をVerifierが検証し、不十分であればThinkerが戦略を修正するといった反復的な改善が、モデル間の協調として自然に行われます。

再帰呼び出しとテスト時スケーリング

Fugu自身がエージェントプールの中に再帰的に含まれる点は、Sakana Fuguの特徴的な設計の1つです。ConductorはWorkerとしてFugu自身を呼び出すことができ、この再帰的な呼び出しは「推論時の計算量を増やすことで品質を上げる新しい軸」、すなわち再帰的テスト時スケーリングとして説明されています（参照*6）。

再帰呼び出しの仕組みでは、推論時に計算量を動的に増減させることが可能です。難しい問題には深い再帰で計算量を費やし、簡単な問題には浅い処理で素早く答えるといった柔軟な振る舞いが実現されています。

FuguとFugu Ultraの比較

用途・レイテンシの違い

Sakana Fuguは用途に応じて2つのモデルを提供しています。Fuguはコーディングやコードレビュー、チャットボットなどの日常的な業務向けであり、Fugu Ultraはデータ分析、論文の再現、サイバーセキュリティ分析、文献・特許調査といった高負荷な業務向けです（参照*1）。

Fugu Ultraは困難な多段階の問題に対して回答品質を最大化するよう調整されており、より深い専門エージェントのプールを連携させます（参照*7）。用途によって両モデルを使い分けることが想定されており、速度を優先する場面ではFugu、精度や深さが求められる場面ではFugu Ultraが適しています。私の経験上、ツールの使い分け判断を現場に委ねると導入が止まりがちです。あらかじめ「このタスクはFugu、このタスクはFugu Ultra」と社内で定義しておくことを勧めます。

オーケストレーション深度の差

Fugu Ultraは、軽い質問でも裏側で約12,444トークン分のオーケストレーションを実行し、応答返却に108秒を要したという報告があります。一方、Fugu単体ではオーケストレーションをほとんど実行しないとされています（参照*8）。

この差は、両モデルの設計思想の違いを明確に示しています。Fuguは必要最小限のオーケストレーションで素早く応答する設計であり、Fugu Ultraはたとえ簡単に見える質問でも深い検証プロセスを走らせる設計です。したがって、レイテンシに敏感な用途でFugu Ultraを選ぶ場合は、応答時間が大幅に延びる可能性を前提として設計する必要があります。「高性能モデルを入れれば速くて賢い」という期待は、この種のオーケストレーション型システムには当てはまりません。

ベンチマーク性能と実タスク評価

主要ベンチマークのスコア比較

Sakana Fuguの性能は複数のベンチマークで検証されています。Fugu UltraはSWE Bench Proで73.7、TerminalBench 2.1で82.1というスコアを記録し、大半のベンチマークでトップの成績を収めています（参照*9）。

また、TRINITYはLiveCodeBench（2025年1月～4月分）において、pass@1で86.2 ± 0.5%を達成し、新たな最高水準を記録しました（参照*4）。さらにFugu Ultraは、最良の平均bits-per-byte（BPB）として0.9774 ± 0.0019を達成し、比較対象のModel C（0.9781）、Model B（0.9793）、Model A（0.9822）を上回りました。最良の単一実行では0.9748に到達し、すべてのベースラインを超えています（参照*6）。

コード生成・エージェント実験の実績

Sakana Fuguは学術的ベンチマークだけでなく、実務に近いタスクでも評価されています。同一の50週間パイプラインを5回実行した投資ポートフォリオ実験では、Fugu Ultraがポートフォリオを11,943.22 ± 633.86ドルまで成長させ、平均リターンは+19.43%に達しました。一方、比較対象となった他のフロンティアモデルのリターンはいずれも+15%未満にとどまっています（参照*6）。

この結果は、Sakana Fuguのマルチエージェントオーケストレーションが、定型的な問題回答だけでなく、時系列データの分析や意思決定を伴う複合的なタスクにおいても有効に機能し得ることを示唆しています。ただし、投資実験のリターンは実行ごとにばらつきがある点には留意が必要です。私がAIを業務評価するときに常に確認するのは、「1回うまくいったのか、繰り返しうまくいくのか」という点です。ベンチマークや実験結果を見る際は、単発の好成績より再現性のある数字を重視すべきです。

料金体系とAPI導入手順

サブスクリプションと従量課金の構成

Sakana Fuguの料金プランは、個人ユーザー向けのサブスクリプションと、エンタープライズ向けの従量課金（トークンプラン）の2種類で構成されています。サブスクリプションにはStandard（月額20ドル）、Pro（月額100ドル）、Max（月額200ドル）の3つのプランがあり、いずれもFuguとFugu Ultraの両方を利用できます（参照*1）。

日常的な業務にはStandardプランで始め、利用量や精度の要件に応じてPro・Maxへ引き上げるという段階的な導入が考えられます。一方、大量のAPI呼び出しが発生するシステム組み込みでは、使った分だけ支払う従量課金プランが選択肢となります。私が企業のAI導入支援で繰り返し伝えているのは、「最初から上位プランを契約するな」ということです。まず小さな業務で試し、効果と使用量の実態を把握してから拡張する順序が現実的です。

OpenAI互換APIでの接続方法

Sakana FuguはOpenAI互換APIとして提供されているため、openai Python SDKをそのまま利用できます。既存のコードに対してbase_urlを1行差し替えるだけで接続が可能です（参照*8）。

FuguとFugu Ultraはいずれも単一のAPIを通じて利用でき、一般提供が開始されています（参照*7）。OpenAI互換という設計により、すでにOpenAIのAPIを使ったアプリケーションを運用している場合、大幅なコード変更なしにSakana Fuguへの切り替えや並行利用を試すことができます。既存環境への接続コストが低い点は、実際に試す際の心理的ハードルを大きく下げます。まず小規模なタスクで動かし、レイテンシと出力品質を自分の業務文脈で確かめることを勧めます。

導入時の注意点

レイテンシの振れ幅と枠消費

Fugu Ultraは、オーケストレーションの深さによってレイテンシが大きく変わる点に注意が必要です。実際の検証では、Fugu Ultraが裏側で26,404トークン分（出力本体の8.8倍）のオーケストレーションを実行し、応答に269秒、つまり約4.5分を要したケースが報告されています。このとき、Fugu単体では55秒でほぼ同等のコードを返しています（参照*8）。

オーケストレーションの深さはタスクの内容によって変動するため、レイテンシが一定にならない点を前提としたシステム設計が求められます。リアルタイム応答が必要なアプリケーションでFugu Ultraを使う場合は、タイムアウト設定やフォールバック処理の検討が欠かせません。私がAI導入支援で見てきた失敗の多くは、「デモでは速かったのに本番で使えない」というものです。検証段階で最悪ケースのレイテンシを意図的に引き出し、それでもシステムが成立するかを確認してから採用可否を判断すべきです。

利用規約・地域制限・ベンチマーク留保

複数の外部プロバイダーのモデルをオーケストレーションして再販する構造は、Sakana Fuguの特性として挙げられています。この構造は各プロバイダーの利用規約との兼ね合いという問題をはらんでおり、これはSakana AIだけでなく、採用する側の企業も引き継ぐ課題であると指摘されています（参照*10）。

また、FuguがFable 5やMythos Previewと同等と主張している一方、これらのモデルはFuguのエージェントプールには含まれていません。あくまで「同等の代替手段がある」という主張であり、これらモデルの出力を直接使っているわけではない点を正確に理解しておく必要があります（参照*10）。導入を検討する際は、自社の利用規約やコンプライアンス要件との適合を法務・情報システム部門と事前に確認することを強く勧めます。ベンダーの説明だけを信じて進めると、後から「あのモデルの利用規約に違反していた」という事態が起きかねません。

おわりに

Sakana Fuguは、複数の専門モデルを1つのAPIで自動的に束ねるマルチエージェントオーケストレーションという新しい方向性を示しました。単一モデルの巨大化とは異なるアプローチで性能向上を図り、単一ベンダーへの依存リスクにも対応し得る構造を持っています。私はこのアーキテクチャの考え方自体が、今後のLLM活用の一つの標準になり得ると見ています。「どのモデルが一番賢いか」ではなく、「複数のモデルをどう組み合わせるか」という問いへの移行が、すでに始まっています。

一方で、Fugu Ultraのレイテンシや外部モデル再販に伴う利用規約上の課題など、導入前に確認すべき点も残っています。ベンチマーク上のスコアだけを見て採用を決めるのではなく、自社の業務要件、レイテンシ許容範囲、コンプライアンス条件と照らし合わせながら検討してください。まずは小さなタスクで動かし、出力品質と応答時間の実態を自分の手で確かめることが、結局は一番早い判断材料になります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））