Sakana Fugu (GA) をサブスクリプションプランで試してみた

2026.06.22
 はじめにこんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
Sakana AI から、新しい LLM 製品 Fugu と Fugu Ultra が 2026 年 6 月 22 日に GA としてリリースされました。サブスクリプションプランも同日に始まったので、その日のうちに Standard $20 / 月で契約して触ってみたところ、想像以上に面白い仕組みのモデルだったので、初回のご紹介を兼ねて手触りをまとめておきます。
https://sakana.ai/fugu/
Fugu は一言でいうと「マルチエージェント・オーケストレーションをひとつのモデルにしてしまった」ものです。OpenAI の GPT 5.5 や Anthropic の Claude Opus 4.8、Google の Gemini 3.1 Pro といった主要モデル群を裏側で動的に呼び分けて、ひとつの API として提供してくれます。
これは、NVIDIA LLM Router のような「外側で 1 モデルを選ぶルーター」とは別のアプローチで、Fugu 自身が学習済みのコーディネーター LLM になっています。
https://dev.classmethod.jp/articles/dgx-spark-nvidia-llm-router-v3/
https://dev.classmethod.jp/articles/dgx-spark-nvidia-llm-router-v3-training/
本記事は GA リリース初日に書いている初回紹介として、(1) Fugu の概要、(2) Standard プラン契約から API を OpenAI 互換クライアントで叩いてみた感想、(3) Fugu と Fugu Ultra の違いを実機で見てみるところまでをまとめてみました。
 Sakana Fugu とは何者か!本章以下の Fugu のアーキテクチャや動作原理に関する説明は、Sakana 公式の LP・リリース記事・論文・GitHub リポジトリ・技術解説メディアの記事を読んだうえでの、自分自身の理解にもとづいています。読み解きが誤っている箇所があったらすみません。お気づきの点があればコメントなどでご指摘いただけると助かります。
Fugu のベースになっているのは、Sakana AI が ICLR 2026 に出した 2 本の論文です。ひとつは TRINITY（進化型 LLM コーディネーター）、もうひとつは Conductor（自然言語でエージェント協調を強化学習で身につけさせる手法）です。
TRINITY: An Evolved LLM Coordinator
Learning to Orchestrate Agents in Natural Language with the Conductor
面白いのは、この 2 本の論文で訓練手法が異なるという点です。TRINITY 側は約 0.6B の小さなコーディネーター LLM を進化戦略（CMA-ES、Sakana がこれまでも得意としてきた進化的最適化の系譜）で最適化、Conductor 側は約 7B のコーディネーター LLM を強化学習で訓練、という対比になっています（いずれも論文 abstract の記載です）。Sakana Fugu の実装がどちらに寄っているのか、両者を組み合わせているのかは公式 GA ページには明記されていないので、本記事ではこのあたりに留めておきます。共通しているのは、コーディネーターが「いつ、どのフロンティアモデルに、何を、何回振るか」を学習で身につけているという点と、ときには自分自身を再帰呼び出しして推論を深める、という構造です。中身に何が入っているかの全体像は、Sakana 公式リリース記事（Sakana Fugu: One Model to Command Them All）の冒頭に掲載されているアーキテクチャ図がわかりやすいので、本記事と併せてそちらを参照していただくと、構造のイメージが掴みやすいと思います。
agent pool に含まれているのは GPT 5.5、Claude Opus 4.8、Gemini 3.1 Pro といったフロンティアモデル群とのことですが、Anthropic の Fable 5 と Mythos Preview だけは輸出規制の影響で agent pool には含まれていない、と Sakana 自身が明記しています。地政学リスクを「単一ベンダー依存を避ける道具」として転じている、ともとれる構図ですね。
 Fugu と Fugu Ultra の違いFugu は 2 つのモデルが組になっていて、軽量側を fugu、上位を fugu-ultra-20260615 と呼びます。軽量側の fugu はベータ期には fugu-mini と呼ばれていたものでレイテンシ重視、日常の問い合わせやコードレビュー、チャットボット向けです。一方の fugu-ultra のほうは agent pool をフルに活用するモードで、272K トークンの context と、長い推論を要するタスク（論文再現、Kaggle 競技、サイバーセキュリティ評価、文献調査など）に向いている、と公式は謳っています。
サブスクリプションプランは Standard $20 / Pro $100 / Max $200 の 3 階層で、どのプランでも fugu と fugu-ultra の両方が使えます。プランごとの差は usage 量で、Pro は Standard の 10 倍、Max は Standard の 20 倍とのこと。実際に Standard で何リクエストくらい捌けるかは公式では数値化されていないので、感覚で覚えるしかない部分です。
Pay-as-you-go の場合、fugu-ultra は入力 $5 / 出力 $30（1M トークンあたり）が標準、context が 272K を超えると入力 $10 / 出力 $45 に切り替わります。fugu 側は単体課金ではなく、「最上位モデル単一レートで課金、複数 agent 呼んでも積み上げない」となっているようです。
ちなみに 2026 年 7 月末までに登録すると 2 か月目が無料になるキャンペーンが付いてくるので、今回は Standard を選びました。$20 で 2 か月分触れるなら、初回の検証としてはちょうどよい温度感です。
ひとつ気をつけておきたいのは、fugu と fugu-ultra の使い分けは、クライアント側が model パラメータで明示指定する仕組みになっているという点です。「軽い質問だから fugu を呼ぼう」「重いコードだから fugu-ultra に振ろう」のような自動判定が Sakana 側に入っているわけではなく、どちらを呼ぶかは呼び出し側の責任です。後で見ますが、fugu-ultra の内部で複数のフロンティアモデルを動的に呼び分ける動き（オーケストレーション）はあって、これはまた別レイヤーの話です。
なお、Codex CLI 用に配布されている model カタログ（~/.codex/fugu.json、後述）には、fugu と fugu-ultra の両方が登録されていて、それぞれ context_window: 1000000 と入力モダリティ ["text", "image"] が書かれていました。1M トークンの context と画像入力までサポートされているのは、公式 LP には明記がない発見でした。
 OpenRouter Fusion や NVIDIA LLM Router と何が違うの？「複数モデルを賢く使う」という方向性は、ここ 1 年で 3 つの異なる解法が並びました。Fugu とそれらの差を初回向けにざっくり整理しておきます。


仕組み
呼び出しパターン
「賢さ」の所在
課金単位


NVIDIA LLM Router
1 リクエスト → 分類器が 1 モデルを選んで送る
軽量分類器（MLP / BERT 系、訓練可能）
選ばれた 1 モデルの単価

OpenRouter Fusion
1 リクエスト → 複数モデル並列で同じ質問 → 統合
並列呼び出し ＋ aggregator
並列呼び出しモデル全部

Sakana Fugu
1 リクエスト → 訓練済みコーディネーター LLM が動的に振り分け ＋ 自己再帰
訓練済みオーケストレーター LLM 自身
最上位モデル単価（積み上げない、と公式にはある）

NVIDIA LLM Router は「どの 1 モデルに振るか」だけを分類器で予測する軽量ルーター、Fusion は「N モデルに同じ質問を投げて最後にまとめる」Mixture of Agents 系、そして Fugu は「いつ、何を、何回、誰に振るか、ときには自分自身に再帰で投げ返すか」を訓練済みのコーディネーター LLM 自身が動的に判断します。
 触ってみるconsole.sakana.ai でログイン後、プラン選択画面で Standard を選び、クレジットカード情報を登録すると、get-started ページで API key と base URL が出ます。
base URL: https://api.sakana.ai/v1
標準モデル id: fugu
Ultra モデル id: fugu-ultra-20260615
認証: OpenAI 互換、Authorization: Bearer <api_key> ヘッダ
API key は自分のローカル環境ではいつもの流儀で .envrc に SAKANA_API_KEY として追記しました。
export SAKANA_API_KEY="sk-..."
ひとつだけ事前に知っておきたいのは、EU / EEA からは現状利用できないという点です。GDPR 対応を進めているところ、と Sakana 公式が明記しているので、EU 在住の方は対応が完了するまで利用を待つ必要があります。データの学習利用についても、デフォルトは ON でコンソールからオプトアウトする運用です。
 OpenAI 互換 API で fugu と fugu-ultra を叩くOpenAI 互換 API ということで、openai Python SDK でそのまま叩けます。base_url を 1 行差し替えるだけです。
from openai import OpenAI

client = OpenAI(
    base_url="https://api.sakana.ai/v1",
    api_key=os.environ["SAKANA_API_KEY"],
)
resp = client.chat.completions.create(
    model="fugu",  # または "fugu-ultra-20260615"
    messages=[{"role": "user", "content": "..."}],
)
同じプロンプトを fugu と fugu-ultra-20260615 の両方に投げて、応答内容と usage、レイテンシを比べてみました。プロンプトは「軽い質問」と「軽い推論」の 2 種類です。


model
prompt
latency (s)
total_tokens
orch_in
orch_out


fugu
軽い質問
7.68
309
0
0

fugu_ultra
軽い質問
108.44
14,607
5,889
6,555

fugu
軽い推論
8.21
339
0
0

fugu_ultra
軽い推論
10.98
1,670
1,260
0

ぱっと表を眺めて気づくことが 3 つありました。
ひとつ目は、usage フィールドが OpenAI 互換から独自拡張されていることです。completion_tokens_details の中に orchestration_output_tokens というフィールド、prompt_tokens_details の中に orchestration_input_tokens と orchestration_input_cached_tokens というフィールドが追加されていて、Fugu が裏側で何 token 分のオーケストレーションを回したかが見える形になっています。
ふたつ目は、fugu 単体ではオーケストレーションをほとんどしないことです。orchestration 系のフィールドはすべて 0 で、fugu が自分一人で答えています。一方の fugu_ultra は、軽い質問でも裏で 5,889 + 6,555 = 約 12,444 tokens 分のオーケストレーションを回していて、「軽い質問」の応答返却に 108 秒かかっていました。Ultra は文字どおり、agent pool をフルに使うモードです。
3 つ目は、fugu_ultra が軽い質問への応答で次のような自己紹介を返してきたことです。
私は Fugu オーケストレーションシステムの作業エージェントです。Fugu は複数 AI の協調推論システムです。
TRINITY 論文では Thinker / Worker / Verifier の 3 つのロールが提案されていますが、その Worker ロールが応答に滲み出てきたと読めます。実装のロール構造が応答に出るのは、論文と GA 製品の繋がりが見えて個人的にはかなり面白いと感じました。
なお、「軽い推論」のほうでは fugu / fugu_ultra どちらも 1 人 3.5 個。ミカン 2 個ずつ、リンゴ 1 個ずつ、残り 1 個のリンゴを半分に切って分ける といった同等の答えを返していて、こちらは Ultra の orchestration_output_tokens も 0 でした。軽い推論なら Ultra も自分一人で答えるので、レイテンシも 11 秒前後に収まります。
 Sakana らしい題材で軽くコードを書かせてみる進化的最適化は Sakana AI のもうひとつの研究の柱なので、文脈に合う題材として「Python で遺伝的アルゴリズムを使って文字列 HELLO FUGU を進化させる短いプログラムを書いて」と頼んでみました。
fugu が返してきたコードはこんな感じで、一様交叉 + エリート保存のオーソドックスな実装でした。
import random
import string

TARGET = "HELLO FUGU"
POPULATION_SIZE = 50
GENERATIONS = 100
MUTATION_RATE = 0.05
CHARS = string.ascii_uppercase + " "

def fitness(individual):
    return sum(a == b for a, b in zip(individual, TARGET))

def tournament_selection(population, k=3):
    return max(random.sample(population, k), key=fitness)

def crossover(parent1, parent2):
    return "".join(random.choice((a, b)) for a, b in zip(parent1, parent2))

def mutate(individual):
    return "".join(
        random.choice(CHARS) if random.random() < MUTATION_RATE else c
        for c in individual
    )
（コードの全体は紙幅の都合で一部だけ載せています。tournament_selection で親を選び、crossover で一様交叉、mutate で突然変異という素直な構成です。）
一方の fugu_ultra は、ほぼ同じ構造ですが交叉が一点交叉に変わり、未到達時の後処理メッセージがひとつ増えていました。出力の質は事実上同じです。問題はそこではなく、usage の値です。


model
latency (s)
total_tokens
orch_in
orch_out


fugu
55.24
2,141
0
0

fugu_ultra
269.06
28,950
8,636
17,768

fugu_ultra は裏で 26,404 トークン分（出力本体の 8.8 倍）のオーケストレーションを回し、269 秒、つまり約 4.5 分の時間をかけて、fugu 単体（55 秒）とほぼ同等のコードを返してきました。
軽いコード生成なら fugu で十分、fugu_ultra は本当に重い問題のために温存するという使い分けです。
レイテンシの振れ幅という意味では、fugu_ultra は本記事の検証範囲だけでも、軽い質問 108 秒・軽い推論 11 秒・コード生成 269 秒と幅広く振れました。内部で「どこまで深く回るか」を動的に判断していることの裏返しでもあり、Ultra で軽いタスクを投げると想像以上にレスポンスが遅いと感じてしまうかもしれません。
 コンソールから見た usage の全体像ここまでの API 検証（軽い質問 2 件、軽い推論 2 件、コード生成 2 件）が終わった段階で、Sakana コンソールの usage 画面を見てみました。
通常の input 24,704 + output 10,774 = 約 35,000 トークンに対して、オーケストレーション側は input 23,531 + output 30,285 = 約 54,000 トークンと、表側より多くなりました。割合でいうと、合計 89,000 トークン中の 60% は裏で動いた分です。fugu_ultra のコード生成 1 件分（裏 26,404 トークン）が大きく効いている計算で、Ultra を呼ぶときの「裏でこれくらい動く」という肌感覚は、ここまで見てきた個別レスポンスの数値とも矛盾なく繋がっています。
サブスクリプションの使用枠のほうもあわせて見ておきます。
5 時間枠が 18%、週間枠が 6% です。今回の検証セッションは、API を 6 リクエスト（fugu 3 件 + fugu-ultra 3 件）と codex-fugu exec を 1 回叩いただけの規模なので、Standard プランで「ちょっと触ってみる」までは余裕がありそう。一方で、fugu_ultra のコード生成 1 件で 5h 枠の 10% 超を持っていく感触なので、Ultra を業務ループに組み込む使い方をするなら、Pro（Standard の 10 倍）以上が現実解になりそうです。Standard はあくまで「個人で慣らす」「軽い問い合わせを fugu でこなす」用、と捉えておくのがよさそうですね。
 codex-fugu をインストールして起動だけ確認Fugu には公式の CLI もあって、SakanaAI/fugu リポジトリにインストール手順が出ています。
curl -fsSL https://sakana.ai/fugu/install | bash
codex-fugu
何が降ってくるのかコードを読んでみたら、codex-fugu の正体は OpenAI の Codex CLI を -p fugu profile で起動するための 392 行の bash wrapper でした。Sakana が独自 CLI を作っているのではなく、Codex CLI の上に profile 切り替えで乗せている形です。
中心となっている行はこれです。
exec "$real" -p fugu ${CODEX_ARGS[@]+"${CODEX_ARGS[@]}"}
インストーラ scripts/install.sh は次のことをやってくれます。
既存の Codex CLI を検出し、特定バージョン（今回は 0.141.0）に pin
~/.codex/config.toml に [model_providers.sakana] セクションを書き足し
~/.codex/.env に SAKANA_API_KEY を 0600 で保存
~/.codex/fugu.config.toml に Fugu 専用の profile 設定を配置
~/.local/bin/codex-fugu ランチャーを設置
~/.codex/fugu.config.toml を覗くと、ちょうどよい温度感の最小構成でした。
model = "fugu"
model_reasoning_effort = "high"
model_provider = "sakana"
model_catalog_json = "/Users/morishige/.codex/fugu.json"
model = "fugu" が既定です。model_catalog_json で参照されている ~/.codex/fugu.json には fugu と fugu-ultra の 2 つが登録されているので、Ultra に切り替えたいときは Codex TUI の /model slash command や、起動時の -c オプションで model を上書きする経路を想定して作られているようです。こちらもクライアント側の明示指定になります。
そして ~/.codex/config.toml 側に挿入された provider 定義はこちらです。
[model_providers.sakana]
name = "Sakana API"
base_url = "https://api.sakana.ai/v1"
env_key = "SAKANA_API_KEY"
wire_api = "responses"
stream_idle_timeout_ms = 7200000
stream_max_retries = 5
request_max_retries = 4
おっと思ったのは 2 か所です。wire_api = "responses" で、Chat Completions ではなく Responses API を使う設定になっていること。そして stream_idle_timeout_ms = 7200000、つまりストリームのアイドル待ちが 2 時間まで許容されていることです。Fugu Ultra の長時間オーケストレーションを前提に作られている設定だとわかります。
自分の環境では既存の Codex 0.140.0 が走っていたので、最初はバージョン mismatch で bundle deploy が refuse されました。Sakana は Codex を特定バージョンに厳格に pin する設計で、ミスマッチがあると自動的には進めずに確認してくれます。OpenAI の Codex 側はバージョン更新が頻繁なので、Fugu 側で動作確認したバージョンに寄せてくれる仕組みがあるのは、互換性の観点でありがたい作りです。手元では npm install -g @openai/codex@0.141.0 で上げてから再実行して、無事にバンドル展開が通りました。
起動後の codex-fugu --status はこうなりました。
codex-fugu status
  CODEX_HOME        : /Users/name/.codex
  CODEX_INSTALL_DIR : /Users/name/.local/bin
  real codex        : /Users/name/.bun/bin/codex
  installed version : 0.141.0
  bundle            : configs
  deployed_target   : 0.141.0
  deployed_format   : modern
  repo_dir          : /Users/name/.fugu
  branch            : main
  install_ref       : ed1535c4f14e715635bc0fcfb4dcf1e0683164b1
  install_method    : npm
  last update check : never
これで codex-fugu exec "..." で 1-shot 実行も、codex-fugu だけで Codex の対話 TUI 起動もできます。既存の ~/.codex/AGENTS.md などの設定はそのまま引き継がれるので、Codex を普段から使っている方なら、profile を Fugu に切り替えるだけで馴染みのまま使い始められると思います。
 CCR から Sakana Fugu に繋いでみるここは記事末尾の補足ですが、Claude Code Router (CCR) からも Fugu に繋いでみました。~/.claude-code-router/config.json の Providers 配列に sakana エントリをひとつ足すだけで、Anthropic 互換 client から呼べるようになります。
{
  "name": "sakana",
  "api_base_url": "https://api.sakana.ai/v1/chat/completions",
  "api_key": "sk-...",
  "models": ["fugu", "fugu-ultra-20260615"]
}
ccr restart の後に、Anthropic 互換 endpoint に curl で叩いてみると応答が返ります。
curl -sS -X POST http://localhost:3456/v1/messages \
  -H 'content-type: application/json' \
  -d '{
    "model": "sakana,fugu",
    "max_tokens": 200,
    "messages": [{"role":"user","content":"Sakana AI の Fugu を 50 字程度で紹介してください。"}]
  }'
{
  "id": "chatcmpl-...",
  "model": "fugu",
  "content": [{ "type": "text", "text": "Fuguは、Sakana AIが開発した、速度と品質を両立するAIエージェントです。" }],
  "stop_reason": "end_turn",
  "usage": { "input_tokens": 65, "output_tokens": 185 }
}
CCR 側のログにも sakana provider registered と出て、4.8 秒で 200 OK が返ります。CCR 経由で Claude Code から Fugu を呼ぶような、込み入った使い方の検証はまた次回以降に。
 いま気になっていることここまで触っていて、初回時点で気になっている点もまとめておきます。
ひとつは、usage で「裏側」が見える設計の良さです。orchestration_input_tokens と orchestration_output_tokens という独自フィールドで裏側のオーケストレーション分を別カラムで返してくれるので、課金されている合計と、裏で動いていた量との差分が見えます。一方で、「どのモデルが何回呼ばれたか」までは出てこないので、internal routing そのものの透明性とは違う粒度のオープンさです。
ふたつ目は、レイテンシの予測しにくさです。今回の検証だけでも fugu_ultra は 11 秒から 269 秒まで振れていて、CLI の stream_idle_timeout_ms = 7200000（2 時間）という設計値からも、内部ではもっと長く回るケースが想定されているのが見えました。チャット用途の感覚で投げると驚くと思うので、Ultra はバッチ向け・じっくり考える系のタスクに使い分けたほうがよさそうです。
3 つ目は、Standard プランの「枠」が、コンソールを見るまでイメージしにくいこと。先ほど触れたように、本記事の検証セッション（API 6 リクエスト + codex-fugu 1 回）で 5h 枠の 18%、週枠の 6% を持っていきました。fugu_ultra を業務ループで日常的に呼ぶ使い方をするなら Pro 以上、Standard はあくまで「個人で慣らす」「fugu 中心で軽く使う」用、と捉えておくのがよさそうです。Pay-as-you-go の単価（Fugu Ultra で入力 $5、出力 $30 / 1M token）も併用の参考値として頭に置いておくとよいですね。
そして 4 つ目は、EU / EEA から利用できないことと、デフォルトで応答が学習に使われる仕様です。後者はコンソールからオプトアウトできるので、本格利用の前に切り替えておくのが安心です。
 おわりにGA リリース当日からその日のうちに触ってみた、初回紹介でした。Fugu の面白さは、「複数モデルを束ねる」のではなく、「束ねる仕組み自身を 1 つの LLM として強化学習で訓練した」というところに尽きると思います。usage の独自拡張や、wire_api = "responses" を選んだ wire 側の設計、Codex CLI 上に profile で乗っかる省エネ実装などからは、Sakana が「やりたいことに集中して、無駄なものを作らない」性質を感じました。
2 か月目無料キャンペーンが 7 月末までなので、Fugu が気になっていた方は、今くらいの温度感で試してみるのに向いている時期だと思います。
 参考リンクSakana Fugu — Multi-agent System as A Model
Sakana Fugu: One Model to Command Them All（リリース記事）
Sakana Console / Pricing
SakanaAI/fugu — GitHub
TRINITY: An Evolved LLM Coordinator (arXiv)
Learning to Orchestrate Agents in Natural Language with the Conductor (arXiv)
NVIDIA LLM Router で LLM の用途別使い分け環境を構築してみた（基礎編）
NVIDIA LLM Router を自分のペルソナに合わせて再訓練してみた（訓練編）
Sakana Fugu (GA) をサブスクリプションプランで試してみた

はじめに

Sakana Fugu とは何者か

Fugu と Fugu Ultra の違い

OpenRouter Fusion や NVIDIA LLM Router と何が違うの？

触ってみる

OpenAI 互換 API で fugu と fugu-ultra を叩く

Sakana らしい題材で軽くコードを書かせてみる

コンソールから見た usage の全体像

`codex-fugu` をインストールして起動だけ確認

CCR から Sakana Fugu に繋いでみる

いま気になっていること

おわりに

参考リンク

国内企業 AI活用実態調査2026 配布中

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

仕組み	呼び出しパターン	「賢さ」の所在	課金単位
NVIDIA LLM Router	1 リクエスト → 分類器が 1 モデルを選んで送る	軽量分類器（MLP / BERT 系、訓練可能）	選ばれた 1 モデルの単価
OpenRouter Fusion	1 リクエスト → 複数モデル並列で同じ質問 → 統合	並列呼び出し＋ aggregator	並列呼び出しモデル全部
Sakana Fugu	1 リクエスト → 訓練済みコーディネーター LLM が動的に振り分け＋自己再帰	訓練済みオーケストレーター LLM 自身	最上位モデル単価（積み上げない、と公式にはある）
model	prompt	latency (s)	total_tokens	orch_in	orch_out
fugu	軽い質問	7.68	309	0	0
fugu_ultra	軽い質問	108.44	14,607	5,889	6,555
fugu	軽い推論	8.21	339	0	0
fugu_ultra	軽い推論	10.98	1,670	1,260	0