Sakana FuguをCodex・Claude Code・GitHub Copilotで使う設定メモ

前回の記事では、Sakana Fugu / Fugu Ultraの料金、性能、モデルプールの考え方を整理しました。

今回はその続きとして、実際にSakana Fuguを契約し、APIキーを手元の開発環境に設定して、Codex、Claude Code、GitHub Copilotでどこまで使えるのかを試しました。

結論から言うと、使えます。ただし「アプリ本体のモデルをFuguへ切り替える」というより、CLIやVS Code ChatのBYOK / Custom Endpoint機能を使って、Sakana APIに向けるという理解が近いです。

今回の前提

今回の環境は次の通りです。

項目	内容
Sakana API endpoint	https://api.sakana.ai/v1
API key	~/.config/sakana-fugu/.env に保存
確認できたモデル	fugu / fugu-ultra / fugu-ultra-20260615
Codex CLI	codex-cli 0.128.0
Claude Code	2.1.185
GitHub Copilot CLI	1.0.63
VS Code	1.125.1

Sakana公式のGet Startedでは、APIエンドポイントは https://api.sakana.ai、Chat CompletionsとResponsesの両方に対応すると説明されています。Codex向けには公式インストーラーも用意されています。参考: Sakana Get Started

ただし公式例の環境変数は SAKANA_API_KEY です。今回は複数のworktreeやCLIから共通で読みたいので、PC内のSakana専用ファイル ~/.config/sakana-fugu/.env に SAKANA_FUGU_API_KEY として保存し、ラッパースクリプト側をそれに合わせました。記事中の例はキー名を統一していますが、公式設定に寄せるなら SAKANA_API_KEY でも構いません。

mkdir -p ~/.config/sakana-fugu
chmod 700 ~/.config/sakana-fugu

# ~/.config/sakana-fugu/.env
SAKANA_FUGU_API_KEY=sk-...

chmod 600 ~/.config/sakana-fugu/.env

最初はリポジトリ直下の .env に置いていましたが、別worktreeで claude-fugu を実行したときに SAKANA_FUGU_API_KEY is not set and no parent .env contains it. になりました。複数の作業ディレクトリから使うなら、PC共通のSakana専用envに寄せたほうが安定します。

まずAPI単体で疎通する

最初にやったのは、Sakana APIそのものの確認です。

curl https://api.sakana.ai/v1/models \
  -H "Authorization: Bearer $SAKANA_FUGU_API_KEY"

この環境では、次の3つが返りました。

fugu
fugu-ultra
fugu-ultra-20260615

Chat CompletionsとResponsesの両方でも、最小プロンプトは通りました。

curl -X POST https://api.sakana.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SAKANA_FUGU_API_KEY" \
  -d '{
    "model": "fugu",
    "messages": [{ "role": "user", "content": "Reply with exactly: ok" }],
    "max_tokens": 80
  }'

curl -X POST https://api.sakana.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SAKANA_FUGU_API_KEY" \
  -d '{
    "model": "fugu",
    "input": "Reply with exactly: ok",
    "max_output_tokens": 80
  }'

ここで気づいたのは、max_tokens / max_output_tokens を極端に小さくすると、短い疎通確認でも途中で切れることがある点です。最初に 20 で試したときは、期待した文字列が途中で切れました。接続確認でも、少し余裕を持たせたほうがよさそうです。

Codex CLI: いちばん素直に動いた

Codex CLIは、Sakana公式のGet Startedに設定手順があります。公式インストーラーは次の形です。

curl -fsSL https://sakana.ai/fugu/install | bash

ただ、手元のCodex CLIは 0.128.0 で、公式ドキュメント上の設定は 0.141.0 を前提にしていました。そのため、公式リポジトリの設定ファイルを確認しながら、既存のCodex設定を壊さないよう手動で provider / profile を追加しました。

追加した考え方はこの形です。

[model_providers.sakana]
name = "Sakana API"
base_url = "https://api.sakana.ai/v1"
env_key = "SAKANA_FUGU_API_KEY"
wire_api = "responses"
stream_idle_timeout_ms = 7200000
stream_max_retries = 5
request_max_retries = 4

[profiles.fugu]
model = "fugu"
model_reasoning_effort = "high"
model_provider = "sakana"
model_catalog_json = "/Users/futoshi/.codex/fugu.json"

[profiles.fugu.features]
image_generation = false
apps = false

[profiles.fugu-ultra]
model = "fugu-ultra"
model_reasoning_effort = "high"
model_provider = "sakana"
model_catalog_json = "/Users/futoshi/.codex/fugu.json"

[profiles.fugu-ultra.features]
image_generation = false
apps = false

ポイントは features.image_generation = false と features.apps = false です。最初は既存のCodex設定に引っ張られて、Sakana APIへ image_generation tool が渡り、Supported values are: 'function' and 'custom' というエラーになりました。FuguをCodexで使う場合は、Sakana側が受けられるtool仕様に絞る必要があります。

最終的には、次のラッパーを用意しました。

codex-fugu exec "このリポジトリの構成を要約して"
codex-fugu-ultra exec "この差分をレビューして"

fugu / fugu-ultra の両方で応答を確認できました。一方で、Codexはエージェント実行時に大きなシステム文脈やツール文脈を持つため、短いプロンプトでも使用トークンはそれなりに大きくなります。小さな確認から始め、usageを見ながら使うのがよいです。

Fugu専用の指示ファイルはあるのか

設定を進めていて気になったのが、CLAUDE.md や AGENTS.md のように、Fugu専用のプロジェクト指示ファイルがあるのか、という点です。

結論として、少なくとも現時点で確認できた公式ドキュメントと公式GitHubリポジトリを見る限り、FUGU.md のような予約ファイル名は見当たりませんでした。

Fuguは、単体では「プロジェクトのファイルを探索して、特定のMarkdownを自動で読み込むエージェント実行環境」というより、OpenAI互換のResponses API / Chat Completions APIで呼び出すモデルです。公式Modelsドキュメントでも、Responses APIでは instructions フィールド、Chat Completions APIでは system / developer / user などの messages を渡す形として説明されています。参考: Sakana Fugu Models

そのため、プロジェクト指示ファイルを読むかどうかは、Fuguではなく、Fuguを呼び出しているツール側の責務として考えるのがよさそうです。

利用経路	指示ファイルの扱い
codex-fugu / Codex	Codex側が AGENTS.md を読む
Claude Code + Fugu	Claude Code側が CLAUDE.md を読む
VS Code Copilot + Fugu	VS Code / Copilot側のカスタム指示や AGENTS.md / Copilot instructions に依存する
API直叩き	ファイルは自動では読まれない。instructions や system / developer messageで渡す

一方で、Sakana公式のCodex設定では ~/.codex/fugu.json や ~/.codex/fugu.config.toml を作ります。これはFuguをCodexで使うためのモデルカタログやprovider設定であって、プロジェクトごとの作業方針を書く AGENTS.md の代替ではありません。参考: Sakana Fugu Get Started

実務上は、既存のAIコーディング環境に合わせて、Codexなら AGENTS.md、Claude Codeなら CLAUDE.md、CopilotならVS Code / GitHub Copilot側のinstructionを整え、そのツールの裏側でFuguを呼ぶ、という分担で考えるのが自然です。

Fugu Ultraのreasoning effortはhigh以上で使える

追記として、fugu-ultra に reasoning_effort を渡せるのかも実機で確認しました。

結論から言うと、使えます。ただし、一般的なモデルのように low / medium / high と細かく下げられるものではなく、少なくとも今回の確認では high / xhigh / max の3つだけが受理されました。

公式のModelsドキュメントでも、Responses APIでは reasoning.effort、Chat Completions APIでは reasoning_effort または reasoning.effort を使い、値は high / xhigh / max と説明されています。xhigh と max は同じreasoning effortとして扱われます。参考: Sakana Fugu Models

今回、fugu-ultra の chat/completions に対して実際に投げたところ、次のような挙動でした。

値	結果
high	成功
xhigh	成功
max	成功
low	400エラー
medium	400エラー
不正値	400エラー。無視はされない。

low / medium を渡すと、次のように拒否されます。

Invalid 'reasoning.effort': must be one of ('high', 'xhigh', 'max')

つまり、reasoning_effort は単に受け取って捨てられる飾りのパラメータではなく、Sakana API側でバリデーションされる実パラメータとして扱われています。

ツールごとの指定は、次のように考えると整理しやすいです。

経路	指定方法	注意点
直API / Copilot経路	reasoning_effort に high / xhigh / max を指定	low / medium は使わない
Responses API	reasoning.effort に high / xhigh / max を指定	公式docs上の基本形はこちら
Codex	model_reasoning_effort = "high" など	手元のglobal設定は xhigh。そのまま流れても許容内
Claude Code / LiteLLM	extended thinkingが reasoning_effort に変換される場合あり	LiteLLM側が low 相当を出すと400になり得るため注意が必要

Fugu Ultraは、そもそも複数エージェントを協調させる高推論寄りのモデルです。そのため「軽くreasoningを効かせる」というより、最小でも high から始まる設計だと捉えるのがよさそうです。

また、Fugu Ultraでは最終回答のtokenだけでなく、内部のorchestration tokensもusageに出ます。公式Pricingでも、orchestration tokensは最終的な料金計算に含まれると説明されています。xhigh / max を使うときは、品質だけでなく内部エージェント委譲が増え、コストやレイテンシにも影響し得る前提で見るのが安全です。参考: Sakana Fugu Pricing

Claude Code: LiteLLM proxyを挟めばFuguは動く

Claude CodeはAnthropic Messages API形式で動くツールです。Sakana FuguはOpenAI互換APIなので、そのまま ANTHROPIC_BASE_URL=https://api.sakana.ai/v1 にするだけでは合いません。

Claude Code公式ドキュメントでは、LLM gatewayがAnthropic Messages形式の /v1/messages などを提供する必要があると説明されています。参考: Claude Code LLM gateway configuration

そこで今回は、LiteLLM proxyを使いました。LiteLLMのドキュメントでも、Claude Codeから非Anthropicモデルを使う場合にLiteLLM proxyで形式変換する手順が案内されています。参考: Use Claude Code with Non-Anthropic Models

設定ファイルは次のようにしました。

model_list:
  - model_name: fugu
    litellm_params:
      model: openai/fugu
      api_base: https://api.sakana.ai/v1
      api_key: os.environ/SAKANA_FUGU_API_KEY
  - model_name: fugu-ultra
    litellm_params:
      model: openai/fugu-ultra
      api_base: https://api.sakana.ai/v1
      api_key: os.environ/SAKANA_FUGU_API_KEY
  - model_name: fugu-ultra-20260615
    litellm_params:
      model: openai/fugu-ultra-20260615
      api_base: https://api.sakana.ai/v1
      api_key: os.environ/SAKANA_FUGU_API_KEY

litellm_settings:
  drop_params: true

proxyはローカルの 127.0.0.1:4000 で起動します。

litellm \
  --config ~/.config/sakana-fugu/litellm.config.yaml \
  --host 127.0.0.1 \
  --port 4000 \
  --telemetry False

Claude Code側は、次の環境変数でproxyへ向けます。

export ANTHROPIC_BASE_URL=http://127.0.0.1:4000
export ANTHROPIC_AUTH_TOKEN=sk-sakana-fugu-local
export ANTHROPIC_MODEL=fugu
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1

ここでの ANTHROPIC_AUTH_TOKEN は、Sakana本体のAPIキーではありません。Claude Codeからローカルproxyへ渡すためのローカル用トークンです。ローカルproxy側で認証を必須にしない構成でも、Claude Code側の接続設定として値は入れておきます。Sakana本体のAPIキーは ~/.config/sakana-fugu/.env に置き、LiteLLM proxy側だけが読みます。

実際には毎回 export するのではなく、次のファイル群に分けました。

役割	ファイル	内容
APIキー	~/.config/sakana-fugu/.env	SAKANA_FUGU_API_KEY=...
モデル変換	~/.config/sakana-fugu/litellm.config.yaml	SakanaのOpenAI互換APIをLiteLLMへ登録
起動ラッパー	~/.local/bin/claude-fugu	proxy確認、環境変数設定、claude 起動
env読み込み補助	~/.local/bin/sakana-fugu-env	親 .env またはPC共通envからキーを読む
proxy起動補助	~/.local/bin/sakana-fugu-proxy	127.0.0.1:4000 でLiteLLM proxyを起動

~/.local/bin が PATH に入っていない場合は、シェル設定に追加します。

export PATH="$HOME/.local/bin:$PATH"

sakana-fugu-proxy は、グローバルenvから SAKANA_FUGU_API_KEY を読み、LiteLLM proxyをローカルだけで起動する薄いラッパーです。

#!/usr/bin/env bash
set -euo pipefail

source "$HOME/.local/bin/sakana-fugu-env"
load_sakana_fugu_key

exec litellm \
  --config "$HOME/.config/sakana-fugu/litellm.config.yaml" \
  --host "${SAKANA_FUGU_PROXY_HOST:-127.0.0.1}" \
  --port "${SAKANA_FUGU_PROXY_PORT:-4000}" \
  --telemetry False

claude-fugu は、proxyが起動していなければ自動起動し、Claude CodeがAnthropic Messages互換Gatewayとして見るための環境変数を入れてから claude を実行します。

#!/usr/bin/env bash
set -euo pipefail

source "$HOME/.local/bin/sakana-fugu-env"
load_sakana_fugu_key

host="${SAKANA_FUGU_PROXY_HOST:-127.0.0.1}"
port="${SAKANA_FUGU_PROXY_PORT:-4000}"
base_url="http://${host}:${port}"
export LITELLM_MASTER_KEY="${LITELLM_MASTER_KEY:-sk-sakana-fugu-local}"

if ! curl -fsS "${base_url}/v1/models" \
  -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" >/dev/null 2>&1; then
  mkdir -p "$HOME/.cache/sakana-fugu"
  nohup sakana-fugu-proxy >"$HOME/.cache/sakana-fugu/litellm.log" 2>&1 &
fi

export ANTHROPIC_BASE_URL="$base_url"
export ANTHROPIC_AUTH_TOKEN="$LITELLM_MASTER_KEY"
export ANTHROPIC_MODEL="${ANTHROPIC_MODEL:-fugu}"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1

exec claude --model "$ANTHROPIC_MODEL" "$@"

作成後は実行権限を付けます。

chmod +x ~/.local/bin/sakana-fugu-env
chmod +x ~/.local/bin/sakana-fugu-proxy
chmod +x ~/.local/bin/claude-fugu

これで、どのリポジトリからでも次のように実行できます。

cd /path/to/your/project
claude-fugu -p "このリポジトリの構成を3行で要約して"

実際にこのリポジトリで実行すると、feelflow-site/ がVercelデプロイ対象であること、Astro + Content Collections + MDXのSSG構成であること、Vite + React SPAからAstroへ移行中であることを、3行で返してくれました。リポジトリ内の AGENTS.md まで読めていることが分かる応答です。

対話モードで使う場合は、引数なしで起動します。

claude-fugu

fugu はClaude Code経由で動作確認できました。ただし fugu-ultra は、LiteLLMのResponses変換で created_at がないというエラーになりました。Sakana APIへ直接投げるとUltraは動くので、これはSakana Fugu Ultraそのものというより、LiteLLM経由の変換相性の問題に見えます。

したがって現時点では、Claude Codeではまず fugu を使うのが現実的です。

Claude公式アプリ: 通常利用では不可、Desktop 3Pなら可能性あり

Claude Codeとは別に、Claudeの公式アプリでSakana Fuguを使えるかも調べました。

まず、通常の claude.ai や、Claudeアカウントでログインして使う標準のClaude Desktopでは、Sakana Fuguをモデルとして追加する導線は見つかりませんでした。標準のClaude体験はAnthropic側のモデルを使う前提です。

一方で、Claude Desktopには Cowork on 3P という第三者推論モードがあります。Anthropicの公式ドキュメントでは、Claude DesktopをAmazon Bedrock、Vertex AI、Microsoft Foundry、または自前のGatewayに向けられると説明されています。参考: Cowork on 3P overview

Gatewayを使う場合、公式ドキュメント上の要件は次の通りです。

• GatewayはAnthropic Messages APIの POST /v1/messages に対応している必要がある。
• streamingとtool useへの対応が必要。
• GET /v1/models は任意。モデルIDがClaude系として認識されない場合は、inferenceModels を明示する。
• Gateway base URLは https:// である必要がある。

参考: Using Cowork on 3P with an LLM Gateway

つまり、Sakana FuguをClaude公式アプリで使うなら、Sakana APIへ直接向けるのではなく、Anthropic Messages API互換のGatewayを挟む必要があります。今回の手元ではLiteLLM proxyの /v1/messages 経由で fugu の疎通は確認できました。

curl -X POST http://127.0.0.1:4000/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-sakana-fugu-local" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "fugu",
    "max_tokens": 40,
    "messages": [{ "role": "user", "content": "Reply with exactly: ok" }]
  }'

ただし、Claude Desktopの3P設定画面はGateway base URLに https:// を要求します。いま手元のproxyは http://127.0.0.1:4000 なので、そのままでは公式アプリの設定値としては不足です。実際に使うには、ローカルHTTPS reverse proxy、社内Gateway、または公開しない前提の安全なHTTPS endpointを用意する必要があります。

また、fugu-ultra / fugu-ultra-20260615 は手元のLiteLLM Messages変換ではエラーになりました。Claude Desktop 3Pで試す場合も、まずは fugu から確認するのが現実的です。

GitHub Copilot CLI: BYOKで動くが、少し工夫が必要

GitHub Copilot CLIにはBYOK（Bring Your Own Key）の仕組みがあります。GitHub公式ドキュメントでは、COPILOT_PROVIDER_BASE_URL、COPILOT_PROVIDER_TYPE、COPILOT_PROVIDER_API_KEY、COPILOT_MODEL などの環境変数で任意のプロバイダーへ向けられると説明されています。参考: Using your own LLM models in GitHub Copilot CLI

素直に COPILOT_MODEL=fugu として試すと、最初はreasoning effortまわりで落ちました。

Invalid 'reasoning.effort': must be one of ('high', 'xhigh', 'max'), got 'medium'

このエラーは、Fugu側がreasoning effortを見ていないという意味ではなく、むしろ low / medium を許容しない形で明確にバリデーションしている、という手がかりになりました。

さらに --effort high を付けると、今度はCopilot CLI側が「そのモデルはreasoning effort設定をサポートしていない」と判断して落ちました。

最終的に動いたのは、Copilot CLIのモデル能力判定には既知のモデルIDを使い、実際にSakanaへ送るwire modelだけ fugu / fugu-ultra にする方法です。

export COPILOT_PROVIDER_TYPE=openai
export COPILOT_PROVIDER_BASE_URL=https://api.sakana.ai/v1
export COPILOT_PROVIDER_API_KEY="$SAKANA_FUGU_API_KEY"
export COPILOT_PROVIDER_WIRE_API=responses
export COPILOT_PROVIDER_MODEL_ID=gpt-5.4
export COPILOT_PROVIDER_WIRE_MODEL=fugu

copilot -p "このリポジトリの構成を要約して" --effort high

これはワークアラウンドです。Copilot CLI側の能力判定が将来変わる可能性はあります。ただ、今回の環境ではこの方法で fugu も fugu-ultra も通りました。

普段使い用には、次のラッパーを作りました。

copilot-fugu -p "このリポジトリの構成を要約して" --allow-all
copilot-fugu-ultra -p "この差分をレビューして" --allow-all

VS Code Copilot Chat: ここが一番詰まった

最後に、VS CodeのCopilot Chatです。ユーザー体験としては、ここが一番わかりやすいです。設定が通ると、モデルピッカーに Sakana Fugu が出ます。最終的な設定では、通常用の fugu と重い確認用の fugu-ultra の2つを並べる形にしました。

このスクリーンショットは Sakana Fugu の表示を確認した時点のものです。最終設定では同じCustom Endpointに Sakana Fugu Ultra も追加しています。モデルピッカーに表示されるだけでなく、Copilot ChatからSakana Fuguを選んで応答が返るところまで確認できました。VS Code側に反映されない場合は、設定後にVS Codeを再起動します。

VS CodeにはBYOK / Custom Endpointの仕組みがあり、Chatのモデルピッカーから独自エンドポイントを追加できます。公式ドキュメントではCustom Endpoint providerがChat Completions、Responses、Messagesの3種類のAPI typeをサポートすると説明されています。参考: AI language models in VS Code / Use your own language model key in VS Code

最初はSakanaのResponses APIへ直接向けました。

{
  "name": "Sakana Fugu Local",
  "vendor": "customendpoint",
  "apiKey": "sk-sakana-fugu-local",
  "apiType": "responses",
  "models": [
    {
      "id": "fugu",
      "name": "Sakana Fugu",
      "url": "http://127.0.0.1:4000/v1/responses",
      "apiType": "responses",
      "toolCalling": true,
      "vision": false,
      "streaming": true
    }
  ]
}

しかし、これではエラーになりました。

The 'previous_response_id' parameter is not accepted.
Please pass all conversation history directly in the 'input' field instead.

VS Code / Copilot Chat側はResponses APIで会話状態を継続するために previous_response_id を送ります。一方、今回確認したSakana APIはこのパラメータを受け付けませんでした。Sakana公式ドキュメントではResponses API自体はサポートされていますが、VS Code Copilot Chatの会話状態管理とは相性が悪い、というのが今回の結論です。

最終的に動いたのは、Chat Completions APIとして登録する方法です。

[
  {
    "name": "Sakana Fugu Local",
    "vendor": "customendpoint",
    "apiKey": "Bearer sk-sakana-fugu-local",
    "apiType": "chat-completions",
    "models": [
      {
        "id": "fugu",
        "name": "Sakana Fugu",
        "url": "http://127.0.0.1:4000/v1/chat/completions",
        "apiType": "chat-completions",
        "toolCalling": true,
        "vision": false,
        "streaming": true,
        "maxInputTokens": 200000,
        "maxOutputTokens": 32000
      },
      {
        "id": "fugu-ultra",
        "name": "Sakana Fugu Ultra",
        "url": "http://127.0.0.1:4000/v1/chat/completions",
        "apiType": "chat-completions",
        "toolCalling": true,
        "vision": false,
        "streaming": true,
        "maxInputTokens": 200000,
        "maxOutputTokens": 32000
      }
    ]
  }
]

ここでは、VS Codeから直接Sakana APIへ送るのではなく、ローカルのLiteLLM proxyを挟んでいます。理由は2つあります。

1. VS CodeのCustom EndpointにSakana APIキーを平文で置きたくなかった。
2. VS CodeとLiteLLMのAuthorizationヘッダー形式の差を、ローカルproxy側で吸収したかった。

最終的なproxyは 127.0.0.1:4000 のローカル限定で、Sakana本体のAPIキーは ~/.config/sakana-fugu/.env から読みます。ローカルproxyは認証なしにしましたが、これはループバックアドレスだけで使う前提です。外部から到達できるhostで認証なしproxyを立てるのは避けるべきです。

この2モデル構成にしておくと、普段の相談や軽い修正は Sakana Fugu、長めの差分レビューや設計相談は Sakana Fugu Ultra という切り替えがしやすくなります。VS Code側の表示名は自由に変えられるので、チームで使う場合は Fugu - daily / Fugu Ultra - review のように用途が分かる名前にしてもよさそうです。

また、VS Code公式のBYOK説明にもある通り、BYOKはChatやagent workflow向けで、標準のコード補完そのものを置き換えるものではありません。インライン補完や一部の埋め込み系機能は、引き続きGitHub Copilot側の機能に依存します。

最終的に使えるようになった範囲

今回の検証結果をまとめるとこうです。

ツール	Fugu	Fugu Ultra	備考
Codex CLI	動作	動作	provider / profile設定で利用
Claude Code CLI	動作	未確認扱い	LiteLLM経由。Ultraは変換エラー
GitHub Copilot CLI	動作	動作	wire_model を使うワークアラウンド
VS Code Copilot Chat	動作	動作確認済み	Chat Completions経由。Responsesは previous_response_id で失敗
Codexアプリ本体	不可	不可	このチャットモデル自体は切り替えられない
Claude公式アプリ（通常）	不可	不可	標準Claudeでは外部モデルを追加する導線なし
Claude Desktop 3P	疎通のみ	未確認扱い	HTTPSのAnthropic Messages互換Gatewayが必要。Ultraは変換エラー
GitHub Copilotの標準補完	不可	不可	BYOKは主にChat / agent workflow向け

使ってみた感想

Fuguは、OpenAI互換APIとして見るとかなり扱いやすいです。API単体、Codex CLI、Copilot CLIまでは比較的素直に動きました。

一方で、既存のAI開発ツールへ入れると、各ツールが想定しているAPI仕様の細部に引っかかります。今回で言えば、Codexはtool定義、Claude CodeとClaude Desktop 3PはAnthropic Messages形式、VS Code Copilot ChatはResponses APIの previous_response_id がポイントでした。

つまり「OpenAI互換APIだから全部そのまま動く」とは考えないほうがいいです。OpenAI互換APIは入口を揃えるには強いですが、agentツールはその上に独自の会話状態、tool calling、権限、usage管理を持っています。そこを1つずつ合わせる必要があります。

個人的には、まず次の順番で使うのがよいと感じました。

1. API単体で疎通確認する。 models、Chat Completions、Responsesを小さく試す。
2. Codex CLIで試す。 公式導線があり、Fugu / Ultraの両方を扱いやすい。
3. Copilot CLIで試す。 BYOKは便利だが、モデル能力判定まわりのワークアラウンドを前提にする。
4. Claude CodeはFuguから試す。 LiteLLM proxyを挟むため、変換層の相性を見ながら使う。
5. Claude公式アプリはDesktop 3Pを別枠で見る。 標準Claudeではなく、HTTPS Gatewayを用意してCowork on 3Pとして検証する。
6. VS Code Copilot ChatはChat Completionsで登録する。 fugu と fugu-ultra を両方登録し、ResponsesではなくChat Completionsにするのが今回の実用解。

まとめ

Sakana Fuguは、単一モデルというより、複数モデルを束ねるオーケストレーションAPIです。その性質上、CodexやCopilot CLIのような「モデルを指定してagentを動かす」ツールとは相性がよい一方、Claude Code、Claude Desktop 3P、VS Code Copilot Chatのように特定のAPI形式や会話状態管理を強く前提にするツールでは、proxyやAPI typeの調整が必要になります。

今回の検証では、Codex CLI、Claude Code CLI、GitHub Copilot CLI、VS Code Copilot Chatのいずれでも、少なくともFuguを実用可能な形で呼び出せました。Claude Desktop 3Pについては、Gateway要件までは整理し、手元のLiteLLM proxyでAnthropic Messages形式の fugu 疎通まで確認しました。特にVS Codeのモデルピッカーに Sakana Fugu が並ぶところまで到達できたのは、日常の開発導線としてかなり使いやすいです。

ただし、Fugu Ultraは reasoning_effort を high / xhigh / max の範囲で使える一方、low / medium に下げる使い方はできません。Responses APIの会話状態をどう扱うか、Copilot CLI側のワークアラウンドが今後も安定するかは、引き続き確認が必要です。まずは小さなタスクでusageを見ながら使い、チーム導入する場合はproxy設定とAPIキー管理を整えるのが現実的だと思います。

参考リンク

• Sakana Fugu — Multi-Agent System as a Model
• Sakana Fugu Get Started
• Sakana Fugu Models
• Sakana Fugu Pricing
• SakanaAI/fugu GitHub repository
• AI language models in VS Code
• Use your own language model key in VS Code
• Using your own LLM models in GitHub Copilot CLI
• Claude Code LLM gateway configuration
• Cowork on 3P overview
• Using Cowork on 3P with an LLM Gateway
• Cowork on 3P installation and setup
• Use Claude Code with Non-Anthropic Models - LiteLLM