ADK と Cloud Run を使用する単一エージェント AI システム

Last reviewed 2025-12-09 UTC

このドキュメントでは、 Google Cloudで単一エージェント AI システムを設計する際に役立つリファレンス アーキテクチャについて説明します。このアーキテクチャの単一エージェント システムは、Agent Development Kit（ADK）を使用して構築され、Cloud Run にデプロイされます。Gemini Enterprise Agent Platform の Agent Runtime または Google Kubernetes Engine（GKE）にエージェントをデプロイすることもできます。このアーキテクチャでは、Model Context Protocol（MCP）を使用します。これにより、エージェントは複数のソースから情報にアクセスして処理し、コンテキストに富んだ分析情報を提供できます。

このドキュメントは、AI アプリケーションのアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI、ML、大規模言語モデル（LLM）のコンセプトに関する基本的な知識があることを前提としています。また、AI エージェントとモデルに関する基本的な知識があることも前提としています。AI エージェントの設計とコーディングに関する具体的なガイダンスは提供していません。

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

アーキテクチャ

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

Cloud Run にデプロイされる単一エージェント アーキテクチャ。 Google Cloudのマルチエージェント AI システムのアーキテクチャ。

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

このサンプル アーキテクチャは、次のコンポーネントで構成されています。

コンポーネント 説明
フロントエンド ユーザーは、サーバーレスの Cloud Run サービスとして実行されるチャット インターフェースなどのフロントエンドを介してエージェントとやり取りします。
エージェント エージェントはユーザーのリクエストを受け取り、ユーザーの意図を解釈し、適切なツールを選択して、情報を合成してクエリに回答します。
エージェント ランタイム エージェントは ADK を使用して構築され、サーバーレス Cloud Run サービスとしてデプロイされます。エージェントは、Gemini Enterprise Agent Platform の Agent Runtime にデプロイすることも、GKE にコンテナ化されたアプリとしてデプロイすることもできます。Agent Runtime の選択方法については、エージェント型 AI アーキテクチャのコンポーネントを選択するをご覧ください。
ADK ADK は、エージェントの開発、テスト、デプロイを行うためのツールとフレームワークを提供します。ADK はエージェント作成の複雑さを抽象化し、AI デベロッパーがエージェントのロジックと機能に集中できるようにします。ADK を使用してエージェントを開発する場合、Google 検索などの組み込みツールにアクセスして使用するようにエージェントを構成できます。
AI モデルとモデル ランタイム 推論サービングの場合、このサンプル アーキテクチャのエージェントは、Gemini Enterprise Agent Platform で Gemini AI モデルを使用します。
MCP ツールボックス データベース向け MCP ツールボックスは、エージェントにデータベース固有のツールを提供します。接続プーリングや認証などの複雑な処理に対応できます。
MCP クライアント、サーバー、ツール MCP は、エージェントとツール間のやり取りを標準化することで、ツールへのアクセスを容易にします。エージェントとツールのペアごとに、MCP クライアントは MCP サーバーにリクエストを送信します。エージェントは、このサーバーを介してファイル システムや API などのツールにアクセスします。たとえば、StackOverflow LangChain ツールや Google 検索ツールなどの外部ツールは、データとグラウンディングを提供できます。
オブザーバビリティ エージェントは、ロギング、モニタリング、トレースに Google Cloud Observability を使用してモニタリングされます。

エージェント フロー

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

  1. ユーザーが、サーバーレス Cloud Run サービスとして実行されるチャット インターフェースなどのフロントエンドからプロンプトを入力します。
  2. フロントエンドはプロンプトをエージェントに転送します。
  3. エージェントは、AI モデルを使用してユーザーのプロンプトを推論し、レスポンスを合成します。
    • AI モデルは、コンテキスト情報の収集やタスクの実行に使用するツールを決定します。
    • エージェントがツール呼び出しを実行し、レスポンスをコンテキストに追加します。
    • エージェントは、グラウンディングと中間検証を行います。

使用するプロダクト

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

ユースケース

このセクションでは、このドキュメントで説明するアーキテクチャのユースケースについて説明します。

バグレポートの自動トリアージ

このリファレンス アーキテクチャを適応させて、受信したバグレポートのトリアージを自動化できます。つまり、問題を理解し、重複を検索し、関連する技術的なコンテキストを収集してから、システムにバグを作成します。AI を活用したエージェントは、初期調査を実行できるインテリジェントなアシスタントとして機能し、人間のエキスパートがより複雑な問題解決に集中できるようにします。

このユースケースでは、このアーキテクチャには次のメリットがあります。

  • 解決時間の短縮: エージェントは初期調査とコンテキスト収集を自動化するため、バグチケットの割り当てと解決にかかる時間を大幅に短縮できます。
  • 精度と一貫性の向上: エージェントは、複数のデータソース（内部データベース、コード リポジトリ、公開ウェブ）を体系的に検索できます。この機能により、手動のトリアージよりも包括的で一貫性のある分析が可能になります。
  • 手動のワークロードの削減: エージェントは、IT サポート チームとエンジニアリング チームから反復的なトリアージ タスクをオフロードできるため、より価値の高い作業に集中できます。

このアーキテクチャは、ソフトウェアを開発し、バグ解決プロセスの効率と効果を向上させたいと考えている組織に最適です。詳細とデプロイ オプションについては、ソフトウェアのバグ アシスタント - ADK Python サンプル エージェントとエージェントを作り上げるツール: ADK を使用してゼロからアシスタントを作成をご覧ください。

カスタマー サービス

このリファレンス アーキテクチャを適応させることで、シームレスでパーソナライズされたショッピング体験を顧客に提供できます。AI 搭載エージェントは、カスタマー サービス、商品の推奨、注文の管理、サービスのスケジュール設定を行うことができるため、人間の担当者は他のタスクに集中できます。

このユースケースでは、このアーキテクチャには次のメリットがあります。

  • アップセルとプロモーション: エージェントは、商品、サービス、プロモーションを提案することで、販売を促進できます。エージェントの提案は、お客様の現在の注文と関連する販売、お客様の注文履歴、カート内の商品に基づいています。

  • 注文管理とスケジュール設定: エージェントは、顧客のショッピング カートの内容を管理し、サービスのセルフ スケジュール設定を容易にすることで、効率を高め、顧客の不満を軽減できます。

  • 手動による作業負荷の軽減: エージェントが一般的な問い合わせ、注文、スケジュール設定を処理するため、人間のカスタマー サービス エージェントはより複雑な顧客の問題に集中できます。

このアーキテクチャは、カスタマー エクスペリエンスの向上、売上の増加、注文管理とスケジューリングの簡素化を必要とする小売組織に最適です。詳細とデプロイ オプションについては、Cymbal Home & Garden カスタマー サービス エージェントをご覧ください。

時系列予測

このリファレンス アーキテクチャを適応させて、需要予測、トラフィック パターンの予測、マシンの障害分析と予測などの結果を予測できます。AI 搭載エージェントは、リアルタイム データ、過去の傾向、今後のイベントを分析できます。エージェントは、これらの分析を使用して、指定された期間の結果を予測できます。これらの予測は、計画の策定に役立ち、人間のデータ アナリストが費やす時間を短縮できます。

このユースケースは、次のようなさまざまなシナリオで組織に役立ちます。

  • 広告在庫管理: 過去の販売データとマーケット トレンドを組み合わせた高度な分析を使用することで、エージェントは、顧客需要の急増または減少に備えて、在庫補充注文を計画できます。
  • 移動ルート: エージェントは、リアルタイムの交通パターンと過去の交通パターン、工事や通行止めなどのイベントを分析することで、配送業者やサービス提供者の時間を節約し、移動費用を削減できます。
  • サービス停止を回避する: エージェントは、過去のサービス停止の根本原因を特定することで、潜在的なサービス中断を回避するのに役立ちます。また、将来発生する可能性のある障害状態を予測して、問題になる前に問題を軽減することもできます。

このアーキテクチャは、確立された傾向に基づいて変化するパターンに適応する必要がある組織に最適です。また、顧客が将来の計画に役立つ事前対応型の分析情報を活用できる組織にも最適です。詳細とデプロイ オプションについては、Google の ADK と MCP Toolbox を使用した時系列予測エージェントをご覧ください。

ドキュメントの取得

このリファレンス アーキテクチャを適応させて Gemini Enterprise Agent Platform の RAG Engine を使用し、コンテキスト データの取得を管理するエージェントを作成できます。ドキュメント取得エージェントは、厳選されたドキュメント セットから関連データを取得し、ソース資料への引用を含む事実に基づいた回答を提供できます。

ドキュメント検索エージェントを使用すると、顧客や内部ユーザーがクエリに対して、コンテキストを認識した情報に基づく回答を得ることができます。この実装により、検証済みの情報に基づいて回答が生成されるため、間違いや不正確さを減らすことができます。

ドキュメント検索アーキテクチャは、ポリシーとプロセス、技術インフラストラクチャ、Google サービスに関する専門性認定、その他の事実に基づくドキュメントに関するナレッジベースに最適です。検索拡張生成（RAG）を活用したドキュメント検索エージェントを開発する方法については、ドキュメント検索エージェントをご覧ください。

代替案を設計する

このセクションでは、 Google Cloudの AI エージェントのデプロイで検討できる代替の設計アプローチについて説明します。

エージェント ランタイム

このドキュメントで説明するアーキテクチャでは、エージェントとそのツールが Cloud Run にデプロイされます。代替ランタイムとして GKE または Agent Runtime を使用することもできます。エージェント ランタイムの選択方法については、「エージェント型 AI アーキテクチャ コンポーネントを選択する」のAgent Runtimeをご覧ください。

AI モデル ランタイム

このドキュメントで説明するアーキテクチャでは、AI モデル ランタイムは Agent Platform です。Cloud Run または GKE を代替ランタイムとして使用することもできます。モデル ランタイムの選択方法については、「エージェント型 AI アーキテクチャ コンポーネントを選択する」のモデル ランタイムをご覧ください。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、運用効率、パフォーマンスに関する特定の要件を満たすアーキテクチャを開発するためのガイダンスを示します。

システム設計

このセクションでは、デプロイに使用する 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 を使用して、エージェント アーキテクチャを効率的に作成、デプロイ、管理する。
  • エージェントの対応:
    • 自然言語によるインタラクションをサポートするように、アーキテクチャ内の人間向けエージェントを設計します。
    • 各エージェントが、依存するクライアントにアクションとステータスを明確に伝達するようにします。
    • 曖昧なクエリやニュアンスのあるやり取りを検出して処理するようにエージェントを設計します。
  • コンテキスト、ツール、データ:
    • エージェントに、マルチターン インタラクションとセッション パラメータを追跡するのに十分なコンテキストがあることを確認します。
    • エージェントが使用できるツールの目的、引数、使用方法を明確に記述します。
    • エージェントの回答が信頼できるデータソースに基づいていることを確認して、ハルシネーションを減らします。
    • プロンプトがトピックから外れている場合など、一致しない状況を処理するロジックを実装します。

メモリとセッション ストレージ

このドキュメントに示すサンプル アーキテクチャには、メモリ ストレージやセッション ストレージは含まれていません。本番環境では、状態とメモリをエージェントに統合することで、レスポンスを改善し、パーソナライズを追加できます。

  • セッション: セッションは、最初のやり取りから会話の終了までの、ユーザーとエージェント間の会話スレッドです。
  • 状態: 状態は、エージェントが特定のセッション内で使用および収集するデータです。収集される状態データには、ユーザーとエージェントが交換したメッセージの履歴、ツール呼び出しの結果、エージェントが会話のコンテキストを理解するために必要なその他の変数が含まれます。

ADK は、Session オブジェクトと state 属性を使用して、短期記憶でセッションを追跡できます。ADK は、Memory Bank などを通じて、同じユーザーとのセッション間で長期記憶もサポートしています。セッション状態を保存するには、Memorystore for Redis などのサービスを使用することもできます。

エージェントのメモリ オプションについては、エージェント型 AI アーキテクチャのコンポーネントを選択するをご覧ください。

セキュリティ

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

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

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

  • 人間の監督: エージェント型 AI システムは、期待どおりに動作しないことがあります。たとえば、モデルが不正確なコンテンツを生成したり、エージェントが不適切なツールを選択したりする可能性があります。ビジネスに不可欠なエージェント型 AI システムでは、人間参加型フローを組み込んで、人間の監督者がエージェントをモニタリング、オーバーライド、一時停止できるようにします。たとえば、人間のユーザーは、エージェントの出力を確認し、出力を承認または拒否して、エラーの修正や戦略的な意思決定を行うためのガイダンスを提供できます。このアプローチでは、エージェント型 AI システムの効率性と、人間のユーザーの批判的思考とドメイン専門知識を組み合わせます。
  • エージェントの ID と最小権限のアクセス:
    • Agent Identity を使用して、各エージェントにワークロードにバインドされた SPIFFE ベースの ID を提供します。エージェントを Agent Runtime または Cloud Run にデプロイするときに、エージェント ID を使用できます。
    • 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 を使用します。詳細については、AI アプリでの機密データの保護をご覧ください。

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

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

  • ツールの登録と検出: エージェントがインベントリに登録され、管理者が承認した MCP エンドポイントにのみ接続するように、MCP サーバーとツールを Agent Registry に登録します。
  • アクセス制御とトラフィック検査: Agent-to-Anywhere（外向き）モードで Agent Gateway を介してエージェントから MCP へのトラフィックをルーティングし、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 で推奨事項を確認するをご覧ください。

セキュリティに関するその他の推奨事項

信頼性

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

コンポーネント 設計上の考慮事項と推奨事項
エージェント

障害をシミュレートする: エージェント型 AI システムを本番環境にデプロイする前に、本番環境をシミュレートして検証します。問題や予期しない動作を特定して修正します。

水平方向にスケーリングする: 高可用性とフォールト トレランスを確保するため、ロードバランサの背後でエージェント アプリケーションの複数のインスタンスを実行します。このアプローチでは、リクエストをインスタンス間で分散することで、レイテンシとタイムアウトを削減することもできます。一部のエージェント ランタイムは、Cloud Run サービスでのインスタンスの自動スケーリングなど、ロード バランシングを自動的に処理します。

停止から復元する: エージェントが再起動を適切に処理し、コンテキストを維持できるようにするには、状態をランタイムから切り離します。このようなステートレス エージェント アプリケーションを実装するには、データベースや分散キャッシュなどの外部データストアを使用します。たとえば、Memory Bank、Memorystore for Redis、Cloud SQL などのデータベース サービスを使用できます。

エラーを処理する: エラーの診断とトラブルシューティングを可能にするため、ロギング、例外処理、再試行メカニズムを実装します。
Agent Platform

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

モデル エンドポイントの可用性: 複数のリージョンまたは国でデータを共有できる場合は、モデルにグローバル エンドポイントを使用できます。
Cloud Run

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

水平スケーリング: Cloud Run サービスは、インスタンスの自動スケーリングを処理します。自動スケーリングは、高可用性を確保するために必要なすべての受信リクエスト、イベント、CPU 使用率をインスタンスが処理できるようにします。
アーキテクチャのすべてのプロダクト

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

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

運用

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

コンポーネント 設計上の考慮事項と推奨事項
エージェント

デバッグと分析: エージェント アプリケーション内に構造化ロギングを実装します。ロギングとトレースを使用すると、呼び出されたツール、エージェントの入力と出力、各ステップのレイテンシなど、重要な情報を構造化された形式でキャプチャできます。
Agent Platform

ログを使用したモニタリング: デフォルトでは、stdout ストリームと stderr ストリームに書き込まれたエージェント ログは Cloud Logging に転送されます。高度なロギングを行うには、Python ロガーを Logging と統合します。ロギングと構造化ログを完全に制御する必要がある場合は、Logging クライアントを使用します。詳細については、エージェントのロギングと ADK でのロギングをご覧ください。

継続評価: エージェントの出力と、エージェントが出力を生成するためにたどった軌跡またはステップの定性的な評価を定期的に実施します。エージェントの評価を実装するには、Gen AI Evaluation Service または ADK がサポートする評価方法を使用します。
Cloud Run

健全性とパフォーマンス: Google Cloud Observability を使用して Cloud Run サービスをモニタリングします。Cloud Monitoring でアラートを設定して、エラー率の増加、レイテンシの増加、リソース使用率の異常などの潜在的な問題を通知します。
データベース

健全性とパフォーマンス: Google Cloud Observability を使用してデータベースをモニタリングします。Monitoring でアラートを設定して、エラー率の増加、レイテンシの増加、リソース使用率の異常など、潜在的な問題を通知します。
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 プロダクト

トレース: Trace を使用してトレースデータを継続的に収集して分析します。トレースデータを使用すると、複雑な Agentic Workflows 内のレイテンシの問題を迅速に特定して診断できます。 Google Cloud コンソールの 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 の視点: パフォーマンスの最適化をご覧ください。

デプロイ

このリファレンス アーキテクチャの自動デプロイは利用できません。次のコードサンプルを使用して、単一エージェント アーキテクチャを構築します。

ADK を MCP サーバーと組み合わせて使用するためのコードサンプルについては、MCP ツールをご覧ください。

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

  • パーソナライズされたショッピング: 特定のブランド、販売者、オンライン マーケットプレイス向けにパーソナライズされたおすすめ商品を提供します。
  • インシデント管理: 動的 ID 伝播を使用して、リクエストごとにエンドユーザー トークンと ID を検証します。
  • 注文処理: 注文を処理して保存し、指定された注文数量に対して条件付きの人間によるレビューを行い、確認メールをオーケストレートします。
  • データ エンジニアリング: Dataform パイプラインの開発、パイプラインの問題のトラブルシューティング、複雑な SQL クエリからデータ変換やデータの依存関係までのデータ エンジニアリングの管理を行います。
  • ドキュメントの取得: RAG を使用して、Gemini Enterprise Agent Platform の RAG Engine にアップロードしたドキュメントをクエリし、ドキュメントとコードの引用を含む回答を取得します。

次のステップ

寄稿者

  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Megan O'Keefe | デベロッパー アドボケイト
  • Shir Meir Lador | デベロッパー リレーションズ エンジニアリング マネージャー