Googleがエージェント型アーキテクチャのスケーリング原則を発表
GoogleとMITの研究者が、マルチエージェントシステムのスケーリングに関する予測フレームワークを発表し、ツール調整のトレードオフを示して特定タスクに最適なエージェント型アーキテクチャを選択できるようにした。
キーポイント
スケーリング予測フレームワークの発表
GoogleとMITの研究者が共同で、マルチエージェントシステムのスケーリングに関する予測フレームワークを論文として発表した。
ツール調整のトレードオフの明示
このフレームワークは、エージェント間のツール調整にはトレードオフが存在することを示している。
最適アーキテクチャ選択への応用
フレームワークを活用することで、特定のタスクに対して最適なエージェント型アーキテクチャを選択できるようになる。
影響分析・編集コメントを表示
影響分析
この研究は、マルチエージェントシステムの設計と実装に理論的基盤を提供し、実務におけるアーキテクチャ選択を最適化する可能性がある。AIエージェントの実用化が進む中で、システム設計の効率化に貢献する重要な研究成果と言える。
編集コメント
マルチエージェントシステムの実用化が進む中、設計指針となるフレームワークの発表はタイムリーな研究と言える。ただし、具体的な実装例やベンチマークデータが記事からは読み取れない点が惜しい。
Google と MIT の研究者らが、マルチエージェントシステムのスケールアップに関する予測フレームワークを記述した論文を発表しました。このフレームワークは、ツール調整とトレードオフの関係があることを示しており、特定のタスクに対して最適なアジェンティックアーキテクチャを選択するために使用できます。
スケーリングモデルは、基盤となる LLM の「インテリジェンス指数」、単一エージェントのベースライン性能、エージェント数、ツールの数、調整指標など、システムのいくつかの予測要因に依存しています。研究者らは、このモデルにおいて 3 つの支配的な効果があることを発見しました。1 つ目はツール調整トレードオフで、多くのツールを必要とするタスクはマルチエージェントによるオーバーヘッドによりパフォーマンスが低下します。2 つ目はキャパシティ飽和で、単一エージェントのベースライン性能が特定の閾値を超えると、エージェントを追加しても得られるリターンは逓減します。3 つ目はトポロジー依存のエラー増幅で、集中型オーケストレーションはエラー増幅を低減します。また、最適な調整戦略はタスクに依存することも発見しました。金融推論では集中型オーケストレーションが有利ですが、ウェブナビゲーションでは分散型戦略の方が優れています。保持されたテストデータでの評価において、このスケーリングフレームワークは最適な調整戦略を 87% の精度で予測しました。Google によると:
Gemini のような基盤モデルが継続して進化する中で、当社の研究では、より賢いモデルがマルチエージェントシステムの必要性を代替するのではなく、むしろそれを加速させることが示唆されています。ただし、これはアーキテクチャが適切である場合に限りです。ヒューリスティックから定量的な原則へと移行することで、単に数が増えるだけでなく、より賢く、安全で、効率的な次世代の AI エージェントを構築することが可能になります。
Google チームは、システム内のエージェントがどのように協調するかという観点に基づき、異なるマルチエージェントアーキテクチャを以下のカテゴリに分類しました。独立型（independent）：エージェント間の協調がない形態；集中型（centralized）：エージェントが中央のオーケストレーターとのみ通信する形態；分散型（decentralized）：ピアツーピアによる協調を行う形態；そしてハイブリッド型（hybrid）：集中型と分散型のバランスを取る形態です。それぞれには、エージェント数や各エージェントあたりの反復回数などの構成パラメータに加え、計算量・メモリ複雑度、および大規模言語モデル（LLM: Large Language Model）の呼び出し回数など、異なる特性が備わっています。
image/filters:no_upscale()/news/2026/03/google-multi-agent/en/resources/1multi-agent-architectures-1772373213503.png)*マルチエージェントアーキテクチャ。画像出典：Google Research*
研究者たちが開発したスケーリングモデルは、9 つの予測変数とそれらの間の相互作用項に基づいた 20 項目からなる回帰モデルです。彼らは「明確なメカニズム的根拠のない相互作用」を除外し、「過学習を防ぐ」ようにしました。Google はこのモデルにはいくつかの限界があると指摘しています。特に、ツール依存度の高いタスクではマルチエージェント間の調整に非効率が生じることを指摘し、「ツール集約型タスク向けの専門的な調整プロトコル」の必要性を示唆しています。
Hacker News での論文に関する議論 discussion about the paper では、複数のユーザーがマルチエージェントワークフローにおける自身の経験を共有しました。あるユーザーは次のように書き込みました：
私は普段の仕事で多くのエージェントワークフローを構築しています。オーケストレーション戦略を決定する際に非常に成功していると感じているのは、計画フェーズの一部としてエージェントに推奨事項を尋ねるという手法です。この技術を用いてエージェント自身のパフォーマンス向上を手伝わせるというアプローチは、私にとってこの技術を効果的に活用するためのゲームチェンジャーとなりました。もちろん個人差はあります（YMMV）。私は主に Claude code を使用しているため、他のモデルについてはわかりません。
マルチエージェントシステムの協調とオーケストレーション戦略は、活発に研究されているトピックです。2025 年、InfoQ は Amazon Bedrock のための Amazon の マルチエージェント協調フレームワーク を取り上げました。これは、専門的なエージェントがスーパーバイザーエージェントの調整のもとで連携して動作することを可能にします。今年初め、InfoQ は Google のガイドを取り上げ、マルチエージェントシステムの 8 つの必須 設計パターン を概説しました。これは各パターンの具体的な説明と、Google の Agent Development Kit 用のサンプルコードを提供しています。
About the Author
## Anthony Alford
Anthony は Genesys で開発シニアディレクターを務め、カスタマーエクスペリエンスに関連する複数の AI および ML プロジェクトに取り組んでいます。彼はスケーラブルなソフトウェアの設計と構築において 20 年以上の経験を持っています。Anthony は電気工学の博士号を取得しており、専門分野はインテリジェントロボティクスソフトウェアです。また、人間-AI インタラクションや SaaS ビジネス最適化のための予測分析などの様々な課題に取り組んできました。
Show moreShow less
原文を表示
Researchers from Google and MIT published a paper describing a predictive framework for scaling multi-agent systems. The framework shows that there is a tool-coordination trade-off and it can be used to select an optimal agentic architecture for a given task.
The scaling model relies on several predictive factors of the system, including the underlying LLM's *intelligence index*; the baseline performance of a single agent; the number of agents; number of tools; and coordination metrics. The researchers found there were three dominant effects in the model: tool-coordination trade-off, where tasks requiring many tools perform worse with multi-agent overhead; capability saturation, where adding agents yields diminishing returns when the single-agent baseline performance exceeds a certain threshold; and topology-dependent error amplification, where centralized orchestration reduces error amplification. They also found that the best coordination strategy is task dependent: financial reasoning benefits from centralized orchestration, while web navigation does better with a decentralized strategy. When evaluated on held-out test data, the scaling framework predicted the optimal coordination strategy at 87%. According to Google:
As foundational models like Gemini continue to advance, our research suggests that smarter models don't replace the need for multi-agent systems, they accelerate it, but only when the architecture is right. By moving from heuristics to quantitative principles, we can build the next generation of AI agents that are not just more numerous, but smarter, safer, and more efficient.
The Google team classified different multi-agent architectures into the categories based on how the agents in the system coordinated: independent, where there is no inter-agent coordination; centralized, where agents communicate only with a central orchestrator; decentralized, with peer-to-peer coordination; and hybrid, with a balance between centralized and decentralized. Each of these has several configuration parameters, such as the number of agents, number of iterations per agent, etc, as well as different computational and memory complexities and number of LLM calls.
Multi-agent Architectures/filters:no_upscale()/news/2026/03/google-multi-agent/en/resources/1multi-agent-architectures-1772373213503.png)
*Multi-agent Architectures. Image Source: Google Research*
The scaling model the researchers developed is a regression model with 20 terms, based on nine predictor variables as well as interaction terms between the different predictor variables. They excluded "interactions without clear mechanistic justification...to avoid overfitting." Google notes that the model does have several limitations. In particular, they note that "tool-heavy" tasks cause inefficiencies in multi-agent coordination, and point toward the need for "specialized coordination protocols for tool-intensive tasks."
In a Hacker News discussion about the paper, several users shared their own experiences with multi-agent workflows. One wrote:
I’ve been building a lot of agent workflows at my day job. Something that I’ve found a lot of success with when deciding on an orchestration strategy is to ask the agent what they recommend as part of the planning for phase. This technique of using the agent to help you improve its performance has been a game changer for me in leveraging this tech effectively. YMMV of course. I mostly use Claude code so who knows with the others.
Collaboration and orchestration strategies for multi-agent systems is an active research topic. In 2025, InfoQ covered Amazon's multi-agent collaboration framework for Amazon Bedrock, which enables specialized agents to work together under a supervisor agent's coordination. Earlier this year, InfoQ covered Google's guide outlining eight essential design patterns for multi-agent systems, which provides concrete explanations of each pattern along with sample code for Google's Agent Development Kit.
About the Author
Anthony Alford
Anthony is a Senior Director, Development at Genesys where he is working on several AI and ML projects related to customer experience. He has over 20 years experience in designing and building scalable software. Anthony holds a Ph.D. degree in Electrical Engineering with specialization in Intelligent Robotics Software and has worked on various problems in the areas of human-AI interaction and predictive analytics for SaaS business optimization.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み