Sakana Fugu Maxの料金：全レートと実際にかかる費用

TL;DR

Sakana AIはFugu Maxの価格を入力100万トークンあたり$2、出力100万あたり$6に設定しました。コンテキスト長に関係なく定額で、加えてキャッシュ入力が100万あたり$0.25、Web検索またはWeb取得の呼び出しが1回$0.007です。月額払いをご希望なら、$20、$100、$200の3つのサブスクリプションがあり、どれにもすべてのFuguモデルが含まれます。

表示レートは安いものの、料金ページだけでは全体像はわかりません。実際の請求額を左右する要因は2つあります。1つ目は、Fugu Maxが1つのリクエストを小さなモデル群に振り分けるオーケストレーションモデルであること、そしてその内部トラフィックのすべてがあなたのメーターに載るため、1回のリクエストが単一モデルの呼び出しより高くなりうることです。逆方向では、キャッシュが大きく効きます。OpenRouterのライブパネルでは、Fugu Max公開直後の実効入力価格は定価$2に対して100万あたり約$0.61でした。

私は3年以上、チームがカスタマーサポート向けにモデルを選ぶ様子を見てきましたが、パターンはいつも同じです。トークンレートは比較しやすい数字ですが、最適化すべき数字ではありません。チケット1件を解決するのにかかる費用は、モデルを取り巻くシステム全体で決まります。eeselのようなAIチームメイトが埋めるのはこの差であり、本当のコスト計算はそこにあります。

Sakana Fugu Maxの料金：全レート表

こちらが、SakanaのFAQとOpenRouterのモデルページから直接まとめた、このモデルの従量課金の全体像です。モデルIDは fugu-max（v1.0）です。

定額の設計は、最もすっきりした点です。Sakanaによると、$2/$6のレートは「コンテキスト長に関係なく」維持されるため、コンテキストウィンドウにどれだけ入っていても、90万トークンのプロンプトは短いプロンプトと同じトークン単価です。多くの最先端モデルは一定の閾値を超えると長コンテキストの割増料金を加えます。大きなドキュメントを日常的にモデルへ渡すなら、これは確認できる本物の利点です。

対照的に、同じファミリーのFugu Ultra v2は長いコンテキストで料金が上がるため、Maxの定額が同じファミリー内でも際立ちます。

2つの支払い方法と、名前の落とし穴

Fuguの購入方法は2つあり、混同しやすいものです。

サブスクリプションは月ごとの利用枠で、どの階層でもMaxだけでなくすべてのFuguモデルを使えます。

一方、従量課金は「月ごとの利用枠ではなくトークン使用量で課金し、急増や大規模ジョブに対応する柔軟な容量を提供する」もので、Sakanaは事前に利用量を上限設定できない企業向けとしています。

ここからが落とし穴です。「Maxプラン」というサブスクリプションは、「Fugu Max」というモデルと同じものではありません。$200のプランはファミリー内のすべてのモデルを含む利用枠で、Fugu Maxはその中の1つのモデルです。Fugu Maxモデルは$20のStandardプランや従量課金でも問題なく使え、触れるために$200のサブスクリプションは必要ありません。料金ページを初めて読む人のほとんどがつまずく、ちょっとした言葉の重なりです。

オーケストレーショントークンの落とし穴

これは料金表では見えにくい、Sakana Fugu Maxの料金の核心部分で、予算を立てる前に理解すべき最も重要な点です。

Fugu Maxを呼び出すとき、話しかけている相手は1つのモデルではありません。リクエストを読み取り、オープンウェイトや専門特化のモデル群に振り分け、1つの回答にまとめる、学習済みの調整役と話しています。これがFuguファミリーの魅力のすべてです。自分で構築しなくても、マルチエージェントシステム、つまり本物のAIエージェントのパターンが手に入ります。

課金への影響はOpenRouterに明記されています。"Orchestration tokens consumed by the system are billed as standard input/output tokens."（システムが消費したオーケストレーショントークンは、標準の入力・出力トークンとして課金される）。平たく言えば、モデル間の内部のやり取りはあなたのメーターに載り、無料ではありません。3、4個のモデルに展開される1回のリクエストは、単一モデルの直接呼び出しよりかなり多くのトークンを消費することがあり、出力レート$6の低さが、そのまま回答あたりの低い請求額になるとは限りません。

Sakanaはこれを和らげており、その仕組みは公平に引用しておくべきでしょう。FAQによると、複数のエージェントが動いている場合、"we never stack fees: you pay a single rate based on the top-tier model involved."（料金を重ねることはなく、関与する最上位モデルに基づく単一のレートを支払う）とのことです。つまり、リクエストにエージェントを追加しても課金レートが倍増することはなく、その単一レートでより多くのトークンが流れるだけです。要するに、コストは総トークン数に比例し、オーケストレーションは総トークン数を膨らませます。表示レートではなく、回答あたりのトークン数で予算を立ててください。

公開直後に購入者が実際に支払った額

定価と実際の請求額は別の数字で、今回はその差を示す公開データがあります。9月11日の公開後、Fugu Maxの最初の数日間のOpenRouterのライブ料金パネルでは、数字は次のとおりでした。

• 定価： 100万あたり入力$2 / 出力$6。
• 実効入力価格：100万あたり約$0.61、定価の$2を大きく下回る。
• 実効出力価格：100万あたり$6、変わらず。
• キャッシュヒット率：79.4%、これが実効入力価格を押し下げている。
• スループットは毎秒約29トークン、単一プロバイダー、稼働率100%。

つまり、キャッシュは入力コストを大きく引き下げる一方、出力は定価のままです。最適化の労力をどこに使うべきかがわかります。Fugu Maxはヘビーなキャッシュ利用に報い、冗長で出力の多い生成には不利です。ワークロードが同じコンテキストを多く再利用する（固定のシステムプロンプト、安定した文書セット）なら、実効入力レートは表示価格のほんの一部になりえます。呼び出しが毎回新規で出力が多いなら、$6のラインに近くなります。

他のモデルとのコスト比較

ここで料金が見出しを得ます。Sakanaはリリース記事で、Fugu MaxはSonnet 5、GPT-5.6 Terra、Kimi K3より出力が「40〜60%安い」うえ、"within striking distance of elite models"（トップクラスのモデルに肉薄する）性能だと主張しています。各ベンダーの定価と並べると、出力の差は確かにあります。

この表をスクリーンショットする前に、2つ正直な注意点があります。1つ目は、これは執筆時点の定価で、ベンダーは変更するため、行の値はスナップショットであり契約ではないと考えてください。2つ目は、この比較は生のトークンレートによるもので、上のオーケストレーションの節で見たとおり、Fugu Maxでの回答あたりのコストとは同じではありません。振り分けを行うモデルは、行わないモデルより同じ答えに至るまでに多くのトークンを使うため、レートが安くても請求額は似たものになりえます。

効率というフレーミングこそが本当のセールスポイントで、公平な主張だと思います。出力コストを抑えながら、トップクラスに近い性能を出す。ただし現時点ではSakana自身のベンチマークでしか確認されていません。Fable 5のような最強クラスのプロプライエタリモデルはFuguのプールに入っておらず、それこそがSakanaの言いたい点であると同時に、この比較がどこまで通用するかの限界でもあります。他のAIモデルの主張と同じく、ベンダーの比較表は出発点であって証明ではありません。

Fugu Maxの請求額を自分で見積もる

上の計算は読むより触って感じるほうが早いので、簡単な計算ツールを用意しました。月間のおおよその量とキャッシュの挙動を入力すると、従量課金の請求額を見積もり、$200のMaxサブスクリプションが得になり始める地点を示します。

スライダーを動かすと目につくポイントは、入力の行に対しては、生のボリュームよりキャッシュヒット率のほうが大きく効くことです。これはOpenRouterのデータと一致しており、サブスクリプションの階層を気にする前に最初に調整するところです。

モデルの請求が終わり、本当のコストが始まる場所

料金の記事ではつい忘れがちですが、私が何度も立ち返る区別があります。ほとんどの仕事では、トークンの請求額は重要なコストではありません。それはエンジンのコストであって、仕事のコストではないのです。

私が最もよく知るカスタマーサポートを例にしましょう。モデルは、トークンがどれだけ安くてもテキストを返すだけです。それを解決済みチケットに変えるには、ヘルプデスクに接続し、ナレッジベースとポリシーを教え、注文の照会やチケットのタグ付けの権限を与え、いつ人間にエスカレーションするかを決め、実際の顧客に触れる前に安全だと証明する必要があります。その作業がプロジェクトの大半で、100万トークンあたりのレートにはまったく現れません。

だからこそ、私はAIエージェントのコストと人間のエージェントを、トークンではなく解決件数で比較しますし、オフショアのサポートチームとのコスト比較も同じ解決あたりの計算にかかっています。

これはFugu自体が魅力的な理由と同じ論理です。ほとんどのチームはマルチエージェントの基盤を自分で作りたくないので、マネージドなオーケストレーションを買います。それを一段上に押し広げれば、サポートでも、モデルを中心に従業員まるごとを手作りしたいとは思わないでしょう。

eeselを試す：トークンではなくチケットに値段をつける

その差を埋めるのがeeselです。eeselはAIチームメイトのプラットフォームで、特定の仕事向けにすぐ働けるチームメイトを採用でき、それぞれが役割に必要なスキル、連携、会社の文脈を備えて加わります。AIヘルプデスクチームメイトは既存のキューに参加し、注文や記録を照会し、チケットにタグを付け、返信を下書きまたは送信します。すべてすでに使っているヘルプデスクの中で行われます。

料金の記事として重要な点：モデルごとの計算は一切不要です。eeselは内部で最先端モデルを使い、その選択をお任せでき、課金はトークンではなくチケットまたはチャット1件につき1クレジット（500クレジットで月$299からのプラン）なので、予測する数字がそのまま終えた仕事に対応します。過去のチケットとナレッジベースで学習し、Zendesk、Freshdesk、Gorgiasなど1000以上のツールに接続し、過去のチケットでシミュレーションして、顧客に回答する前に解決率とコストの両方を確認できます。これはFuguの不透明なルーティングでは得られないリハーサルです。

ターミナル派の方には、eeselはプログラム可能な本物のインターフェースも提供します。eesel CLI（@eesel/cli）とそのMCPサーバーを使えば、人、スクリプト、Claude Codeのようなコーディングエージェントが、ダッシュボードと同じチームメイトを操作できます。連携の接続、チームメイトの常時指示の編集、eesel activity による各実行の確認、アクションの承認や拒否まで、すべてJSONで、書き込みが送信する前に実際の呼び出しを表示する --dry-run フラグも備えています。これは、API専用のモデルでは自分で作ることになるエージェント的なアクセスです。

Fugu Maxは、「アプリにどのモデルを使うべきか、トークンはいくらかかるか」という問いへの強力な答えです。本当の問いが「より多くのチケットを解決するにはいくらかかるか」なら、eeselを無料で試せます。クレジットカードも営業電話も不要で、トークンではなく仕事に値段をつけられます。