Slackで「ChatGPTが仕事に使える」と話題になり、社内でClaudeを併用しはじめ、画像はGemini、コードはCursor、トークン単価が気になってDeepSeekも触っている。気づけばAPIキーが6本、こんな状況になっていないでしょうか。正解を決めきれないまま、料金の請求だけが毎月積み上がっていきます。
そこに2026年6月22日、東京のSakana AIが「Sakana Fugu」を公開しました。オーケストレーションモデルで、Fugu自身は文章を生成せず、複数のフロンティアモデルを呼び分けて答えをまとめます。使い分けを人間の設計からモデル側に移す、これが根っこの設計思想です。
Fuguに使い分けを任せる路線と、Claudeを中心に据えDeepSeekで費用を抑え画像はGeminiやChatGPTに振る自前路線。決める前に、料金構造・ルーター選定・エージェント型ツールの内部設計を並べて見ます。
Sakana Fuguが提示した新しい選択肢
Sakana Fuguは軽量のFuguと高負荷向けのFugu Ultraの2系統で、コンソール console.sakana.ai からOpenAI互換エンドポイントとして呼べます。Sakana公式ブログ「One Model to Command Them All」によれば、Fugu自身が他のLLMを呼び分けて役割分担と統合を担うよう訓練された言語モデルです。複雑な問いでは、Fugu UltraがClaude MythosやGPT-5.5を自分の中で組み合わせて回答をまとめます。再帰的に自身を呼ぶ設計です。
価格はクラウドAPI経由のみ、OSS版はありません。gihyo.jpによれば、サブスクリプションは月20ドル前後から、エンタープライズは従量課金です。トークン単価そのものは非公開。CEOのDavid氏はNikkei Asiaの取材で、Anthropicがフロンティアモデルの輸出規制を強化した直後のタイミングだと認め、単一ベンダー依存をヘッジする製品と位置づけました。
「11ベンチマーク中10で首位」という公式主張は鵜呑みにしないほうが無難です。スコアの内訳は執筆時点で非公開、独立評価も出揃っていません。それでもFuguの登場で何が動いたかは押さえておく価値があります。
| 従来 | Fugu以後 |
|---|---|
| 利用側が複数モデルを切り替える | 1つのAPIに投げ、内部で切り替えが起きる |
| ルーター（OpenRouter等）を自社で組む | Fuguの料金にルーティングが含まれる |
| 単一ベンダーロックの不安 | マルチプロバイダ前提で設計 |
| 役割分担のプロンプト設計が必要 | 役割分担はモデルの責務 |
Fuguという製品自体が「使い分けは人間の設計より、モデルに任せた方が正しい」という仮説の検証装置です。この仮説が正しければ、ここ1年で各社が積み上げてきたルーター製品やマルチエージェントフレームワークの立ち位置は、Fugu型の統合モデルに置き換わります。数四半期後の勢力図で答えが出ます。
「自分で組む」マルチモデル運用の経済学
自前で複数モデルを束ねる路線も有力です。実務で動いているシステムの大半は、いまこちら側です。判断の起点は料金で、ここから設計の方向が決まります。
| モデル | 入力 / 1Mトークン | 出力 / 1Mトークン | 得意領域 |
|---|---|---|---|
| Claude Opus 4.7／4.8 | $5 | $25 | 長文脈の推論、エージェント、コード |
| Claude Sonnet 4.6 | $3 | $15 | 日常タスクのバランス |
| Claude Haiku 4.5 | $1 | $5 | 軽量ルーティング、要約 |
| GPT-5.5 | $5 | $30 | マルチモーダル、画像、汎用 |
| Gemini 2.5 Pro | $1.25 | $10 | 動画、長文脈、Google統合 |
| Gemini 2.5 Flash | $0.30 | $2.50 | 軽量タスク |
| DeepSeek V4-flash | $0.14 | $0.28 | コスト最小、コード、推論 |
DeepSeekとClaude Opusの単純比較で、入力は約36倍、出力は約89倍の差です。プロンプトキャッシュがヒットすると、入力差は1,000倍を超えます。同じ仕事をどちらに任せるかで、月額が3桁変わります。MindStudioは、Claudeをプランナー、DeepSeekとGemmaをワーカーに置く構成で、トークンコストを5〜10倍削減しつつ品質を保った事例を公開しました。John Rodriguesは個人開発のClaude Code環境にDeepSeekを噛ませ、年1,200ドルの請求を60ドルに落としています。
全部DeepSeekに投げれば安く済む、という単純な話ではありません。Stanfordの「FrugalGPT」論文は、安価モデルから順に試し品質スコアが閾値を下回ったときだけ上位モデルに昇格させるcascade設計で、GPT-4単独比の最大98%コスト削減を品質を保ちながら達成しました。LMSYSの「RouteLLM」もMT BenchでGPT-4性能を95%維持しつつ85%安く動かしています。AkitaOnRailsは逆に、手動でオーケストレーションを組んでOpus単独より3倍高くついた失敗を検証記事で公開しました。設計を誤ると逆効果に振れます。
役割分担のルーターをどう選ぶか
マルチモデルを束ねるルーター（ゲートウェイ）の選択肢も揃いました。得意分野が違うので、自社の運用と相性のいいものを選びます。
| 製品 | 形態 | 強み | 弱み |
|---|---|---|---|
| OpenRouter | 商用SaaS | 300以上のモデルを1つのAPIで、OpenAI互換 | クレジット購入時に約5.5%手数料 |
| LiteLLM | OSS（MIT） | 100以上のプロバイダ統一、フォールバック・コスト追跡内蔵 | 運用は自社、Proxyの保守が必要 |
| Portkey | 商用SaaS | 1,600以上のモデル、リトライ・サーキットブレーカー、観測性40指標 | 機能多く学習コスト高 |
| LangGraph | フレームワーク（OSS） | 状態付きグラフでの条件分岐、複雑なエージェント設計 | 軽い切替には過剰 |
| Vercel AI SDK | TypeScriptライブラリ | モデル文字列の差し替えだけで切替 | サーバー側の制御は別途 |
| AWS Bedrock | クラウドサービス | IAM・VPCと統合、エンタープライズ要件に強い | AWS依存、対応モデルに偏り |
軽く始めるならOpenRouterが圧倒的に楽です。OpenAIのSDKをそのまま使い、base_url を差し替えるだけで動きます。
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key="<OPENROUTER_API_KEY>",
)
resp = client.chat.completions.create(
model="anthropic/claude-opus-4.7",
messages=[{"role": "user", "content": "競合の決算資料を要約して"}],
)
print(resp.choices[0].message.content)OSS派でフォールバック制御まで持ちたいならLiteLLM、エンタープライズで観測性とSLAが要るならPortkeyかBedrock、複雑なエージェント分岐を組むならLangGraph。新規プロジェクトはOpenRouterで一通り検証し、運用が固まった段階でLiteLLMかPortkeyへ移すと、コストと工数の折り合いがつきます。
DeepSeekを噛ませる現実：Anthropic互換エンドポイントという伏線
中国語圏のコミュニティでは、Claude CodeにDeepSeekを噛ませる構成が一気に広がりました。きっかけは、DeepSeekがAnthropic互換エンドポイント https://api.deepseek.com/anthropic を公式に提供し、claude-opus-* を deepseek-v4-pro に、claude-sonnet/haiku-* を deepseek-v4-flash にマップする標準対応を出したことです。ANTHROPIC_BASE_URL を差し替えるだけで、Claude Code側のコードは一行も変えずにDeepSeekへ流せます。
GitHubで25,000以上のスターを集める claude-code-router、ゲートウェイの one-api ・ new-api は、この種のプロキシ運用を標準化しました。コスト削減に加え、中国国内からAPIへの支払いや接続制限を回避する用途でも、現地の開発者は広く使っています。
日本の業務でそのまま真似する前に、確認事項があります。Zennの運用ガイドが繰り返し指摘するように、DeepSeek APIに送ったデータは中国国内のサーバを経由します。機密データや個人情報を含むワークロードでは、法務とセキュリティ部門の判断が要ります。「安いからとりあえずDeepSeek」の前に、何のデータをどこに流していいかを社内規定で先に整理してください。
エージェント型ツールが採っているマルチモデル戦略
Claude CodeやCursorといったエージェント型のコーディングツールが、内部でどう複数モデルを使い分けているかも押さえておきます。各社の試行錯誤の結果は、自前で組むときの参考になります。
| ツール | マルチモデル戦略 | OSSモデル対応 |
|---|---|---|
| Claude Code | Sonnetをデフォルト、Haikuをサブエージェント用に推奨。frontmatterの model で個別指定 | 公式非対応（プロキシ経由で可能） |
| Cursor | Auto modeがタスクごとに最適モデルを自動選択、品質低下時は自動切替 | 公式リストに依存 |
| Windsurf（旧） | 自社のSWE-1.6を軽量タスクに、推論モデルが計画を担当 | Kimi K2.5などOSSも提供 |
| Aider | --model でメイン、--weak-model でコミット等の軽作業を分離 | LiteLLM経由でOSS自由 |
| Continue.dev | config.yaml でロール別（chat / autocomplete / embed / rerank）に分離 | Ollama / vLLM経由で任意のOSS |
| GitHub Copilot | Chatのモデルピッカーでユーザー手動切替 | 公式非対応 |
共通点は「重い推論用」と「軽量ルーティン用」の二段構成です。AiderとWindsurfは明示的で、コミットメッセージや要約のような軽い処理を安価モデルに逃がします。Continue.devはロールで分離し、autocompleteに専用モデルを当てます。CursorとCopilotは利用者が手で選ぶ前提で、ロール分離を積極的には打ち出していません。
自社のシステムをこの並びに当てると、選択肢は3つに絞れます。Cursor型で毎回手で選ぶ、Aider型でロール固定で組む、Continue.dev型でロールを増やして細分化する。エージェントの内部をどこまで分割するかは、運用負荷とコスト最適化のトレードオフです。
自分で組むか、Fuguに任せるか
自前で複数モデルを設計するか、Fuguのようなオーケストレーションモデルに任せるか。両者は補完関係にあります。目的と組織の状況で組み合わせます。
| 状況 | 選び方 |
|---|---|
| 新規にエージェントを作る、社内に設計知見がない | Fuguで始め、不満が出てから自前化を検討 |
| 既にClaude＋OpenRouter等で運用、コスト最適化が課題 | 自前ルーターを残し、DeepSeek連携を増やす |
| 機密データを扱う、中国経由を避けたい | 自前構成でAWS BedrockやAzure経由に統制 |
| 個別タスクの品質を最大化したい | 自前で各モデルに最適化したプロンプトを作り込む |
| 運用人員が薄い、本質的な開発に時間を使いたい | Fuguやマネージドルーターに任せて運用負担を下げる |
| 料金透明性とコスト予測を厳しく求められる | 自前ルーターで各モデルへの振り分けを可視化 |
2026年内は両方を並行で持つのが現実解です。Fuguは新しすぎてSLAも事例も揃っていません。自前で全部組むのは設計と運用の負担が重く、ROIも見えにくい段階です。重要な業務はOpenRouterやBedrock経由の自前構成で安定させ、新規ワークロードでFuguを試す。半年程度はこのハイブリッドで進めます。
健全な「振り分け率」とコスト監視の指標
マルチモデル運用に踏み込むと、必ず出る質問が「どのモデルにどれくらい振り分けるか」です。Tianpanの運用記事はフロンティアモデルへのエスカレート率15〜35%を健全なラインとしています。50%を超えると安価モデルの閾値が保守的すぎ、5%を切ると緩すぎてフロンティアの価値が出ません。
運用に入ったら、最低限3点を見ます。モデル別の費用、エスカレート率、品質スコア（ユーザーフィードバックや自動評価）。ダッシュボードに出ていないなら、そこを先に整えます。新しいモデルの導入は後です。Portkeyのような観測性付きゲートウェイか、LiteLLMの自前ダッシュボードで計測できる状態を作ってから、構成を動かしてください。
実装の落とし穴：3つの典型
手を動かすと必ずぶつかる落とし穴を、先に3つ挙げます。
1. モデルごとのプロンプト最適化を怠る。ClaudeとDeepSeekでは反応するプロンプトの形が違います。同じプロンプトを両方に投げて品質を比較し、Claude優位と結論を出す例の多くは、DeepSeek側のチューニング不足が原因です。AkitaOnRailsの失敗事例もここでした。
2. フォールバック設計を忘れる。DeepSeekで失敗したらClaude Opusへ、というシナリオを最初から組み込まないと、本番障害時に手作業の切り替えが発生します。LiteLLMやPortkeyにはフォールバックが標準で入っており、これを使わない理由はありません。
3. データの流れる先を整理していない。マルチモデルにすると、どのモデルが何のデータを受け取ったかが分散します。社内規定でNGなデータが、たまたまDeepSeek経由で送信されている、という事故が起きるのはこの構造です。送信先ごとのデータ分類を、最初に決めます。
まとめ
Sakana Fuguの登場で、複数モデルの使い分けを誰が担うかという問いが、製品の形で問い直されました。モデル自身が役割分担を判断する世界が、実装として動き始めています。この方向が定着すれば、Cursorのモデル切替やOpenRouterのルーティング設定も、統合モデルの内側に取り込まれていきます。
いま手を動かす作業はもっと地味です。料金構造を直視し、DeepSeekやGemini Flashなど安価モデルを役割分担で使い分け、OpenRouterやLiteLLMでルーティングを管理し、機密データの流れる先を整理する。Fuguはこの作業の代替ではなく、選択肢のひとつです。重要な業務は自前構成で安定させ、新規ワークロードや実験はFuguで試す。半年はこのハイブリッドで進めます。
自社のAIエージェント運用でモデル選定やコスト最適化を進めたいときは、DE-STKの初回相談（30分・無料）を壁打ち相手にお使いください。料金構造の試算、ルーター選定、データガバナンス設計まで一緒に整理できます。
よくある質問（FAQ）
Q. Sakana Fuguを使えば、もうOpenRouterやLiteLLMは要らなくなりますか？
A. 現時点は並存が現実的です。Fuguは内部で他社モデルを呼ぶため、機能はルーターと重なります。ただ、料金構造の透明性、フォールバック制御、モデルの自由選択、機密データの送信先制御では、OpenRouterやLiteLLMのほうが細かく握れます。重要な業務システムは自前ルーターで安定させ、Fuguは新規実験や軽量ユースケースで併用する。当面のバランスはこれです。
Q. DeepSeekを使うとどれくらいコストが下がりますか？
A. 単純比較で、入力はClaude Opusの約36分の1、出力は約89分の1です。全ワークロードをDeepSeekに移すのは品質リスクが大きすぎます。Claudeをプランナーやエスカレート先に残し、DeepSeekをワーカーや軽量タスクに振り分けます。公開事例では月額70%減・年額95%減のレポートもありますが、設計を誤ってOpus単独より3倍高くついたAkitaOnRailsの失敗例もあります。最初は20〜30%の振り分けから始めてください。
Q. 機密データを扱う業務でDeepSeekは使えますか？
A. データの分類と社内規定次第です。DeepSeek APIに送ったデータは中国国内のサーバを経由するので、個人情報・営業機密・顧客データなど、社外移転に制限がかかる情報は通常NG。社内ドキュメントの体裁チェック、OSSコードのリファクタ、外部公開資料のドラフト生成など、機密性の低いタスクは問題なく使えます。送信先ごとに「OK / NG」のデータ分類を先に文書化し、システム側でルーティングを強制してください。
Q. 画像や動画生成は、ChatGPTとGeminiのどちらを選ぶべきですか？
A. 用途と既存スタックで分かれます。画像生成はGemini 2.5 Flash Imageが1枚3.9セントと安く、Imagen 4は2〜6セントのレンジで品質も安定。OpenAIのgpt-image-2はテキスト連携の精度で評価が高く、ChatGPTで既に検証している組織は移植が楽です。動画はGoogleのVeo 3.1が秒40セント前後で、現状の有力候補です。ビジュアル系は実利用で試すのが早いので、各社の無料枠で代表的なプロンプトを比較してください。
Q. マルチモデル運用は、そもそも小規模チームでも始められますか？
A. はじめは 2 モデルの併用で十分です。Claude Opus を主軸、DeepSeek V4-flash を軽量タスク用の副軸、この 2 つを OpenRouter で切り替えるだけで、コスト効果は 5〜10 倍出ます。ルーターの選定・フォールバック・エージェント統合は、月 200〜500 タスクを超えてから検討で問題ありません。少人数チームでは、まず OpenRouter + Claude + DeepSeek の 3 点セットから始めるのが実装コスト最小の入り口です。
Q. Claude と DeepSeek のコスト差は、実案件でどのくらいになりますか？
A. 単純比較では入力 36 倍・出力 89 倍の差ですが、実案件では「振り分けの上手さ」で 3〜10 倍のレンジに収まるのが標準です。全ワークロードを DeepSeek に寄せると品質リスクが出るため、Claude をプランナー / エスカレート先、DeepSeek をワーカー / 軽量タスクに配分するのが典型的な組み方です。月額 100 万円のワークロードなら、適切な振り分け設計で月 20〜40 万円まで圧縮できる案件が多いです。詳細な計算方法は 生成AI 投資の ROI 計算 に整理しています。
Q. マルチモデル構成の予算を経営に説明する際、どう組めばよいですか？
A. ライセンス費（複数モデル契約）、社内人件費（ルーター設計・運用）、外部支援（初期の伴走）の 3 項目で内訳を示すのが経営層に伝わりやすい形です。単一モデル契約より一見コストが増えて見えますが、振り分けによる圧縮効果を数字で示せれば承認されやすい。予算配分の目安と経営説明のフォーマットは 生成AI 導入予算の使い方 に整理しています。
参考・出典
- Sakana AI公式「Sakana Fugu: One Model to Command Them All」 sakana.ai
- Sakana AI公式「Sakana Fugu Beta」 sakana.ai
- Nikkei Asia「Japan’s Sakana Fugu multiagent AI scores well against Fable 5, GPT-5.5」 asia.nikkei.com
- gihyo.jp「Sakana Fugu リリース」 gihyo.jp
- MarkTechPost「Sakana AI Launches Sakana Fugu」 marktechpost.com
- Anthropic 価格表 claude.com/pricing
- DeepSeek 価格表 api-docs.deepseek.com
- OpenAI 価格表 developers.openai.com
- Gemini 価格表 ai.google.dev
- FrugalGPT 論文（Stanford） arxiv.org/abs/2305.05176
- RouteLLM（LMSYS） lmsys.org
- OpenRouter Quickstart openrouter.ai
- LiteLLM GitHub github.com/BerriAI/litellm
- DeepSeek Claude Code 連携公式 api-docs.deepseek.com
- MindStudio事例 mindstudio.ai
- AkitaOnRails 検証記事 akitaonrails.com
- Tianpan「LLM routing と model cascades」 tianpan.co