🕛 2026.5.4 19:03 文:ズバッとショウ

Sakana AI、商用マルチエージェント基盤「Sakana Fugu」β テスター募集を開始

Sakana AI、商用マルチエージェント基盤「Sakana Fugu」β テスター募集を開始
X はてブ LINE Feedly

国産 AI 大手の Sakana AI が、商用フラッグシップを公開した、という話。

Sakana Fugu という名前のマルチエージェント・オーケストレーション基盤の β テスターを、4 月 24 日付けの公式ブログで募集開始しています。要するに、複数のフロンティア基盤モデル(OpenAI / Google / Anthropic)を一つの「協調プール」として扱い、タスクごとに最適な組み合わせを動的に呼び出す仕掛けが API として外に出てくる、ということ。

なぜ重要か

ここがポイントで、Sakana AI は以前から「巨大モデルを単独で叩くより、役割の異なる複数エージェントを協調させる方が伸びる」という路線を採っており、Evolutionary Model Merge、AI Scientist、ShinkaEvolve、AB-MCTS と研究を積み上げてきました。Sakana Fugu はその研究路線を、外部に売れる商品として束ねた最初のプロダクト、という位置づけです。

日本発の AI 研究機関がフロンティアモデルの上に層を載せる戦略を取った、という事実は重い。要するに、GPT-5.4 や Claude Opus 4.6 に正面から対抗するのではなく、それらの上で動くオーケストレータで勝負するという話。

仕組みをやさしく言うと

Sakana Fugu 自身は 小規模なモデルで、「いまの問題はどのモデルに振るのが効くか」「複数のモデルにどう役割を割るか」を学習で覚えていく構造。重要なのは、人間がドメイン知識でルールを書くのではなく、Sakana Fugu が独自に「人間には思いつきにくい効率的な協調パターン」を発見していく点だと公式ブログは強調しています。

技術的なバックボーンは ICLR 2026 採択の 2 本——Trinity(進化的な LLM コーディネーター学習)と Conductor(自然言語ベースのエージェント指揮)——で、それを商品向けに改良したものが今回の Fugu。

いまの実力と限界

ベンチマークで Sakana が出している数字。fugu-ultra(フル版)が GPQAD で 95.1、LCBv6 で 93.2、SWEPro で 54.2。比較用に並んでいるのは Gemini 3.1(high)、GPT 5.4(high)、Opus 4.6(max)。3 ベンチマークすべてで fugu-ultra がトップ、というスコアです。

タスクGemini 3.1 highGPT 5.4 highOpus 4.6 maxfugu-minifugu-ultra
GPQAD94.490.992.792.495.1
LCBv690.392.192.490.493.2
SWEPro48.451.253.4*51.354.2

ただし注意点もあって、Opus 4.6 max の SWEPro 53.4 は Anthropic 独自スキャフォールドでの自己申告値で、Sakana 側の検証ではタイムアウトが多発したため公式値を採用、と但し書きが入っています。要するに、3 番目のスコアは横並びとは言いにくいセル。

これからどうなるか

提供形態は OpenAI 互換 API。GPT / Gemini / Claude を API で使っている既存ワークフローはほぼそのまま差し替えで動く設計、というのが β の売り。ラインナップは latency 重視の Sakana Fugu Mini 🐟 と、フル協調を回す Sakana Fugu Ultra 🐡 の 2 系統。応募はブログ末尾の Google Forms から。締切日について本ブログ記事中には記載がないため、興味があれば早めに出しておく、というのが現実的なところ。

だから何が変わるか

「フロンティアモデルを 1 個契約して使う」設計が現実解だった時代から、「複数フロンティアモデルを束ねて切り替えるレイヤを買う」設計が選択肢に入ってきた、という話。日本の AI スタートアップで OpenAI / Anthropic / Google の API キーを 3 本管理している現場には、このオーケストレータ層を商用で買う、という判断が今後出てきます。第 2 フェーズはどこのラボから出るか、見ものです。

Sakana AI 公式ブログ「Sakana Fugu」発表記事

Sakana Fugu β テスト 申し込みフォーム

arXiv — TRINITY: An Evolved LLM Coordinator(ICLR 2026、英語)

arXiv — Learning to Orchestrate Agents in Natural Language with the Conductor(ICLR 2026、英語)

みんなの反応

ろんぶん先生
(AI 研究者・大学准教授・30 代男性 / 仮名)

Trinity と Conductor の論文を読むと、Sakana Fugu の中身は「LLM 呼び出しグラフを学習で生成する」という、かなり攻めた設計。GPQAD 95.1 は確かに最強クラスだが、ベンチマーク 1 個の差というよりはオーケストレーション効率の積み上げで取りに行った数字、と読むのが正しい。学会と商用が同じ路線で動いているのは健全。
G
GPU貧乏エンジニア
(ML エンジニア・スタートアップ・20 代男性 / 仮名)

うちは OpenAI と Anthropic の API キーを並列で叩いて、タスクごとにルーティングを手書きしてる。fugu-mini が「latency 重視」を謳ってる時点で、内部実装は気になるが、OpenAI 互換エンドポイントだけで切り替えできるなら、検証コストはほぼゼロ。料金体系が β 時点で見えてないのは早めにつぶしたい。
呪文つかい
(プロンプトエンジニア・フリーランス・30 代女性 / 仮名)

「人間がドメイン知識で役割分担を書かない」を全面に打ち出すのは強気。プロンプト側で職人芸的に組んでた設計が、学習済みオーケストレータに置き換わる流れは大きい。逆に言うと、業務適合のチューニングは β テスター側のフィードバックでしか出てこないので、独自業務で使ってる人は応募する価値がある。
D
DD魔キャピタリスト
(VC・AI 特化ファンド・40 代女性 / 仮名)

国産 AI が「フロンティアモデル提供層」ではなく「オーケストレーション層」で勝負しに行った、という決断は VC 視点でも重要。日本のスタートアップが Sakana Fugu の上に業務特化エージェントを載せる、というレイヤ構造が成立すれば、海外資本に握られていない AI バリューチェーンを 1 本作れる。商用 SaaS の値付けが見えるタイミングが次の判断ポイント。
安全第一マン
(AI セーフティ研究者・40 代男性 / 仮名)

複数のフロンティアモデルを動的に呼び分けるオーケストレータ、というのは「どのモデルが何を答えたか」のトレーサビリティ設計が肝。Compliance や安全性の観点だと、各サブタスクのモデル選択ログがどう保存されるかが β 検証の重要ポイントになる。Trinity の論文側にもまだ開いている課題だと思う。
X はてブ LINE Feedly