Sakana AIはエージェント時代を踏まえ、どのような考えのもと、製品を設計しているのだろうか。
2026年10月30日、Google Cloudが開催した「Agentic AI Summit '26 Fal」の基調講演では、「From Model to Orchestration」(モデルからオーケストレーションへ)と題した講演が行われた。
そこではSakana AIのChief ScientistであるYujin Tang(湯聿津)氏が登壇し、オーケストレーションシステム「Sakana Fugu」を例に、製品の設計について解説している。
群れの中の赤い魚という理念
講演はまず、同社のロゴの説明から始まる。魚の群れの中に赤い魚が1匹いるこのロゴには、少なくとも2つの意味が込められているという。
1つは、周囲とは異なる考え方をして革新的であろうとする姿勢だ。もう1つは、市場に数多く存在する技術やモデル、エージェントの違いをうまく活かし、集合知として製品をより強力にするという考え方である。この2つ目の発想が、今回紹介されたSakana Fuguの土台になっている。
モデルではなくオーケストレーションシステム
Yujin氏は、Sakana Fuguが単一のモデルではなくオーケストレーションシステムであることを強調した。Gemini、ChatGPT、Claudeといった強力なエージェントのプールの上に立つ指揮者を学習させ、それらを組み合わせて多様なタスクをこなす方法を習得させる仕組みとなる。
現在は3つのプロダクトラインが用意されており、汎用的な性能を目指すFugu UltraとFugu Max、そして特化した能力を表すFugu Xだ。コストを横軸、性能を縦軸にモデルを配置すると、既存のモデルによってパレートフロンティアが形成される。
Sakana Fuguのミッションは、このフロンティアを外側へ押し広げることにある。Ultraは同社のフラッグシップとして性能を上方向に押し上げ、Maxはコスト制約の下で可能な限り高い性能を引き出すことで、境界を左上方向に広げる。Fugu Xの例としては、今年初めにサイバーセキュリティに特化したFugu Cyberがリリースされた。
ベンチマークと実運用での成果
性能面では、約2カ月前にリリースされたFugu Ultra V2が最先端のモデルを上回り、一部のベンチマークではAstraやFableといったモデルと肩を並べたという。注目すべきは、V2の開発時点ではプールにFableシリーズもAstraも含まれていなかった点だ。
Fugu Max V1も、ほとんどのベンチマークで既存モデルが形成するフロンティアの左上に位置し、より高いコスト効率で性能を発揮した。
Fugu Cyberについても、プールにGPT 5.4 CyberやMythosが入っていない状態で、レッドチーミングとブルーチーミングの両タスクでこの2つを上回ったという。
さらに講演の前夜には、新たな成果が発表された。Sakana Fuguと社内のエージェント用スキャフォールディングを組み合わせて、再帰的自己改善に関する数学コンペティションに参加し、1位を獲得したのだ。同社では、Sakana Fuguが日々の研究活動も支えているという。
単純なルーティングではない、適応的な指揮
Sakana Fuguは、昨年発表された2本のICLR論文を基にしており、技術レポートも公開されている。Yujin氏は技術的な詳細のうち、4つのポイントに絞って解説した。
1つ目は、行っているのがオーケストレーションであって単純なルーティングではないという点だ。ユーザーのクエリを次のモデルに渡して回答をそのまま返すのではなく、クエリの性質に応じて適応的に処理する。
例えば「Hello」のような簡単なクエリであれば、プールの中から安価で小さめのモデルだけを選んで回答を返す。「このコードベースをレビューして」のような複雑なクエリには、複数の強力なエージェントの連携が必要だと判断する。そして、ChatGPTなどに最初のレビューを担当させ、そのレビューをGeminiにレビューさせたうえで、結果をユーザーに返すといった動きをする。
入れ替えと拡張を支えるモデルプロファイル
2つ目のポイントは、スケーラビリティと拡張性である。Sakana Fugu自体が、他のあらゆる言語モデルの上に位置する言語モデルであるため、学習後の変化にどう対応できるのかという質問が寄せられるという。Yujin氏は3つのケースを挙げて答えた。
1つ目は、同じモデルの新バージョンがリリースされた場合だ。Sakana Fuguの構築前に、プール内の各モデルについてモデルプロファイルを作成しており、新旧のプロファイルが似ている限りオーケストレーターの再学習は不要となる。モデルを入れ替える、いわゆるホットスワップで済むため、コストを大幅に抑えられ、リリースの速度も上がる。
2つ目は、プールに含まれていないモデルを追加する場合である。この場合はオーケストレーターの再学習が必要だが、Sakana Fugu自体が小さなモデルであるため、ファインチューニングに多くの反復や計算資源を要さず、比較的素早く対応できる。
3つ目は、言語モデル以外の扱いだ。画像分類器のようなものもツールとして扱ってモデルプールに含められ、エージェントがそのツールを効率的に使えるなら、Fuguが使い方を学習するという。
モデルプロファイルが生む代替と補完
3つ目のポイントが、このモデルプロファイルの位置づけである。公開ベンチマークと社内ベンチマークを数多く用意し、それを基にすべてのモデルのプロファイルを作成している。プロファイルが非常に似ていれば、あるモデルがベンダーによってブロックされた場合などにも代替が可能だと分かる。また、一部のモデルが互いに補完的な能力を持っていることも見えてくる。
Yujin氏はこれをエージェント型システム全般にとって朗報だと述べ、それぞれの違いを活かせば、パレートフロンティアをより効率的に押し広げられると語った。
Google Cloudを基盤とした運用
4つ目のポイントは、メインのインフラとしてGoogle Cloudを採用している点である。同社は学習にかける労力をすべてGPUと、Gemini platformが提供するデータストレージに振り向けており、エージェントモデルの多くもGemini platformのModel Gardenから利用している。
研究成果を製品レベルで提供するには安定したサービス品質が欠かせない。BigQueryとダッシュボードによってシステムの健全性を効率的に監視することで、エンドユーザーに比較的良好なサービスを提供できているという。
複数のモデルが併存する市場の状況を、違いを活かす機会として捉える。その上で、プロファイルに基づく入れ替えや拡張を前提に設計する。
今回の講演では、こうした同社の発想が一貫して示されている。










