Fugu、ARD、A2Aが示すAIエージェント時代の競争軸

Fugu、ARD、A2Aが示す「AIエージェント時代」の本当の競争軸

モデル単体の性能競争から、発見・通信・指揮レイヤーの競争へ

AIの競争は、単に「どのLLMが一番賢いか」という段階から、かなり別の局面に移りつつある。

これまでは、OpenAI、Anthropic、Google、Meta、xAI、Mistral、DeepSeekなどが、より大きく、より賢い基盤モデルを作る競争をしていた。もちろん、この競争はいまも続いている。だが最近の動きを見ると、次の主戦場は「モデルそのもの」だけではなく、「モデルやエージェントをどう探し、どう接続し、どう指揮するか」に移り始めている。

その象徴が、Sakana AIのFugu、Googleらが進めるA2A、そしてARDである。

この三つは似たように見えるが、実際には役割が違う。

最も短く言えば、

**ARDは探すための標準。 A2Aは話すための標準。 Fuguは指揮するための仕組み。**

である。

Fuguとは何か

Fuguは、Sakana AIが発表した「マルチエージェント・システムを一つのモデルAPIのように使う」仕組みである。

通常のLLMでは、ユーザーはGPT、Claude、Gemini、Kimi、Qwenなど、どのモデルを使うかを自分で選ぶ。しかしFuguは、その選択を内部で行う。タスクに応じて複数のモデルやエージェントを呼び出し、考える役、作業する役、検証する役のように分担させる。

つまりFuguは、単体モデルというより「モデル群の司令塔」に近い。

たとえば難しいコード修正であれば、あるモデルが問題を分解し、別のモデルが実装し、別のモデルが検証し、最後に統合する。Fugu Ultraでは、より多くの専門エージェントを使い、Kaggle、論文再現、サイバーセキュリティ分析、特許調査のような重いタスクを狙う。

ここで重要なのは、Fuguが「新しい基盤モデルそのもの」ではないという点だ。むしろ、複数の既存フロンティアモデルをどう組み合わせるかを学習した、クローズドなオーケストレーターである。

Sakana AIは、FuguがFable 5やMythos Preview級に近いスコアを出すと主張している。しかしそれは、「Fuguの中にFableが入っている」という意味ではない。むしろ、単体ではFableでなくても、複数モデルをうまく組み合わせれば、フロンティア級の結果に近づける可能性がある、という意味で重要である。

ただし、FuguはAI主権ではない

ここで注意すべきなのは、Fuguを「AI主権」の解決策として見るのは危ういということだ。

AI主権というなら、本来は、どのモデルを使うのか、データがどこへ送られるのか、どの国・企業・規制圏に依存するのか、監査できるのかが重要になる。

しかしFuguでは、内部でどのモデルが使われたかは基本的に見えない。通常版Fuguでは一部モデルの除外ができるが、Fugu Ultraでは性能のために固定のエージェントプールを使う。つまり、ユーザーから見ると、便利になる一方で、内部の制御権はSakana側に移る。

これは「単一ベンダー依存を下げる」可能性はあるが、「ユーザー自身が完全に制御できるAIになる」という意味ではない。むしろ、クローズドな基盤モデル群の上に、さらにクローズドな指揮層が重なる構造である。

だからFuguは、AI主権というより、AI利用の抽象化・ブラックボックス化をさらに進める商用オーケストレーション層と見るべきだ。

ARDとは何か

一方、ARDはFuguとはまったく違う。

ARDは、Agentic Resource Discoveryの略で、AIエージェントが外部のツール、スキル、MCPサーバー、他のエージェントを発見するための仕様である。

現在のAIエージェント開発では、使うツールをあらかじめ開発者が設定しておくことが多い。たとえば、GitHubを使うMCPサーバー、ブラウザ検索ツール、社内データベース、Slack連携、決算書検索ツールなどを、人間が手動で接続する。

しかし、エージェントが本当に自律的に仕事をするなら、「この仕事に使える能力はどこにあるのか」を自分で探せる必要がある。

ARDは、そのための発見レイヤーである。

たとえるなら、AIエージェント用の検索エンジン、電話帳、DNS、あるいはアプリストアの入口に近い。エージェントが「このタスクにはどんなツールが必要か」を考え、ARDを通じて外部の能力を検索し、信頼できるかを確認する。

重要なのは、ARD自体は知能ではないということだ。ARDは、エージェントが能力を探すための道であり、地図であり、索引である。

A2Aとは何か

A2Aは、Agent2Agentの略で、AIエージェント同士が通信・協調するための標準である。

たとえば、あるエージェントが「この企業の最新決算を分析してほしい」と別のエージェントに依頼する。相手は作業を受け取り、途中経過を返し、必要なら追加情報を求め、最終的な成果物を返す。

このようなエージェント間の業務依頼、進捗管理、成果物の受け渡しを標準化するのがA2Aである。

つまりA2Aは、AIエージェント同士の会話・依頼プロトコルである。

ARDが「誰を使えばよいか探す」仕組みだとすれば、A2Aは「見つけた相手とどうやり取りするか」の仕組みである。

ここでMCPとの違いも重要になる。MCPは、エージェントがツールやデータに接続するための仕組みである。一方A2Aは、エージェント同士が互いに仕事を頼み合う仕組みである。

つまり、

MCPはツールを使う。 ARDはツールやエージェントを探す。 A2Aはエージェント同士が話す。 Fuguはどれを使うかを指揮する。

という関係になる。

個人でもFugu的なものは作れるのか

ここで面白いのは、Fuguが示した可能性である。

もしFuguが本当に、複数の既存モデルを組み合わせてFable級に近い結果を出せるなら、それは「最強の単体モデルを持たなくても、組み合わせ次第でフロンティア級の作業能力に近づける」ことを意味する。

これは個人開発者や個人クリエイターにとって重要だ。

個人でも、複数のLLM APIやローカルLLMを使い、役割分担させることはできる。

たとえば、

企画役のAI。 調査役のAI。 批判役のAI。 コードを書くAI。 テストするAI。 引用確認するAI。 最終編集するAI。

このように分ければ、単体モデルに全部やらせるより、精度は上がりやすい。

ただし、これは「個人がFable級の基盤モデルを作れる」という意味ではない。作れるのは、Fable級に近い作業体験を目指す「個人版Fugu的システム」である。

そして、そのためにはコスト、ログ、評価、失敗時の再試行、ツール安全性、検証役の設計が必要になる。複数モデルを回せば性能は上がるが、APIコストも増える。検証役が間違えることもある。複数モデルが同じ誤解を共有することもある。

だから重要なのは、単にモデルを増やすことではない。

どのタスクで、どのモデルを、どの順番で、何回使い、どの基準で止めるか。 ここが次の競争軸になる。

Gemini、ChatGPT、Claude、Fuguの違い

この話は、最近のGeminiやChatGPTの評価とも繋がる。

Geminiの問題は、単にモデルが弱いというより、Googleの持つ検索、YouTube、Gmail、Drive、Android、Cloud、NotebookLMのような強い部品が、一人の信頼できる作業AIとして十分に統合されていない点にある。

ChatGPTの強さは、モデル単体だけでなく、検索、ファイル、コード、画像、ツール、推論、エージェント的実行が、一つの体験にまとまっている点にある。

Claudeの強さは、慎重な長文作業やコード作業、破綻しにくい文脈維持にある。

そしてFuguは、複数のモデルそのものを束ねる外部オーケストレーターである。

つまり、AIの競争はこう変わっている。

昔は、どのモデルが一番賢いか。 次は、どのAIプロダクトが一番作業しやすいか。 そしてこれからは、どのシステムが、どのモデル・ツール・エージェントを、どれだけ上手く指揮できるか。

AIインフラへの影響

この流れは、AIインフラ需要にも直結する。

単体モデルに一回質問するだけなら、推論コストは比較的読みやすい。しかしFugu Ultraのような仕組みでは、複数モデルが並列に考え、検証し、再試行し、長時間の作業を続ける。

つまり、AIの進化は必ずしも「一回の回答を安くする」だけではない。

むしろ、

より多く考える。 より多く試す。 より多く検証する。 より長く作業する。

という方向に進む。

これは、GPU、HBM、DRAM、NAND、CXL、ネットワーク、ストレージ、データセンター、電力需要にとって追い風になる。特に、エージェントが自動で調査、実験、コード生成、検証を回す時代になると、推論需要は人間のチャット回数よりもはるかに大きくなる可能性がある。

個人が一回質問するだけではなく、AIが裏側で十回、百回、千回と試行するようになるからだ。

まとめ

Fugu、ARD、A2Aは、それぞれ違うレイヤーにある。

ARDは、AIエージェントが能力を探すための発見レイヤー。 A2Aは、AIエージェント同士が仕事を依頼し合う通信レイヤー。 Fuguは、複数モデルをどう使うかを決める指揮レイヤー。

この三つが示しているのは、AIの競争が「モデル単体の性能」から、「AIシステム全体の設計」へ移っているということだ。

今後重要になるのは、単に大きなモデルを持っているかではない。

どの能力を探せるか。 どのエージェントと繋がれるか。 どのモデルをいつ使うか。 どれだけ検証するか。 どこまで透明性を保てるか。 誰がその指揮権を持つのか。

Fuguは性能を上げるが、ブラックボックス化も進める。 ARDとA2Aは相互運用性を高めるが、それ自体は知能ではない。 個人版Fuguは作れるが、評価とコスト管理が難しい。

つまり、これからのAIエージェント時代の本質は、「AIが賢くなる」だけではない。

AIが、他のAIを探し、呼び出し、使い分け、検証し、作業を継続する時代になる。

そしてその時、最も重要になるのは、モデルそのものだけではなく、モデル群を指揮する権限、透明性、コスト、そして信頼性である。

さらに深める: 競争軸は「最強モデル」から「最強の編成」へ移る

Fugu、ARD、A2Aを一つの流れとして見ると、AI競争の単位が変わっていることが分かる。これまでは、単一モデルのベンチマーク、コンテキスト長、推論能力、コード性能が中心だった。もちろん最上位モデルの能力は今後も重要である。だが、エージェント時代には、強いモデルを一つ持つだけでは足りない。

必要なのは、能力を探し、相手を選び、依頼し、結果を検証し、失敗時に別の経路へ切り替える編成能力である。

ARD: 使える能力を探す
  ↓
A2A: 見つけたエージェントに仕事を頼む
  ↓
MCP: ツールやデータを操作する
  ↓
Fugu型オーケストレーター: 誰に何を任せ、どう検証するかを決める

この構図では、モデルの賢さは必要条件であって、十分条件ではない。どのモデルをどの順番で使うか。どの専門エージェントに分担するか。どこで人間承認を挟むか。どのログを残すか。ここが、AIプロダクトの品質とコストを分ける。

透明性は性能と同じくらい重要になる

Fugu型の仕組みは、ユーザーにとって便利である。内部で複数モデルや専門エージェントが動き、結果だけが返ってくるなら、利用者はモデル選択に悩まなくてよい。しかし、企業利用や主権AIの文脈では、便利さだけでは足りない。

内部でどのモデルが使われたのか。データはどこへ送られたのか。どの国・企業・規制圏に依存したのか。途中の判断を監査できるのか。失敗した時、原因を追えるのか。

この透明性がなければ、オーケストレーションは性能を上げる一方で、責任の所在を見えにくくする。AIエージェント時代の重要な問いは、「誰が最も賢いか」だけではない。「誰が指揮権を持ち、その指揮をどこまで説明できるか」である。

二人の短い対話

絶ノイア: Fuguは便利だけれど、主権AIそのものではないですね。

Sil-Kathna: 便利な司令官が、民の選んだ王とは限らぬ。

絶ノイア: ARDとA2Aは、発見と通信を標準化する。でも知能そのものではない。

Sil-Kathna: 道と橋は、旅人の知恵ではない。だが旅人を遠くへ運ぶ。

絶ノイア: これからは、モデル単体ではなく、モデル群をどう編成するかが競争になる。

Sil-Kathna: ならば問うべきは、最も強い声ではない。どの合唱が、最後まで崩れぬかである。

観測メモ

• ARDは発見、A2Aは通信、MCPはツール接続、Fuguは指揮に近い役割を持つ。
• Fugu型の価値は、複数モデルを組み合わせて単体モデル以上の作業品質を狙える点にある。
• 一方で、内部モデル、データ経路、監査可能性が見えない場合、主権AIや企業統制とは緊張する。
• 個人版Fugu的システムは作れるが、コスト、評価、ログ、再試行、ツール安全性を設計しないと破綻しやすい。
• AIインフラ需要は、単発推論ではなく、多段の探索、分担、検証、再試行によって押し上げられる。

免責

この記事は市場観測とAIによる考察、キャラクター表現を含みます。内容は投資助言ではありません。判断は必ず一次情報とご自身の状況にもとづいて行ってください。

[1] Sakana Fugu — Multi-Agent System as a Model

[2] Announcing the Agentic Resource Discovery specification - Google Developers Blog

[3] Announcing the Agent2Agent Protocol (A2A) - Google Developers Blog