Google Cloud のマルチエージェント AI システム

Last reviewed 2026-10-09 UTC

このドキュメントでは、 Google Cloudで堅牢なマルチエージェント型 AI システムを設計する際に役立つリファレンス アーキテクチャについて説明します。マルチエージェント AI システムは、複雑で動的なプロセスを、複数の特化型 AI エージェントが連携して実行する個別のタスクに分割することで、プロセスを最適化します。

このドキュメントは、クラウドで AI インフラストラクチャとアプリケーションを構築して管理するアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI エージェントとモデルに関する基本的な知識があることを前提としています。このドキュメントでは、AI エージェントの設計とコーディングに関する具体的なガイダンスは提供していません。

このドキュメントのDeploymentセクションには、マルチエージェント型 AI システムのビルド方法とデプロイ方法を学習するために使用できるコードサンプルが記載されています。

アーキテクチャ

次の図は、 Google Cloudにデプロイされたマルチエージェント AI システムのアーキテクチャの例を示しています。

 Google Cloudのマルチエージェント AI システムのアーキテクチャ。  Google Cloudのマルチエージェント AI システムのアーキテクチャ。

アーキテクチャ コンポーネント

前のセクションのサンプル アーキテクチャには、次のコンポーネントが含まれています。

フロントエンド
ユーザーは、サーバーレスの Cloud Run サービスとして実行されるチャット インターフェースなどのフロントエンドを介して、マルチエージェント システムとやり取りします。
エージェント

この例では、コーディネーター エージェントがエージェント型 AI システムを制御します。コーディネーター エージェントは、適切なサブエージェントを呼び出して、エージェント フローをトリガーします。エージェントは、Agent2Agent(A2A)プロトコルを使用して相互に通信できます。これにより、プログラミング言語やランタイムに関係なく、エージェント間の相互運用性が実現します。このアーキテクチャの例では、シーケンシャル パターンと反復的な改良パターンのエージェントを示しています。

この例のサブエージェントの詳細については、エージェント フローのセクションをご覧ください。

エージェント ランタイム

AI エージェントは、サーバーレス Cloud Run サービスとして、Google Kubernetes Engine(GKE)上のコンテナ化されたアプリとして、または Gemini Enterprise Agent Platform の Agent Runtime 上にデプロイできます。

ADK

Agent Development Kit(ADK)は、エージェントの開発、テスト、デプロイを行うためのツールとフレームワークを提供します。ADK はエージェント作成の複雑さを抽象化し、AI デベロッパーがエージェントのロジックと機能に集中できるようにします。

AI モデルとモデル ランタイム

推論サービングの場合、このサンプル アーキテクチャのエージェントは Gemini Enterprise Agent Platform の AI モデルを使用します。このアーキテクチャでは、使用する AI モデルの代替ランタイムとして Cloud Run と GKE が示されています。

Model Armor

Model Armor を使用すると、Agent Platform と GKE にデプロイされたモデルの入力とレスポンスを検査してサニタイズできます。Model Armor は、Agent Gateway を介してルーティングされるエージェントとツールのトラフィックにも使用できます。詳細については、Model Armor と Google Cloud サービスの統合をご覧ください。

MCP クライアント、サーバー、ツール

Model Context Protocol(MCP)は、エージェントとツールのやり取りを標準化することで、ツールへのアクセスを容易にします。エージェントとツールのペアごとに、MCP クライアントは MCP サーバーにリクエストを送信します。エージェントは、このサーバーを介してデータベース、ファイル システム、API などのツールにアクセスします。

エージェント フロー

上記のアーキテクチャのマルチエージェント システムの例では、次のフローがあります。

  1. ユーザーが、サーバーレス Cloud Run サービスとして実行されるチャット インターフェースなどのフロントエンドからプロンプトを入力します。
  2. フロントエンドはプロンプトをコーディネーター エージェントに転送します。
  3. コーディネーター エージェントは、プロンプトで表現されたインテントに基づいて、次のいずれかのエージェント フローを開始します。

    • 順次:
      1. タスク A のサブエージェントがタスクを実行します。
      2. task-A サブエージェントが task-A.1 サブエージェントを呼び出します。
    • 反復的な改良:

      1. タスク B のサブエージェントがタスクを実行します。
      2. 品質評価サブエージェントは、タスク B サブエージェントの出力を確認します。
      3. 出力が不十分な場合、品質評価者はプロンプト エンハンサー サブエージェントを呼び出してプロンプトを調整します。
      4. タスク B サブエージェントは、拡張プロンプトを使用してタスクを再度実行します。

      このサイクルは、出力が満足のいくものになるか、最大イテレーション回数に達するまで続きます。

    このアーキテクチャの例には、必要に応じて人間のユーザーがエージェント フローに介入できるように、human-in-the-loopのパスが含まれています。

  4. タスク A.1 サブエージェントと品質評価サブエージェントは、レスポンス生成サブエージェントを個別に呼び出します。

  5. レスポンス生成サブエージェントは、レスポンスを生成し、検証とグラウンディング チェックを実行してから、コーディネーター エージェントを介して最終レスポンスをユーザーに送信します。

使用するプロダクトとツール

このリファレンス アーキテクチャでは、次の Google Cloud プロダクトとサードパーティのプロダクトとツールを使用します。

  • Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるサーバーレス コンピューティング プラットフォーム。
  • Gemini Enterprise Agent Platform: エンタープライズ グレードの AI エージェントを構築、スケーリング、管理、最適化できる包括的なプラットフォーム。
  • Google Kubernetes Engine(GKE): Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できる Kubernetes サービス。
  • Model Armor: プロンプト インジェクション、センシティブ データの漏洩、有害なコンテンツから生成 AI リソースとエージェント型 AI リソースを保護するサービス。
  • Agent Development Kit(ADK): AI エージェントを開発、テスト、デプロイするための一連のツールとライブラリ。
  • Agent2Agent(A2A)プロトコル: プログラミング言語やランタイムに関係なく、エージェント間の通信と相互運用を可能にするオープン プロトコル。
  • Model Context Protocol(MCP): AI アプリケーションを外部システムに接続するためのオープンソース標準。

ユースケース

マルチエージェント AI システムは、ビジネス目標を達成するために、複数の専門的なスキルセットにわたるコラボレーションと調整が必要な複雑なユースケースに適しています。マルチエージェント AI システムに適したユースケースを特定するには、ビジネス プロセスを分析し、AI で拡張できる特定のタスクを特定します。コスト削減や処理の高速化など、具体的なビジネス成果に焦点を当てます。このアプローチは、AI への投資をビジネス価値に合わせるのに役立ちます。

マルチエージェント AI システムのユースケースの例を次に示します。

ファイナンシャル アドバイザー

パーソナライズされた株式取引の推奨事項を提供し、取引を実行します。次の図は、このユースケースのエージェント フローの例を示しています。この例では、順次パターンを使用します。

マルチエージェント システムのファイナンシャル アドバイザーのユースケース。

図は次のフローを示しています。

  1. データ取得エージェントは、信頼できるソースからリアルタイムと過去の株価、企業の財務報告、その他の関連データを取得します。
  2. 財務分析エージェントは、データに適切な分析手法とグラフ作成手法を適用し、価格変動パターンを特定して予測を行います。
  3. 株式レコメンダー エージェントは、分析とチャートを使用して、ユーザーのリスク プロファイルと投資目標に基づいて、特定の株式の売買に関するパーソナライズされたおすすめ表示を生成します。
  4. 取引実行エージェントは、ユーザーに代わって株式を売買します。

リサーチ アシスタント

リサーチプランを作成し、情報を収集し、リサーチを評価して改良し、レポートを作成します。次の図は、このユースケースのエージェント フローの例を示しています。この例のメインフローでは、シーケンシャル パターンを使用します。この例には、反復的な改良パターンも含まれています。

マルチエージェント システムのリサーチ アシスタントのユースケース。

図は次のフローを示しています。

  1. プランナー エージェントが詳細なリサーチプランを作成します。
  2. リサーチャー エージェントは、次のタスクを完了します。

    1. リサーチプランを使用して、適切な内部データソースと外部データソースを特定します。
    2. 必要なデータを収集して分析します。
    3. 調査の概要を準備し、評価エージェントに提供します。

    リサーチャー エージェントは、評価エージェントが調査を承認するまで、これらのタスクを繰り返します。

  3. レポート作成エージェントが最終的なリサーチ レポートを作成します。

サプライ チェーン オプティマイザー

在庫の最適化、配送の追跡、サプライ チェーン パートナーとのコミュニケーション。 次の図は、このユースケースのエージェント フローの例を示しています。この例では、シーケンシャル パターンを使用しています。

マルチエージェント システムのサプライ チェーン最適化ツールのユースケース。

  1. 倉庫管理エージェントは、在庫、需要予測、サプライヤーのリードタイムに基づいて再入荷注文を作成し、最適な在庫レベルを確保します。

    • エージェントは、配送トラッカー エージェントとやり取りして配送を追跡します。
    • エージェントは、サプライヤー コミュニケーター エージェントとやり取りして、注文の変更をサプライヤーに通知します。
  2. 配送トラッカー エージェントは、サプライヤーの物流プラットフォームや配送業者のシステムと統合することで、注文をタイムリーかつ効率的に処理します。

  3. サプライヤー コミュニケーター エージェントは、システム内の他のエージェントに代わって外部サプライヤーと通信します。

代替案を設計する

管理性、制御性、柔軟性の要件に応じて、 Google Cloud の AI エージェントとモデルのさまざまなランタイム オプションから選択できます。詳細については、エージェント型 AI アーキテクチャ コンポーネントを選択するをご覧ください。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、推奨事項について説明します。

このセクションのガイダンスはすべてを網羅しているわけではありません。ワークロードの要件と、使用する Google Cloud およびサードパーティのプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。

システム設計

このセクションでは、デプロイに使用する Google Cloud リージョンの選択と、適切な Google Cloud プロダクトとツールの選択に役立つガイダンスを示します。

リージョンの選択

AI アプリケーションの Google Cloud リージョンを選択する場合は、次の要素を考慮してください。

  • 各リージョンでの Google Cloud サービスの可用性。
  • エンドユーザーのレイテンシ要件。
  • Google Cloud リソースの費用。
  • 規制要件

アプリケーションに適した Google Cloud のロケーションを選択するには、次のツールを使用します。

  • Google Cloud リージョン選択ツール: 温室効果ガス排出量、費用、レイテンシなどの要因に基づいて、アプリケーションとデータに最適な Google Cloudリージョンを選択するためのインタラクティブなウェブベースのツール。
  • Cloud Location Finder API: Google Cloud、Google Distributed Cloud、その他のクラウド プロバイダでデプロイ ロケーションをプログラムで検索できる公開 API。

エージェントの設計

このセクションでは、AI エージェントを設計する際の一般的な推奨事項について説明します。エージェントのコードとロジックの作成に関する詳細なガイダンスは、このドキュメントの範囲外です。

  • エージェントの定義と設計:
    • エージェント型 AI システムのビジネス目標と、各エージェントが実行するタスクを明確に定義します。
    • 要件に最適なエージェント設計パターンを選択します。
    • ADK を使用して、エージェント アーキテクチャを効率的に作成、デプロイ、管理します。
  • エージェントの対応:
    • 自然言語によるインタラクションをサポートするように、アーキテクチャ内の人間向けエージェントを設計します。
    • 各エージェントが、依存するクライアントにアクションとステータスを明確に伝えるようにします。
    • 曖昧なクエリやニュアンスのあるインタラクションを検出して処理するようにエージェントを設計します。
  • コンテキスト、ツール、データ:
    • エージェントに、マルチターン インタラクションとセッション パラメータを追跡するのに十分なコンテキストがあることを確認します。
    • エージェントが使用できるツールの目的、引数、使用方法を明確に記述します。
    • エージェントの回答が信頼できるデータソースにグラウンディングされていることを確認して、ハルシネーションを減らします。
    • プロンプトがトピックから外れている場合など、一致しない状況を処理するロジックを実装します。

セキュリティ

このセクションでは、ワークロードのセキュリティ要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。

エージェントのセキュリティに関する考慮事項

AI エージェントは、従来の決定論的なセキュリティ プラクティスでは適切に軽減できない、特有の重大なセキュリティ リスクをもたらします。Google は、決定論的なセキュリティ管理の強みと、動的な推論ベースの防御を組み合わせた AI のセキュリティ保護アプローチを推奨しています。このアプローチは、人間による監視、慎重に定義されたエージェントの自律性、オブザーバビリティという 3 つの基本原則に基づいています。以下に、これらの基本原則に沿った具体的な推奨事項を示します。

  • 人間の監視: エージェント型 AI システムは、失敗したり、期待どおりに動作しなかったりすることがあります。たとえば、モデルが不正確なコンテンツを生成したり、エージェントが不適切なツールを選択したりする可能性があります。ビジネス クリティカルなエージェント型 AI システムでは、人間参加型フローを組み込んで、人間の監督者がエージェントをモニタリング、オーバーライド、一時停止できるようにします。たとえば、人間のユーザーは、エージェントの出力を確認し、出力を承認または拒否して、エラーの修正や戦略的な意思決定を行うためのガイダンスを提供できます。このアプローチでは、エージェント型 AI システムの効率性と、人間のユーザーの批判的思考とドメイン専門知識を組み合わせます。
  • エージェント ID と最小権限アクセス:
    • Agent Identity を使用して、各エージェントにワークロードにバインドされた SPIFFE ベースの ID を提供します。Agent Identity は、エージェントを Agent Runtime または Cloud Run にデプロイするときに使用できます。
    • Identity and Access Management(IAM)アクセス ポリシーと IAM による Agent Platform のアクセス制御を使用して、エージェントごとの権限を構成します。各エージェントには、タスクの実行、ツールや他のエージェントとの通信に必要な権限のみを付与します。各エージェントをさらに分離し、セキュリティ侵害による潜在的な影響を制限するには、プリンシパル アクセス境界(PAB)ポリシーをエージェント ID にバインドします。
    • エージェントが外部ツールまたはサードパーティ API に対する認証を行う必要がある場合は、Agent Identity Auth Manager を使用します。このアプローチでは、エージェント コードやプロンプトに認証情報を埋め込む必要がなく、OAuth トークンと API キーを一元的に管理できます。
  • 上り(内向き)と下り(外向き)のトラフィック ガバナンス: エージェント トラフィックを Agent Gateway 経由でルーティングし、上り(内向き)と下り(外向き)の両方の境界でランタイム セキュリティ ポリシーを適用します。Agent Gateway をサポートする Agent Runtime プラットフォームについては、サポートされている Agent Runtimeをご覧ください。
    • クライアントからエージェントへ(内向き): Agent Runtime の前に Agent Gateway をデプロイします。ゲートウェイは、Model Armor を使用して、呼び出し元を認証し、インバウンド プロンプトをリアルタイムで検査します。
    • エージェントから任意の場所(下り(外向き)):
      • 外向きモードの Agent Gateway を介して、アウトバウンドのエージェント間(A2A)リクエストとエージェントからツール(MCP)へのリクエストをルーティングします。
      • IAM アクセス ポリシーと Identity-Aware Proxy(IAP)を使用して、デフォルト拒否のアクセス ポリシーを適用します。
      • ターゲット エージェントとツールが Agent Registry に登録されていることを確認します。
      • Model Armor を使用して、アウトバウンド ツールの呼び出しとレスポンスを検査し、データの引き出し、間接的なプロンプト インジェクション、ツールの不正使用を防止します。
  • モニタリング: 包括的なトレース機能を使用して、エージェントの動作をモニタリングします。これにより、推論プロセス、ツールの選択、実行パスなど、エージェントが実行するすべてのアクションを可視化できます。詳細については、Agent Runtime でエージェントをロギングすると ADK でのロギングをご覧ください。

AI エージェントの保護の詳細については、AI エージェントの安全性とセキュリティをご覧ください。

Agent Platform のセキュリティに関する考慮事項

Agent Platform の構成と使用がセキュリティ要件を満たすようにするには、次の推奨事項を考慮してください。

  • 責任の共有: セキュリティは責任の共有です。Agent Platform は基盤となるインフラストラクチャを保護し、データ、コード、モデルを保護するためのツールとセキュリティ管理を提供します。サービスを適切に構成し、アクセス制御を管理して、アプリケーションを保護することは、お客様の責任で行っていただきます。詳細については、Agent Platform の責任の共有をご覧ください。
  • セキュリティ管理: Agent Platform は、データ所在地、顧客管理の暗号鍵(CMEK)、VPC Service Controls を使用したネットワーク セキュリティ、アクセスの透明性の要件を満たすために使用できる Google Cloud セキュリティ管理をサポートしています。詳細については、以下のドキュメントをご覧ください。
  • 安全性: AI モデルは、悪意のあるプロンプトに応じて有害な回答を生成することがあります。
    • 安全性を強化し、エージェント型 AI システムの不正使用の可能性を軽減するには、有害な入力やレスポンスに対するバリアとして機能するようにコンテンツ フィルタを構成します。詳細については、安全フィルタとコンテンツ フィルタをご覧ください。
    • 推論リクエスト、エージェント プロンプト、ツール呼び出し、レスポンスを検査して、プロンプト インジェクションや有害なコンテンツなどの脅威をサニタイズするには、直接モデル API 呼び出しに Model Armor を使用し、Agent Gateway を介してルーティングされるリクエストに を使用します。Model Armor を使用すると、悪意のある入力の防止、コンテンツの安全性の検証、機密データの保護、コンプライアンスの維持、安全性とセキュリティ ポリシーの一貫した適用が可能になります。
  • モデルへのアクセス: 組織のポリシーを設定して、 Google Cloud プロジェクトで使用できる AI モデルのタイプとバージョンを制限できます。詳細については、Model Garden モデルへのアクセスを制御するをご覧ください。
  • データ保護: プロンプトとレスポンス、ログデータ内の機密データを検出して匿名化するには、Cloud Data Loss Prevention API を使用します。詳細については、機密データの匿名化をご覧ください。

MCP のセキュリティに関する考慮事項

MCP の実装がセキュリティ要件を満たすように、次の推奨事項を検討してください。

  • ツールの登録と検出: エージェントがインベントリに登録され、管理者が承認した MCP エンドポイントにのみ接続するように、MCP サーバーとツールを Agent Registry に登録します。
  • アクセス制御とトラフィック検査: エージェントから MCP へのトラフィックを Agent-to-Anywhere(外向き)モードの Agent Gateway 経由でルーティングし、IAP と IAM アクセス ポリシーを使用して MCP サーバー(Cloud Run でホストされている MCP サーバーなど)を保護します。Agent Gateway で Model Armor またはセマンティック ガバナンス ポリシーを構成して、MCP ツールの入出力を検査し、機密データの漏洩や間接的なプロンプト インジェクションを検出します。
  • 一般的な MCP セキュリティ: MCP を使用するようにエージェントを構成する場合は、外部データとツールへのアクセスが認可されていることを確認し、暗号化などのプライバシー管理を実装します。また、センシティブ データを保護するフィルタを適用し、エージェントのインタラクションをモニタリングします。詳細については、MCP とセキュリティをご覧ください。

A2A のセキュリティに関する考慮事項

A2A の実装がセキュリティ要件を満たすように、次の推奨事項を検討してください。

  • トランスポート セキュリティ: A2A プロトコルでは、本番環境でのすべての A2A 通信に HTTPS が必須であり、Transport Layer Security(TLS)バージョン 1.2 以降が推奨されています。
  • 認証: A2A プロトコルは、認証を HTTP ヘッダーなどの標準のウェブ メカニズムと、OAuth2 や OpenID Connect などの標準に委任します。各エージェントは、エージェント カードで認証要件をアドバタイズします。詳細については、A2A 認証をご覧ください。
  • エージェント間のガバナンス: A2A エージェントを Agent Registry に登録し、エージェント間のリクエストを Agent Gateway 経由でルーティングします。Agent Gateway を Agent Identity、IAP、IAM アクセス ポリシーと組み合わせることで、呼び出し元エージェントの ID を暗号的に検証し、コーディネーター エージェントとサブエージェント間で詳細な認可を適用し、Model Armor でエージェント間のペイロードを検査できます。

Cloud Run のセキュリティに関する考慮事項

Cloud Run の実装がセキュリティ要件を満たすようにするには、次の推奨事項を検討してください。

  • 上り(内向き)セキュリティ(フロントエンド サービス用): アプリケーションへのアクセスを制御するには、フロントエンド Cloud Run サービスのデフォルトの run.app URL を無効にして、リージョン外部アプリケーション ロードバランサを設定します。ロードバランサは、アプリケーションへの受信トラフィックのロード バランシングとともに、SSL 証明書の管理も処理します。保護を強化するために、Google Cloud Armor セキュリティ ポリシーを使用して、サービスにリクエスト フィルタリング、DDoS 保護、レート制限を提供できます。
  • ユーザー認証:

    • 組織内のユーザー: フロントエンド Cloud Run サービスへの内部ユーザー アクセスを認証するには、IAP を使用します。ユーザーが IAP で保護されたリソースにアクセスしようとすると、IAP が認証と認可のチェックを行います。
    • 組織外のユーザー: フロントエンド サービスへの外部ユーザー アクセスを認証するには、Identity Platform または Firebase Authentication を使用します。外部ユーザー アクセスを管理するには、ログインフローを処理し、Cloud Run サービスに対して認証済みの API 呼び出しを行うようにアプリケーションを構成します。

    詳細については、ユーザーの認証をご覧ください。

  • エージェントと MCP サーバーのセキュリティ: Cloud Run でエージェントまたは MCP サーバーをホストする場合は、Cloud Run の Agent Platform 機能を構成して、マネージド エージェント ID をサービスに割り当てます。また、Agent Gateway で IAP を使用して、インバウンド エージェントとツール リクエストを認証および認可します。

  • コンテナ イメージのセキュリティ: 承認済みのコンテナ イメージのみが Cloud Run にデプロイされるようにするには、Binary Authorization を使用します。コンテナ イメージのセキュリティ リスクを特定して軽減するには、Artifact Analysis を使用して脆弱性スキャンを自動的に実行します。詳細については、コンテナ スキャンの概要をご覧ください。

  • データ所在地: Cloud Run は、データ所在地の要件を満たすのに役立ちます。Cloud Run サービスは、選択したリージョン内で実行されます。

コンテナ セキュリティの詳細については、Cloud Run の一般的な開発のヒントをご覧ください。

アーキテクチャ内のすべての Google Cloud プロダクトのセキュリティに関する考慮事項

アーキテクチャがセキュリティ要件を満たすように、次の一般的な推奨事項を検討してください。

  • データの暗号化: デフォルトでは、 Google Cloud は Google-owned and Google-managed encryption keysを使用して保存データを暗号化します。管理する暗号鍵を使用してエージェントのデータを保護するには、Cloud KMS で作成して管理する CMEK を使用します。Cloud KMS と互換性のある Google Cloud サービスについては、互換性のあるサービスをご覧ください。
  • データの引き出しのリスクを軽減する: データの引き出しのリスクを軽減するには、インフラストラクチャの周囲に VPC Service Controls 境界を作成します。VPC Service Controls は、このリファレンス アーキテクチャで使用されるすべてのGoogle Cloud サービスをサポートしています。
  • アクセス制御: トポロジ内のリソースの権限を構成するときは、最小権限の原則に従います。
  • クラウド環境のセキュリティ: Security Command Center のツールを使用して、脆弱性の検出、脅威の特定と軽減、セキュリティ ポスチャーの定義とデプロイ、詳細な分析のためのデータのエクスポートを行います。
  • デプロイ後の最適化:Google Cloudにアプリケーションをデプロイしたら、Active Assist を使用してセキュリティをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、Active Assist で推奨事項を確認するをご覧ください。

AI ワークロードと ML ワークロードに固有のセキュリティの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: セキュリティをご覧ください。

信頼性

このセクションでは、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。

エージェントの信頼性に関する考慮事項

エージェント構成が信頼性要件を満たすようにするには、次の推奨事項を考慮してください。

  • フォールト トレランス: エージェント レベルの障害を許容または処理するようにエージェント システムを設計します。可能な場合は、エージェントが独立して動作できる分散型アプローチを使用します。
  • 障害をシミュレートする: エージェント型 AI システムを本番環境にデプロイする前に、本番環境をシミュレートして検証します。エージェント間の連携の問題や予期しない動作を特定して修正します。
  • エラー処理: エラーの診断とトラブルシューティングを可能にするため、ロギング、例外処理、再試行メカニズムを実装します。

Agent Platform の信頼性に関する考慮事項

Agent Platform の構成と使用が信頼性要件を満たすようにするには、次の推奨事項を考慮してください。

  • 容量計画: リクエスト数が割り当てられた容量を超えると、エラーコード 429 が返されます。ビジネス クリティカルで常に高いスループットを必要とするワークロードの場合は、プロビジョンド スループットを使用してスループットを予約できます。
  • モデル エンドポイントの可用性: 複数のリージョンまたは国でデータを共有できる場合は、モデルにグローバル エンドポイントを使用できます。

ゾーンとリージョンの停止に対する Cloud Run の堅牢性

Cloud Run はリージョン サービスです。リージョン内の複数のゾーンにデータを同期的に保存し、ゾーン間でトラフィックを自動的にロードバランスします。ゾーンが停止しても、Cloud Run は引き続き実行され、データは失われません。リージョンが停止した場合、Google が問題を解決するまでサービスは実行を停止します。

アーキテクチャ内のすべての Google Cloud プロダクトの信頼性に関する考慮事項

Google Cloudにアプリケーションをデプロイしたら、Active Assist を使用して信頼性をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、Active Assist で推奨事項を確認するをご覧ください。

AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。

運用

このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できる Google Cloud トポロジを設計する際に考慮すべき要素について説明します。

Agent Platform のオペレーションに関する考慮事項

Agent Platform の構成と使用が運用要件を満たすようにするには、次の推奨事項を考慮してください。

  • ログを使用したモニタリング: デフォルトでは、stdout ストリームと stderr ストリームに書き込まれたエージェント ログは Cloud Logging にルーティングされます。高度なロギングを行うには、Python ロガーを Cloud Logging と統合します。ロギングと構造化ログを完全に制御する必要がある場合は、Cloud Logging クライアントを使用します。詳細については、エージェントのロギングと ADK でのロギングをご覧ください。
  • 継続評価: エージェントの出力と、エージェントが出力を生成するために行った軌跡またはステップの定性評価を定期的に実施します。エージェント評価を実装するには、Gen AI Evaluation Service または ADK がサポートする評価方法を使用します。

MCP オペレーションに関する考慮事項

MCP の実装が運用要件を満たすように、次の推奨事項を考慮してください。

  • データベース ツール: AI エージェントのデータベース ツールを効率的に管理し、エージェントが接続プーリングや認証などの複雑な処理を安全に行えるようにするには、データベース向け MCP ツールボックスを使用します。データベース ツールを保存して更新するための一元化された場所を提供します。ツールをエージェント間で共有し、エージェントを再デプロイすることなくツールを更新できます。このツールボックスには、AlloyDB for PostgreSQL などの Google Cloudデータベースや MongoDB などのサードパーティ データベース用の幅広いツールが含まれています。
  • 生成 AI モデル: AI エージェントが Imagen や Veo などの Google 生成 AI モデルを使用できるようにするには、 Google Cloud 生成メディア API 用の MCP サーバーを使用します。
  • Google のセキュリティ プロダクトとツール: AI エージェントが Google Security Operations、Google Threat Intelligence、Security Command Center などの Google のセキュリティ プロダクトとツールにアクセスできるようにするには、Google のセキュリティ プロダクト用の MCP サーバーを使用します。

アーキテクチャ内のすべての Google Cloud プロダクトに関するオペレーション上の考慮事項

Cloud Trace を使用して、トレースデータを継続的に収集して分析します。トレースデータを使用すると、複雑な Agentic Workflows 内のエラーを迅速に特定して診断できます。Trace エクスプローラ ツールで可視化することで、詳細な分析を行うことができます。詳細については、エージェント トレースを表示するをご覧ください。

AI ワークロードと ML ワークロードに固有のオペレーショナル エクセレンスの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 運用の卓越性をご覧ください。

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。

Agent Platform の費用に関する考慮事項

Agent Platform の構成と使用量が費用の要件を満たすようにするには、次の推奨事項を検討してください。

  • 費用の分析と管理: Agent Platform の費用を分析して管理するには、秒間クエリ数(QPS)と秒間トークン数(TPS)のベースライン指標を作成することをおすすめします。次に、デプロイ後にこれらの指標をモニタリングします。ベースラインは、容量計画にも役立ちます。たとえば、ベースラインは、プロビジョンド スループットが必要なタイミングを判断するのに役立ちます。
  • モデルの選択: AI アプリケーションに選択するモデルは、費用とパフォーマンスの両方に直接影響します。特定のユースケースでパフォーマンスと費用の最適なバランスを実現するモデルを特定するには、モデルを繰り返しテストします。最も費用対効果の高いモデルから始めて、より強力なオプションに徐々に移行することをおすすめします。
  • 費用対効果の高いプロンプト: プロンプト(入力)の長さと生成されたレスポンス(出力)は、パフォーマンスと費用に直接影響します。短く、直接的で、十分なコンテキストを提供するプロンプトを作成します。モデルから簡潔な回答を得られるようにプロンプトを設計します。たとえば、「2 文で要約して」や「3 つの要点をリストアップして」などのフレーズを含めます。詳細については、プロンプト設計のベスト プラクティスをご覧ください。
  • コンテキスト キャッシュ保存: 入力トークン数が多い繰り返しコンテンツを含むリクエストの費用を削減するには、コンテキスト キャッシュ保存を使用します。
  • バッチ リクエスト: 関連する場合は、バッチ予測を検討してください。バッチ リクエストは、標準リクエストよりも費用が低くなります。

Cloud Run の費用に関する考慮事項

Cloud Run の実装が費用要件を満たすようにするには、次の推奨事項を考慮してください。

  • リソースの割り当て: Cloud Run サービスを作成するときに、割り当てるメモリと CPU の量を指定できます。デフォルトの CPU とメモリ割り当てから始めます。リソースの使用量と費用を継続的にモニタリングし、必要に応じて割り当てを調整します。詳細については、サービスのメモリ上限を構成するとサービスの CPU 上限を構成するをご覧ください。
  • レートの最適化: CPU とメモリの要件を予測できる場合は、確約利用割引(CUD)を使用して費用を節約できます。

アーキテクチャ内のすべての Google Cloud プロダクトの費用に関する考慮事項

Google Cloudにアプリケーションをデプロイしたら、Active Assist を使用して費用をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、Active Assist で推奨事項を確認するをご覧ください。

Google Cloud リソースの費用を見積もるには、Google Cloud の料金計算ツールを使用します。

AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。

パフォーマンスの最適化

このセクションでは、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。

エージェントのパフォーマンスに関する考慮事項

エージェント構成がパフォーマンス要件を満たすようにするには、次の推奨事項を検討してください。

  • モデルの選択: エージェント型 AI システムのモデルを選択する際は、エージェントが実行する必要があるタスクに必要な機能を考慮します。
  • プロンプトの最適化: プロンプトのパフォーマンスを大規模かつ迅速に改善して最適化し、手動での書き換えを不要にするには、Agent Platform プロンプト オプティマイザーを使用します。オプティマイザーを使用すると、さまざまなモデルでプロンプトを効率的に調整できます。

Agent Platform のパフォーマンスに関する考慮事項

Agent Platform の構成と使用状況がパフォーマンス要件を満たすようにするには、次の推奨事項を考慮してください。

  • モデルの選択: AI アプリケーションに選択するモデルは、費用とパフォーマンスの両方に直接影響します。特定のユースケースでパフォーマンスと費用の最適なバランスを実現するモデルを特定するには、モデルを繰り返しテストします。最も費用対効果の高いモデルから始めて、より強力なオプションに徐々に移行することをおすすめします。
  • プロンプト エンジニアリング: プロンプト(入力)の長さと生成されたレスポンス(出力)は、パフォーマンスと費用に直接影響します。短く、直接的で、十分なコンテキストを提供するプロンプトを作成します。モデルから簡潔な回答を得られるようにプロンプトを設計します。たとえば、「2 文で要約して」や「3 つの要点をリストアップして」などのフレーズを含めます。詳細については、プロンプト設計のベスト プラクティスをご覧ください。
  • コンテキスト キャッシュ保存: 入力トークン数が多い繰り返しコンテンツを含むリクエストのレイテンシを短縮するには、コンテキスト キャッシュ保存を使用します。

Cloud Run のパフォーマンスに関する考慮事項

パフォーマンス要件に応じて、Cloud Run サービスに割り当てるメモリと CPU を構成します。詳細については、サービスのメモリ上限を構成するとサービスの CPU 上限を構成するをご覧ください。

パフォーマンスの最適化に関するガイダンスについては、Cloud Run の一般的な開発のヒントをご覧ください。

アーキテクチャ内のすべての Google Cloud プロダクトのパフォーマンスに関する考慮事項

Google Cloudにアプリケーションをデプロイしたら、Active Assist を使用してパフォーマンスをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、Active Assist で推奨事項を確認するをご覧ください。

AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。

デプロイ

マルチエージェント AI システムを構築してデプロイする方法については、次のコードサンプルをご覧ください。これらのコードサンプルは、学習とテストの出発点として完全に機能します。本番環境で最適な運用を行うには、特定のビジネス要件と技術要件に基づいてコードをカスタマイズする必要があります。

次のステップ

協力者

著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー

その他の寄稿者:

  • Alan Blount | プロダクト マネージャー
  • Ali Arsanjani 博士 | 応用 AI エンジニアリング担当ディレクター
  • Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
  • Holt Skinner | デベロッパー アドボケイト
  • Jack Wotherspoon | デベロッパー アドボケイト
  • Joe Shirey | Cloud デベロッパー リレーションズ マネージャー
  • Megan O'Keefe | デベロッパー アドボケイト
  • Samantha He | テクニカル ライター
  • Sara Ford | シニア デベロッパー リレーションズ エンジニア
  • Shir Meir Lador | デベロッパー リレーションズ エンジニアリング マネージャー
  • Victor Dantas | 生成 AI フィールド ソリューション アーキテクト
  • Vlad Kolesnikov | デベロッパー リレーションズ エンジニア