Sakana AIのFugu MaxとFugu Ultra v2を業務目線で読む｜「オーケストレーターをモデルとして買う」調達の損得

東京のAIラボであるSakana AIが、Fugu MaxとFugu Ultra v2を公開しました。公式ブログの日付は2026年9月11日です。ただし、これは「新しい大規模言語モデルが2つ増えた」という話ではありません。Fuguは単一のモデルではなく、複数モデルのプールを動的に協調・オーケストレーションして、1つのOpenAI互換APIとして提供する仕組みだからです。つまり今回売られているのは、モデルそのものというより「どのモデルに何を任せるかを決める層」です。この記事では、公式ページで確認できる料金と提供条件を押さえたうえで、ルーター/オーケストレーターをモデルとして調達するとき、業務側で何が楽になり、何が見えなくなるのかを切り分けます。

何が発表されたのか#

事実関係から押さえます。Sakana AIは公式ブログ「Introducing Fugu Max and Fugu Ultra v2: Orchestrating the Pareto Frontier」でこの2つを発表しました。ブログの日付表記は2026年9月11日です(海外メディアには9月10日付で報じているものもあります)。同社は東京に拠点を置き、サイトでは「Building Frontier AI in Japan」を掲げています。

ブログは両者の関係を、はっきりこう説明しています。Fugu MaxとFugu Ultra v2は別々の製品ではなく、同じオーケストレーション基盤を2つの異なる目的に最適化したものである、と。Fugu Maxが問うのは「最も低いコストで出せる最良の出力は何か」、Fugu Ultra v2が問うのは「複雑な多段タスクで到達できる最高の能力は何か」です。同じ仕組みを、コスト軸と能力軸のどちらに振るかという違いになります。

製品ページ側では、Fuguファミリーは4つのモデルとして整理されています。レイテンシと品質のバランスを取る標準の「Fugu」、回答品質を最優先する「Fugu Ultra」、最大のモデルプールでコストパフォーマンスを狙う「Fugu Max」、そしてサイバーセキュリティ推論に特化した「Fugu Cyber」です。いずれも同じOpenAI互換APIから使え、連携を変えずに切り替えられると案内されています。

Fuguが「単一のモデル」ではない、というのはどういうことか#

製品ページの説明はシンプルです。Fuguは、強力で多様なモデル群を動的に組み合わせて協調させることで性能を出す仕組みで、人手で役割分担やワークフローを設計するのではなく、プールからエージェントを動的に編成して連携させることを学習している、とされています。なお、オーケストレーター自体もルールベースの振り分け層ではなく、ユーザーのクエリを理解してタスクごとにエージェントの編成(スキャフォールド)を組み立てるよう訓練された言語モデルだ、とテクニカルレポートには書かれています。

技術的な背景として、ICLR 2026に採択された2本の論文が挙げられています。1本目のTRINITYは、軽量な進化型コーディネーターが複数のLLMを複数ターンにわたって統括し、各モデルにThinker(思考役)・Worker(実行役)・Verifier(検証役)の役割を割り当てる仕組みです。2本目のConductorは、強化学習によって自然言語ベースの協調戦略そのものを発見させるアプローチとされています。より詳しい内容はテクニカルレポート(arXiv:2606.21228「Sakana Fugu Technical Report」)にまとまっています。ただしこのレポートの投稿は2026年6月で、記述の中心はFuguとFugu-Ultra(v1)です。今回のv2やMaxの詳細がそのまま書かれているわけではない点は、読むときに意識しておくとよいところです。

公式ブログには、ここまでの経緯も時系列で整理されています。4月にベータ、6月に一般提供とFugu Ultra v1、7月にFugu-CyberとClaude Codeインターフェース、8月にSakana ChatとNVIDIAとの連携(Nemotronのオープンモデル統合の開始)、そして9月が今回のFugu MaxとFugu Ultra v2、という流れです。半年弱で機能追加が続いている領域だと理解しておくと、後述する「プールが更新される」という論点が実感として掴めます。

公式で確認できる料金と提供条件#

料金は公式製品ページの料金セクションとFAQに記載があります。従量課金(Token Plan)の単価は次のとおりです。

Fugu Maxはコンテキスト長にかかわらず一律で、web_searchとweb_fetchは1回あたり$0.007と記載されています。Fugu Ultra v2は272Kトークンを境に、入力とキャッシュ入力が2倍、出力が1.5倍に上がる段差があり、長文を扱う設計では効いてきます。

サブスクリプションも3段階で用意されています。Standard Plan($20/月)、Pro Plan($100/月、Standardの10倍の利用量)、Max Plan($200/月、Standardの20倍)で、いずれのプランでもFugu・Fugu Ultra・Fugu Maxが使えるとされています。Fugu Cyberの料金は営業への問い合わせ扱いです。

料金の考え方で1つ特徴的なのが、複数エージェントが動いてもモデル料金を積み上げない、という説明です。FAQでは無印Fuguの例として、プールにモデルA・B・Cが含まれていても支払いは1つのレート、つまりA・B・Cのうち最上位モデルのレートだけだと説明されています。エージェントを増やすと請求が掛け算で増える、という心配は不要な設計になっています。一方でFugu MaxとFugu Ultra v2は、そもそも上表の固定レートです。

コンテキスト長と入力形式は公式ページに記載がない#

実務で真っ先に知りたいコンテキストウィンドウと最大出力トークン数ですが、これは公式の製品ページにもブログにも記載が見当たりませんでした。一方、Fuguを取り扱っているOpenRouterのモデル情報では、fugu-ultra-v2とfugu-maxのいずれもコンテキスト1,000,000トークン、最大出力128,000トークン、入力モダリティはテキスト・画像・ファイルで出力はテキストのみ、と記載されています。対応パラメータとしてはinclude_reasoning、reasoning、reasoning_effort、structured_outputs、tools、tool_choice、web_search_optionsが並んでいます。同じ情報では推論が必須(mandatory)で常時有効、選べるreasoning_effortもhigh・xhigh・maxの3段階のみ(既定値はFugu Ultra v2がxhigh、Fugu Maxがhigh)と示されています。

この数字は一次情報ではなく再販側の記載である、という点は明確にしておきます。実際に使うときは、自分のアカウントのエンドポイントに長い入力を投げて上限を確かめるのが確実です。

Fugu自体はOpenAI互換APIで提供され、既存のクライアントやコーディングハーネスをFuguのエンドポイントに向けるだけでSDKの移行は不要、と公式FAQに書かれています。すでにFuguを使っている場合、MaxやUltra v2への切り替えはパラメータ1行の変更で済むともブログに記載があります。また、OpenRouterやVercelなどのサードパーティ経由でも提供されています(この場合、web検索などの付随機能の単価は取扱先のレートになる点に注意してください)。

提供地域については、EU(欧州連合)およびEEA(欧州経済領域)加盟国には提供していないと明記されています。GDPRなどEU固有規制への対応を進めている最中、という説明です。欧州拠点を含むグローバル展開を想定しているなら、ここは技術検証より先に確認すべき条件になります。

ベンチマークの主張と、その読み方#

公式ブログが掲げている数字を、まず正確に並べます。

公式は、Fugu MaxがNVIDIAとの協業を通じたNVIDIA Nemotronファミリーを含む、これまでにない数のオープンウェイトモデルと専門モデルを統合していると説明しています。プール全体は非公開ですが、含まれる系列が名指しされている数少ない例です。

Fugu Maxについては、Terminal Bench 2.1、GPQAD、AA-LCR、GDP.pdf、AutomationBench、そしてSakana AI社内のコーディング課題を反映したSWEFishを含む6つのベンチマークで総合最高スコアを達成した、とされています。また10のベンチマークのうち7つでコストパフォーマンスのパレートフロンティアを押し広げたという説明と、入力$2・出力$6という価格設定について「出力料金はSonnet 5、GPT 5.6 Terra、Kimi K3より40〜60%低い」という比較が添えられています。

Fugu Ultra v2については、視覚的な推論とデータ解釈を測るChartographyで48.3を記録し、Opus 5の27.3、Fable 5の29.5を上回ったとされています。実世界のソフトウェア工学を測るDeepSWEでは74.3で、トークン単価が3倍から5倍高いモデルを上回ったという説明です。総括としては、GDP.pdf、Chartography、SWEFish、DeepSWE、Toolathonの5つで単独最高または同率最高、8つのベンチマークのうち7つでトップ2、とされています。

そして今回いちばん話題になりやすいのが、この一文です。Fugu Ultra v2は、Fable 5・Fable 5.1・GPT-6-Astraをエージェントプールに含まずにこれらのスコアを出している、と明記されています(あわせて学習データのカットオフ日が20260828であることも注記されています)。最上位のプロプライエタリモデルに依存せず、入れ替え可能なオープンモデルと専門モデルのプールだけでフロンティア級の出力を出せる、というのが同社の主張です。

この主張の意味は理解できます。オーケストレーション層を売る事業者にとって、「結局は他社の最強モデルを呼んでいるだけでは」という疑いは避けて通れない論点だからです。そこに対して、特定の最上位モデルを外した構成でもスコアが出ると示すのは、筋の通った反論です。

ただし、業務判断に使うときの割り引きは、他のモデル発表と同じです。

1つ目は、これがベンダー自己申告値である点です。第三者による再現ではありません。SWEFishに至っては同社の社内ベンチマークであることが明記されており、外部から検証する手段がありません。

2つ目は、比較の土俵を発表側が選んでいる点です。どのベンチマークを並べ、どのモデルを比較列に置くかは発表側の裁量です。自社がいま使っているモデルが表に載っていなければ、この表からは何も言えません。

3つ目は、オーケストレーターに固有の事情です。Fuguの挙動はプールの構成に依存します。公式FAQには、新しいフロンティアモデルが一般公開された場合、更新版Fuguモデルのトレーニングと評価に約2週間をかけて順次提供していく予定だ、と書かれています。これは追従が速いという長所である一方、「今日測ったスコア」と「3か月後の挙動」が同じ保証はない、ということでもあります。単一モデルなら、モデルIDを固定すれば挙動もおおむね固定できます。オーケストレーターでは、固定しているつもりのモデル名の内側で構成が動き得ます。

「オーケストレーターをモデルとして買う」と何が変わるか#

ここからが本題です。多くのチームは、程度の差こそあれ自前でモデルの振り分けをしています。簡単な分類は安いモデル、コード生成は別のモデル、長文の要約はまた別、といった具合です。Fuguが提案しているのは、その振り分け層そのものを外部から1つのモデルとして買う、という調達形態です。

買うことで手に入るものは、はっきりしています。

第一に、モデル選定の意思決定を手放せます。新しいモデルが出るたびに評価して差し替えるという作業が、提供側の仕事になります。前述のとおり同社は約2週間での追従を目安として掲げています。

第二に、API・契約・課金の窓口が1つになります。複数ベンダーと個別に契約し、それぞれのレート制限とキーとログを管理する手間は、実務ではばかになりません。請求も一本化されます。

第三に、供給の分散です。公式は、入れ替え可能なプールをオーケストレーションすることで、ベンダーロックイン、APIの提供停止、地政学的な不確実性、突然のサービス遮断からユーザーを守る、と説明しています。単一ベンダーに全面依存していると、その1社の障害や方針変更が自社のサービス停止に直結します。プールが複数ベンダーにまたがっていれば、そのリスクは理屈のうえでは薄まります。

一方で、手放すものもあります。

内部委譲ゆえの実務論点#

この構成を業務で採るときに、具体的に詰めておくべき点を並べます。感情論ではなく、確認項目として記録に残せる形にするのが実務的です。

1. どのモデルにデータが渡るかが見えにくくなる#

公式FAQのQ9に、明確な記載があります。各クエリでFuguが選択した具体的なモデルや連携の仕方は独自技術であり、この情報は設計上公開していない、というものです。これは隠しているという話ではなく、オーケストレーション自体が製品価値の中核なので当然といえば当然の方針です。ただし利用者側から見ると、リクエストごとの委譲先が原理的に分からない、ということになります。

制御の余地については、FAQのQ3に切り分けが書かれています。Fugu Ultraは性能を出すために全エージェントプールを使うためプールは固定、Fugu Maxもコストと性能の両方を最適化する必要があるためプールは固定。プロバイダやモデル単位での除外ができるのは無印のFuguのみで、コンソールの設定メニューから行える、とされています。加えて、特定のモデルやプロバイダ構成が必要なエンタープライズ顧客には個別対応サービスを提供しているので問い合わせてほしい、とも書かれています。

つまり、「委譲先を自社で限定したい」という要件があるなら、今回発表されたMaxやUltra v2ではなく無印Fuguを選ぶか、エンタープライズの個別契約で詰めるか、のどちらかになります。ここは記事の見出しになりにくい部分ですが、社内審査を通す立場では最初に確認すべき条件です。

学習利用については、コンソールページからいつでもオプトアウトできると案内されています。利用データは性能向上に役立てるが共有するかどうかは顧客の判断、という書き方です。本番投入するなら、既定値がどちらなのかをコンソールで自分の目で確認し、確認した日付とスクリーンショットを残しておくことをおすすめします。

2. 委託先開示を求める契約との相性#

顧客との契約で「再委託先を含む委託先の一覧を事前に開示・承認する」という条項が入っている業務は珍しくありません。オーケストレーター経由では、この一覧を正確に埋めることが構造的に難しくなります。プールの構成が非公開である以上、「Sakana AI」と書くのか、その先のモデル提供者まで書くのかという整理が要ります。

これは技術の問題ではなく契約と説明責任の問題なので、法務や情報セキュリティの担当と早い段階ですり合わせておくと手戻りが減ります。逆に、社内業務の効率化など委託先開示の制約がない用途であれば、この論点はそこまで重くなりません。用途を先に区切るのが近道です。

3. レイテンシのばらつき#

複数のモデルを複数ターンにわたって協調させる以上、応答時間は単一モデルの1回呼び出しより伸びる方向に働きます。公式FAQも、Fugu Ultraについて精度と深さを優先する分だけ応答時間は長くなる、と正直に書いています。標準のFuguがレイテンシと品質のバランス型として位置づけられているのも、同じ理由からでしょう。

問題は平均値ではなく、ばらつきです。タスクごとに動員されるエージェント数が変われば、同じような入力でも応答時間が大きく振れる可能性があります。対話型のUIに組み込むなら、p50ではなくp95・p99を測り、タイムアウト値とユーザーへの待機表示を設計してください。逆に、バッチ処理や非同期のジョブなら、多少遅くても品質が上がるほうが得なことは多いです。

4. 障害時の切り分けが難しい#

出力の品質が急に落ちたとき、あるいはエラー率が上がったときに、原因がどこにあるかを自分たちで特定しづらくなります。自社のプロンプトの問題なのか、オーケストレーション層の更新なのか、プール内のどれかのモデル提供者側の障害なのか。ルーティング情報が公開されない以上、切り分けは提供元への問い合わせに頼ることになります。

これは「だから使えない」という話ではなく、運用体制の設計に反映すべき事実です。具体的には、自社側で入力・出力・レイテンシ・消費トークンを必ず記録しておき、「いつから変わったか」だけは自分たちで言えるようにしておくこと。問い合わせるときに、日時と再現する入力を添えられるかどうかで、解決までの時間がまったく変わります。

5. コストは単価ではなく実測で#

単価表だけを見ると、Fugu Maxの入力$2・出力$6は同クラスの単体モデルと比べて確かに安い部類です。ただし、内部で複数のエージェントが動く構成である以上、1つのリクエストを終えるまでに消費するトークン量が、単一モデルを1回呼ぶ場合と同じとは限りません。公式も、トークン使用量と対応するコストはリクエストごとに報告されるのでリアルタイムに把握できる、と案内しています。この報告値を使って、自社の代表タスク1件あたりの実費を出してから単価を掛けるのが確実です。加えて、OpenRouterの記載によれば推論は常時有効で、effortもhigh以上しか選べません。出力トークンが増えやすい前提でコストを見積もってください(いずれも再販側の記載である点は前述のとおりです)。

Fugu Ultra v2を検討する場合は、272Kトークンの段差も忘れないでください。長い会話履歴や大きなドキュメントを毎回投げる設計だと、コンテキストが272Kトークンを超えたリクエストから上位レートが適用され、入力は2倍、出力は1.5倍になります。履歴の圧縮や検索での絞り込みを先に検討する価値があります。

6. ロックインは消えるのではなく、位置が変わる#

「ベンダーロックインから守る」という主張は、半分は正しく、半分は言い換えです。個別のモデル提供者への依存は確かに薄まります。しかし代わりに、オーケストレーション層への依存が生まれます。Fuguの挙動に合わせてプロンプトやツール定義をチューニングすればするほど、そこから離れるコストは上がります。

救いは、OpenAI互換APIである点です。エンドポイントとモデル名を差し替えれば疎通までは進むので、比較検証も撤退も、独自SDKの製品よりはるかにやりやすい構造です。撤退容易性を保ちたいなら、次の2つを守るだけでかなり違います。1つは、アプリ側のコードをOpenAI互換の範囲に収め、Fugu固有のパラメータに深く依存しないこと。もう1つは、評価データセットと評価スクリプトを自社資産として持っておくことです。乗り換え判断が「勘」ではなく「数値」でできる状態を保つのが、いちばん強い保険になります。

買うか、作るか#

自作のマルチエージェント構成と比べて、どう判断すればよいのか。論点を整理します。

ざっくりした線引きとしては、こうなります。

買うほうが向くのは、タスクの種類が多様で事前に振り分け規則を書ききれない場合、社内にモデル評価を継続的に回す人がいない場合、そして委託先開示の制約が緩い用途です。「とりあえず良い答えが返ってくればよい」タスクの集合に対して自作のルーターで同等の振り分け精度を保とうとすると、モデルが更新されるたびに評価と調整をやり直す継続コストがかかります。

作るほうが向くのは、タスクの型が少なく固定的な場合です。「この帳票をこの形式に変換する」のような定型処理は、一番安いモデルで十分な精度が出るかを自分で確かめて固定したほうが、コストも再現性も勝ちます。また、委譲先を完全に把握する必要がある業務、レイテンシの上限が厳しい対話用途、ドメイン固有の検証ロジックを噛ませたい場合も自作側です。

そして、多くの現場にとって現実的な答えは「両方」です。定型で量が多い処理は自分たちで固定したモデルに流し、難易度が高く頻度の低い処理だけをオーケストレーターに投げる。この切り分けなら、コストの大半を占める定型処理の予測可能性を保ったまま、難所の品質だけを外部の仕組みに任せられます。

試すときの手順#

OpenAI互換であることは、検証の入口としては大きな利点です。次の順番で進めると、無駄が少なくなります。

向かない場面#

冷静に見て、今回のモデルを選ばないほうがよい場面もあります。

まず、委譲先のモデル提供者を完全に特定して説明する必要がある業務です。Fugu Ultra v2とFugu Maxはプールが固定で、リクエスト単位のルーティング情報も非公開です。この要件があるなら、無印Fuguでの除外設定かエンタープライズの個別契約を前提に相談するところから始まります。

次に、EU/EEA域内の利用者を含むサービスです。公式に提供対象外と明記されているため、技術的な評価以前の話になります。

応答速度が厳しく要求される対話用途も、素直な選択肢ではありません。複数エージェントの協調は応答時間を延ばす方向に働きます。この場合は、レイテンシと品質のバランス型として位置づけられている標準のFuguか、単一の高速モデルを検討するほうが合理的です。公式も標準のFuguについて、応答性の高いチャットボットや対話的な作業に適した標準モデルだと説明しています。

そして、タスクの型が固定されていて、すでに安い単体モデルで十分な精度が出ている処理も、わざわざ移す理由が薄いところです。オーケストレーションの価値は「どのモデルを使うべきか分からない」タスクで最も大きくなります。答えがすでに分かっている処理に高機能な振り分けを噛ませても、コストと不確実性が増えるだけになりがちです。

最後に、公開直後という時期そのものです。レート制限の実際の挙動、混雑時のレイテンシ、障害時の情報提供の速さといった運用面の情報は、しばらく使ってみないと分かりません。ミッションクリティカルな用途にいきなり載せる判断は避けるのが安全です。

よくある質問#

発表日(公式ブログの日付表記は2026年9月11日)、両モデルが同一のオーケストレーション基盤を2つの目的に最適化したものであるという説明、Fugu Maxが6つのベンチマークで総合最高スコア・10のうち7つでコストパフォーマンスのパレートフロンティアを拡張したという主張、出力料金がSonnet 5・GPT 5.6 Terra・Kimi K3より40〜60%低いという比較、Fugu Ultra v2のChartography 48.3(Opus 5は27.3、Fable 5は29.5)とDeepSWE 74.3、8つ中5つで単独最高または同率最高・8つ中7つでトップ2という整理、Fable 5/Fable 5.1/GPT-6-Astraをエージェントプールに含まないという注記、学習カットオフ20260828、4月から9月までの経緯、Fugu MaxがNVIDIA Nemotronファミリーを含むオープンウェイト・専門モデルを統合しているという説明、OpenAI互換APIでの即日提供とパラメータ1行での切り替えは、Sakana AI公式ブログ(sakana.ai/fugu-max-release/)の記載に基づきます。Fuguファミリー4モデルの位置づけ、TRINITYとConductorというICLR 2026論文への言及、従量課金の単価(Fugu Max: 入力$2/出力$6/キャッシュ入力$0.25、web_searchとweb_fetchは1回$0.007。Fugu Ultra v2: 入力$5/出力$30/キャッシュ入力$0.50、272Kトークン超で$10/$45/$1.00)、サブスクリプション3プラン($20/$100/$200)、複数エージェントでも料金を積み上げないという説明、ルーティング情報を設計上公開しないという記載、UltraとMaxのプールが固定で無印Fuguのみ除外設定が可能という記載、学習データ利用のオプトアウト、リクエストごとのトークン使用量とコストの報告、EU/EEA非提供、約2週間での更新方針は、Sakana Fugu公式製品ページ(sakana.ai/fugu/)の記載に基づきます。テクニカルレポートはarXiv:2606.21228(2026年6月投稿)で、記述の中心はFuguとFugu-Ultra(v1)です。オーケストレーター自体が訓練された言語モデルである点も同レポートの記載に基づきます。コンテキストウィンドウ1,000,000トークン、最大出力128,000トークン、入力モダリティ、対応パラメータは、公式ページに記載が見当たらなかったためOpenRouterのモデル情報に基づく再販側の記載です。東京に拠点を置く点と「Building Frontier AI in Japan」の掲出はSakana AI公式サイト(sakana.ai/)、海外メディアが9月10日付で報じている点はMarkTechPostの記事に基づきます。すべて2026年9月12日時点の確認です。

まとめ#

Fugu MaxとFugu Ultra v2は、「より賢いモデルが出た」という発表ではなく、「モデルを選ぶ層を製品として買えるようになった」という発表です。料金は公式ページで明示されており、OpenAI互換APIなので試すこと自体のハードルも低く、ここまでは素直に評価できます。

一方で、内部で複数モデルに委譲する構成は、業務に持ち込むときに独特の宿題を出してきます。どのモデルにデータが渡るかがリクエスト単位では見えないこと、UltraとMaxではプールを絞れないこと、EU/EEAでは使えないこと、レイテンシと出力がばらつき得ること、障害時の切り分けが提供元頼みになること。どれも致命的な欠陥ではありませんが、契約と運用の設計に反映しておかないと、後から説明に詰まります。

やることは、いつもと同じです。公式ページで料金と提供条件を確認し、法務と情報セキュリティの制約を先に潰し、自社の代表タスクで現行モデルと並走させて品質・実測コスト・レイテンシを測ります。そのうえで、定型処理は自分たちで固定したモデルに、難所だけをオーケストレーターに、という切り分けができないかを考えます。ベンチマークの順位表から入るのではなく、この順番で進めるのが、結局いちばん手戻りの少ない道筋だと考えています。