このドキュメントでは、エージェント型 AI システムの設計パターンを選択する際のガイダンスを提供します。エージェント設計パターンは、エージェント アプリケーションを構築するための一般的なアーキテクチャ アプローチです。エージェント設計パターンは、システムのコンポーネントを整理し、モデルを統合して、単一のエージェントまたは複数のエージェントをオーケストレートしてワークフローを完了するための明確なフレームワークを提供します。
AI エージェントは、自律的な意思決定や複雑なマルチステップ ワークフロー管理を必要とする、自由形式の問題を解決するアプリケーションに効果的です。エージェントは、外部データを使用して問題をリアルタイムで解決し、知識集約型のタスクを自動化することに優れています。AI エージェントは、AI がある程度の自律性を持って目標に焦点を当てたタスクを完了する必要がある場合に適しています。その他のユースケースでは、アシスト AI アプリケーションと生成 AI アプリケーションを使用できます。AI エージェントと非エージェント AI アプリケーションの違いについては、AI エージェント、AI アシスタント、bot の違いをご覧ください。
このガイドは、エージェント型 AI システムの基礎知識と、そのアーキテクチャが非エージェント型システム（直接モデル推論や検索拡張生成（RAG）を使用するシステムなど）のアーキテクチャとどのように異なるかを理解していることを前提としています。
要件を定義する
以下の質問は、計画に関する完全なチェックリストではありません。これらの質問を出発点として、エージェント システムの主な目標を特定し、最適な設計パターンを選択します。
- タスクの特性: タスクは、事前定義されたワークフロー ステップで完了できるか、それとも自由回答形式か。タスクで AI モデルを使用してワークフローをオーケストレートする必要があるか。
- レイテンシとパフォーマンス: 精度や高品質なレスポンスを犠牲にして、高速なレスポンスやインタラクティブなレスポンスを優先する必要がありますか？または、より正確な結果や完全な結果を得るために、アプリケーションで遅延を許容できますか？
- 費用: 推論費用の予算はどれくらいですか？1 つのリクエストに対してモデルへの複数の呼び出しが必要なパターンをサポートできますか？
- 人間の関与: タスクに、重大な影響を及ぼす意思決定、安全性に不可欠なオペレーション、人間の判断を必要とする主観的な承認が含まれていますか。
ワークロードが予測可能または高度に構造化されている場合、または AI モデルへの 1 回の呼び出しで実行できる場合は、タスクに非エージェント ソリューションを検討する方が費用対効果が高くなります。たとえば、ドキュメントの要約、テキストの翻訳、顧客フィードバックの分類などのタスクには、エージェント ワークフローは必要ない場合があります。
以降のセクションでは、信頼性が高く効果的なエージェント型 AI システムを構築するための一般的なエージェント設計パターンについて説明します。
シングルエージェント システム
シングル エージェント システムは、AI モデル、定義されたツールセット、包括的なシステム プロンプトを使用して、ユーザー リクエストを自律的に処理したり、特定のタスクを完了したりします。この基本的なパターンでは、エージェントはモデルの推論機能を利用して、ユーザーのリクエストを解釈し、一連のステップを計画して、定義されたセットから使用するツールを決定します。システム プロンプトは、エージェントのコアタスク、ペルソナ、オペレーション、各ツールの使用に関する特定の条件を定義することで、エージェントの動作を形成します。
次の図は、単一エージェント パターンの概要を示しています。
シングル エージェント システムは、複数のステップと外部データへのアクセスを必要とするタスクに最適です。たとえば、カスタマー サポート エージェントがデータベースにクエリを実行して注文ステータスを確認する必要がある場合や、リサーチ アシスタントが API を呼び出して最近のニュースを要約する必要がある場合などです。エージェント型でないシステムは、ツールを自律的に使用したり、複数ステップの計画を実行して最終的な回答を合成したりできないため、これらのタスクを実行できません。
エージェント開発の初期段階では、1 つのエージェントから始めることをおすすめします。シングルエージェント システムでエージェント開発を開始すると、より複雑なアーキテクチャ コンポーネントを追加する前に、エージェントのコアロジック、プロンプト、ツール定義の改良に集中できます。
1 つのエージェントのパフォーマンスは、使用するツールが増え、タスクの複雑さが増すと、効果が低下する可能性があります。これは、レイテンシの増加、ツールの選択や使用の誤り、タスクの完了の失敗として現れることがあります。多くの場合、推論と行動（ReAct）パターンなどの手法を使用してエージェントの推論プロセスを改良することで、これらの問題を軽減できます。ただし、ワークフローでエージェントが複数の異なる責任を管理する必要がある場合、これらの手法では不十分な場合があります。このような場合は、マルチエージェント システムを検討してください。このシステムでは、特定のスキルを専門のエージェントに委任することで、復元力とパフォーマンスを向上させることができます。
マルチエージェント システム
マルチエージェント システムは、複数の専門エージェントをオーケストレートして、単一のエージェントでは簡単に管理できない複雑な問題を解決します。基本原則は、大きな目標を小さなサブタスクに分解し、各サブタスクを特定のスキルを持つ専用のエージェントに割り当てることです。これらのエージェントは、協調型または階層型のワークフローを通じて相互に作用し、最終的な目標を達成します。マルチエージェント パターンは、モノリシックなプロンプトを使用する単一エージェントと比較して、システム全体の拡張性、信頼性、メンテナンス性を向上させることができるモジュラー設計を提供します。
マルチエージェント システムでは、各エージェントがタスクを効果的に実行するために特定のコンテキストを必要とします。コンテキストには、ドキュメント、過去の設定、関連リンク、会話履歴、運用上の制約などを含めることができます。この情報フローを管理するプロセスは、コンテキスト エンジニアリングと呼ばれます。コンテキスト エンジニアリングには、特定のエージェントのコンテキストを分離する、複数のステップにわたって情報を保持する、大量のデータを圧縮して効率を向上させるなどの戦略が含まれます。
AI エージェントは、従来の決定論的なセキュリティ対策では適切に軽減できない、特有の重大なセキュリティ リスクをもたらします。上り（内向き）トラフィックと下り（外向き）トラフィックのルーティングとセキュリティには Agent Gateway を、ワークロードにバインドされた認証と最小権限のアクセス制御には Agent Identity を、検証済みのツールとサブエージェントが使用されるようにするには Agent Registry を使用します。
このセクションのガイダンスはすべてを網羅しているわけではありません。設計要素とベスト プラクティスの詳細、およびマルチエージェント AI システムの構築とデプロイに関する推奨事項については、 Google Cloudのマルチエージェント AI システムをご覧ください。
シーケンシャル パターン
マルチエージェント シーケンシャル パターンは、事前定義された線形順序で一連の専門エージェントを実行します。このパターンでは、1 つのエージェントの出力が次のエージェントの直接入力として使用されます。
次の図は、マルチエージェント シーケンシャル パターンの概要を示しています。
シーケンシャル パターンは、オペレーションのシーケンスが変更されない、高度に構造化された反復可能なプロセスに使用します。たとえば、データ処理パイプラインでこのパターンを使用すると、まずデータ抽出エージェントが元データを取得し、そのデータをデータ クリーニング エージェントに渡してフォーマットします。その後、クリーンなデータをデータ読み込みエージェントに渡してデータベースに保存します。
シーケンシャル パターンは、AI モデルを使用してタスク ワークフローをオーケストレートするパターンと比較して、レイテンシと運用コストを削減できます。ただし、この効率性は柔軟性を犠牲にしています。パイプラインの構造が厳格で事前に定義されているため、動的な条件に適応したり、不要なステップをスキップしたりすることが難しく、不要なステップが遅い場合は、処理が非効率になったり、累積レイテンシが増加したりする可能性があります。
並列パターン
マルチエージェント並列パターン（同時実行パターンとも呼ばれます）では、複数の専門サブエージェントがタスクまたはサブタスクを同時に独立して実行します。サブエージェントの出力が合成され、最終的な統合レスポンスが生成されます。このパターンは、オーケストレーションのために AI モデルに問い合わせることなく、事前定義されたロジックで動作します。
次の図は、マルチエージェント並列パターンの概要を示しています。
サブタスクを同時に実行してレイテンシを短縮したり、さまざまな視点を収集したりできる場合は、並列パターンを使用します。たとえば、異なるソースからデータを収集したり、複数のオプションを一度に評価したりする場合です。たとえば、顧客からのフィードバックを分析するために、並列エージェントは、1 つのフィードバック エントリを 4 つの専門エージェント（感情分析エージェント、キーワード抽出エージェント、分類エージェント、緊急度検出エージェント）に同時にファンアウトできます。最後のエージェントが、これら 4 つの出力をフィードバックの包括的な分析にまとめます。
並列パターンは、複数のソースからさまざまな情報を同時に収集できるため、シーケンシャルなアプローチと比較して全体的なレイテンシを短縮できます。ただし、このアプローチでは、費用と複雑さのトレードオフが発生します。複数のエージェントを並列で実行すると、即時のリソース使用率とトークン消費量が増加し、運用コストが増加する可能性があります。さらに、収集ステップでは、競合する可能性のある結果を合成するために複雑なロジックが必要になり、システムの開発とメンテナンスのオーバーヘッドが増加します。
ループパターン
マルチエージェント ループ エージェント パターンは、特定の終了条件が満たされるまで、事前定義された一連の特化型サブエージェントを繰り返し実行します。すべてのサブエージェントがタスクを完了すると、ループ エージェントは終了条件が満たされているかどうかを評価します。条件には、最大反復回数またはカスタム状態を指定できます。終了条件が満たされない場合、ループ エージェントはサブエージェントのシーケンスを再度開始します。フロー内の任意の時点で終了条件が評価されるループパターンを実装できます。コンテンツを生成し、品質基準を満たすまで批評家エージェントにレビューさせるなど、反復的な改良や自己修正が必要なタスクには、ループパターンを使用します。
次の図は、マルチエージェント ループパターンの概要を示しています。
ループ エージェント パターンは、複雑な反復ワークフローを構築する方法を提供します。これにより、エージェントは独自の作業を改良し、特定の品質または状態が達成されるまで処理を継続できます。ただし、このパターンの主なトレードオフは、無限ループのリスクです。終了条件が正しく定義されていない場合や、サブエージェントが停止に必要な状態を生成できない場合、ループは無期限に実行される可能性があります。これにより、運用コストの増加、リソース消費量の増加、システムのハングアップが発生する可能性があります。
レビューと批評のパターン
マルチエージェント レビューと批評パターン（生成と批評パターンとも呼ばれます）は、2 つの専用エージェント（通常は順次ワークフロー）を使用して、生成されたコンテンツの品質と信頼性を向上させます。レビューと批評のパターンは、ループ エージェント パターンの実装です。
レビューと批評のパターンでは、ジェネレータ エージェントがコードブロックやドキュメントの要約などの初期出力を生成します。次に、批評エージェントが、事実に基づく正確性、形式ルールの遵守、安全に関するガイドラインなど、事前定義された一連の基準に照らしてこの出力を評価します。評価に基づいて、批評家はコンテンツを承認、拒否、または修正のためのフィードバックとともに生成者に返すことができます。
次の図は、マルチエージェントのレビューと批評パターンの概要を示しています。
このパターンは、出力がユーザーに提示される前、またはダウンストリーム プロセスで使用される前に、出力の精度を高くする必要があるタスクや、厳格な制約に準拠する必要があるタスクに適しています。たとえば、コード生成ワークフローでは、ジェネレータ エージェントがユーザーのリクエストを満たす関数を記述することがあります。生成されたコードは、セキュリティ監査者として機能する批評家エージェントに渡されます。批評家エージェントの役割は、コードが使用を承認される前に、セキュリティ上の脆弱性のスキャンや、すべての単体テストに合格していることの確認など、一連の制約に照らしてコードをチェックすることです。
レビューと批評のパターンでは、専用の検証ステップが追加されるため、出力の品質、精度、信頼性を向上させることができます。ただし、この品質保証は、レイテンシと運用費用の増加という直接的なコストを伴います。ワークフローでは、批評家の評価のために少なくとも 1 つの追加のモデル呼び出しが必要です。プロセスに、コンテンツが修正のために返される修正ループが含まれている場合、反復ごとにレイテンシと費用の両方が増加します。
反復的な改良パターン
反復的な改良パターンでは、ループ メカニズムを使用して、複数のサイクルにわたって出力を段階的に改善します。反復的な改良パターンは、ループ エージェント パターンの実装です。
このパターンでは、1 つ以上のエージェントがループ内で動作し、各イテレーション中にセッション状態に保存された結果を変更します。このプロセスは、出力が事前定義された品質しきい値を満たすか、最大イテレーション回数に達するまで継続されます。これにより、無限ループが防止されます。
次の図は、マルチエージェントの反復的な改良パターンの概要を示しています。
このパターンは、1 つのステップで出力を達成するのが難しい複雑な生成タスクに適しています。このようなタスクの例としては、コードの作成とデバッグ、詳細なマルチパート プランの作成、長文ドキュメントの作成と修正などがあります。たとえば、クリエイティブ ライティング ワークフローでは、エージェントがブログ投稿の下書きを生成し、下書きのフローとトーンを批評して、その批評に基づいて下書きを書き直すことができます。このプロセスは、エージェントの作業が事前定義された品質基準を満たすか、繰り返しが最大イテレーション回数に達するまで、ループで繰り返されます。
反復的な改良パターンを使用すると、1 つのステップでは実現が難しい、非常に複雑な出力や洗練された出力を生成できます。ただし、ループ メカニズムは、サイクルごとにレイテンシと運用コストを直接増加させます。このパターンでは、過剰な費用や制御不能な実行を防ぐために、品質評価や最大反復回数などの終了条件を慎重に設計する必要があるため、アーキテクチャが複雑になります。
コーディネーター パターン
マルチエージェント コーディネーター パターンでは、中央エージェント（コーディネーター）を使用してワークフローを指示します。コーディネーターは、ユーザーのリクエストを分析してサブタスクに分解し、各サブタスクを専門のエージェントにディスパッチして実行します。各専門エージェントは、データベースのクエリや API の呼び出しなど、特定の機能の専門家です。
コーディネーター パターンの特徴は、AI モデルを使用してタスクをオーケストレートし、動的にルーティングすることです。一方、並列パターンは、ハードコードされたワークフローに依存して、AI モデルのオーケストレーションを必要とせずに、同時実行のためにタスクをディスパッチします。
次の図は、マルチエージェント コーディネーター パターンの概要を示しています。
適応型ルーティングを必要とする構造化されたビジネス プロセスを自動化するには、コーディネーター パターンを使用します。たとえば、カスタマー サービス エージェントがコーディネーターとして機能できます。コーディネーター エージェントは、リクエストを分析して、注文ステータスのリクエスト、商品の返品、払い戻しリクエストのいずれであるかを判断します。リクエストのタイプに基づいて、コーディネーターはタスクを適切な専門エージェントにルーティングします。
コーディネーター パターンは、より厳格で事前定義されたワークフローと比較して柔軟性があります。モデルを使用してタスクをルーティングすることで、コーディネーターはより幅広い入力を処理し、実行時にワークフローを適応させることができます。ただし、このアプローチにはトレードオフもあります。コーディネーターと各専門エージェントは推論にモデルを使用するため、このパターンでは、単一エージェント システムよりもモデル呼び出しが多くなります。コーディネーター パターンは、より高品質な推論につながる可能性がありますが、シングル エージェント システムと比較すると、トークン スループット、運用コスト、全体的なレイテンシも増加します。
階層型タスク分解パターン
マルチエージェント階層型タスク分解パターンは、エージェントをマルチレベルの階層に編成して、広範な計画を必要とする複雑な問題を解決します。階層型タスク分解パターンは、コーディネーター パターンの実装です。最上位の親エージェント（ルートエージェント）は、複雑なタスクを受け取り、そのタスクを管理しやすい小さなサブタスクに分解します。ルート エージェントは、各サブタスクを下位レベルの専用サブエージェントに委任します。このプロセスは複数のレイヤで繰り返され、エージェントは割り当てられたタスクを、最下位レベルのワーカー エージェントが直接実行できるようになるまで段階的に分解します。
次の図は、マルチエージェント階層型タスク分解パターンの概要を示しています。
階層型タスク分解パターンは、調査、計画、合成を伴うタスクなど、マルチステップの推論を必要とする、曖昧で自由度の高い問題に使用します。たとえば、複雑な調査プロジェクトを完了するために、コーディネーター エージェントは、情報の収集、調査結果の分析、最終レポートの統合など、複数のタスクに高レベルの目標を分解します。コーディネーター エージェントは、これらのタスクを、データ収集エージェント、分析エージェント、レポート作成エージェントなどの専門のサブエージェントに委任して、実行またはさらに分解します。
階層型タスク分解パターンは、複雑で曖昧な問題を管理しやすいサブタスクに体系的に分解するため、このような問題の解決に最適です。このパターンでは、よりシンプルなパターンよりも包括的で高品質な結果が得られます。ただし、この高度な機能には大きなトレードオフがあります。マルチレベル構造により、アーキテクチャが大幅に複雑になり、システムの設計、デバッグ、メンテナンスが難しくなります。委任と推論の複数のレイヤにより、モデル呼び出しの数も多くなり、他のパターンと比較して全体的なレイテンシと運用コストの両方が大幅に増加します。
群れパターン
マルチエージェント スウォーム パターンでは、協調的な全対全通信アプローチを使用します。このパターンでは、複数の専門エージェントが連携して、複雑な問題の解決策を反復的に改良します。
次の図は、マルチエージェント スウォーム パターンの概要を示しています。
スウォーム パターンでは、ディスパッチャ エージェントを使用して、ユーザー リクエストを専門エージェントのコラボレーション グループにルーティングします。ディスパッチャ エージェントはリクエストを解釈し、スウォーム内のどのエージェントがタスクの開始に最適かを判断します。このパターンでは、各エージェントが他のすべてのエージェントと通信できるため、調査結果の共有、提案の批評、互いの作業の積み重ねにより、ソリューションを繰り返し改良できます。スウォーム内のエージェントは、次のステップの処理に適していると判断した別のエージェントにタスクを引き継ぐことができます。また、コーディネーター エージェントを介して最終的なレスポンスをユーザーに伝えることもできます。
通常、スウォームには、プロセスを軌道に乗せるための中央スーパーバイザーやコーディネーター エージェントがありません。コーディネーター パターンとは異なり、ディスパッチャ エージェントはエージェント ワークフローをオーケストレートしません。代わりに、ディスパッチャ エージェントがスウォーム サブエージェントとユーザー間の通信を容易にします。スウォームが最終的に停止して結果を返すようにするには、明示的な終了条件を定義する必要があります。この条件は、多くの場合、最大イテレーション回数、制限時間、または特定の目標（コンセンサスの達成など）の達成です。
議論と反復的な改良が有効な、曖昧な問題や非常に複雑な問題には、スウォーム パターンを使用します。たとえば、新製品の設計には、市場調査エージェント、エンジニアリング エージェント、財務モデリング エージェントが関与する場合があります。エージェントは、最初のアイデアを共有し、機能と費用のトレードオフについて議論し、競合するすべての要件のバランスをとる最終的な設計仕様に収束します。
スウォーム パターンは、専門家の共同チームをシミュレートするため、非常に高品質で創造的なソリューションを生成できます。ただし、実装するマルチエージェント パターンとしては最も複雑で費用がかかります。AI モデルを使用してオーケストレーションを行うエージェントがないと、非生産的なループやソリューションの収束に失敗するリスクが生じる可能性があります。そのため、複雑なエージェント間通信を管理し、反復的なワークフローを制御し、複数のエージェント間で動的なマルチターン会話を実行することに関連する多大な運用コストとレイテンシを処理する高度なロジックを設計する必要があります。
推論と行動（ReAct）パターン
ReAct パターンは、AI モデルを使用して、思考プロセスとアクションを自然言語による一連のインタラクションとしてフレーム化するアプローチです。このパターンでは、エージェントは終了条件が満たされるまで、思考、行動、観察の反復ループで動作します。
- 思考: モデルはタスクについて推論し、次に何をすべきかを決定します。モデルは、収集したすべての情報を評価して、ユーザーのリクエストに完全に回答しているかどうかを判断します。
- アクション: 思考プロセスに基づいて、モデルは次の 2 つのアクションのいずれかを行います。
- タスクが完了していない場合は、ツールを選択して、さらに情報を収集するためのクエリを作成します。
- タスクが完了すると、ユーザーに送信する最終的な回答を作成し、ループを終了します。
- 観察: モデルはツールから出力を受け取り、関連する情報をメモリに保存します。モデルは関連する出力を保存するため、以前の観察結果に基づいて構築できます。これにより、モデルが同じことを繰り返したり、コンテキストを失ったりするのを防ぐことができます。
反復ループは、エージェントが決定的な回答を見つけた場合、事前に設定された最大反復回数に達した場合、または続行を妨げるエラーが発生した場合に終了します。この反復ループにより、エージェントは動的に計画を立て、証拠を収集し、最終的な回答に向けてアプローチを調整できます。
次の図は、ReAct パターンの概要を示しています。
継続的な計画と適応が必要な複雑で動的なタスクには、ReAct パターンを使用します。たとえば、初期状態から目標状態に移行するパスを生成する必要があるロボット エージェントを考えてみましょう。
- 思考: モデルは、現在の状態から目標状態に移行するための最適なパスを推論します。思考プロセス中、モデルは時間やエネルギーなどの指標を最適化します。
- アクション: モデルは、計算されたパス セグメントに沿って移動することで、計画の次のステップを実行します。
- 観察: モデルは環境の新しい状態を観察して保存します。モデルは、新しい位置と、認識した環境への変更を保存します。
このループにより、エージェントは新しい観測に基づいて計画を常に更新することで、新しい障害物の回避や交通規制の遵守などの動的な制約を遵守できます。エージェントは、目標を達成するかエラーが発生するまで、反復ループを続けます。
単一の ReAct エージェントは、複雑なマルチエージェント システムよりも実装とメンテナンスが簡単で、費用対効果に優れています。モデルの思考は、モデルの推論の文字起こしを提供します。これはデバッグに役立ちます。ただし、この柔軟性にはトレードオフが伴います。ループの反復的なマルチステップの性質により、単一のクエリと比較してエンドツーエンドのレイテンシが高くなる可能性があります。さらに、エージェントの有効性は、AI モデルの推論の品質に大きく依存します。そのため、1 つの観察ステップでツールからエラーや誤解を招く結果が返されると、それが伝播して最終的な回答が不正確になる可能性があります。
人間参加型パターン
人間参加型パターンでは、人間が介入するポイントをエージェントのワークフローに直接統合します。事前定義されたチェックポイントで、エージェントは実行を一時停止し、外部システムを呼び出して、人間が作業をレビューするのを待ちます。このパターンでは、エージェントが続行する前に、人間が決定を承認したり、エラーを修正したり、必要な入力を提供したりできます。
次の図は、人間参加型パターンの概要を示しています。
人間参加型パターンは、人間による監視、主観的な判断、重要なアクションに対する最終承認が必要なタスクに使用します。このようなアクションには、大規模な金融取引の承認、機密ドキュメントの要約の検証、生成されたクリエイティブ コンテンツに関する主観的なフィードバックの提供などがあります。たとえば、エージェントに研究用の患者データセットの匿名化を任せるとします。エージェントは、すべての保護医療情報を自動的に識別して削除しますが、最終チェックポイントで一時停止します。その後、人間のコンプライアンス担当者がデータセットを手動で検証し、リリースを承認するまで待機します。これにより、機密データが公開されないようにすることができます。
人間参加型パターンでは、ワークフロー内の重要な意思決定ポイントに人間の判断を挿入することで、安全性と信頼性を向上させます。このパターンでは、ユーザー操作用の外部システムを構築して維持する必要があるため、アーキテクチャが大幅に複雑になる可能性があります。
ADK によるマルチエージェントのオーケストレーション
ADK は、単一エージェント システムとマルチエージェント システムの開発とオーケストレーションを行うためのオープンソース フレームワークです。このドキュメントで説明する設計パターンを実装するために、ADK を使用すると、エージェント、ツール、決定論的コード関数を構造化されたエージェント ワークフローに構成できます。
ADK は、次のワークフロー タイプを使用したエージェント オーケストレーションをサポートしています。
- グラフベースのワークフロー: アプリケーション ロジックを、実行ノードとエッジの宣言型グラフとして定義します。このアプローチにより、柔軟な実行パスを構築して、AI エージェント、ツール、決定的コード関数、ネストされたワークフロー間でデータをオーケストレートしてルーティングできます。
- 動的ワークフロー:
ifステートメントやelseステートメント、whileループやforループ、同時タスク実行などの標準的なプログラミング構造を使用して、ワークフロー ロジックを命令的に定義します。動的ワークフローを使用すると、ノード呼び出し間で型付き出力を直接渡すことができます。一方、ADK は各子ノードの実行を自動的に追跡し、チェックポイントを設定します。 - コラボレーション調整ワークフロー: ワークフロー ロジックを、問題を解決するために通信してコラボレーションできるマルチエージェント チームとして定義します。このアプローチでは、コーディネーター エージェントが AI モデルを使用してリクエストを解釈し、問題を分解して、専門のサブエージェントにサブタスクを動的に委任します。ADK は、宣言されたサブエージェントごとに委任ツールを自動的に生成するため、コーディネーターは実行時にタスクをルーティングできます。
次のステップ
- ADK を使用したマルチエージェント システムの設計と構築方法の詳細。
- Cloud Run で AI アプリとエージェントをホストする方法を学習する。
- ADK を使用してエージェントを構築する方法を学習する。
- Google Cloudでマルチエージェント AI システムを構築する方法を学習する。
- Google Cloudでエージェント型 AI アプリケーションのアーキテクチャ コンポーネントを選択する方法を学習する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Samantha He | テクニカル ライター
その他の寄稿者:
- Abdul Saleh | ソフトウェア エンジニア
- Amina Mansour | グローバル デベロッパー リレーションズおよび戦略的コンテンツ担当テクニカル リード
- Amit Maraj | デベロッパー リレーションズ エンジニア
- Casey West | アーキテクチャ アドボケイト、 Google Cloud
- Jack Wotherspoon | デベロッパー アドボケイト
- Joe Fernandez | スタッフ テクニカル ライター
- Joe Shirey | Cloud デベロッパー リレーションズ マネージャー
- Karl Weinmeister | Cloud プロダクト デベロッパー リレーションズ担当ディレクター
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Lisa Shen | シニア アウトバウンド プロダクト マネージャー、 Google Cloud
- Mandy Grover | アーキテクチャ センター責任者
- Mark Lu | テクニカル ライター
- Megan O'Keefe | デベロッパー アドボケイト
- Olivier Bourgeois | デベロッパーリレーションズ エンジニア
- Shir Meir Lador | デベロッパー リレーションズ エンジニアリング マネージャー
- Vlad Kolesnikov | デベロッパー リレーションズ エンジニア