DEV Community

Cover image for ApidogでサカナフグAPIをテストする方法
Akira
Akira

Posted on • Originally published at apidog.com

ApidogでサカナフグAPIをテストする方法

Sakana Fugu APIをApidogでテストするには、FuguのOpenAI互換エンドポイント /chat/completions にHTTPリクエストを作成し、Authorization: Bearer ヘッダーにAPIキーを設定し、model に fugu または fugu-ultra を指定します。FuguはOpenAIチャット形式に対応しているため、ApidogではSDKを入れ替えずに、リクエスト保存、SSEストリーム確認、レスポンス比較、usage の確認、レイテンシー測定まで一連の検証を実行できます。

今すぐApidogを試す

コードファーストでSDK統合を進めたい場合は、別記事のSakana Fugu APIの使用に関するガイドを参照してください。この記事では、Apidog上でFugu APIをテスト・観察する手順に絞って説明します。

Fuguでテストする対象

Fuguは、単なるチャットモデルではありません。Sakanaによると、Fuguは単一APIの背後で複数のLLMを動的に調整するマルチエージェント・オーケストレーションシステムです。委譲、エージェント間コミュニケーション、作業統合に特化したモデルが、自身の再帰的インスタンスを含む複数のLLMを必要に応じて呼び出します。

背景を整理したい場合は、Sakana Fuguとは何かを解説した記事も参照してください。

この設計では、通常の単一モデルAPIとは見るべきポイントが変わります。Apidogでは特に以下を確認します。

  • 応答時間：オーケストレーションホップが発生している可能性の代理指標
  • SSEデルタ：ストリーミング開始までの待ち時間とトークン出力の流れ
  • usage：親リクエストで計上されるトークン数
  • fugu と fugu-ultra の差分：同じプロンプトで品質・速度を比較

Fuguには同じエンドポイントを共有する2つの主要バリアントがあります。

  • Fugu：低レイテンシーを重視したバランス型。コーディング、コードレビュー、チャットボット、インタラクティブサービス向け。
  • Fugu Ultra：回答品質を重視。AI研究、論文再現、サイバーセキュリティ分析、文献・特許調査向け。

初期報道やベータ版では小型バリアントが「Fugu Mini」と呼ばれる場合がありましたが、リリースページでは Fugu と Fugu Ultra が使われています。実装時はコンソールに表示される正確なモデルIDを確認してください。

事前準備：ベースURLとAPIキーを取得する

Fuguはログインウォールの背後にあります。まず console.sakana.ai にGoogleまたはメールでサインインし、コンソールから以下をコピーします。

  • APIキー
  • ベースURL
  • 利用可能なモデルID

2026年6月22日時点では、ベースURLはSakanaの公開ページに掲載されていません。推測せず、必ずコンソールからコピーしてください。

この記事では、コンソールから取得したベースURLを次のプレースホルダーで表します。

<YOUR_FUGU_BASE_URL_FROM_CONSOLE>
Enter fullscreen mode Exit fullscreen mode

ApidogでFuguリクエストを作成する

Apidogで新しいプロジェクトを作成し、HTTPリクエストを1つ追加します。

1. 環境変数を作成する

APIキーをリクエストURLやボディに直書きしないでください。Apidogの環境変数に保存します。

例として Fugu Prod という環境を作成し、次の2つの変数を追加します。

変数名 値
fugu_base_url <YOUR_FUGU_BASE_URL_FROM_CONSOLE>
fugu_key Sakanaコンソールで発行したAPIキー

以降、リクエストでは次のように参照します。

{{fugu_base_url}}/chat/completions
Enter fullscreen mode Exit fullscreen mode 
Bearer {{fugu_key}}
Enter fullscreen mode Exit fullscreen mode

この構成にしておくと、ステージングキーと本番キーを切り替える場合も、リクエストを編集せずに環境を切り替えるだけで済みます。同様のパターンは、OpenRouterを使ったClaude Codeのウォークスルーでも使われています。

2. HTTPメソッドとURLを設定する

Apidogのリクエストで以下を設定します。

POST {{fugu_base_url}}/chat/completions
Enter fullscreen mode Exit fullscreen mode

ヘッダーは次の2つです。

Authorization: Bearer {{fugu_key}}
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode

3. リクエストボディを作成する

まずは非ストリーミングで基本動作を確認します。

{
  "model": "fugu",
  "messages": [
    {
      "role": "system",
      "content": "You are a concise API testing assistant."
    },
    {
      "role": "user",
      "content": "Summarize what an SSE delta is in two sentences."
    }
  ],
  "stream": false
}
Enter fullscreen mode Exit fullscreen mode

この形式はOpenAIチャット補完リファレンスと同じです。FuguのOpenAI互換エンドポイントでは、messages、model、stream などの基本構造をそのまま使えます。

リリース時点で報告されているモデルIDは次の通りです。

fugu
fugu-ultra
Enter fullscreen mode Exit fullscreen mode

ただし、fugu-ultra-20260615 のような日付付きIDが提供される場合もあります。モデルIDは変更される可能性があるため、実装では必ずコンソールで確認してください。

送信後、通常のチャット補完レスポンスが返ることを確認します。

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "..."
      }
    }
  ],
  "usage": {
    "prompt_tokens": 38,
    "completion_tokens": 120,
    "total_tokens": 158
  }
}
Enter fullscreen mode Exit fullscreen mode

このリクエストをApidogに Fugu balanced として保存します。

Ultraバリアント用リクエストを複製する

保存した Fugu balanced リクエストを複製し、model だけを変更します。

{
  "model": "fugu-ultra",
  "messages": [
    {
      "role": "user",
      "content": "Reproduce the core result of the Trinity coordinator paper in plain language and note one limitation."
    }
  ],
  "stream": false
}
Enter fullscreen mode Exit fullscreen mode

このリクエストを Fugu Ultra として保存します。

これで、同じエンドポイントに対して以下の2つの保存済みリクエストを持てます。

リクエスト名 model
Fugu balanced fugu
Fugu Ultra fugu-ultra

以降は、同じプロンプトを両方に送信して以下を比較します。

  • レスポンス内容
  • 応答時間
  • usage.total_tokens
  • ストリーミング開始までの時間
  • 回答品質の差分

複数リクエストの連鎖やアサーション設計については、APIテストオーケストレーションガイドも参考になります。

SSEストリーミングデルタを確認する

Fuguの挙動を観察するなら、ストリーミング検証が有効です。stream を true に変更します。

{
  "model": "fugu-ultra",
  "messages": [
    {
      "role": "user",
      "content": "Walk through a one-shot chess opening analysis, step by step."
    }
  ],
  "stream": true
}
Enter fullscreen mode Exit fullscreen mode

ストリーミング有効時、レスポンスは text/event-stream として返ります。ApidogではSSEストリームをリアルタイムに確認できます。

代表的なチャンクは次のような形式です。

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":" Sicilian"},"finish_reason":null}]}

data: [DONE]
Enter fullscreen mode Exit fullscreen mode

確認すべきポイントは以下です。

  • 最初の data: チャンクが返るまでの時間
  • delta.content がどの程度安定して流れるか
  • 最終チャンクで finish_reason が設定されるか
  • 最後に data: [DONE] が返るか

delta は増分トークンを運ぶオブジェクトです。最初のチャンクでは role が含まれることがあり、その後のチャンクで content が分割されて届きます。

Ultraで最初のデルタまでに長い待ち時間があり、その後トークンが安定して流れる場合、Fuguが回答前に内部でモデル群を調整している可能性があります。バランス型の fugu は、より直接的に回答するケースが多いため、ストリーミング開始が早い傾向があります。

usage を読んでトークン数を比較する

非ストリーミング呼び出しでは、レスポンス内の usage を確認します。

{
  "usage": {
    "prompt_tokens": 38,
    "completion_tokens": 412,
    "total_tokens": 450
  }
}
Enter fullscreen mode Exit fullscreen mode

Apidogで直接確認できるのは、Fugu APIに対する親リクエストのトークン数です。

注意点として、Fuguは自身を再帰的に含む複数モデルを呼び出すオーケストレーターです。そのため、usage はFuguへのリクエストに対する会計情報であり、内部で呼び出された可能性のあるすべての下流モデルの詳細を示すものではありません。

比較時は、同じプロンプトを fugu と fugu-ultra に送信し、次のように記録すると実装判断に使いやすくなります。

model prompt_tokens completion_tokens total_tokens response time
fugu
fugu-ultra

単一モデルのベースラインも同じApidogプロジェクトで比較したい場合は、Claude Fable 5 APIガイドも参照できます。

レイテンシーでオーケストレーションコストを測る

FuguをApidogでテストする目的の一つは、品質とレイテンシーのトレードオフを実測することです。

手順はシンプルです。

  1. Fugu balanced と Fugu Ultra に同じプロンプトを設定する
  2. それぞれを複数回実行する
  3. Apidogのレスポンス下部に表示される応答時間を記録する
  4. レスポンス内容と usage も合わせて比較する

通常、バランス型の fugu の方が早く返る傾向があります。Sakanaによると、fugu は低レイテンシーのインタラクティブ用途向けで、fugu-ultra は研究グレードの品質を重視します。

Ultraが遅い場合、その差分はオーケストレーションホップの可視化されたコストとして扱えます。つまり、単一パスで即答するのではなく、Fuguが内部で複数のモデルやエージェントを調整している可能性があります。

差分を確認しやすいプロンプトには、次のようなタスクが向いています。

  • 論文の要点再現
  • AutoResearch系の調査タスク
  • 機械設計の検討
  • 金融時系列予測
  • ワンショットチェス分析
  • セキュリティ調査の仮説生成

Sakanaは、特定アプリケーションでFuguがGemini 3.1 Pro、Opus 4.8、GPT 5.5を一貫して上回ると説明しています。ただし、Fuguはそれらのような外部モデルを呼び出し、出力を統合する可能性があるオーケストレーターです。したがって、これは単一モデル同士の単純な勝敗ではなく、「モデル群を調整するモデル」の結果として評価してください。

エージェントルーティングとガバナンスを検証する

Fuguのリリース情報では、エージェントプール内のモデルを交換可能にし、データやコンプライアンス上の理由で特定エージェントを除外できる仕組みが説明されています。

もしSakanaコンソールでエージェントプールやルーティング制御が公開されている場合は、次の流れで検証できます。

  1. コンソールで利用可能なエージェントまたはモデル条件を変更する
  2. Apidogで保存済みの Fugu balanced と Fugu Ultra を再実行する
  3. 応答内容、レイテンシー、usage を比較する
  4. ルーティング変更が回答品質や速度に影響したか確認する

研究背景としては、ICLR 2026の以下の論文が関連します。

Trinityは、Thinker、Worker、Verifierの役割を持つ小規模LLMコーディネーターを進化的に最適化するアプローチです。Conductorは、強化学習で訓練された7Bモデルが自然言語でエージェントを調整するアプローチです。

両者は手法もサイズも異なるため、同一視しないでください。また、論文上のパラメータ数を製品版Fuguに直接対応付けることは、公式情報がない限り推測になります。

ApidogでFuguをテストする利点

単発の curl でもFugu APIは呼び出せます。ただし、実装前の検証や継続的な比較にはApidogの方が扱いやすくなります。

Apidogでは次の作業を1つのプロジェクト内で行えます。

  • ベースURLとAPIキーを環境変数で管理
  • fugu と fugu-ultra のリクエストを保存
  • 同じプロンプトを複数バリアントに再送信
  • レスポンス履歴を保持
  • SSEストリームをライブ確認
  • usage と応答時間を比較
  • モデルIDやキー変更時に環境だけを差し替え

FuguのモデルIDが変わったり、ステージングキーから本番キーに切り替えたりする場合も、環境変数を更新すれば保存済みリクエスト全体に反映できます。

Fuguは、複数モデルを調整して1つの回答を生成するオーケストレーターです。Apidogでは、その振る舞いをブラックボックスのまま終わらせず、レイテンシー、ストリーミング、トークン数、レスポンス差分として観察できます。

まずは環境変数を設定し、fugu と fugu-ultra の2つのリクエストを保存してください。同じプロンプトを両方に送信し、オーケストレーションホップのコストと回答品質の差を自分のユースケースで確認するのが最短の検証手順です。

よくある質問

ApidogでFuguをテストするには、どのベースURLを使えばよいですか？

console.sakana.ai にサインインし、コンソールからベースURLをコピーしてください。2026年6月22日時点では、Sakanaは公開ページにホストを掲載していません。推測せず、Apidogの環境変数 fugu_base_url に保存し、次の形式で参照します。

{{fugu_base_url}}/chat/completions
Enter fullscreen mode Exit fullscreen mode

Fuguを呼び出すために専用SDKは必要ですか？

不要です。FuguはOpenAI互換エンドポイントを提供しているため、OpenAIチャット形式に対応するクライアントやツールであれば、ベースURLとAPIキーを変更するだけで利用できます。同じ考え方はOpenRouterを使ったClaude Codeガイドでも使われています。

Fuguのストリーミングレスポンスをテストするには？

リクエストボディで "stream": true を設定します。

{
  "model": "fugu",
  "messages": [
    {
      "role": "user",
      "content": "Explain SSE deltas briefly."
    }
  ],
  "stream": true
}
Enter fullscreen mode Exit fullscreen mode

レスポンスは text/event-stream として返り、data: チャンクに delta が含まれます。最後は data: [DONE] で終了します。ApidogではこのSSEストリームをリアルタイムに確認できます。

FuguとFugu Ultraの違いは何ですか？

fugu は低レイテンシーを重視したバランス型で、日常的なコーディング、レビュー、チャットボット向けです。fugu-ultra は回答品質を重視し、研究、論文再現、セキュリティ分析などの重いタスク向けです。どちらも同じ /chat/completions エンドポイントを使い、model フィールドだけが異なります。

Fugu Ultraが遅いのはなぜですか？

Sakanaによると、Fuguは必要に応じて複数モデルを調整します。Ultraは品質重視のため、より深いオーケストレーションが発生し、応答時間が長くなる可能性があります。Apidogで見えるレイテンシー差は、そのオーケストレーションホップの実測値として扱えます。

Fuguのベンチマーク結果は単一モデルの勝利ですか？

単純な単一モデルの勝利として扱うべきではありません。Fuguは、自身を再帰的に含め、他の最先端モデルを呼び出して出力を統合するオーケストレーターです。したがって、ベンチマーク結果は「モデル群を調整するモデル」の結果として読み、自分のプロンプトと制約で検証してください。

Top comments (0)