2026年6月、Sakana AIが「Sakana Fugu」を一般提供しました。複数のAIモデルを束ねて“集合知”を引き出すオーケストレーションモデルで、上位の「Fugu Ultra」はフロンティア級と肩を並べると報じられています。私たちは日頃から日本産LLMとオンプレミスAIに取り組む立場として、このFuguを自社のオンプレ環境で実際に動かし、検証してみました。本コラムはその第一報です。
従来のAIは「1つの巨大モデルで何でもこなす」方向で進化してきました。Fuguの発想はその逆で、タスクに応じて最適なAIを選び、役割を分担させ、複数のモデルを動的に制御します。利用者は単一のAPIに依頼を投げるだけで、背後で複数モデルが連携する——いわば“一つのモデルの顔をしたマルチエージェント”です。特定ベンダーへの過度な依存（規制や提供停止のリスク）を避けられる点も、企業利用の利点として挙げられています。
検証には、常駐型のエージェント基盤「Hermes Agent」を使い、自社内のLinux機（Ubuntu）上で動かしました。Fuguの組み込みはシンプルで、HermesにOpenAI互換のプロバイダとして登録するだけです。実機の設定はこうなっていました。
model: fugu ／ provider: openai-api ／ base_url: https://api.sakana.ai/v1
つまりFuguは、OpenAI互換のクラウドAPI（api.sakana.ai）として提供されており、こちらは単一のエンドポイントに問い合わせるだけ。背後のモデル選択やルーティングは、すべてFugu側が引き受けてくれます。導入のしやすさは確かに魅力で、既存のOpenAI向けツールにそのまま差し込めます。
実機の構成を確認して、最も重要だと感じたのはこの一点です。Fuguはクラウドサービスであり、送信したプロンプトは外部（Sakanaのクラウド）へ出ていく、ということです。エンドポイントが api.sakana.ai である以上、AIに与えた入力——たとえば社内文書や顧客情報——は、自社のネットワークの外へ送信されます。これは欠点ではなく、クラウドAIである以上は当然の性質です。便利さの源泉が「世界中の優れたモデルを束ねること」にある以上、その束ね役はクラウドに置かれます。
ここに、用途を見極める分岐点があります。社外に出して差し支えない情報を、最高水準の集合知で処理したいなら、Fuguは非常に強力な選択肢です。一方で、「このデータは絶対に社外に出せない」という機密領域では、クラウド前提のFuguをそのまま使うことはできません。エアギャップ（ネットワーク遮断）やデータ主権を最優先する場面では、別のアプローチが必要になります。
強みは明確です。単一APIで複数モデルの集合知を得られること。特定の1社に依存しない構成にできること。そして、固定的な手順に縛られず、優れた新モデルが出ればプールに組み込んで全体が強くなっていくこと。これは「特化モデルを統合して強くする」という、私たち自身の方向性とも通じる考え方です。
留意点は、クラウド前提であることに尽きます。データの送信先（どのモデル事業者まで渡るか）の管理、レイテンシ（複数モデルを束ねる以上、待ち時間が伸びる場面もあると報じられています）、そして通信が前提である以上オフライン・エアギャップでは使えないこと。これらは「集合知をクラウドで実現する」というFuguの設計から自然に生じるトレードオフです。
Fuguの「複数AIの合議で精度を上げる」という発想自体は、まさに正しいと考えています。私たちが開発する「TRIAD（三賢AI評議）」も、独立した複数のAIが合議して結論を出すという点で、同じ系譜にあります。違いは置き場所です。Fuguがクラウドで集合知を実現するのに対し、TRIADは社内（オンプレミス）で合議を完結させ、データを一切外に出さない。Fuguはクラウドの集合知、TRIADはローカルの合議——この対比こそが、今回の検証で最も腑に落ちた点でした。どちらが優れているかではなく、扱うデータの機密性で使い分けるべきものです。
Sakana Fuguは、単一APIで複数モデルの集合知を引き出す、よくできたオーケストレーションモデルです。導入も容易で、ベンダーロックインを避けたい企業には有力な選択肢になります。ただし本質はクラウドサービスであり、入力データは社外へ出ます。機密データを扱うなら、その前提を理解したうえで用途を選ぶ必要があります。次回は、実際のタスク（コーディング・要約・推論）でFuguとローカルLLMを走らせ、精度・速度・通信の実測値を比較する予定です。クラウドの集合知と、ローカルの合議。両者の距離を、数字で確かめていきます。