【お断り】本記事は、公開された技術レポートと第三者の実測報告をもとにした筆者の主観的なレビューです。 評価には筆者の主観が含まれます。最終的な判断は、ご自身のワークロードでの実測に基づいて行ってください。
「フロンティアモデルを1つも訓練せずに、Fable 5に並んだ」
このフレーズだけ見ると、出来すぎている。
2026年6月、東京のSakana AIが Fugu と Fugu Ultra を公開した。自前の巨大モデルを訓練せず、既存のフロンティアモデル（GPT-5.5、Claude Opus 4.8、Gemini 3.1 Pro）をオーケストレーションすることで、AnthropicのFable 5やMythos Previewと肩を並べるベンチマークを叩き出した、と。
魅力的な物語だ。だが、この記事ではその物語を一度わきに置く。ベンチマークの数字と、実際に使ったときの体感は一致するのか。 公開された技術レポートと、第三者の実測報告だけを根拠に検証する。
結論から言うと
- ベンチマークは本物。SWE-Bench Pro 73.7、GPQA Diamond 95.5など、単体モデルを上回る数字が技術レポートに記載されている
- だが実用は別物。複数の独立テスターが「Fableほどの実力は実使用では感じない」「GPT-5.5より明確に悪かった」と報告
- 隠れたコスト：1リクエストで3〜5モデルに展開するため、トークン消費が直接呼び出しの4〜6倍になる
- 構造的な皮肉：「Fable 5に並ぶ」と言いながら、Fable 5は輸出規制でエージェントプールに入れられない。性能は他社モデルの提供状況に丸ごと依存する
- レポート自身が認める弱点：レイテンシ・コストの定量データなし、ベースラインはベンダー自己申告、日本語タスクは25ページのみ
これは「ダメな製品」という話ではない。オーケストレーションという方向性は研究として重要だ。ただし「今すぐ日常のメインモデルに据えられるか」と問われれば、現時点の証拠は「ノー」を指している。
Fugu Ultraとは何か（誇張なしの説明）
Fugu Ultraは、単体のLLMではない。**他のモデルを呼び出す小さな調整役（コーディネーター）**だ。技術レポートによると、構造は2系統ある。
Fugu（レイテンシ重視）
- 事前学習済みモデルの上に「軽量な選択ヘッド」を載せる
- 最終隠れ層の後段で、どのワーカーモデルに振るかをロジットで判定
- 自己回帰デコードを待たず、早い段階の隠れ状態で即ディスパッチ
- 1クエリにつきワーカーは1つ
- 学習は特異値ファインチューニング＋進化的最適化（sep-CMA-ES）
Fugu Ultra（性能重視）
- 「Conductor」フレームワーク上で強化学習（GRPO）
- サブタスク・担当ワーカー・通信戦略を自然言語のワークフローとして出力
- 最大5ステップ、木構造のトポロジー
- 「orchestration collapse（調整破綻）」を防ぐためのエージェント分離
- 複数ターンをまたぐ永続共有メモリ
ワーカープールは3つ。
- Gemini 3.1 Pro
- Claude Opus 4.8
- GPT-5.5
ここが最初の重要点だ。Fugu Ultraの賢さは、これら3モデルの賢さの再配分である。 土台のモデルが手に入らなくなれば、性能も連動して落ちる。
ベンチマーク：数字は確かに強い
技術レポート記載の主要スコア（「Best Single」は各ベンチでの単体最強モデル）。
| ベンチマーク | Fugu Ultra | Fugu | Best Single |
|---|---|---|---|
| SWE-Bench Pro | 73.7 | 59.0 | Opus 4.8: 69.2 |
| Terminal Bench 2.1 | 82.1 | 80.2 | Opus 4.8: 74.6 |
| GPQA Diamond | 95.5 | 95.5 | Gemini 3.1: 94.3 |
| LiveCodeBench Pro | 90.8 | 87.8 | Opus 4.8: 84.8 |
| Humanity's Last Exam | 50.0 | 47.2 | Opus 4.8: 49.8 |
SWE-Bench ProやTerminal Benchでは単体最強を明確に上回る。これは事実だ。
ただし、冷静に見るべき点もある。
- GPQA Diamond：95.5 対 94.3。差は1.2ポイント
- Humanity's Last Exam：50.0 対 49.8。差は0.2ポイント。これは誤差の範囲と言っていい
つまり「全領域で圧勝」ではなく、コーディング系で効き、知識・推論系では単体とほぼ互角というのが数字の正直な読み方だ。
ここからが本題：実用での評価
ベンチマークは制御された環境の話だ。実際のワークフローで何が起きたか。第三者テスターの報告を見る。
レイテンシ：体感が重い
あるテスターの報告では、典型的なコーディングテスト（シェーダーやインタラクティブシーン）の実行に30分かかったという。オーケストレーションは「複数モデルに振って待つ」構造なので、レイテンシは原理的に積み上がる。
品質：ベンチと体感の乖離
ベンチマークではFable 5と並ぶとされるが、実使用の評価は厳しい。
Fableほどの実力は、実使用では感じない。
別のテスターは、Three.jsのゲーム生成タスクで結果がGPT-5.5より明確に悪く、修正のための追加プロンプトが7〜8回必要だったと報告している（GPT-5.5は0回）。
ベンチマークのスコアは「特定タスクでの正答率」であって、「日々の開発での使い勝手」ではありません。Fugu Ultraはこの2つの差が、現状かなり大きいモデルです。
隠れたコスト：トークン・ファンアウト
価格表だけ見ると、入力 $5 / 出力 $30（100万トークンあたり）。Fable 5の $10 / $50 より安く見える。
だが、これは表示価格にすぎない。
Fugu Ultraは1リクエストを3〜5モデルに展開する。報告によれば、実際のトークン消費は直接呼び出しの4〜6倍。あるテスターは1プロンプトで5時間ぶんのクォータを使い切ったという（概算で約$6/プロンプト）。
表示単価: 出力 $30 / 1M トークン
実効消費: 1リクエストで 4〜6倍のトークン
→ 実効コストは「単価 × ファンアウト倍率」で評価する必要がある
「安いオーケストレーター」ではなく、「複数の高級モデルをまとめて叩く課金」だと理解したほうがいい。
構造的な皮肉：Fable 5はプールにいない
最大の論点はここだ。
Fugu Ultraは「Fable 5・Mythosに並ぶ」と謳う。だがFable 5もMythosも、Fugu Ultraのエージェントプールに入っていない。理由は前回の記事で書いた通り、米国の輸出規制でFable 5が止められているからだ。
- プールはGPT-5.5・Opus 4.8・Gemini 3.1 Proの3つ
- つまり「Fableに並ぶ」性能を、Fableを使わずに達成している、という主張
- 裏を返せば、性能は完全に他社モデルの提供状況に依存する
OpenAI・Google・Anthropicのいずれかが、価格変更・規制・APIの仕様変更を出せば、Fugu Ultraの実力はその日に変わりうる。ベンダーロックインを避けるための設計が、3社へのロックインになっているとも読める。
技術レポート自身が認めている限界
誇張を避けるなら、Sakana AI自身が書いている注意書きも併記すべきだ。
| レポートの記載 | 意味 |
|---|---|
| レイテンシ・コストの定量比較なし | 実運用コストは読者が自分で測るしかない |
| ベースラインの多くはベンダー自己申告値 | 比較条件が完全に揃っていない |
| 日本語の古文書読解は25ページのみ | 「日本語に強い」と一般化するには小さすぎる |
| AutoResearchの改善は「絶対値では控えめ」 | 派手な領域以外の上積みは限定的 |
| チェス・取引の例は「勝率の推定ではない」 | デモであって実力指標ではない |
| コーディネーターのパラメータ数は非開示 | 「小さい」の中身が検証できない |
研究としては誠実な開示だ。だが、これらを読み飛ばして「Fable級」だけを受け取ると、期待値を誤る。
では、いつ使うべきか
証拠ベースで整理すると、向き・不向きははっきりしている。
向いている
- 時間とコストを許容できる、高難度・多段の問題（研究、論文再現、特許・文献調査）
- 1回の精度が金額より重要な「腰を据えた」タスク
- 単一モデルへの依存を避けたい実験的ワークロード
向いていない
- 対話的な日常開発（レイテンシと追加プロンプトが効率を削る）
- コスト感度の高い大量処理
- 「速くて安い」を期待する用途
まとめ：これは「研究の勝利」であって「製品の完成」ではない
| 観点 | 評価 |
|---|---|
| ベンチマーク | 強い（特にコーディング系） |
| 実使用の品質 | 報告は厳しめ（Fable・GPT-5.5に劣る場面） |
| レイテンシ | 重い（30分級の報告あり） |
| 実効コスト | 高い（4〜6倍のファンアウト） |
| 自立性 | 低い（他社3モデルに依存） |
| 開示の誠実さ | 高い（限界を自分で明記） |
Fugu Ultraが示したのは、「巨大モデルを訓練しなくても、賢く束ねれば最前線に届く」という方向性の証明だ。それ自体は価値がある。
だが「明日から自分のメインモデルにできるか」は別の問いだ。現時点の証拠は、ベンチマークの数字を実用の期待値にそのまま変換するな、と言っている。
数字に踊らされず、自分のワークロードで、レイテンシとファンアウト後の実コストを実測する。それが、この手のオーケストレーションモデルとの正しい付き合い方だ。
この記事が役に立ったら、いいねと保存をお願いします！
あなたはオーケストレーション型モデルを試しましたか？実測値があればコメントで教えてください。
参考リンク
Sakana Fugu — Multi-agent System as A Model
Sakana Fugu Technical Report (arXiv)
Sakana Fugu: Benchmarks vs Real-World Testing (June 2026 Update)
No Claude Fable 5? No problem: Sakana achieves frontier performance with new Fugu multi-model system - VentureBeat
Sakana AI's Fugu orchestrates multiple LLMs to match Anthropic's Fable and Mythos benchmarks - The Decoder