Fuguが示した次のAI競争はモデル単体ではなくオーケストレーションである

AIモデルを選ぶとき、これまでは「どのモデルが一番強いか」を見がちでした。

コーディングならこのモデル。

長文推論ならこのモデル。

画像を含むならこのモデル。

しかし、AIエージェントが実務に入り始めると、この考え方だけでは足りなくなります。実際の仕事は、単一の能力で終わらないからです。

調査、設計、実装、検証、レビュー、修正、説明。

一つのタスクの中に、性質の違う小さな仕事が混ざっています。

Sakana AIが発表したFugu / Fugu-Ultraは、この問題を「最強の単一モデルを作る」方向ではなく、「複数のモデルやエージェントをタスクに応じて組み合わせる」方向で解こうとしています。技術報告はarXivでも公開されています。

この記事で見たいのは、ベンチマークの順位そのものではありません。

IT技術者にとって重要なのは、モデル競争が「単体性能」から「モデルをどう選び、どう分担させ、どう監査するか」へ移り始めている点です。

Fuguはモデルを使うモデルである

FuguとFugu-Ultraは、ユーザーの入力を受け取り、そのまま一つのモデルで答えるのではなく、背後にある複数のモデルやエージェントを使い分ける仕組みです。

Sakana AIの説明では、Fuguは速度を重視したモデル、Fugu-Ultraはより長い推論や複雑な作業を重視したモデルとして位置づけられています。

ざっくり言えば、違いは次のようになります。

仕組み	向いている仕事	主な考え方
Fugu	チャット、比較的短い推論、基本的なコーディング	速く、適切なワーカーモデルを選ぶ
Fugu-Ultra	長いコーディング、調査、複数段階の推論	タスクを分解し、複数エージェントで進める

Fuguは、入力や作業の流れに応じて、どのワーカーモデルを使うかを選びます。

Fugu-Ultraはさらに踏み込み、タスクをサブタスクに分け、必要に応じて複数のエージェントを並列に動かします。技術報告では、Fugu-UltraがConductorという仕組みを使い、サブタスク分解、エージェント調整、共有メモリを扱うと説明されています。

これは、単なるモデルルーターではありません。

「最初に一回だけモデルを振り分ける」のではなく、作業を分解し、途中で別のモデルやエージェントを呼び出しながら、最終出力へ進む構成です。

なぜ単一モデルでは足りなくなるのか

AIエージェントの仕事は、一見すると一つの依頼に見えても、中身は複数の判断に分かれます。

たとえば、次のような依頼を考えます。

管理画面にチーム別の権限フィルタを追加してください。
既存の検索条件とCSV出力にも反映してください。

この依頼には、少なくとも次の作業が含まれます。

• 既存画面の構造を調べる
• 権限モデルを理解する
• APIの検索条件を確認する
• UIを変更する
• CSV出力の仕様を確認する
• テストを追加する
• 既存ユーザーへの影響を考える
• セキュリティ上の抜けを確認する

このすべてを、同じモデルに同じ重さで任せる必要はありません。

単純なファイル調査や機械的な修正は、低コストのモデルで十分かもしれません。一方で、権限設計、仕様の矛盾、セキュリティ判断、最終レビューは、高性能モデルや人間の確認が必要になります。

つまり、現場で必要なのは「強いモデルを一つ選ぶこと」ではなく、次の設計です。

どの作業を
どのタイミングで
どのモデルまたはエージェントに渡し
どこで人間が止めるか

Fuguが示しているのは、この設計そのものをモデル側に持たせる方向です。

ベンチマークは強い。ただし読み方には注意がいる

Sakana AIは、FuguとFugu-Ultraについて、コーディング、科学知識、長文推論、エージェント型タスクなどで高い結果を示しています。

公式ページでは、Terminal-Bench、LiveCodeBench、SWE-Bench Pro、GPQA-Diamond、Humanity's Last Examなどの結果が紹介されています。技術報告でも、Fugu-Ultraが複雑なエージェント型タスクで強い性能を示したと説明されています。

ただし、IT技術者としては、ここをそのまま「すぐ本番採用できる」と読まない方がよいです。

理由は3つあります。

1. 評価結果はSakana AI側の報告であり、利用環境やタスク分布に依存する
2. オーケストレーションのレシピ、学習データ、基盤モデル、モデルプールの詳細はすべて公開されているわけではない
3. ベンチマークで強いことと、自社の権限、データ、監査、コスト制約に合うことは別問題である

特に、モデルオーケストレーション型のシステムでは、単体モデル以上に「何が起きたか」を追いにくくなります。

どのモデルが呼ばれたのか。

どのサブタスクを誰が担当したのか。

どの情報を見たのか。

どの段階で間違ったのか。

この追跡ができないまま本番業務に入れると、性能が高いほど危険になります。

価格表より先に見るべきもの

FuguはSakana API、OpenRouter、Vercelなどから利用可能とされています。また、Fugu-Ultraには入力、出力、キャッシュトークンごとの価格やサブスクリプションプランも示されています。

価格が公開されていることは重要です。

しかし、モデルオーケストレーションでは、単純に「100万トークンあたりいくら」だけを見ても判断できません。

見るべきなのは、次の総コストです。

コスト項目	具体的に見ること
モデル呼び出し	1つの依頼で何回モデルが呼ばれるか
並列実行	サブエージェントが同時に何本走るか
コンテキスト	長文履歴やコードベース情報を何度渡すか
キャッシュ	どの単位で再利用できるか
失敗時の再試行	やり直しでどれだけ膨らむか
レビュー	人間が確認する時間は減るか、増えるか
監査	ログ保存、追跡、説明のコストを払えるか

安いモデルを混ぜても、分解が下手なら総コストは下がりません。

逆に、高性能モデルを常に使うより、判断の重い部分だけに使う方が、品質とコストのバランスを取りやすくなります。

ここで重要なのは、モデル単価ではなく、ワークフロー単価です。

IT技術者が設計すべきモデルプール

Fuguのような考え方を自社のAI活用に取り入れるなら、最初に必要なのはモデルプールの設計です。

単に「使えるモデルをたくさん登録する」ことではありません。

どのデータなら、どのモデルに渡してよいかを決めることです。

たとえば、次のように分けます。

データ分類	利用可能なモデル例	ルール
公開情報	外部APIの高性能モデル、低コストモデル	比較的自由に利用できる
社内一般情報	契約済みモデル、ログ保存条件を確認したモデル	プロバイダと保持条件を限定する
機密情報	社内承認済みモデル、閉域環境、専用契約	外部送信を制限する
個人情報	原則として最小化、匿名化、または利用不可	人間承認と記録を必須にする
本番権限に関わる情報	高性能モデル + 人間承認	自動実行させない

モデルオーケストレーションで危ないのは、ルーターやエージェントが便利さを優先して、意図せず別プロバイダへ情報を渡すことです。

「このタスクはこのモデルが得意そうだから呼ぶ」だけでは足りません。

「このデータをそのモデルに渡してよいのか」を先に判定する必要があります。

ルーティング条件はチームの設計資産になる

モデルオーケストレーションでは、ルーティング条件が重要になります。

これは、単なるプロンプトの工夫ではありません。チームの開発標準、セキュリティ標準、レビュー標準に近いものです。

たとえば、AIコーディングエージェントに次のようなルールを持たせます。

低コストモデルに任せてよい作業:
- 関連ファイルの探索
- lintやformatの修正
- テスト名やコメントの軽微な整理
- 既存パターンに沿った小さな実装
- ログやCI結果の要約

高性能モデルへ上げる作業:
- 仕様の解釈が必要
- 変更範囲が複数モジュールにまたがる
- テスト失敗の原因が一意に説明できない
- 設計判断や責任分界が必要
- セキュリティ、課金、個人情報、権限に触れる

人間承認を必須にする作業:
- 本番設定の変更
- 権限変更
- 顧客データの参照
- 外部送信
- デプロイ
- 監査ログの削除や変更

この表は、一度作って終わりではありません。

AIエージェントの失敗事例、レビュー指摘、コスト増加、セキュリティ指摘を見ながら更新します。

つまり、ルーティング条件は運用しながら育てる設計資産です。

ログは「使った証拠」ではなく「説明できる証拠」

モデルオーケストレーション型のAIでは、ログ設計が単一モデル以上に重要です。

残すべきログは、単に「AIを使った」という事実ではありません。

次のような情報が必要になります。

ログ項目	なぜ必要か
入力の分類	機密情報や個人情報を含んでいないか確認するため
呼び出したモデル	どのプロバイダに何を渡したか追跡するため
サブタスク	どの作業をどのエージェントが担当したか見るため
参照した情報	誤った前提や古い情報を検出するため
実行したツール	ファイル変更、外部アクセス、コマンド実行を追うため
失敗と再試行	コスト増加や品質低下の原因を見るため
人間承認	どこで人間が判断したかを残すため

ここが弱いと、事故が起きたときに原因を説明できません。

「AIがそう判断した」では、組織の説明責任を果たせません。

AIエージェント時代のログは、操作記録であると同時に、責任分界を示す証拠です。

自社導入で最初に作るべきチェックリスト

Fuguのようなオーケストレーション型AIを見たとき、すぐに本番業務へ入れるより、まずは自社の受け皿を確認した方がよいです。

最低限、次の項目を確認します。

モデルプール
- 使ってよいモデル一覧がある
- プロバイダごとのデータ保持条件を確認している
- 機密情報を渡してよいモデルと渡してはいけないモデルを分けている

ルーティング
- タスク分類の基準がある
- 高性能モデルへ昇格する条件がある
- 人間承認に戻す条件がある
- コスト上限とタイムアウトがある

権限
- AIが読める情報を制限している
- AIが実行できる操作を段階分けしている
- 本番影響のある操作は自動実行させない

ログ
- 呼び出したモデルを記録している
- サブタスクとツール実行を追える
- 失敗、再試行、人間承認を残している

評価
- ベンチマークだけでなく自社タスクで評価している
- 成功率だけでなくレビュー負荷を測っている
- コストだけでなく手戻りと事故リスクを見ている

このチェックリストがない状態で、複数モデルを自動的に呼び分ける仕組みを入れると、便利さより先に不透明さが増えます。

モデルを選ぶ人から、モデルを束ねる人へ

Fuguの面白さは、特定のベンチマークで上位になったことだけではありません。

「モデルを使うモデル」という発想が、今後のAIシステム設計の中心になり得ることです。

これからのAI活用では、単一モデルの性能差だけを追う時代から、次のような設計力が問われる時代へ移ります。

• タスクを分解する力
• モデルごとの得意不得意を見極める力
• データ分類とモデル選択を結びつける力
• コスト、品質、速度を同時に見る力
• 失敗時に説明できるログを残す力
• AIに任せる範囲と人間が止める範囲を設計する力

AIモデルの競争は、これからも続きます。

しかし、現場のIT技術者にとって重要なのは、ランキングの一位を当てることではありません。

複数のモデル、複数のエージェント、複数のツールを、業務として安全に束ねることです。

Fuguが示しているのは、AIエージェント時代の次の論点です。

モデルを選ぶ時代から、モデルを束ねる時代へ。

その移行に備えるなら、まず作るべきものは新しいプロンプト集ではありません。

モデルプール、ルーティング条件、権限設計、監査ログ、そして人間が止める基準です。

---

作成日: 2026-07-03