Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

エージェント AI システムの設計パターンを選択する

Last reviewed 2026-05-28 UTC

このドキュメントでは、エージェント型 AI システムの設計パターンを選択する際のガイダンスを提供します。エージェント設計パターンは、エージェントアプリケーションを構築するための一般的なアーキテクチャアプローチです。エージェント設計パターンは、システムのコンポーネントを整理し、モデルを統合して、単一のエージェントまたは複数のエージェントをオーケストレートしてワークフローを完了するための、明確なフレームワークを提供します。

AI エージェントは、自律的な意思決定や複雑なマルチステップワークフロー管理が必要となる可能性のある、オープンエンドの問題を解決するアプリケーションに効果的です。エージェントは、外部データを使用して問題をリアルタイムで解決し、知識集約型のタスクを自動化することに優れています。AI エージェントは、AI がある程度の自律性を持って目標に焦点を当てたタスクを完了する必要がある場合に適しています。その他のユースケースでは、アシスト AI アプリケーションと生成 AI アプリケーションを使用できます。AI エージェントと非エージェント AI アプリケーションの違いについては、AI エージェント、AI アシスタント、bot の違いをご覧ください。

このガイドは、エージェント型 AI システムと、そのアーキテクチャが直接モデル推論や検索拡張生成（RAG）を使用するシステムなどの非エージェントシステムのアーキテクチャとどのように異なるかについての基本的な知識があることを前提としています。

エージェントパターンのガイダンスの概要については、このドキュメントの後半のデザインパターンを比較するをご覧ください。

設計プロセスの概要

エージェント型 AI システムの設計パターンを選択する大まかな手順は次のとおりです。これらの手順については、このドキュメントの後のセクションで詳しく説明します。

要件を定義する: タスクの複雑さ、レイテンシとパフォーマンスの期待値、費用予算、人間の関与の必要性など、ワークロードの特性を評価します。
一般的なエージェント設計パターンを確認する: このガイドでは、シングルエージェントシステムとマルチエージェントシステムの両方を含む一般的な設計パターンについて説明します。
パターンを選択する: ワークロードの特性に基づいて、適切な設計パターンを選択します。

このプロセスは 1 回限りの決定ではありません。ワークロードの特性の変化、要件の進化、新しい Google Cloud 機能の利用可能性に応じて、これらの手順を定期的に見直してアーキテクチャを改良する必要があります。

要件を定義する

以下の質問は、計画に関する完全なチェックリストではありません。これらの質問を出発点として、エージェントシステムの主な目標を特定し、最適な設計パターンを選択します。

タスクの特性: タスクは事前定義されたワークフローステップで完了できますか？それとも、タスクはオープンエンドですか？タスクで AI モデルを使用してワークフローをオーケストレートする必要があるか。
レイテンシとパフォーマンス: 精度や高品質の応答を犠牲にして、高速またはインタラクティブな応答を優先する必要がありますか？または、より正確で徹底的な結果を得るために、アプリケーションで遅延を許容できますか？
費用: 推論費用の予算はどれくらいですか？1 つのリクエストに対してモデルへの複数の呼び出しが必要なパターンをサポートできますか？
人間の関与: タスクに、重大な影響を及ぼす意思決定、安全性に不可欠なオペレーション、人間の判断を必要とする主観的な承認が含まれていますか？

ワークロードが予測可能または高度に構造化されている場合や、AI モデルへの 1 回の呼び出しで実行できる場合は、タスクに非エージェントソリューションを検討する方が費用対効果が高くなります。たとえば、ドキュメントの要約、テキストの翻訳、顧客フィードバックの分類などのタスクでは、エージェントワークフローは必要ない場合があります。エージェント型インフラストラクチャを必要としない生成 AI アプリケーションのアーキテクチャコンポーネントの選択については、生成 AI アプリケーションのモデルとインフラストラクチャを選択するをご覧ください。

以降のセクションでは、信頼性が高く効果的なエージェント型 AI システムを構築するための一般的なエージェント設計パターンについて説明します。

単一エージェントシステム

シングルエージェントシステムは、AI モデル、定義されたツールセット、包括的なシステムプロンプトを使用して、ユーザーリクエストを自律的に処理したり、特定のタスクを完了したりします。この基本的なパターンでは、エージェントはモデルの推論機能を利用して、ユーザーのリクエストを解釈し、一連のステップを計画して、定義されたセットから使用するツールを決定します。システムプロンプトは、エージェントのコアタスク、ペルソナ、オペレーション、各ツールの使用に関する特定の条件を定義することで、エージェントの動作を形成します。

次の図は、単一エージェントパターンの概要を示しています。

単一エージェント設計パターンのアーキテクチャ。

単一エージェントシステムは、複数のステップと外部データへのアクセスを必要とするタスクに最適です。たとえば、カスタマーサポートエージェントがデータベースにクエリを実行して注文ステータスを確認する必要がある場合や、リサーチアシスタントが API を呼び出して最近のニュースを要約する必要がある場合などです。エージェント型でないシステムは、ツールを自律的に使用したり、マルチステップの計画を実行して最終的な回答を合成したりできないため、これらのタスクを実行できません。

エージェント開発の初期段階では、1 つのエージェントから始めることをおすすめします。シングルエージェントシステムでエージェントの開発を開始すると、より複雑なアーキテクチャコンポーネントを追加する前に、エージェントのコアロジック、プロンプト、ツール定義の改良に集中できます。

1 つのエージェントがより多くのツールを使用し、タスクの複雑さが増すと、パフォーマンスが低下する可能性があります。これは、レイテンシの増加、ツールの選択や使用の誤り、タスクの完了の失敗として現れることがあります。多くの場合、Reason and Act（ReAct）パターンなどの手法を使用してエージェントの推論プロセスを改善することで、これらの問題を軽減できます。ただし、ワークフローでエージェントが複数の異なる責任を管理する必要がある場合は、これらの手法では不十分な可能性があります。このような場合は、マルチエージェントシステムを検討してください。このシステムでは、特定のスキルを特化したエージェントに委任することで、復元力とパフォーマンスを向上させることができます。

マルチエージェントシステム

マルチエージェントシステムは、複数の専門エージェントをオーケストレートして、単一のエージェントでは簡単に管理できない複雑な問題を解決します。基本的な原則は、大きな目標を小さなサブタスクに分解し、各サブタスクを特定のスキルを持つ専用のエージェントに割り当てることです。これらのエージェントは、協調型または階層型のワークフローを通じて連携し、最終的な目標を達成します。マルチエージェントパターンは、モノリシックなプロンプトを使用する単一エージェントと比較して、システム全体のスケーラビリティ、信頼性、メンテナンス性を向上させることができるモジュラー設計を提供します。

マルチエージェントシステムでは、各エージェントがタスクを効果的に実行するために特定のコンテキストを必要とします。コンテキストには、ドキュメント、過去の設定、関連リンク、会話履歴、運用上の制約などを含めることができます。この情報フローを管理するプロセスは、コンテキストエンジニアリングと呼ばれます。コンテキストエンジニアリングには、特定のエージェントのコンテキストを分離する、複数のステップにわたって情報を保持する、大量のデータを圧縮して効率を向上させるなどの戦略が含まれます。

AI エージェントは、従来の決定論的なセキュリティプラクティスでは適切に軽減できない、特有の重大なセキュリティリスクをもたらします。上り（内向き）トラフィックと下り（外向き）トラフィックのルーティングとセキュリティには Agent Gateway を、ワークロードにバインドされた認証と最小権限のアクセス制御には Agent Identity を、検証済みのツールとサブエージェントが使用されるようにするには Agent Registry を使用します。

このセクションのガイダンスはすべてを網羅しているわけではありません。設計要素とベストプラクティスの詳細、およびマルチエージェント AI システムの構築とデプロイに関する推奨事項については、 Google Cloudのマルチエージェント AI システムをご覧ください。

シーケンスパターン

マルチエージェントシーケンシャルパターンは、事前定義された線形順序で一連の専門エージェントを実行します。このパターンでは、1 つのエージェントの出力が次のエージェントの直接入力として使用されます。このパターンでは、サブエージェントのオーケストレーションのために AI モデルに問い合わせることなく、事前定義されたロジックで動作するシーケンシャルワークフローエージェントを使用します。

次の図は、マルチエージェントのシーケンシャルパターンの概要を示しています。

マルチエージェントシーケンシャル設計パターンのアーキテクチャ。

オペレーションの順序が変更されない、高度に構造化された反復可能なプロセスには、シーケンシャルパターンを使用します。たとえば、データ処理パイプラインでこのパターンを使用すると、まずデータ抽出エージェントが元データを取得し、そのデータをデータクリーニングエージェントに渡してフォーマットします。その後、クリーンなデータをデータ読み込みエージェントに渡してデータベースに保存します。

シーケンシャルパターンを使用すると、AI モデルを使用してタスクワークフローをオーケストレートするパターンと比較して、レイテンシと運用コストを削減できます。ただし、この効率性は柔軟性を犠牲にして実現されています。パイプラインの構造が厳格で事前に定義されているため、動的な条件に適応したり、不要なステップをスキップしたりすることが難しく、不要なステップが遅い場合は、処理が非効率になったり、累積レイテンシが増加したりする可能性があります。

並列パターン

マルチエージェント並列パターン（同時実行パターンとも呼ばれます）では、複数の専門サブエージェントがタスクまたはサブタスクを同時に独立して実行します。サブエージェントの出力が合成され、最終的な統合レスポンスが生成されます。シーケンシャルパターンと同様に、並列パターンでは、並列ワークフローエージェントを使用して、他のエージェントの実行方法と実行タイミングを管理します。サブエージェントをオーケストレートするために AI モデルに問い合わせる必要はありません。

次の図は、マルチエージェント並列パターンの概要を示しています。

マルチエージェント並列設計パターンのアーキテクチャ。

並列パターンは、サブタスクを同時に実行してレイテンシを短縮したり、さまざまな視点を収集したりできる場合に使用します。たとえば、異なるソースからデータを収集したり、複数のオプションを一度に評価したりする場合です。たとえば、顧客からのフィードバックを分析するために、並列エージェントは、1 つのフィードバックエントリを 4 つの専門エージェント（感情分析エージェント、キーワード抽出エージェント、分類エージェント、緊急度検出エージェント）に同時にファンアウトできます。最後のエージェントが、これら 4 つの出力をフィードバックの 1 つの包括的な分析にまとめます。

並列パターンは、複数のソースからさまざまな情報を同時に収集できるため、シーケンシャルなアプローチと比較して全体的なレイテンシを短縮できます。ただし、このアプローチではコストと複雑さのトレードオフが発生します。複数のエージェントを並列で実行すると、即時のリソース使用率とトークン消費量が増加し、運用コストが高くなる可能性があります。さらに、収集ステップでは、競合する可能性のある結果を合成するために複雑なロジックが必要になり、システムの開発とメンテナンスのオーバーヘッドが増加します。

ループパターン

マルチエージェントループエージェントパターンは、特定の終了条件が満たされるまで、特殊なサブエージェントのシーケンスを繰り返し実行します。このパターンでは、他のワークフローエージェントと同様に、オーケストレーションのために AI モデルを参照することなく、事前定義されたロジックで動作するループワークフローエージェントを使用します。すべてのサブエージェントがタスクを完了すると、ループエージェントは終了条件が満たされているかどうかを評価します。条件には、最大反復回数またはカスタム状態を指定できます。終了条件が満たされない場合、ループエージェントはサブエージェントのシーケンスを再度開始します。フロー内の任意の時点で終了条件が評価されるループパターンを実装できます。ループパターンは、反復的な改良や自己修正が必要なタスクに使用します。たとえば、コンテンツを生成し、品質基準を満たすまで批評エージェントにレビューさせる場合などです。

次の図は、マルチエージェントループパターンの概要を示しています。

マルチエージェントループ設計パターンのアーキテクチャ。

ループエージェントパターンは、複雑な反復ワークフローを構築する方法を提供します。これにより、エージェントは特定の品質または状態が達成されるまで、自身の作業を改善し、処理を継続できます。ただし、このパターンの主なトレードオフは、無限ループのリスクです。終了条件が正しく定義されていない場合や、停止に必要な状態をサブエージェントが生成できない場合、ループは無限に実行される可能性があります。これにより、運用コストの増加、リソース消費量の増加、システムのハングアップが発生する可能性があります。

レビューと批評のパターン

マルチエージェントレビューと批評パターン（ジェネレータと批評パターンとも呼ばれます）は、通常はシーケンシャルワークフローで 2 つの専門エージェントを使用して、生成されたコンテンツの品質と信頼性を向上させます。レビューと批評のパターンは、ループエージェントパターンの実装です。

レビューと批判のパターンでは、生成エージェントがコードブロックやドキュメントの要約などの初期出力を生成します。次に、批評エージェントが、事実に基づく正確性、形式ルールの遵守、安全に関するガイドラインなど、事前定義された一連の基準に照らしてこの出力を評価します。評価に基づいて、批評家はコンテンツを承認、拒否、または修正のフィードバックとともにジェネレータに返送できます。

次の図は、マルチエージェントレビューと批評パターンの概要を示しています。

マルチエージェントレビュー / 批評設計パターンのアーキテクチャ。

このパターンは、ユーザーに提示される前に、またはダウンストリームプロセスで使用される前に、出力が非常に正確であるか、厳格な制約に準拠している必要があるタスクに適しています。たとえば、コード生成ワークフローでは、ジェネレータエージェントがユーザーのリクエストを満たす関数を作成することがあります。この生成されたコードは、セキュリティ監査者として機能する批評エージェントに渡されます。批評家エージェントの役割は、コードの使用が承認される前に、セキュリティ上の脆弱性のスキャンや、すべての単体テストに合格していることの確認など、一連の制約に照らしてコードをチェックすることです。

レビューアと批評のパターンは、専用の検証ステップを追加するため、出力の品質、精度、信頼性を向上させることができます。ただし、この品質保証には、レイテンシと運用費用の増加という直接的なコストがかかります。ワークフローでは、批評家の評価のために少なくとも 1 つの追加のモデル呼び出しが必要です。プロセスに、コンテンツを改良のために送り返すリビジョンループが含まれている場合、レイテンシと費用は反復ごとに増加します。

反復的な改善パターンでは、ループメカニズムを使用して、複数のサイクルにわたって出力を段階的に改善します。反復的な改良パターンは、ループエージェントパターンの実装です。

このパターンでは、1 つ以上のエージェントがループ内で動作し、各イテレーション中にセッション状態に保存された結果を変更します。このプロセスは、出力が事前定義された品質しきい値を満たすか、最大イテレーション回数に達するまで継続されます。これにより、無限ループが防止されます。

次の図は、マルチエージェントの反復型改善パターンの概要を示しています。

マルチエージェントの反復的改善設計パターンのアーキテクチャ。

このパターンは、出力を 1 つのステップで実現することが難しい複雑な生成タスクに適しています。このようなタスクの例としては、コードの作成とデバッグ、詳細なマルチパートプランの作成、長文ドキュメントの作成と修正などがあります。たとえば、クリエイティブライティングワークフローでは、エージェントがブログ投稿の下書きを生成し、下書きのフローとトーンを批評して、その批評に基づいて下書きを書き直すことができます。このプロセスは、エージェントの作業が事前定義された品質基準を満たすか、繰り返しが最大イテレーション回数に達するまで、ループで繰り返されます。

反復的な改善パターンでは、1 回のステップでは実現が難しい、非常に複雑で洗練された出力を生成できます。ただし、ループメカニズムは、サイクルごとにレイテンシと運用コストを直接増加させます。このパターンでは、アーキテクチャの複雑さも増します。過剰なコストや制御不能な実行を防ぐには、品質評価や最大反復回数などの終了条件を慎重に設計する必要があるためです。

コーディネーターパターン

マルチエージェントコーディネーターパターンでは、中央エージェント（コーディネーター）を使用してワークフローを指示します。コーディネーターは、ユーザーのリクエストを分析してサブタスクに分解し、各サブタスクを専門のエージェントにディスパッチして実行します。各専門エージェントは、データベースのクエリや API の呼び出しなど、特定の機能の専門家です。

コーディネーターパターンの特徴は、AI モデルを使用してタスクをオーケストレートし、動的にルーティングすることです。一方、並列パターンは、ハードコードされたワークフローに依存して、AI モデルのオーケストレーションを必要とせずに、タスクをディスパッチして同時に実行します。

次の図は、マルチエージェントコーディネーターパターンの概要を示しています。

マルチエージェントコーディネーター設計パターンのアーキテクチャ。

適応型ルーティングを必要とする構造化されたビジネスプロセスを自動化するには、コーディネーターパターンを使用します。たとえば、カスタマーサービスエージェントがコーディネーターとして機能できます。コーディネーターエージェントは、リクエストを分析して、注文ステータスのリクエスト、商品の返品、払い戻しリクエストのいずれであるかを判断します。コーディネーターは、リクエストのタイプに基づいて、タスクを適切な専門エージェントにルーティングします。

コーディネーターパターンは、より厳格で事前定義されたワークフローと比較して柔軟性があります。モデルを使用してタスクをルーティングすることで、コーディネーターはより幅広い入力を処理し、実行時にワークフローを適応させることができます。ただし、このアプローチにはトレードオフもあります。コーディネーターと各専門エージェントは推論にモデルを使用するため、このパターンでは、単一エージェントシステムよりもモデル呼び出しが多くなります。コーディネーターパターンは、より高品質な推論につながる可能性がありますが、シングルエージェントシステムと比較すると、トークンスループット、運用コスト、全体的なレイテンシも増加します。

階層型タスク分解パターン

マルチエージェントの階層型タスク分解パターンは、エージェントを多層階層に編成して、広範な計画を必要とする複雑な問題を解決します。階層型タスク分解パターンは、コーディネーターパターンの実装です。最上位の親エージェント（ルートエージェント）は、複雑なタスクを受け取り、そのタスクを管理しやすい小さなサブタスクに分解します。ルートエージェントは、各サブタスクを下位レベルの専門のサブエージェントに委任します。このプロセスは複数のレイヤで繰り返すことができます。エージェントは、割り当てられたタスクを最下位レベルのワーカーエージェントが直接実行できるようになるまで、段階的に分解します。

次の図は、マルチエージェント階層型タスク分解パターンの概要を示しています。

マルチエージェント階層型タスク分解設計パターンのアーキテクチャ。

階層型タスク分解パターンは、調査、計画、合成を伴うタスクなど、マルチステップの推論を必要とする、曖昧で自由度の高い問題に使用します。たとえば、複雑な調査プロジェクトを完了するために、コーディネーターエージェントは、高レベルの目標を情報の収集、調査結果の分析、最終レポートの統合などの複数のタスクに分解します。コーディネーターエージェントは、これらのタスクをデータ収集エージェント、分析エージェント、レポート作成エージェントなどの専門のサブエージェントに委任して、実行またはさらに分解します。

階層型タスク分解パターンは、複雑で曖昧な問題を体系的に管理可能なサブタスクに分解するため、このような問題の解決に最適です。このパターンを使用すると、よりシンプルなパターンよりも包括的で高品質な結果が得られます。ただし、この高度な機能には大きなトレードオフがあります。マルチレベル構造により、アーキテクチャが大幅に複雑になり、システムの設計、デバッグ、メンテナンスが難しくなります。また、委任と推論の複数のレイヤにより、モデル呼び出しの数が増加し、他のパターンと比較して全体的なレイテンシと運用コストが大幅に増加します。

スウォームパターン

マルチエージェントスウォームパターンでは、協調的なオールツーオール通信アプローチを使用します。このパターンでは、複数の専門エージェントが連携して、複雑な問題の解決策を繰り返し改良します。

次の図は、マルチエージェントスウォームパターンの概要を示しています。

マルチエージェントスワーム設計パターンのアーキテクチャ。

スウォームパターンでは、ディスパッチャエージェントを使用して、ユーザーリクエストを専門エージェントのコラボレーショングループにルーティングします。ディスパッチャエージェントはリクエストを解釈し、タスクの開始に最適なスウォーム内のエージェントを決定します。このパターンでは、各エージェントが他のすべてのエージェントと通信できるため、調査結果の共有、提案の批評、相互の作業の積み重ねによるソリューションの反復的な改善が可能になります。スウォーム内のエージェントは、次のステップの処理に適していると判断した別のエージェントにタスクを引き継ぐことができます。また、コーディネーターエージェントを介して最終的なレスポンスをユーザーに伝えることもできます。

通常、スワームにはプロセスを追跡する中央のスーパーバイザーまたはコーディネーターエージェントがありません。コーディネーターパターンとは異なり、ディスパッチャエージェントはエージェントワークフローをオーケストレートしません。代わりに、ディスパッチャエージェントが、スウォームサブエージェントとユーザー間の通信を容易にします。スウォームが最終的に停止して結果を返すようにするには、明示的な終了条件を定義する必要があります。この条件は、多くの場合、最大イテレーション回数、時間制限、コンセンサスの達成などの特定の目標の達成です。

議論と反復的な改善が有効な、曖昧または非常に複雑な問題には、スウォームパターンを使用します。たとえば、新製品の設計には、市場調査エージェント、エンジニアリングエージェント、財務モデリングエージェントが関与する場合があります。エージェントは最初のアイデアを共有し、機能と費用のトレードオフについて議論し、競合するすべての要件のバランスを取る最終的な設計仕様に集団で収束します。

スウォームパターンは、エキスパートのコラボレーションチームをシミュレートするため、非常に高品質で創造的なソリューションを生み出すことができます。ただし、実装するマルチエージェントパターンとしては最も複雑でコストがかかります。AI モデルを使用してオーケストレーションを行うエージェントがないと、非生産的なループが発生したり、ソリューションに収束しなかったりするリスクが生じます。そのため、複雑なエージェント間通信を管理し、反復的なワークフローを制御し、複数のエージェント間で動的なマルチターン会話を実行することに関連する多大な運用コストとレイテンシを処理する高度なロジックを設計する必要があります。

推論と行動（ReAct）パターン

ReAct パターンは、AI モデルを使用して、思考プロセスとアクションを自然言語による一連のインタラクションとしてフレーム化するアプローチです。このパターンでは、エージェントは終了条件が満たされるまで、思考、アクション、観察の反復ループで動作します。

思考: モデルはタスクについて推論し、次に何をすべきかを決定します。モデルは、収集したすべての情報を評価して、ユーザーのリクエストに完全に回答したかどうかを判断します。
アクション: 思考プロセスに基づいて、モデルは次の 2 つのアクションのいずれかを行います。
- タスクが完了していない場合は、ツールを選択し、追加情報を収集するためのクエリを作成します。
- タスクが完了すると、ユーザーに送信する最終的な回答が作成され、ループが終了します。
観察: モデルがツールから出力を受け取り、関連情報をメモリに保存します。モデルは関連する出力を保存するため、以前の観測結果に基づいて構築できます。これにより、モデルが同じことを繰り返したり、コンテキストを失ったりすることを防ぐことができます。

反復ループは、エージェントが最終的な回答を見つけたとき、事前に設定された最大反復回数に達したとき、または続行を妨げるエラーが発生したときに終了します。この反復ループにより、エージェントは動的に計画を立て、証拠を収集し、最終的な回答に向けてアプローチを調整できます。

次の図は、ReAct パターンの概要を示しています。

ReAct 設計パターンのアーキテクチャ。

継続的な計画と適応が必要な複雑で動的なタスクには、ReAct パターンを使用します。たとえば、初期状態から目標状態に移行するパスを生成する必要があるロボットエージェントを考えてみましょう。

思考: モデルは、現在の状態から目標の状態に移行するための最適なパスについて推論します。思考プロセス中に、モデルは時間やエネルギーなどの指標を最適化します。
アクション: モデルは、計算されたパスセグメントに沿って移動し、プランの次のステップを実行します。
観察: モデルは環境の新しい状態を観察して保存します。モデルは、新しい位置と、認識した環境への変更を保存します。

このループにより、エージェントは新しい観測に基づいて計画を常に更新することで、新しい障害物の回避や交通規制の遵守などの動的な制約に従うことができます。エージェントは、目標を達成するかエラーが発生するまで、反復ループを続行します。

単一の ReAct エージェントは、複雑なマルチエージェントシステムよりも実装とメンテナンスが簡単で、費用対効果に優れています。モデルの思考は、モデルの推論の文字起こしを提供し、デバッグに役立ちます。ただし、この柔軟性にはトレードオフが伴います。ループの反復的なマルチステップの性質により、単一のクエリと比較してエンドツーエンドのレイテンシが高くなる可能性があります。さらに、エージェントの有効性は、AI モデルの推論の品質に大きく依存します。そのため、1 つの観測ステップでツールからエラーや誤解を招く結果が出力されると、それが伝播して最終的な回答が誤ったものになる可能性があります。

人間参加型パターン

人間参加型パターンでは、人間が介入するポイントをエージェントのワークフローに直接統合します。事前定義されたチェックポイントで、エージェントは実行を一時停止し、外部システムを呼び出して、作業のレビューを待ちます。このパターンを使用すると、エージェントが続行する前に、ユーザーが決定を承認したり、エラーを修正したり、必要な入力を提供したりできます。

次の図は、人間参加型パターンの概要を示しています。

マルチエージェント人間参加型設計パターンのアーキテクチャ。

人間参加型パターンは、人間の監視、主観的な判断、重要なアクションの最終承認が必要なタスクに使用します。このようなアクションには、大規模な金融取引の承認、機密性の高いドキュメントの要約の検証、生成されたクリエイティブコンテンツに関する主観的なフィードバックの提供などがあります。たとえば、エージェントに研究用の患者データセットの匿名化を指示したとします。エージェントは保護された医療情報をすべて自動的に特定して編集しますが、最終チェックポイントで一時停止します。その後、人間のコンプライアンスオフィサーがデータセットを手動で検証し、リリースを承認するまで待機します。これにより、機密データが公開されないようにします。

人間参加型パターンは、ワークフロー内の重要な意思決定ポイントに人間の判断を挿入することで、安全性と信頼性を向上させます。このパターンでは、ユーザーインタラクション用の外部システムを構築して維持する必要があるため、アーキテクチャが大幅に複雑になる可能性があります。

カスタムロジックパターン

カスタムロジックパターンを使用すると、ワークフロー設計の柔軟性を最大限に高めることができます。このアプローチでは、コード（条件ステートメントなど）を使用して、複数の分岐パスを持つ複雑なワークフローを作成する特定のオーケストレーションロジックを実装できます。

次の図は、カスタムロジックパターンを使用して払い戻しプロセスをキャプチャする例を示しています。

マルチエージェントカスタム設計パターンのアーキテクチャ。

上の図は、お客様の払い戻しエージェントの例のエージェントワークフローを示しています。

ユーザーが、コーディネーターエージェントとして機能するお客様の払い戻しエージェントにクエリを送信します。
コーディネーターのカスタムロジックは、まず並列検証エージェントを呼び出します。このエージェントは、購入者検証エージェントと払い戻しの対象エージェントの 2 つのサブエージェントを同時にディスパッチします。
結果が収集されると、コーディネーターエージェントはツールを実行して、リクエストが払い戻しの対象かどうかを確認します。
1. お客様が対象となる場合、コーディネーターはタスクを払い戻し処理エージェントにルーティングし、エージェントは process_refund ツールを呼び出します。
2. お客様が対象外の場合は、コーディネーターがタスクを別の順次フローに転送します。このフローは、Google ストアポイントエージェントとプロセスクレジット決定エージェントから始まります。
どちらのパスの結果も、最終レスポンスエージェントに送信され、ユーザーへの回答が作成されます。

顧客払い戻しエージェントの例では、他のパターンが提供する構造化されたアプローチを超える、ロジックレベルのオーケストレーションに独自のソリューションが必要です。このワークフローでは、並列チェックを実行してから、2 つのまったく異なるダウンストリームプロセスにルーティングするカスタム条件分岐を実行するため、パターンが混在しています。このタイプの複雑な混合パターンのワークフローは、カスタムロジックパターンの理想的なユースケースです。

エージェントの実行をきめ細かく制御する必要がある場合や、ワークフローがこのドキュメントで説明されている他のパターンのいずれにも当てはまらない場合は、カスタムロジックパターンを使用します。ただし、このアプローチでは開発とメンテナンスが複雑になります。オーケストレーションフロー全体の設計、実装、デバッグはユーザーが行う必要があります。これには、Agent Development Kit（ADK）などのツールでサポートされている事前定義されたパターンを使用する場合よりも多くの開発作業が必要になり、エラーが発生しやすくなります。

カスタムエージェントと、ADK を使用してカスタムロジックを実装する方法については、カスタムエージェントをご覧ください。

デザインパターンを比較する

エージェントパターンの選択は、アーキテクチャに関する基本的な決定です。各パターンには、柔軟性、複雑さ、パフォーマンスのトレードオフが異なります。ワークロードに適したパターンを決定するには、次のセクションのデザインパターンを検討してください。

決定的なワークフロー

決定的なワークフローには、予測可能で順次実行されるタスクが含まれ、開始から終了までのワークフローパスが明確に定義されています。タスクのステップは事前にわかっており、プロセスは実行ごとに大きく変化しません。

決定論的なワークフローのエージェント設計パターンは次のとおりです。

マルチエージェントシーケンシャルパターン