前回は、Sakana Fuguが「クラウドの集合知」であることを、実機の設定から確認しました。今回はその続きとして、自社のオンプレ機（Ubuntu＋Hermes Agent）でFuguを実際に走らせ、応答速度・動的ルーティング・通信先を計測しました。公開ベンチの順位ではなく、自分たちの手元で測った一次データです。
常駐エージェント基盤Hermes上で、FuguをOpenAI互換プロバイダ（model: fugu / provider: openai-api / base_url: https://api.sakana.ai/v1）として呼び出し、ワンショットで4種のタスクを投げました。本稿では、確実に取れた2タスク（自己説明・日本語要約）と通信先の計測結果を報告します。
まず、エンドポイントの名前解決から確認しました。
getent hosts api.sakana.ai → 8.233.232.167 api.sakana.ai
解決先は 8.233.232.167。これは社内ネットワーク（192.168系）ではなく、社外の公開IPです。さらに、Fuguを実行している最中に通信状況を監視すると、Hermesのプロセスが実際にこの外部IPへ接続を張っていることを確認できました。
ESTAB 192.168.1.200:44088 → 8.233.232.167:443 users:(("hermes",pid=30560))
社内機（192.168.1.200）から、Sakanaのクラウド（8.233.232.167:443）へTLS接続が確立されています。これは推測ではなく、実行中に観測した実際の接続です。AIに与えた入力——プロンプトの中身——は、この経路で社外へ送られます。前回「クラウドの集合知」と述べた点が、通信先という具体的な事実として裏づけられました。機密データをこの経路に乗せるべきでないことは、もはや設定の問題ではなく、観測された事実です。
応答時間は次のとおりでした（ワンショット、1回計測）。
・自己説明（モデル名とルーティング理由を問う）：8.55秒
・日本語要約（3行に要約させる）：7.82秒
注目すべきは、これらが決して重いタスクではないのに、いずれも約8秒かかっている点です。Fuguは「複数モデルを束ねるオーケストレーション」である以上、(1) どの下位モデルに振り分けるかを判断し、(2) その下位モデルを呼び出し、(3) 結果をまとめる、という多段の処理が走ります。そのオーバーヘッドが、シンプルな問いでも数秒の応答時間として表れます。リアルタイム性が要る対話よりも、多段の作業をまとめて任せる用途に向く——という性格が、数字からも読み取れます（実際、Fuguは待ち時間の長さが報じられることもあります）。
もっとも興味深かったのが、自己説明タスクへのFuguの回答です。Fuguは自らを「Sakana AI, Fuguオーケストレーションシステムの一部」と名乗ったうえで、こう説明しました。「本回答は単純な自己説明の質問で、ツール実行も複雑な推論も不要なため、軽量・高速な下位モデルを選択した。速度と効率を優先しつつ十分な品質を確保できると判断した」。
つまり、タスクの複雑さを見て下位モデルを動的に選ぶという、Fuguの中核機能が実際に働いていることを、出力からも確認できました。「一つのモデルの顔をしたマルチエージェント」は、看板倒れではなく、確かに内部で判断・振り分けを行っていたわけです。
日本語要約も自然で、与えた内容の要点（エンタメ業界特化・オンプレ生成AI・TRIAD）を3行で過不足なくまとめていました。実務での下書きや要約用途には十分な品質です。フロンティア級と肩を並べると報じられるだけのことはあります。
実測してみて、Fuguの像はより鮮明になりました。賢く、日本語も達者。動的ルーティングも本物。ただし本質はクラウドで、入力は社外（8.233.232.167）へ出る。そして応答は数秒オーダー。これは欠点ではなく、クラウドで集合知を実現するという設計から来る当然の帰結です。社外に出せる情報なら、Fuguは強力な選択肢になります。
一方、私たちが開発する「TRIAD」は、同じ“複数AIの合議”という発想を、社内（オンプレミス）で完結させます。データを外に出さず、通信先はゼロ。次回は、まったく同じ問いをローカルLLMに投げ、応答速度と「外部接続が出ないこと」を並べて比較します。クラウドの集合知と、ローカルの合議。両者の距離を、引き続き数字で確かめていきます。
※ 計測は2026年6月25日、自社環境（Ubuntu＋Hermes Agent v0.17.0、Fugu via api.sakana.ai）で実施。応答時間は1回計測の参考値。