2026.07.28 AI

Sakana FuguをClaude Codeで使う設定手順｜公式対応でゲートウェイが不要になった接続方法と判断基準

Sakana AIは2026年7月24日、FuguのClaude Code向けインターフェースを公開しました。それまでClaude CodeからFuguを呼ぶには、OpenAI互換APIをAnthropic Messages形式へ変換するプロキシを自分で立てる必要がありました。公式対応によってこの変換層が要らなくなり、環境変数を数行そろえるだけで接続できます。この記事では、ランチャー方式と環境変数方式の2通りの手順、Opus・Sonnet・Haiku枠へのモデル割り当て、そしてClaude Codeがクローズドソースであることに由来する制約まで、実装計画に直結する条件を整理します。

まとめ：接続方法の要点と、移行するかどうかの分かれ目

変わったのは接続経路だけです。Fuguの中身が入れ替わったわけではなく、複数のモデルを単一のAPIの裏で束ねるオーケストレーションという性格はそのまま。追加されたのは、Anthropic Messages形式のリクエストを受け付けるエンドポイントに当たります。同じ日にFugu-Ultra v1.1も公開され、v1.0比で最大7.9ポイントの改善、ProgramBenchとTerminal Bench 2.1で伸びた一方、価格は据え置きと発表されています。

手順は2通りあります。インストールスクリプトを実行してclaude-fuguで起動する方法と、ANTHROPIC_BASE_URLとANTHROPIC_AUTH_TOKENを含む環境変数を手で設定する方法。前者は速く、後者はCIやコンテナに組み込みやすい。認証はANTHROPIC_API_KEYではなくベアラトークンとしてANTHROPIC_AUTH_TOKENを使う点が、書き間違えやすい箇所になります。

判断としては、すでにclaude-code-routerやLiteLLMでプロキシを運用しているなら、切り替える価値があります。管理対象がひとつ減り、変換層で起きていたリクエスト形式の不整合も消えるためです。一方、Claude Code側のUI表示は接続先の実態と一致しません。エフォートの選択やモデル名の表示はClaude Code内蔵の前提のまま出るため、画面表示を運用の根拠にしている現場では、その前提を先に外す必要があります。承認フローや課金管理を既存ゲートウェイに集約している場合も、移行の前に代替手段を決めてください。

2026年7月24日の変更内容｜Anthropic Messages互換エンドポイント

差分を正確に押さえると、移行の要否が判断しやすくなります。

前提となるFuguの提供形態｜1つのAPIの裏で複数モデルを束ねる構成

Fuguは単一のモデルではなく、裏側で複数のLLMに役割を割り振るオーケストレーションとして提供されています。呼び出し側からはひとつのモデルに見え、内部でどのモデルへ振るかはSakana AI側が決める設計です。コンテキストは全モデルで1,000,000トークン、入力はテキストと画像に対応し、並列のツール呼び出しと組み込みのweb searchも利用できます。

APIのベースURLはhttps://api.sakana.aiで、従来から提供されているのはOpenAI互換のチャット補完エンドポイント（/v1/chat/completions）とResponses API。APIキーはfish_で始まる文字列で、コンソールから発行します。料金プランやFugu Ultraのベンチマークといった本体側の条件はSakana Fuguの使い方とFugu Ultraの性能で扱っているため、本記事では接続の側だけを見ます。

従来の壁｜Claude CodeはAnthropic Messages形式しか叩かない

問題はクライアント側の仕様にありました。Claude Codeが標準で通信する相手はAnthropic Messages API、またはAmazon BedrockとGoogle Vertex AI経由のClaude。リクエストとレスポンスの構造がこの3系統に固定されており、OpenAI互換のエンドポイントをそのまま指定しても通りません。

両者の形式差は表面的なものではありません。システムプロンプトの置き場所、ツール定義のスキーマ、ストリーミングのイベント種別、思考ブロックの扱いがそれぞれ異なります。URLとモデル名を書き換えるだけでは動かず、間に翻訳する層が要る、というのが2026年7月23日までの状況でした。

迂回路だったLLMゲートウェイ｜変換プロキシの構成と運用負荷

この差を埋めるために使われてきたのが、claude-code-routerやLiteLLMプロキシです。ローカルにプロキシを立て、Claude Codeの接続先をそのプロキシへ向け、プロキシがAnthropic形式をOpenAI形式へ翻訳してSakana側へ転送する。AIゲートウェイとLLMゲートウェイの役割で整理されているとおり、複数モデルを1系統の窓口に集約する用途では合理的な構成でした。

ただし運用の手間は残ります。プロキシのプロセス管理、ポートの占有、バージョン追従、そして変換の取りこぼし。実際、公開されている検証記事ではFugu本体は動くもののFugu Ultra側でResponses変換のエラーが出たという報告もあり、変換層そのものが不具合の発生源になっていました。公式対応で消えたのは、まさにこの層です。プロキシのプロセス、ローカルポート、変換ロジックの3つを自前で抱える必要がなくなりました。

接続手順の選び方｜ランチャー方式と環境変数方式を使い分ける基準

目的が違うので、どちらを選ぶかは運用形態で決まります。

最短経路｜インストールスクリプトとclaude-fuguランチャー

手早く試すなら公式のインストールスクリプトを使います。curl -fsSL https://sakana.ai/fugu/install | bashを実行したうえでclaude-fuguを起動すると、必要な設定を済ませた状態でClaude Codeが立ち上がります。Codex向けには同じスクリプトからcodex-fuguが用意されており、対象ツールごとにランチャーが分かれる構成です。

注意点がひとつあります。claude-fuguランチャーは自動更新されません。Sakana側が新しいモデルへ対応した際、ランチャーを入れ直さないと新モデルを選べない場合があります。パイプ経由でシェルスクリプトを実行する形式でもあるため、社内の実行ポリシーによってはスクリプトを一度取得して内容を確認してから流す運用が要ります。

環境変数方式の設定手順｜公式が案内する変数一式と安全な入力方法

CIやコンテナ、あるいは既存のシェル設定に組み込むなら環境変数を直接指定します。公式が案内している内容は次のとおりです。

export ANTHROPIC_BASE_URL="https://api.sakana.ai"
export ANTHROPIC_AUTH_TOKEN="fish_..."
export ANTHROPIC_DEFAULT_OPUS_MODEL="fugu-ultra[1m]"
export ANTHROPIC_DEFAULT_SONNET_MODEL="fugu[1m]"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="fugu[1m]"
export ANTHROPIC_DEFAULT_FABLE_MODEL="fugu-cyber[1m]"
export CLAUDE_CODE_SUBAGENT_MODEL="fugu[1m]"

モデルIDに付く角括弧の表記は、公式の設定例に記載されているとおりの形です。この角括弧が何を指すかについての説明は、2026年7月28日時点の公開ドキュメントには見当たりません。意味を推測して書き換えると接続に失敗する可能性があるため、公式例のまま記述するのが安全です。ANTHROPIC_DEFAULT_FABLE_MODELに割り当てられているfugu-cyberは申請制のエンドポイントで、承認前は指定しても使えません。

API_KEYではなくAUTH_TOKENを使う理由｜認証ヘッダの違い

設定でつまずきやすいのがここです。公式は「ANTHROPIC_API_KEYではなく、ベアラトークンとしてANTHROPIC_AUTH_TOKENを使うこと」と明示しています。両者は同じ資格情報を渡す別名ではなく、送出されるHTTPヘッダが違うためです。

Anthropic APIの標準的なキー認証はx-api-keyヘッダを使い、ANTHROPIC_AUTH_TOKENではAuthorization: Bearerヘッダを使用。Sakana側が受け付けるのは後者です。ANTHROPIC_API_KEYにキーを入れると認証エラーで弾かれます。既存のAnthropic向け設定を流用する場合、変数名の置き換えを見落としがちな箇所なので、切り替え時に真っ先に確認してください。なお両方を同時に設定すると資格情報が二重に送られて失敗するため、片方は明示的に外しておく必要があります。

モデル割り当ての設計方法｜4つの枠とリーズニング強度の決め方

環境変数を眺めると分かるとおり、設計上の判断はモデルの割り当てに集約されます。

4つのモデル枠の意味｜Claude Codeの内部階層にFuguを載せる

Claude Codeは内部でOpus・Sonnet・Haiku・Fableという階層を持ち、場面に応じて使い分けます。公式の設定例は、この階層へFuguの各モデルを対応づける形になっています。計画や難所の推論に回るOpus枠へfugu-ultra、通常の実行に回るSonnet枠と軽量処理のHaiku枠へfugu、という配分です。

この割り当ては固定ではありません。コストを抑えたいならOpus枠にもfuguを当てて全体を1モデルに寄せられますし、逆に難所の成功率を優先するならSonnet枠までfugu-ultraへ引き上げる設計も取れます。Claude Code側で計画と実行にモデルを振り分ける発想そのものは既存の仕組みと同じで、割り当て先がFuguに変わっただけと捉えると設計しやすくなります。

サブエージェント枠の扱い方｜並列実行時にコストが効く処理の範囲

CLAUDE_CODE_SUBAGENT_MODELは、Claude Codeのサブエージェントが使うモデルを指定します。公式例ではfuguが当てられており、ここは意図のある設定です。サブエージェントは調査や検索の分担で複数同時に走ることがあり、上位モデルを当てると本数ぶんだけ費用が積み上がります。

ただしFugu側にも独自の性質があります。公式リポジトリの注記によれば、コーディネータとなるモデルの委譲はターン単位の逐次実行で、複数エージェントが同時並行で動く構成ではありません。Claude Code側で複数のサブエージェントを走らせる場合と、Fugu内部のオーケストレーションは別々の層で動くため、並列度を見積もるときは2層あることを前提にしてください。

リーズニング強度の使い分け方｜high・xhigh・maxの選択基準

Fugu側のモデルは推論の深さを段階で指定できます。fugu-ultra-v1.1はhigh・xhigh・maxの3段階、fugu-ultra-v1.0とfugu-cyberはhighとxhighの2段階。段階を上げるほど内部で費やすトークンが増え、応答までの時間も伸びます。

実務での落とし穴は、この強度をClaude Codeの画面から素直に操作できない点にあります。次章で触れるとおり、表示と実態がずれるためです。強度を明示的に管理したい場合は、画面の操作ではなく環境変数側でモデルIDを決め打ちする運用に寄せるほうが、意図した設定を保てます。

クローズドソース由来の制約｜表示ずれ・自動更新なし・2層のオーケストレーション

公式対応後も残る制約があります。原因はいずれも同じで、Claude Codeの内部をSakana側から変更できないことに由来します。

UIが実態とずれる｜エフォートスライダーとモデルピッカーの表示

公式ドキュメントは「Claude Codeはクローズドソースであるため、Sakana Fuguは公開されているANTHROPIC_*変数とサーバ側のゲートウェイを通じて全体を制御している」と説明しています。その帰結として、エフォートのスライダーやモデルピッカーといったUI要素は、Fuguの実際の能力ではなくClaude Code内蔵の前提を表示します。

一方で、実際に会話している相手のモデル、その応答、ストリーミング、ツール利用、サブエージェントは設定どおりに動作するとも明記されています。つまり挙動は正しく、表示だけが古い前提を映している状態です。運用上の影響は、画面のモデル名やエフォート表示をログや報告の根拠に使えなくなること。どのモデルへ振ったかを追いたいなら、Claude Codeの画面ではなくSakana側のコンソールで使用量を確認する運用に切り替えてください。

ランチャーは自動更新されない｜新モデル対応時の再インストール

先述のとおりclaude-fuguは自動で更新されません。Sakana側が新しいモデルを追加しても、ランチャー経由の利用者は入れ直すまで選択肢に現れない場合があります。Fugu-Ultra v1.1のように既存モデルの改良版が短い間隔で出る製品では、この差が効いてきます。

チームで使うなら、ランチャーの更新を誰がいつ行うかを決めておく運用が要ります。あるいは環境変数方式に寄せて、モデルIDを構成管理の対象にしてしまうほうが差分を追いやすい。個人の検証はランチャー、チームの共通環境は環境変数、という切り分けが現実的です。

互換性の差が残る範囲｜細部の挙動を自社ワークフローで確認する理由

公式リポジトリも「Claude Codeはクローズドソースであり、Fuguとの間に主として表示上の互換性の差がある」と述べています。表示上と限定されてはいるものの、どの機能でどう差が出るかの網羅的な一覧は公開されていません。プラグイン、フック、カスタムコマンドといった周辺機能まで含めて自社の使い方が保たれるかは、実際に回して確かめる工程が必要になります。

確認の順序としては、まず日常的に使うコマンドとツール実行、次にサブエージェントを含む長い作業、最後にCIなど無人で走る経路の順に広げると、影響範囲を切り分けやすくなります。いきなり共通基盤の接続先を差し替える進め方は避けてください。

採用判断の条件整理｜移行する場面と見送る場面を分ける具体的な基準

ここまでの条件を踏まえて、切り替えるかどうかを条件付きで整理します。

採用が見合う場面｜既存プロキシの置き換えと、コスト分散の検証

切り替える価値が明確なのは2つの場面です。1つ目は、claude-code-routerやLiteLLMでFugu向けのプロキシをすでに運用しているケース。公式エンドポイントに寄せれば、管理するプロセスがひとつ減り、変換層に起因する形式の不整合も消えます。移行の手間は環境変数の入れ替えが中心で、失うものはほぼありません。

2つ目は、単一ベンダーへの依存を分散させる前提で、コーディングエージェントの推論先を比較検討したいケースです。接続先の差し替えが環境変数だけで済むため、同じ作業を複数の推論先で走らせて品質と費用を測る評価が組みやすくなります。評価設計から本番のワークフローへの組み込みまでを社内リソースだけで回しにくい場合は、生成AI導入支援のように業務要件とモデル選定の両面を踏まえた外部の設計支援を挟む選択肢もあります。

見送るべき条件の整理｜導入を保留する4つの判断分岐と背景条件

次の条件のいずれかに当たるなら、現時点では切り替えません。様子見ではなく、条件が解消されるまで見送りという判断です。

  • 既存のLLMゲートウェイに承認フロー・監査ログ・部門別の課金按分を集約している：公式エンドポイントへ直結すると、その統制層を通らなくなる
  • Claude Codeの画面表示を作業ログや報告の根拠にしている：表示が接続先の実態と一致せず、記録として成立しない
  • 複数の推論先を1つのクライアントから動的に切り替える要件がある：環境変数はプロセス単位の指定で、ゲートウェイのようなルーティングは行えない
  • Fugu-Cyberを前提に設計している：申請制で、承認前はモデル枠に指定しても利用できない

優先順位をつけるなら、実務でまず引っかかるのは1つ目です。ゲートウェイを外すという判断は、モデル接続の話ではなく統制の話になります。技術検証より前に、承認と課金の経路をどこに置くかを決めてください。

移行設計の進め方｜接続先を段階的に移すための3つの検証手順案

切り替える場合、既存プロキシをいきなり停止する進め方は取りません。環境変数はプロセス単位で効くため、シェルのプロファイルではなく起動スクリプト側で指定すれば、従来の経路と新しい経路を同じ端末で併存させられます。

手順としては3段階に分けます。第1に、個人の検証環境で新経路を立て、日常の作業を1週間ほど回して差分を洗い出すこと。第2に、洗い出した差分のうち画面表示に依存していた運用を、コンソール側の使用量確認へ置き換えること。第3に、統制層の代替が決まってからCIや共通環境の接続先を移すこと。この順序であれば、変換層を外す利得を取りながら、統制を落とさずに移行できます。

よくある質問

Claude CodeからFuguへ接続する際に問い合わせの多い5点を整理します。

claude-code-routerやLiteLLMはもう不要になりますか？

Fuguへ接続する目的だけであれば不要になります。公式のAnthropic Messages互換エンドポイントが変換層の役割を担うためです。ただしゲートウェイを、複数のモデル提供元を1つの窓口に束ねる目的や、承認・監査・課金按分といった統制の目的で使っている場合は話が別になります。その場合はゲートウェイを残したまま、その配下でFuguを扱う構成のほうが整合します。切り替えの前に、ゲートウェイが担っている役割を接続変換だけに限定できるかを確認してください。

ANTHROPIC_API_KEYに値を入れてはいけないのはなぜですか？

送出されるHTTPヘッダが異なるためです。ANTHROPIC_API_KEYの送出先はx-api-keyヘッダ、ANTHROPIC_AUTH_TOKENの送出先はAuthorization: Bearerヘッダです。Sakana側が受け付けるのはベアラトークンの形式で、公式もANTHROPIC_AUTH_TOKENを使うよう明示しています。加えて両方を設定すると2種類の認証ヘッダが同時に送られ、リクエストが拒否されます。既存のAnthropic向け設定から移す場合は、旧変数を明示的に解除したうえで新しい変数を設定してください。

モデルIDの角括弧はそのまま書く必要がありますか？

公式の設定例に記載されている表記なので、そのまま書いてください。fugu[1m]やfugu-ultra[1m]という形で案内されています。この角括弧が何を意味するかについて、2026年7月28日時点の公開ドキュメントに説明は見当たりません。意味が分からないからと角括弧を外したり別の値に置き換えたりすると、モデルの解決に失敗する可能性があります。公式例からの逸脱は避け、疑問が残る場合はコンソールの設定ページで最新の記載を確認するのが確実です。

Fugu Ultraは接続できますか。以前は変換エラーが出るという報告がありました。

公式エンドポイント経由であれば、Fugu Ultraも設定例のとおりOpus枠に割り当てて使えます。報告されていた変換エラーは、LiteLLMプロキシがResponses APIの形式を変換する過程で発生したもので、自前の変換層に固有の問題でした。公式のClaude Codeインターフェースはその変換を経由しないため、同じ原因での失敗は起きません。ただし公式対応後の細部の挙動は自社のワークフローで確かめる前提を残してください。2026年7月24日にはFugu-Ultra v1.1も同時公開されており、v1.0比で最大7.9ポイントの改善が発表されています。

費用はどう変わりますか？

接続経路を変えても、Fugu側の課金体系そのものは変わりません。プロキシを自分で立てていた場合、そのプロキシを動かすホストの費用が浮くという差が出る程度です。費用に効くのはむしろモデル割り当ての設計で、Opus・Sonnet・Haiku・サブエージェントの4枠にfugu-ultraとfuguのどちらを当てるか、リーズニング強度をどの段階に置くかで総額が動きます。サブスクリプションと従量課金の条件、各モデルの単価といった本体側の料金体系は、Sakana Fuguの解説記事側で整理しています。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る