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