@moritaoy(oy morita)

Sakana Fugu について、情報を集めて解説してみた

Posted at 2026-06-29

前提

筆者は、ゲームのモック作成や市場調査、資料の分析とレビューなど、複数の用途でSakana Fuguを使ってみました。
そして、使えば使うほど、これってどういうプロダクトなんだっけ？という疑問が湧いてきます。

勉強がてら、論文や公式の発表などを参考に情報をまとめてみました。

間違った解釈・情報があるかもしれません。
もし見つけられた際は、ご指摘いただけますと幸いです。

Sakana Fugu とは何か

2026年6月22日に、Sakana AIが「Sakana Fugu」をリリースしました。
このプロダクトは、主に以下の２種類の要素で構成されています。

独自のオーケストレーション用言語モデル
２種類のプロダクト「Fugu」「Fugu Ultra」

Sakana Fuguを理解するためには、まずオーケストレーション用言語モデルについて理解する必要があります。

独自のオーケストレーション用言語モデル

「Sakana Fugu」という名称は、サービスのシステム全体、あるいは、このオーケストレーションを行う言語モデルそのものを指します。
そして、この言語モデルは、いわゆる「Claude Opus」「Gemini」「GPT」などのフロンティアモデルとは全くもって違う性質のものです。

Sakana Fuguは2つのモデルをベースとして構築されている、とSakana AIは発表しています。

TRINITY

約6億（0.6B）パラメータの小型言語モデル（SLM）と、1万パラメータ未満の超軽量なルーティングヘッドを組み合わせた進化型コーディネーター。
タスクを分解し、モデルプールから最適なLLMを選んで

「Thinker（思考役：戦略を練る）」
「Worker（実行役：タスクをこなす）」
「Verifier（検証役：結果をチェックする）」

の3つの役割を動的に割り当てて協調させる。

Conductor

強化学習（RL）によって訓練された70億（7B）パラメータのモデル。
自然言語による協調戦略を自ら見つけ出し、エージェント間のコミュニケーション方法や、各モデルに与える的確な指示（プロンプト）を設計する。
また、自分自身を呼び出して過去の出力を読み返し、誤りがあれば自律的に修正のワークフローを立ち上げる「再帰的テスト時スケーリング」の能力も備えている。

※詳細は、末尾の参考資料内の論文をご確認ください

どちらも「ほかのLLMを呼び出して、統率すること」を目的に学習された言語モデルです。
より適切に複数のエージェントを協調させてタスクを遂行させることを目的にしています。
パラメータのサイズも、フロンティアモデルに比べれば非常に軽量です。
※一般的にフロンティアモデルは、数千億～数兆パラメータを持つとされています

重要なポイントとして、基本的にこれらのモデルは調査や検証、実装を請け負うことはありません。
あくまで、タスクを分析し、適切なLLMを選択してタスクをこなさせること。複数のエージェントを適切に協調させること。
これらを実現するために存在する言語モデルです。

これから説明する「Fugu」「Fugu-Ultra」を理解するうえで、コアとなるオーケストレーション用言語モデルについて、実作業を遂行する能力はほぼ無いことを理解しておくことが重要です。
非情に軽量な作業、例えば自身について説明させる場合などは、オーケストレーション用言語モデルが返答することはあれど、具体的な処理は、すべてルーティングした先のフロンティアモデル（Opus、Gemini、GPTなど）が実行することになります。

Sakana AIが開発した言語モデルは、あくまで複数モデルのオーケストレーションを実現するものである、という点について、理解してもらえればと思います。
ただし、低レベルな処理しかできない訳ではありません。
後述しますが、ConductorをベースとしたFugu-Ultraでは、特に高度なタスク分解やオーケストレーション戦略の構築などを行っています。

なお、このように複数の異なるAIモデルを協調させるアーキテクチャを Mixture-of-Agents、MoAと呼びます。

「Fugu」と「Fugu Ultra」について

先ほど説明した、TRINITYやConductorといった基盤技術を用いて開発されたのが「Sakana Fugu」というプロダクトです。
複数の強力なフロンティアモデルを、適切にオーケストレーションすることで、単一のモデルを使用したとき以上の性能を発揮することが出来ます。

このプロダクトでは、２種類のモデルが用意されています。

Fugu

高い性能と低レイテンシのバランスに優れ、日常的な業務のデフォルトとして最適なモデルです。
[引用]

応答速度を最優先に設計されたモデルです。
先述したTRINITYのアーキテクチャを実用向けに最適化したモデルが、オーケストレーションに使用されています。Conductorに比べて、より軽量なほうですね。
論文のTRINITYに比べて最適化した箇所として、応答速度を優先するため、役割（Thinkerなど）を指定せず、選択したモデルを「Worker」として直接呼び出しています。
役割割り当ての処理をなくすことで、オーケストレーションのオーバーヘッドを減らしているとのことです。

基本的に、1つの作業につき単一のモデルを使用します。複数のモデルを並列で走らせて、協調させることはありません。
Technical Reportによると、具体的には以下のような挙動をするとのことです。

ビルドの作業をGPTが実施した
環境でmerge conflictが発生した
Fuguは作業をOpusに切り替えた
Opusはマージを解決した

このように、作業自体は直列に単一のモデルが請け負いますが、ケースに応じて適切にFuguが使用するモデルを切り替えていることがわかります。

Fugu Ultra

困難な多段階の問題に対する回答品質を最大化するよう調整されており、精度と深さが最も重要な場面では、より厚みのある専門エージェント群を連携させます。
[引用]

より複雑なタスクに対応するよう設計されたモデルです。
こちらは、Conductorのアーキテクチャをベースにしており、課題解決を複数のステップで計画し、複数のモデルを同時に動かして議論や検証を行わせます。
Fuguに比べて、より高度なオーケストレーションを行っていると言えるでしょう。

オーケストレーション方法や、課題解決のワークフローは複雑、かつ多岐にわたります。
同じくTechnical Reportの中で上げられている、具体的な挙動を紹介します。

PyPIサーバー構築と脆弱性チェック
（ベンチマーク Terminal Bench 2.1による課題）

まずGPT-5.5を投入してサーバーを構築した
ビルド完了後、Opusをデプロイして、GPTの実装のリスクを列挙した
調査結果をGPTにフィードバックして、GPTはビルドを正常に完了できた

Heroes of Might & Magic III の特定のゲーム状態の結果を判定する
（ベンチマーク Humanity's Last Exam による課題。超難問）
ゲームメカニクスに関する知識と応用力を、正確な雑学を交えて問う問題、らしいです。

２つの独立した推論を合成するような、木構造を生成した
- つまり根と、そこから２つの葉が生えているような構造
アグリゲーター（情報を集約するモデル、つまり根ノードに該当する）としてGeminiを使用した
推論するモデルとしては、GPTとGeminiを使用した
- GPTはゲームメカニクスのルールを間違えた
- Geminiは基本防御力のルールを間違えた
だが、アグリゲーターのGeminiがそれぞれの正しい部分を識別し、完全に正しい回答を合成した

他にも、Opusが問題の把握と修正案の提示を行った際に行き詰ってしまうと、Fugu-UltraがGPTを白紙の状態で呼び出して問題を再検討させた例なども紹介されています。

例からもわかるように、タスクに応じて様々なワークフローを自律的に構築していることがわかります。
Fuguよりもより高度なオーケストレーションを行っていることもわかりました。

そして、勘のいい方なら、処理時間や、トークン消費量が不安になってくるかと思います。
ここからは、筆者が実際に使ってみた感想をあっさりお伝えします。

筆者の感想

ここからは、筆者の感想です。
主にFugu Ultraを使用してきました。

タスクの遂行力については非常に高いと思います。結果だけ見れば、満足のいくものを一発で出してくれます。

ただ、処理速度とトークン効率、タイパとコスパについては難があると感じます。
先ほどの仕組みを理解すれば納得かと思いますが、如何せん遅いです。

また、Context Sizeが272kを超えると料金がほぼ倍になります。

トークン種別	通常価格	コンテキスト > 272K
入力	$5	$10
出力	$30	$45
キャッシュ済み入力	$0.50	$1.00

[引用]

ただでさえトークン量が嵩むので、1Mの枠でモデルを使用するのは使用制限枠的に厳しいです。
なので、小さなContext Sizeで作業を任せなければいけません。

コーディングにおいては、これが致命的に辛いです。Fugu-Ultraはコンテキストの消費も激しいです。大きすぎるタスクでは、コンテキストの上限を食い尽くし、コンテキスト圧縮も限界を迎え、作業が行き詰るようなケースが何度か見られました。そして、Fugu-Ultraは諦めが悪いので、行き詰ったままトークン消費だけを食い続ける...

ならば、それなりの規模のタスクに抑えるか。そうなると、Fugu-Ultraのコスパ、タイパの悪さが如実に表れます。Opusでいいじゃん、GPTでいいじゃん、となってしまうわけです。

1Mのコンテキストサイズを気軽に使えないのは、このご時世、かつ大規模な課題解決を実現できることを主張しているプロダクトでは非常に厳しいです。

Fugu-Ultraはコーディングに気軽に使えるプロダクトでないことは確かです。
おそらくは、アカデミックな研究や多角的な分析など、そういった用途で使用するのが正しいプロダクトなのでしょう。

是非記事の内容を参考にしていただいて、身近でこのケースなら輝くかも！という用途があれば、試していただければと思います。

筆者はUltraではない、Fuguの方をもうちょっと検証してみようと思います。

主に参考にした公式サイト・論文

https://sakana.ai/fugu-release/
https://sakana.ai/fugu-beta/
https://sakana.ai/fugu/
TRINITY：進化型LLMコーディネーター
 Conductor による自然言語でのエージェント統率の学習
 Sakana Fugu Technical Report

参考サイト

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up