Algorithm behind Gemini Enterprise Agent Designer

https://2026.gcts.jp/

Transcript

1. Algorithm behind Gemini Enterprise Agent Designer Asei Sugiyama
2. 自己紹介 杉山 阿聖 (@K_Ryuichirou) Software Engineer @ Citadel AI Google Developer Expert @ Cloud AI MLSE GenAIOps WG 機械学習図鑑 共著 事例でわかる MLOps 共著
3. The NeurIPS 2025 Experience 2025 年 12 月に参加した NeurIPS 現地にて "Our research: Heterogeneous Swarms" "Our product: Gemini Enterprise Agent Designer" ついにマルチエージェントシ ステムの「自動構築」が実用 化されるのかという期待
4. 本セッションの概要 Gemini Enterprise Agent Designer に搭載予定の自動構築アルゴリズ ム H-Swarm の背景にある研究の紹介 マルチエージェントシステムが必要となる背景: コンテキスト崩壊 複数の論文 (MLE-STAR, DS-STAR) に共通する設計パターンの抽出 H-Swarm の重厚長大さと、現実に直面するコストや制約の分析 スケーリング則から学ぶ「盲目的なエージェント追加」の弊害と、 真にスケールするための条件 組織論 (Team Topologies) を応用し、AI エージェントを「新たな同 僚」と捉える設計原則の提言
5. TOC イントロダクション: AI エージェントの時代 <- コンテキスト設計の原則: 責務の分離と疎結合 Google のマルチエージェント事例に学ぶ「成功パターン」 マルチエージェントシステムの「設計」を自動化する試み 現実的な設計指針: 組織論としてのアプローチ
6. イントロダクション: AI エージェントの時代
7. 本セクションの概要 単なるチャットボットから自律的な AI エージェントへの進化 Prompt Engineering から Context Engineering へのパラダイムシフト 単一エージェントへの知識集約が引き起こす「コンテキスト崩壊」 の課題
8. LLM から AI エージェントへの進化 LLM のプランニング能力の向上 (Gemini 2.0 / 3.0 等) ツール利用 (Tool Use / Function Calling) の標準化 単なるチャットボットから自律的に行動するエージェントへの変容
9. パラダイムシフト: Prompt から Context へ Prompt Engineering: ユーザーによる静的な指示書の作成と提供 Context Engineering: 動的かつ包括的な環境の設計への転換 ユーザーと共に試行錯誤し、知識を蓄積していく「パートナー」と しての存在 Ref: [2510.26493] Context Engineering 2.0: The Context of Context Engineering
10. Context Collapse (コンテキスト崩壊) 1/2 単一のエージェントへの知識・ツール・ルールの 詰め込みの限界 認知負荷の増大による機能不全とハルシネーショ ンリスクの向上
11. Context Collapse (コンテキスト崩壊) 2/2 具体例: 開発者の失敗談 (Reddit "I was wrong about Agent Skills" より) 自分の知識をすべてコンテキストファイルに書き出 すことによる機能不全 コンテキストの構造化・分割と、必要な知識を必 要なタイミングで読み込む設計
12. TOC イントロダクション: AI エージェントの時代 コンテキスト設計の原則: 責務の分離と疎結合 <- Google のマルチエージェント事例に学ぶ「成功パターン」 マルチエージェントシステムの「設計」を自動化する試み 現実的な設計指針: 組織論としてのアプローチ
13. コンテキスト設計の原則: 責務の分離と疎結合
14. 本セクションの概要 コンテキスト崩壊を防ぐための Divide & Conquer (分割統治) のアプ ローチ 適切な粒度にコンテキストを分割し、疎結合なシステムを構築する 設計原則 分割を支える技術要素の解説 (MCP, Skills, A2A) とそれらがもたらす 恩恵
15. 解決策: Divide & Conquer (分割統治) 責務を分離し、コンテキストを適切な粒度へと分 割するアーキテクチャ設計 全てを一度に解決せず、専門化された小さな単位 へ分解することによる課題解決 疎結合なシステム構築による各機能の独立性とタ スク精度の確保 コンテキストエンジニアリングの本質としての 「情報の交通整理」 Ref: [Context Engineering 2.0] Definition 4: Systematic design of context management.
16. MCP (Model Context Protocol) AI エージェントと外部のツール・知識を繋 ぐ標準的なインターフェース 全てのツールの実行方法を明示的に与える のではなく、実行に必要なリソースの呼び 出し方だけを提供 "God Server" の回避: ツール定義過多によ るコンテキストウィンドウ圧迫の防止 単一責任の原則に基づき、タスクに必要な サーバーのみを選択的に接続する設計 Ref: Anthropic Engineering Blog "Code execution with MCP"
17. Skills: 再利用可能な能力のパッケー ジ化 ツールとプロンプトを特定の役割として定 義し、再利用可能な単位とする標準仕様 頻繁に利用するワークフローのパッケージ 化によるプロンプトの冗長性の排除 Gemini CLI における同一コンテキスト内で の「便利なコマンド」としての利用 実行コンテキストの純度を保ち、無関係な 命令への「注意」の分散を防ぐ効果 Ref: Agent Skills Standard https://agentskills.io/
18. A2A (Agent-to-Agent) 専門家エージェント同士が直接対話・連携 するための通信プロトコル規格 情報隠蔽: 内部状態や思考プロセスを隠蔽 し、メッセージパッシングのみで連携 MCP よりも強力な隔離により、ドメイン 間の境界を明確に維持する設計 各エージェントが自律的に動作することに よる、システム全体の認知負荷の最小化 Ref: A2A Protocol Specification https://a2a-protocol.org/
19. 結論: マルチエージェントシステムの必然性 「コンテキスト崩壊」という課題を技術的に回避するための強力な 処方箋 疎結合な専門家ネットワークがもたらす、システムの高い拡張性と 信頼性の担保 単なる機能の拡張ではなく、LLM の特性から導かれる必然的なアー キテクチャの帰結 良いエージェント設計は、常に「良い分割」から始まるという事実
20. TOC イントロダクション : AI エージェントの時代 コンテキスト設計の原則 : 責務の分離と疎結合 Google のマルチエージェント事例に学ぶ「成功パターン」 <- マルチエージェントシステムの「設計」を自動化する試み 現実的な設計指針 : 組織論としてのアプローチ
21. Google のマルチエージェント事例に学ぶ 「成功パターン」
22. 本セクションの概要 先行事例 (MLE-STAR, DS-STAR) を通じたマルチエージェントの適 用パターンの理解 Google の研究に共通する設計原則「The Google Pattern」の抽出 モデル非依存のフレームワーク「PlanGen」による一般化 エージェントが機能するための絶対条件「評価可能性 (Evaluatability)」の重要性
23. MLE-STAR: Machine Learning Engineering (1/2) ターゲット: Kaggle コンペ ティション等の定量的評 価が可能な ML タスク 前提条件: 正解データ (Ground Truth) と実行環境 があり、スコアによる評 価が可能なこと Ref: [2506.15692] MLE-STAR: Machine Learning Engineering Agent via Search and Targeted Refinement
24. MLE-STAR: Machine Learning Engineering (2/2) Step 1: Web 検索による外 部知識の補完 Step 2: Ablation Study によ るボトルネックの特定 Step 3: 特定のコードブロ ックに対する局所的な改 善ループ Step 4: 2, 3 を繰り返す Ref: [2506.15692] MLE-STAR: Machine Learning Engineering Agent via Search and Targeted Refinement
25. DS-STAR: General Data Science (1/2) ターゲット: データ分析や 可視化など、正解が一つ ではないオープンエンド な課題 前提条件: LLM Judge によ る「計画の十分性」の主 観的評価が機能すること Ref: [2509.21825] DS-STAR: Data Science Agent via Iterative Planning and Verification
26. DS-STAR: General Data Science (2/2) Step 1: ファイル構造の要 約によるコンテキストの 把握 Step 2: Verifier で「計画の 十分性」の主観的評価 Step 3: Router でタスクの 追加・修正・完了の判断 Ref: [2509.21825] DS-STAR: Data Science Agent via Iterative Planning and Verification
27. 共通の設計原則 初期化 : ゼロから生成せず、環境 や外部知識を分析して高品質な初 期解を作成 診断的評価 : 成否だけでなく、ボ トルネックや計画の不備を具体的 に「診断」 根拠ある改善ループ : 診断結果に 基づき、局所的な修正と再検証を 繰り返す
28. パターンの抽象化: PlanGen (1/2) ターゲット: 数学・論理パ ズル・カレンダー調整等 の複雑な制約充足問題 前提条件: タスク難易度の 測定と、自然言語からの 制約条件の抽出が可能な こと Ref: [2411.02275] PlanGen: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories
29. パターンの抽象化: PlanGen (2/2) 多様な推論・計画タスク に適用可能な、モデル非 依存の一般化 難易度に応じた推論アル ゴリズムの動的選択 抽出された制約に基づく 厳格かつ多角的な検証 Ref: [2411.02275] PlanGen: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories
30. ループを回すための大前提: 評価可能性 改善ループを回すには、エージェント自身が出力の「良し悪し」を 判定できる必要がある 客観的評価 (MLE-STAR): 実行エラーや精度スコアといった明確な指 標による検証 主観的評価 (DS-STAR): スコアがない課題では、LLM 自身を「裁判 官」として妥当性を検証 適応的計算量 (PlanGen): 課題の難易度に応じて、ループの回数や探 索手法を動的に変える
31. TOC イントロダクション: AI エージェントの時代 コンテキスト設計の原則: 責務の分離と疎結合 Google のマルチエージェント事例に学ぶ「成功パターン」 マルチエージェントシステムの「設計」を自動化する試み <- 現実的な設計指針: 組織論としてのアプローチ
32. マルチエージェントシステムの 「設計」を自動化する試み
33. 本セクションの概要 「人手による設計」から「AI による自動最適化」への進化 重みを固定したままプロンプトと接続を磨く現実的なアプローチ (MASS) 接続構造とモデルの重みを同時に最適化する理想の極致 (H-Swarm) 自動構築技術が直面する「コスト」と「実用性」のトレードオフ
34. 実践的な自動設計: MASS (1/2) 概要 : 重み更新を伴わない、プロンプトとトポロジーの自動最適化 ターゲットタスク : 複雑な推論、多段 QA、コード生成 前提条件 : 検証用データセットを用いた探索が可能なこと (重みは 固定) 知見 : 複雑なトポロジーを組む前に「プロンプトを磨く」ことが最 も効果的 Ref: [2502.02533] Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies
35. 実践的な自動設計: MASS (2/2) 3 段階最適化 : 1. 個々のプロンプト最適化 (最優先) 2. ワークフロー (トポロジ ー) の探索 3. 全体の一貫性を保つ最終 調整 Ref: [2502.02533] Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies
36. 理想の極北: H-Swarm (1/2) 概要 : トポロジー (役割) とモデルの重みを同時に最適化する野心的 な試み ターゲット : 知識探索、複雑な推論、エージェントタスク全般 前提条件 : モデルの重みが更新可能であり、膨大な計算資源がある こと 特徴 : 各タスクに特化した「専用の脳と神経系」をゼロから構築す る Ref: [2502.13840] Heterogeneous Swarms: Jointly Optimizing Model Roles and Weights
37. 理想の極北: H-Swarm (2/2) 最適化メカニズム : Role-Step : 粒子群最適化 (PSO) による エージェント接続の動的変更 Weight-Step : 独自の貢献度指標 (JFK- score) に基づくパラメータ更新 これまでとは違い、モデルは固定ではな く、モデルとネットワーク・トポロジーを 最適化 Ref: [2502.13840] Heterogeneous Swarms: Jointly Optimizing Model Roles and Weights
38. H-Swarm 実用化における壁 評価可能性の前提 : 全てのタスクで定量・定性的な「評価」ができ るとは限らない 複雑性の増大 : モデルの管理が必要で、システムが複雑化する 環境構築のハードル : 「モデルを学習できる環境」の用意が必要 で、手軽さが失われる 費用対効果の疑問 : 1 タスクの最適化に A100 GPU 数時間の投資が 必要で割に合わない 結論 : Agent Designer に期待される「手軽さ」と、H-Swarm の要件 は現状乖離している
39. TOC イントロダクション: AI エージェントの時代 コンテキスト設計の原則: 責務の分離と疎結合 Google のマルチエージェント事例に学ぶ「成功パターン」 マルチエージェントシステムの「設計」を自動化する試み 現実的な設計指針: 組織論としてのアプローチ <-
40. 現実的な設計指針: 組織論としてのアプローチ
41. 本セクションの概要 エージェントを増やすことで直面する「性能劣化」のジレンマ マルチエージェントにおけるスケーリング則の基本原則 組織論 (Team Topologies) を応用した、認知的負荷を考慮した設計 魔法 (自動構築) を待つのではなく、手動で「良い分割」を行うた めの提言
42. Towards a Science of Scaling Agent Systems (1/4) 概要 : マルチエージェントの性能を左右する「スケーリング則」を 定量化した研究 目的 : 「エージェントを増やせば賢くなる」という期待の妥当性を 検証 規模 : 5 つのアーキテクチャ、180 の設定、4 つのベンチマークでの 大規模比較 Ref: [2501.12948] Towards a Science of Scaling Agent Systems
44. Towards a Science of Scaling Agent Systems (2/4) ターゲット : Web ナビゲーション、金融分析、複雑な計画、ワーク フロー 前提条件 (Agentic Evaluation) : i. 継続的な環境との対話 ii. 部分観測下での反復的な情報収集 iii. フィードバックに基づく適応的な戦略修正 Ref: [2501.12948] Towards a Science of Scaling Agent Systems
45. Towards a Science of Scaling Agent Systems (3/4) 単体精度が一定 (約 45%) を超えると、連携の恩恵 は消失または負に エージェントを増やすと 調整コストがメリットを 食い潰す 順序制約の強いタスクで は、全構成で性能劣化 Ref: [2501.12948] Towards a Science of Scaling Agent Systems
46. Towards a Science of Scaling Agent Systems (4/4) アーキテクチャ選定 : タスクの性質に応じた「使い分け」が最重要 逐次タスクや単一で十分 : 連携コストを避け「単一 (SAS)」を選択 並列可能かつツールが少ない : 「集中型 (Centralized / Hybrid)」で効 率化 複雑な探索が必要な場合 : 「分散型 (Decentralized)」で探索能力 警告 : 安全性が最優先なら、検証のない「独立型」は避けるべき Ref: [2501.12948] Towards a Science of Scaling Agent Systems
48. 推論のスケーリング則: 3 つの基本原則 1. Tool-Coordination Trade-off : ツールとエージェントの数に比例して 調整コスト増大 2. Limited Collaboration Gains : タスク分解性が低い場合、連携による 恩恵は限定的 3. Error Amplification : 検証なき連携は、個々の小さなエラーをシステ ム全体へ増幅させる Ref: [2501.12948] Towards a Science of Scaling Agent Systems
49. 提言: エージェントのための "Team Topologies" エージェントは「魔法」ではなく「新たな 同僚」: 人間の組織設計論を適用する 認知負荷の管理 : 1 つのエージェントに与 えるコンテキストと責務を厳格に制限 責任境界の明確化 : 境界づけられたコンテ キストによる、疎結合な自律性の確保 イネーブリングチーム : エージェントが活 動できるよう支援するガードレールを整備
50. まとめ
51. まとめ (1/2) コンテキスト崩壊への対処: 単一エージェントへの過度な知識集約 は機能不全を招くため、MCP や A2A を用いて責務を分離し、疎結 合なネットワークを構築することが不可欠である。 評価主導の設計パターン: Google の先行事例 (MLE-STAR 等) が示す ように、 「初期化」から始まり、評価可能性を前提とした「診断的 評価」と「根拠ある改善ループ」を回す設計が成功の鍵となる。 自動化の理想と現実の壁: H-Swarm のような構成や重みの自動最適 化は強力だが、莫大な計算コストや環境構築のハードルなど、現状 では実用ツールへの適用には高い壁が存在する。
52. まとめ (2/2) 盲目的なスケーリングの弊害: 「エージェントを増やせば賢くなる」 は誤りであり、タスクの性質によっては連携コストが能力を上回 り、かえって性能劣化を引き起こす。 組織論に基づく実践的設計: これらを乗り越えるため、魔法を待つ のではなく「Team Topologies」等の組織論を応用し、エージェント の「認知負荷の管理」と「責任境界の明確化」を人間が設計すべき である。
54. 参考文献 (References) Context Engineering 2.0: [2510.26493] Context Engineering 2.0: The Context of Context Engineering MLE-STAR: [2506.15692] MLE-STAR: Machine Learning Engineering Agent via Search and Targeted Refinement DS-STAR: [2509.21825] DS-STAR: Data Science Agent via Iterative Planning and Verification PlanGen: [2411.02275] PlanGen: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories MASS: [2502.02533] Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies
55. 参考文献 (References) H-Swarm: [2502.13840] Heterogeneous Swarms: Jointly Optimizing Model Roles and Weights Scaling Agent Systems: [2501.12948] Towards a Science of Scaling Agent Systems MCP: Model Context Protocol Specification (Anthropic / community- led) Skills: Agent Skills Standard (https://agentskills.io/) A2A: Agent-to-Agent Protocol (https://a2a-protocol.org/)