- ADK のマルチエージェント システムは、モノリシックなプロンプトをモジュール式の連携エージェントに置き換えます。
- ワークフロー エージェント (シーケンシャル、ループ、パラレル) は、共有セッション状態を介して LLM とカスタム エージェントをオーケストレーションします。
- Google Cloud は、ADK MAS をデプロイするためのリファレンス アーキテクチャ、セキュリティ、オブザーバビリティ スタックを提供します。
- コーディネーター、パイプライン、ファンアウト/ギャザー、反復的な改良などのパターンは、ADK プリミティブから自然に生まれます。
エージェントアプリケーションは、従来の「単一のメガプロンプト」パターンを急速に超えて成長しており、開発者は混乱に陥ることなく複数のエージェントを構築するための強固なメンタルモデルを必要としています。 Google のエージェント開発キット（ADK）はまさにこのために設計されており、信頼性の高いマルチエージェント システムを構成し、ツールとメモリを接続し、本番環境レベルの可観測性、セキュリティ、コスト管理を備えながらすべてを Google Cloud にデプロイできます。
このガイドでは、ADK でサポートされている主なマルチエージェント パターン（単純な親子階層から、シーケンシャル、ループ、並列ワークフロー エージェントまで）について説明し、それらが Google Cloud 上のより広範なリファレンス アーキテクチャにどのように適合するかを示します。 また、共有セッション状態、委任メカニズム、一般的なマルチエージェントブループリント、および実際の環境でこれらのシステムを展開、保護、および運用するための実用的な側面についても説明します。
ADK でマルチエージェント システムを使用する理由
アプリケーションが単一のモノリシックなエージェント プロンプトによって駆動される場合、そのアプリケーションについて検討し、テストし、進化させることがすぐに困難になります。 巨大なプロンプトは壊れやすく、デバッグが難しく、要件が大きくなるにつれてメンテナンスも大変です。ADKは、 マルチエージェントシステム（MAS） 各エージェントには特定の責任があり、オーケストレーションは明示的に行われます。
アプリを複数の連携エージェントとして構造化すると、モジュール性、特化、再利用性が実現します。 リサーチ エージェント、批評家、ファイル ライター、ルーター、データ アクセス エージェントを用意し、同じロジックを 1 つの巨大なプロンプトに再度埋め込むのではなく、プロジェクトやワークフロー全体で再利用できます。
ADK は、これを実現するための具体的な構成要素として、LLM 中心のエージェント、ワークフロー エージェント (シーケンシャル、パラレル、ループ)、および非 LLM ロジックをカプセル化するカスタム エージェントを提供します。 それらはすべて共通の BaseAgent、それらは同じオーケストレーション モデル、ログ記録、状態処理、およびツール システムに接続されます。
システムが成長するにつれて、この構成モデルは、アドホック オーケストレーション コードや、単一モデルを中心とした深くネストされた関数呼び出しのチェーンよりも拡張性が向上します。 認知負荷を管理可能な状態に保ちます。各エージェントには明確な任務があり、他のエージェントとのインタラクション領域が明確に定義されています。
エージェントを構成するための ADK プリミティブ
ADK は、組み合わせることで驚くほど豊富なマルチエージェント アーキテクチャを表現できる、プリミティブの小さなセットを公開します。 これらのコア概念を理解すると、後でより高レベルのパターンについて推論するのがはるかに簡単になります。
最初のプリミティブはエージェント階層です。各エージェントは、 sub_agents単一の木を形成する root_agent 頂点で。 子どもを sub_agentsADKは自動的に配線し、 parent_agent 参照し、特定のインスタンスが1つの親のみを持つことを強制します（そうでない場合は ValueError が発生します。
この階層は単なる装飾ではありません。どのエージェントがどのエージェントに委任できるかを定義し、ワークフロー エージェントと LLM 駆動型転送で使用されるスコープです。 どのエージェントからでも、 agent.parent_agent または子孫を見つける agent.find_agent(name)デバッグに非常に便利です。
ADKは基本的なLLMエージェントに加えて、専用のワークフローエージェントを導入します。 SequentialAgent, ParallelAgent および LoopAgent その仕事は「考える」ことではなく、サブエージェントを調整することです。 これらはすべて同じインターフェースを共有しますが、順番に実行する、並列にファンアウトする、明示的な終了ルールを使用してループで反復するなど、異なる実行戦略を実装します。
3つ目の基本的な基本要素は、共有された Session とその state 辞書。 セッション状態は共通のホワイトボードのように機能します。どのエージェントやツールも中間結果やフラグを書き込むことができ、同じ呼び出しの他のエージェントは、多くの場合、命令内のキーテンプレートを介してそれらを読み取ることができます（たとえば、 {PLOT_OUTLINE?}).
ADKでエージェント同士が会話する方法
ADKは、エージェント間の3つの補完的な通信モードをサポートしています。共有セッション状態、LLM駆動型転送、および明示的な呼び出しです。 AgentTool. 各インタラクションに適切なものを選択することで、システムの表現力と予測可能性が維持されます。
共有セッション状態（session.state）は最も単純かつ最も普及しているメカニズムです。 1回の呼び出しで、すべてのエージェントは同じ Session オブジェクトを介して InvocationContextツールやコールバックでできること context.state = value、そして後のエージェントはそれを context.state.get("data_key")LLMエージェントの場合、設定 output_key 最終的な回答は自動的にそのキーの下に保存されます。
LLM 主導の委任 (「エージェント転送」と呼ばれることもあります) により、LLM は指示とエージェントの説明に基づいて、別のエージェントにいつ引き継ぐかを決定できます。 内部的には、モデルは次のような特別な関数呼び出しを発行します。 transfer_to_agent(agent_name="screenwriter"). ADKの AutoFlow この呼び出しをインターセプトし、許可されたスコープ (構成に応じて親、子、兄弟) 内の選択されたエージェントに実行を再ルーティングします。
明示的な呼び出し AgentTool より制御された関数のような方法で、あるエージェントから別のエージェントを呼び出すことができます。 ターゲットエージェントインスタンスをラップする AgentTool発信者の tools リストに表示され、LLMは他の関数と同様にそのツールを選択できます。呼び出されると、 AgentTool.run_async サブエージェントを実行し、状態と成果物をマージして、サブエージェントの応答をツールの結果として返します。
これら 3 つのチャネルは、状態を介した非同期データの受け渡し、転送を介した柔軟なルーティング、ツールを介した緊密な同期呼び出しなど、マルチエージェントのほとんどのニーズに対応します。 より複雑な設計では、多くの場合、これらを 1 つのツリー内に混在させます。子に転送するルーター、状態を使用して通信するスペシャリスト、およびアドホック委任のツールとして使用できる 1 つまたは 2 つのエージェントです。
構成要素: LLM エージェント、ワークフロー エージェント、カスタム エージェント
ADK のほとんどの MAS トポロジは、LLM ベース、ワークフロー、カスタム エージェントの 3 つのエージェント タイプの組み合わせです。 各カテゴリは、オーケストレーション問題の異なる部分を解決します。
LLMエージェントは、大規模な言語モデルとオプションのツール、コールバック、出力ルーティングをラップします。 BaseAgent. これらは「考える」コンポーネントと考えてください。ユーザー入力を解釈し、ツールを呼び出し、状態を更新し、ユーザーに応答するか別のエージェントに引き継ぎます。
ワークフロー エージェントは、ワーカーではなくマネージャーとして機能します。エージェント自身は推論しませんが、サブエージェントの実行の順序、並列処理、繰り返しを制御します。 SequentialAgent 同じものを共有しながら、次々に子を実行します InvocationContext, ParallelAgent 状態を共有しながらも異なる履歴ブランチを持つ複数のブランチに広がり、 LoopAgent 停止条件が満たされるまでシーケンスを繰り返し実行します。
カスタムエージェントは拡張します BaseAgent 組み込みのオーケストレーション戦略では不十分な場合は、任意の非 LLM ロジックを使用します。 たとえば、メトリックに基づいて条件付きでエージェントを実行するカスタム スケジューラを実装したり、規制上の制約に応じて実行するサブフローを決定するビジネス ルール エンジンを統合したりすることができます。
汎用オーケストレーション プリミティブとプラグ可能なロジックの組み合わせにより、ADK はデモだけでなく本格的なエンタープライズ ワークロードにも適しています。 標準的なワークフローエージェントから始めて、要件が特殊な場合にのみ、 CustomAgent.
セッション状態とメモリパターン
ADK のセッション状態は、短期的な会話メモリとエージェント間で渡される構造化データの両方を支えます。 すべての会話で Session メッセージ履歴と変更可能なオブジェクト state その呼び出し内のすべてのエージェントが利用できる辞書。
状態への書き込みは通常、ツールやコールバック内で、 ToolContext or CallbackContext オブジェクト。 たとえば、次のようなツール save_attractions_to_state(tool_context, attractions: List) 新しいアトラクションを既存のアトラクションと統合することができます stateADK がセッション内の状態デルタを保持しながら、エージェントに簡単なステータス メッセージを返します。
状態からの読み取りは、命令に埋め込まれたキー テンプレートによって人間工学的に行われます。 指示に {my_key?}ADKは注入します state 存在する場合、キーは必須ではありません。疑問符が付いているため、キーが欠落していてもエージェントが失敗することはありません。これは、「リサーチ → ライティング → レビュー」といったワークフローにおいて、各ステップで前のステップで保存された内容を読み取る場合に重要です。
会話の記憶をターン間で共有するには、同じ会話を再利用することが鍵となる。 Session 毎回新しいメッセージを作成するのではなく、後続のユーザー メッセージに対して使用します。 共有セッションでは、エージェントは以前のターンを確認し、フォローアップの質問、修正、複数ステップの計画を処理できます。誤ってターンごとに新しいセッションを作成した場合、エージェントは記憶喪失になったかのように動作し、フォローアップを以前のコンテキストに関連付けることができません。
状態は、次のようなワークフローエージェントでも重要な役割を果たします。 LoopAgentカウンター、フィードバック リスト、フラグなどの永続キーに依存して、さらに反復が必要かどうかを決定します。 批評エージェントはコメントを追加するかもしれない CRITICAL_FEEDBACK 各パスで、プランナーまたはリファイナーがそのキーを読み取り、次の反復で計画を改善します。
SequentialAgent: 明示的な線形ワークフロー
SequentialAgent 一連の手順を決まった順序で実行する必要がある場合に使用するパターンです。 「リクエストを分析 → 調査 → 草稿 → ファイルに保存」や「目的地を特定 → ルートを計画 → 交通手段を予約」のようなパイプラインを考えてみましょう。
ADKでは、 SequentialAgent リストを保持 sub_agents そして、それらを一つずつ実行し、同じ InvocationContext チェーン全体を通じて。 から Session および state 共有されている場合、最初のエージェントは結果を output_key="destination" そして次のエージェントはそれを {destination} グルーコードなしで命令に記述します。
典型的な例としては、映画のピッチジェネレータがあります。グリータールートエージェントがユーザーと会話し、次に仕事を SequentialAgent それは研究者、脚本家、そしてファイルライターを呼びます。 ユーザーには最終的な結果しか見えませんが、ADK Web のイベント グラフには、 greeter → film_concept_team → という内部ツリーが表示されます。
明示的な手動オーケストレーションと比較して if/elif ブロックと関数呼び出し、 SequentialAgent 制御フローを宣言的に保ち、定型文を最小限に抑えます。 シーケンスを一度宣言し、それをランナーまたは UI 内の単一の呼び出し可能なエージェントとして扱い、セッション状態を活用してステップ間でデータを渡します。
シーケンシャル ワークフローは他のワークフロー エージェントとうまく組み合わせることができ、長いチェーンのステップの 1 つとしてループや並列ファンアウトを埋め込むことができます。 このようにして、「ストーリーの品質を繰り返し検討し、興行成績とキャスティングの分析を実行し、統合レポートを作成する」などのより高度なフローが構築されます。
LoopAgent: 反復的な改良とライタールーム
LoopAgent 品質しきい値が満たされるまで作業を複数回実行することでメリットが得られるタスク向けに設計されています。 「一度生成して最善の結果を期待する」という単一のアプローチではなく、提案、批評、改良のプロセスをコード化できます。
典型的なループ構成には、複数のラウンドにわたって共同作業を行う研究者、ジェネレーター (脚本家など)、批評家などのエージェントが含まれます。 各反復ごとに、研究者は背景情報を更新し、脚本家はアウトラインまたは計画を調整し、批評家はそれを明確なガイドラインに照らして評価し、さらなる反復が必要かどうかを決定します。
ループは2つの条件で停止します。 max_iterations または、作業が完了したことを知らせるサブエージェント。 ADKは次のような組み込みツールを公開しています exit_loop 計画、概要、またはデザインが内部チェックリストを通過したときに批評家が呼び出すことができるもの。 LoopAgent また、 escalate=True フラグを立てる Event アクションにより、早期に脱出する別の方法が得られます。
永続的なセッション状態がここで鍵となる。エージェントは次のようなキーを読み取る。 PLOT_OUTLINE, research or CRITICAL_FEEDBACK そして、各パスごとに改良版や追加のコメントを書き込みます。 このパターンは、誰かが作品の準備ができたと宣言するまで、専門家がブレインストーミング、批評、磨きをかける「ライターズルーム」を効果的にシミュレートします。
組み合わせることにより LoopAgent SequentialAgent、反復ループ全体を、より大きなエンドツーエンドのワークフロー内の 1 つのステップとして配置できます。 たとえば、 writers_room （LoopAgent）は最初に実行され、しっかりとしたプロットのアウトラインを作成し、その後 file_writer エージェントは結果を保存し、他のレポートを添付します。
ParallelAgent: 独立したタスクのために分散して収集する
ParallelAgent 独立しているがコンテキストを共有するタスクに対して、古典的な「ファンアウト/ギャザー」パターンを実装します。 N 個の調査ステップを順番に実行するのではなく、すべてを一度に実行し、すべてが完了するまで待機してから、その出力を集約します。
内部的には、 ParallelAgent 各サブエージェントに異なる InvocationContext.branch - お気に入り ParentBranch.ChildName – 同じものを共有しながら session.state. つまり、彼らは皆、次のような初期コンテキストを読み取ることができる。 PLOT_OUTLINE出力を異なる状態キーに書き込む必要があります（例： box_office_report, casting_report) を使用してください。
一般的な例としては、映画企画のための「プリプロダクションチーム」が挙げられます。1 人のエージェントが類似の映画に基づいて興行収入の可能性を見積もり、もう 1 人のエージェントがキャスティングのオプションを提案し、両方が並行して実行されます。 その後の file_writer 次に、各サブ結果のキーテンプレートを使用してレポートを作成し、ディスクに保存します。
並列ワークフローは、幅広いクエリのレイテンシを大幅に削減し、 リアルタイムデータ分析: 週末の美術館のおすすめ、コンサートのオプション、レストランのアイデアなどが必要な場合、3 つの専門エージェントを並行して実行すると、順番にクエリを実行するよりも高速になります。 ファンアウト後、合成エージェントは状態からすべての結果を読み取り、ユーザーに対して統一された応答を生成します。
並列ステップはほとんどの場合、 SequentialAgent まずコンテキストを準備し、次に ParallelAgentその後、集計とレポート作成を続行します。 ADK のワークフロー エージェントに慣れれば、このパターンは簡単に認識して再利用できます。
ADKプリミティブを使用したオーケストレーションパターン
階層、ワークフロー エージェント、状態を理解すると、いくつかの標準的なマルチエージェント パターンを ADK で直接実装できます。 これらのパターンはハードコードされたプリミティブではなく、同じ基本的な構成要素で構築された構成です。
コーディネーター/ディスパッチャー パターンでは、複数の特殊なサブエージェントによってサポートされる中央 LLM エージェントをユーザー クエリの「ルーター」として使用します。 コーディネータはリクエストを読み取り、LLM駆動の委任を介してサブエージェントに制御を移すか、または明示的にスペシャリストを呼び出します。 AgentToolグルメ、交通、週末ガイドの代理店などが一般的な例です。
シーケンシャルパイプラインパターンは、 SequentialAgent その子はそれぞれ、プロセスの適切にスコープされたステップを実装します。 ジェネレーターと批評家のフローは古典的なバリエーションです。最初のエージェントがドラフトを書き、それを output_key2 番目のエージェントがそれを分析してフィードバックを保存し、3 番目のエージェントがそのフィードバックに基づいて結果を改良する場合があります。
並列ファンアウト/ギャザーパターンは次のように表現されます。 ParallelAgent 順次ワークフロー内にネストされます。 並列の子は結果を別々の状態キーに書き込み、後の合成エージェントがそれを読み取り、結合された回答を提示します。
階層的なタスク分解は、親/子ツリーから自然に発生します。 上位レベルのエージェントは、目標をサブ目標に分割し、それらを子に委任します（委任またはツールを介して）。その結果はツリーを遡って反映されます。これは、各サブドメインに専門エージェントが存在するリサーチアシスタント、サプライチェーン最適化ツール、ファイナンシャルアドバイザーシステムなどで特に有用です。
反復的な改良 LoopAgent ジェネレーター-クリティック ループを再利用可能なパターンに形式化します。 ループは、プランナー、批評家、リファイナー エージェントを複数回実行し、状態キーを使用して最新のプランと対応するフィードバックを保持し、品質基準または反復上限に達したときに停止します。
Google Cloud 上のマルチエージェント システムのリファレンス アーキテクチャ
エージェント ロジック以外にも、システムをどこかで実行する必要があります。Google Cloud では、本番環境レベルのマルチエージェント デプロイメント向けに明確に定義されたリファレンス アーキテクチャを提供しています。 大まかに言えば、このソリューションは、フロントエンド、エージェント ランタイム、Vertex AI モデル、セキュリティ サービス、MCP などのオプションのツール フレームワークを組み合わせたものです。
一般的なセットアップは、Cloud Run で実行されるフロントエンド（多くの場合、チャット インターフェース）から始まります。 ユーザーはこのUIに話しかけると、リクエストをサービスとして公開されているコーディネーターエージェントに転送します。コーディネーターはユーザーの意図に基づいて複数のエージェントワークフローから適切なものを選択します。これには、エージェントの決定を人間が検証または上書きできるオプションのヒューマンインザループパスも含まれます。
エージェント自体は、Cloud Run サービス、Google Kubernetes Engine (GKE)、Vertex AI Agent Engine など、複数の環境で実行できます。 ADK はこれらのオプションを網羅し、ランタイムの詳細の一部を抽象化することで、開発者がインフラストラクチャの構築ではなくエージェント ロジックに集中できるようにします。
すべてのエージェント呼び出しは推論のために Vertex AI またはその他のモデル ランタイムに依存しており、多くの場合、プロンプトと応答をサニタイズするために Model Armor でラップされています。 Model Armor は、モデル呼び出しの前後にプロンプト インジェクションの試行、機密データの漏洩、または有害なコンテンツをフィルター処理するのに役立ち、生成コンポーネントの周囲の安全ガードレールとして機能します。
エージェントが標準化された方法で外部システム (データベース、ファイルシステム、SaaS API) と通信する必要がある場合は、MCP (モデル コンテキスト プロトコル) ツールとサーバーが登場します。 MCPはエージェントとツールサーバー間の共通契約を定義するため、エージェント内の単一のMCPクライアントは、密結合なしで異なるチームによって構築された多くのツールにアクセスできます。 データストレージシステム 安全な情報を提供します。
エージェントアプリケーションのセキュリティとガバナンス
エージェント システムは、従来のマイクロサービスを超えるセキュリティ上の課題をもたらします。これは、注意を怠ると、LLM が騙されてツールを悪用したり、データを漏洩したりする可能性があるためです。 Googleの推奨アプローチは、LLM対応のポリシー駆動型防御と決定論的セキュリティ制御をレイヤー化します。 límites, sesgos y riesgos デ・ロス・モデルロス・アル・ディセニャル・エスタス・ディフェンサス。
人間による監視は依然として最も重要です。影響の大きいフローには、エージェントの提案されたアクションを人が一時停止、確認、または拒否できる承認手順を含める必要があります。 これは、UI にリクエストを表示し、人間が応答した場合にのみ実行を再開する専用の「人間による確認」ツールとしてモデル化できます。
エージェントのアクセス制御は IAM を通じて処理されます。各エージェントまたはサービス アカウントには、その職務を実行するために必要な最小限の権限のみを与える必要があります。 特定のエージェントが侵害されたり悪用されたりした場合、そのエージェントのサービス アカウントは関連のないリソースやツールにアクセスできないため、影響範囲は制限されます。
ポリシー駆動型のツールゲーティングは、次のようなコンポーネントで実装されます。 SecurityPlugin プラス PolicyEngineを使用すると、特定のツールを実行する前にユーザーの確認を求めることができます。 ポリシーによって機密性の高い呼び出しにフラグが付けられると、プラグインはそれを傍受し、特別な「確認を求める」関数呼び出しを発行して、アプリケーションが判定を返すのを待機します。これにより、高リスクの操作に効果的に人間が介入することになります。
標準的な Google Cloud セキュリティ機能により、データの流出リスクを軽減する VPC Service Controls、顧客管理の暗号鍵用の CMEK、WAF と DDoS 保護のための Cloud Armor、ユーザー認証用の IAP または Identity Platform、リソース アクセスのためのきめ細かな IAM など、すべてが揃います。 A2A 経由のエージェント間通信の場合、実稼働環境では TLS 1.2+ および OAuth ベースの認証が必須または推奨されます。
信頼性、可観測性、コスト最適化
本番環境の MAS デプロイメントは信頼性が高く、監視可能で、コスト効率に優れている必要があります。ADK は Google Cloud の運用ツールと適切に統合され、それを実現します。 エージェント、セッション、ツールをインストルメント化して、そのログとトレースを Cloud Logging と Cloud Trace に表示することができます。
信頼性の観点から、個々のコンポーネントの障害を許容するようにエージェント グラフを設計します。 可能な限り、単一の、かけがえのない中央の頭脳を避け、独立したエージェントが局所的なタスクを実行できるようにすることで、1つのパスの停止によってアプリケーション全体がダウンすることはありません。 流通貨物のバランス パラディストリビュールカーゲイとリデューサープントスデファロ。ステージングの失敗をシミュレートして、ストレス下での調整動作を検証します。
モデル呼び出しの場合、Vertex AI は動的な共有割り当てとプロビジョニングされたスループットをサポートします。 共有クォータは、従量課金制のシナリオにおけるプロジェクトごとの厳格な制限を回避します。一方、プロビジョニングされたスループットは、QPSが高く、レイテンシに敏感で、スロットリングが許されないワークロードにとって不可欠です。リクエストレートとトークンの使用状況をモニタリングすることで、オンデマンド容量からプロビジョニングされた容量へ移行するタイミングを判断できます。
コスト管理は、スマートなモデルの選択、慎重なプロンプト設計、不要なトークンの回避に大きく依存します。 可能な限りコスト効率の高いモデルから開始し、プロンプトは簡潔でありながら有益な情報を提供し、可能な場合は短い出力を明示的に要求し、繰り返される大きなプロンプトに対してコンテキスト キャッシュを活用し、ワークロードで許可されている場合はバッチ予測を検討します。
Cloud Run のリソース調整と長期割引により、ランタイム コストがさらに最適化されます。 デフォルトのCPU/メモリから始めて、実際の使用状況を観察し、調整してください。予測可能なワークロードの場合、確約利用割引により費用を大幅に削減できます。
可観測性の面では、監視戦略においてエージェントを第一級のエンティティとして扱う必要があります。 入力内容、決定事項（どのツールを呼び出すか、どのエージェントに委任するかなど）、状態の変化をログに記録します。ADK のウェブ UI のイベントグラフを使用して個々のセッションをデバッグし、Cloud Logging とカスタム ダッシュボードを使用してフリート全体の傾向を把握できます。
これらの実践をうまく行えば、MASの透明性が高まり、どのエージェントが遅いか、どのツールが過剰に使用されているか、どのプロンプトが長すぎるか、そして品質管理ループが LoopAgent 予想以上に繰り返します。 このフィードバック ループは、時間の経過とともに品質とコストの両方を微調整するために重要です。
ADK のエージェント プリミティブ、ワークフロー パターン、状態メカニズムを Google Cloud のリファレンス アーキテクチャ、セキュリティ スタック、運用ツールと組み合わせることで、理論上は優れているだけでなく、本番環境での導入、管理、経済的にも実現可能なマルチエージェント システムを設計できます。 単純な親/子エージェントから始めて、シーケンシャル、ループ、並列オーケストレーションへと進むことで、エージェントのアイデアを、実際にビジネス価値をもたらす堅牢で保守可能なアプリケーションに変換するためのツールキットを手に入れることができます。
