Google Cloud のマルチエージェント プライベート ネットワーキング パターン

Last reviewed 2026-04-16 UTC

このドキュメントでは、エージェント、サブエージェント、ツール間のプライベート接続を備えた、一般公開されているマルチエージェントの Gemini Enterprise アプリをサポートするプライベート ネットワーキング インフラストラクチャの設計に役立つガイダンスを提供します。ネットワーク設計では、Vertex AI Agent Engine、Cloud Run、Google Kubernetes Engine（GKE）、オンプレミス データセンター、または他のクラウドでホストされているエージェントにプライベート接続が提供されます。この設計では、インターネット ロケーションで実行されるエージェントへの接続もサポートしています。

マルチエージェント AI システムには、組織的に機密性の高いデータや独自のデータが関与することがよくあります。プライベート ネットワーキングを使用すると、このトラフィックを公共のインターネットに公開することを回避できます。この設計では、 Google Cloud ネットワーク インフラストラクチャ、Virtual Private Cloud（VPC）ネットワーク リソース、オンプレミス環境またはクロスクラウド ネットワークへのプライベート接続を使用します。

このドキュメントで説明する設計では、エージェントは Agent2Agent（A2A）プロトコルと Model Context Protocol（MCP）を使用して、他のエージェントやツールと通信します。通信は VPC ネットワーク経由でルーティングされるため、プライベートになります。この設計では、VPC ネットワークとの間でトラフィックを移動するために、Private Service Connect エンドポイント、Private Service Connect インターフェース、Cloud Run Direct VPC 下り（外向き）を組み合わせて使用します。Cloud Next Generation Firewall（Cloud NGFW）は、VPC ネットワークを通過するトラフィックを制御します。追加のセキュリティ レイヤでは、Secure Web Proxy を使用して制御されたインターネット下り（外向き）が提供され、VPC Service Controls 境界を使用して API サービス アクセス ポリシーが提供されます。

このドキュメントは、クラウド AI インフラストラクチャとアプリを構築して管理するアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI エージェントとモデルの基礎知識があり、 Google Cloud ネットワーキングのコンセプトを理解していることを前提としています。

マルチエージェント設計パターン

マルチ エージェントの Gemini Enterprise アプリでは、ツールとサブエージェントへの接続のオーケストレーターまたはルート エージェントとして機能するカスタム エージェントが必要です。Google Cloud またはオンプレミスでホストされているツールとサブエージェントへのプライベート接続を実装するために、この設計ではプライベート IP アドレスを持つ VPC ネットワークを使用します。ルート エージェントは、Agent Engine、Cloud Run、GKE を使用して Google のインフラストラクチャ内でホストされます。マルチエージェント設計パターンでは、次のようなインタラクションが強調されます。

1. カスタム ルート エージェントとやり取りする Gemini Enterprise アプリ。 Gemini Enterprise アプリは、カスタム エージェントの機能を公開するセキュリティ機能が組み込まれた管理対象ユーザー インターフェースを提供します。カスタムビルドのルート エージェントは Gemini Enterprise に登録され、エンドユーザーがアプリで利用できるようになります。カスタム ルート エージェントは最上位のワークフロー オーケストレーターとして機能し、専門タスクをサブエージェントに委任します。このアーキテクチャでは、Vertex AI Agent Engine、Cloud Run、GKE でホストされているカスタム ルート エージェントを使用します。
2. サブエージェントとツールを操作するルート エージェント。AI システムのワークフローとビジネス ロジックの中核は、ルート エージェントと専用のサブエージェントにあります。エージェント フレームワーク、ランタイム、ホスティング プラットフォームの柔軟性により、VPC ネットワークを介してルート エージェントをサブエージェントやツールに接続するためのさまざまなオプションが提供されます。アーキテクチャのこの部分に VPC ネットワーキングを使用することで、エージェントは、他のプライベート エンドポイント、エンタープライズ セキュリティ制御、より広範なネットワーク到達可能性を公開する、ユーザーが定義したプライベート ネットワーキング パスを使用できます。

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

• Gemini Enterprise アプリ: ユーザーがアプリ内チャット インターフェースにアクセスして、マルチエージェント AI システムとやり取りするためのフロントエンド。ユーザーは、公共のインターネットまたはハイブリッド接続を介して非公開で Gemini Enterprise アプリにアクセスできます。
• カスタム エージェント: Gemini Enterprise で構築および登録され、Vertex AI Agent Engine、Cloud Run、または GKE でホストされているルート エージェント。これらのルート エージェントは、サブエージェントにタスクを委任するオーケストレーターとして機能します。
• VPC ネットワーク: エージェントにプライベート エンドポイントへの IP ネットワーク接続と、より広範なネットワーク到達可能性を提供するために制御するリソース。VPC ネットワークは、他のエージェントやツールに対するエージェント リクエストのプライベート接続とネットワーク セキュリティ制御を実装するためのプラットフォームを提供します。
• サブエージェント: ルート エージェントのワークフローによってトリガーされる専門エージェント。サブエージェントは A2A プロトコルを使用して通信します。これにより、プログラミング言語やランタイムに関係なく、エージェント間の相互運用が可能になります。
• ツール: API、データソース、ワークフロー関数などのサービスを公開するリモート システム。これらのツールは、エージェントのデータを取得し、アクションやトランザクションを実行します。ツールはエージェントの外部にあり、エージェントは MCP 仕様を使用してツールに接続し、ツールとやり取りします。

このハイレベルのマルチエージェント設計パターンは、マルチエージェント AI システム内のネットワーキング コンポーネントをハイライト表示します。さまざまなエージェント間のルーティング パターンをサポートできます。他の AI システム設計パターンについては、エージェント型 AI システムの設計パターンを選択するをご覧ください。

共有 VPC

マルチエージェント設計パターンでは、共有 VPC を使用してネットワーキングとセキュリティの権限と責任を一元化します。この設計により、組織のセキュリティ ニーズを満たす環境がデベロッパーに提供されます。共有 VPC を使用して一元管理することで、ネットワークとセキュリティの構成を簡素化することをおすすめします。

共有 VPC アーキテクチャでは、ホスト プロジェクトに、VPC ネットワーク、Cloud Router、サブネット、ファイアウォール、Cloud DNS などの共有ネットワーク リソースが含まれます。管理者は、これらのリソースを使用する権限をサービス プロジェクトに付与できます。サービス プロジェクトには、Vertex AI Agent Engine、Cloud Run、GKE、Gemini Enterprise、アプリ固有のロードバランサなどのエージェント ランタイム リソースが含まれています。

共有 VPC は、ネットワーク管理者とセキュリティ管理者のペルソナと AI アプリ デベロッパーのペルソナの間に明確な境界を適用します。

• ネットワーク管理者とセキュリティ管理者は、VPC ルーティング、サブネット、DNS ピアリング、ファイアウォール ポリシーなどのコア インフラストラクチャを制御します。
• AI アプリ開発者は、基盤となるネットワーク インフラストラクチャを変更する権限を持たずに、接続されたサービス プロジェクトにエージェントを構築します。

ネットワークとセキュリティのデプロイをホスト プロジェクト内で一元化すると、エージェント間の通信とエージェントとサービス間の通信の単一の管理ポイントが作成されます。この設計により、一貫した接続を確保しながら、多くの異なるサービス プロジェクトにセキュリティ ポリシーを簡単に適用できます。

Network Connectivity Center（NCC）VPC スポークを使用して共有 VPC ネットワークをワークロード VPC ネットワークとして追加することで、共有 VPC ネットワークをクロス クラウド ネットワークに組み込むことができます。この実装では、共有 VPC に NCC ハブルートへの完全な到達可能性と、他のスポークからのサービス アクセス ポイントへの接続が提供されます。

カスタムルート エージェントから開始されたリクエストは、プライベートな顧客管理の VPC ネットワークを使用して、サブエージェント、ツール、サービスへの安全なネットワーク パスを提供します。VPC ネットワーク ルーティングは、プライベート エンドポイントへの到達可能性を制御します。VPC ネットワークに適用される Cloud NGFW ポリシーは、ネットワーク アクセスを制御します。

エージェントは、次の接続を含むプライベート VPC ネットワーク パスへの安全なアクセスを取得します。

• VPC ネットワーク ピアリング、マルチ NIC アプライアンス、NCC を介した他の VPC ネットワーク。
• プロデューサー サービスへのアクセスに使用される Private Service Connect エンドポイント。
• Cloud SQL などのプライベート IP アドレスを持つマネージド サービス。
• 内部ロードバランサのフロントエンドと Compute Engine リソース。
• プライベート Google アクセスまたは Private Service Connect を介した Google API。
• Secure Web Proxy を介して制御されるインターネット。
• Cloud Interconnect、Cloud VPN、ルーター アプライアンス、SD-WAN を使用したハイブリッド クラウドとクロスクラウドの宛先。
• VPC ネットワーク IP ルーティングで到達可能なエンドポイントの宛先。
• その他の AI エージェント、ツール、サポート サービス。

共有 VPC の詳細については、次のリソースをご覧ください。

• VPC 設計のベスト プラクティスとリファレンス アーキテクチャ
• Google Cloud 設定ガイド付きフロー
• NCC を使用したクロスクラウド ネットワークの VPC 間接続

Gemini Enterprise ネットワーキング

Gemini Enterprise アプリは、VPC ネットワークの外部にあるホスト環境で動作するマネージド リソースですが、Google のネットワーク内にあります。以降のセクションでは、ユーザーと Gemini Enterprise アプリ間のネットワーキングの構成と、アプリとエージェント間のネットワーキングについて説明します。

ユーザーが Gemini Enterprise アプリとチャットする

ユーザーは、Google API とサービスにリクエストを送信するブラウザベースのアプリを使用して、Gemini Enterprise アプリとチャットします。プライベート ユーザー接続を有効にするには、VPC ネットワーク経由でルーティングされるプライベート IP アドレス範囲に解決されるように Google API の URL を構成します。詳細については、プライベート UI アクセスを構成するをご覧ください。

Gemini Enterprise アプリからカスタム エージェント

カスタム エージェントは Gemini Enterprise ディスカバリ サービスに登録します。エージェントを登録すると、Gemini Enterprise はエージェントの名前を特定のターゲット（ Vertex AI Agent Engine リソース URI または A2A エージェント URL）にマッピングします。Gemini Enterprise アプリには、アシスタントと呼ばれるチャット インターフェースが組み込まれています。ユーザーが @agent_name を使用してエージェントを指定した場合、またはアシスタントが委任を決定した場合、アプリはレジストリでエージェントを検索して、関連付けられたエンドポイントを見つけます。

ルート エージェントを Gemini Enterprise に登録すると、そのエージェントをカスタム エージェントとして任意の場所にデプロイできます。Vertex AI Agent Engine と Cloud Run のカスタム エージェントは、追加のネットワーキング リソースを構成せずに、既存のプライベート ネットワーク パスを使用できます。GKE にカスタム エージェントをデプロイするには、外部ゲートウェイを使用してサービスを公開する必要があります。外部 Gateway をより安全に構成する方法については、このドキュメントで後述する GKE ネットワーキングをご覧ください。

カスタム エージェントにリクエストを行うため、Gemini Enterprise は Vertex AI Discovery Engine サービス アカウントの ID を使用します。ネットワーク パスと認可メカニズムは、使用するホスティング プラットフォームによって異なります。

• Vertex AI Agent Engine のカスタム エージェント: Vertex AI Discovery Engine サービス エージェントには、組み込み機能として Vertex AI Agent Engine リソースを呼び出すために必要な Vertex AI Identity and Access Management（IAM）ロールが含まれています。システムは、Vertex AI API サービスに対して行われたリクエストを、Google ネットワーク経由で内部 API 呼び出しとして転送します。
• Cloud Run のカスタム エージェント: Gemini Enterprise アプリは、Vertex AI Discovery Engine サービス エージェント ID を使用して、エージェントカードから登録された安定版の run.app URL を呼び出します。AI エージェントの Cloud Run サービスがこれらの呼び出しを承認するには、Discovery Engine サービス エージェントに Cloud Run 起動元 IAM ロール（roles/run.invoker）を付与する必要があります。Cloud Run へのリクエストは、Google 本番環境ネットワークを介して Cloud Run 用 Google Front End（GFE）の上り（内向き）に転送されます。

• GKE のカスタム エージェント: Gemini Enterprise アプリは、Vertex AI Discovery Engine サービス エージェントの ID を使用して、エージェントカードから登録された URL を呼び出します。パブリック DNS は、ホスト名を Gateway によって管理される外部 IP アドレスに解決できる必要があります。gke-l7-regional-external-managed ロードバランサまたは gke-l7-global-external-managed ロードバランサを使用することをおすすめします。セキュリティを強化するため、Gemini Enterprise は Identity-Aware Proxy（IAP）を使用して GKE ホストの A2A エージェントを呼び出すことをおすすめします。IAP がこれらの呼び出しを承認するには、Discovery Engine サービス エージェントに IAP で保護されたウェブアプリ ユーザー IAM ロール（roles/iap.httpsResourceAccessor）を付与する必要があります。Google 本番環境ネットワークは、外部アプリケーション ロードバランサ Ingress の GFE に GKE へのリクエストを転送します。

  Gemini Enterprise から GKE Ingress を保護するには、このドキュメントで後述する IAP と Google Cloud Armor のセクションをご覧ください。

エージェント ホスティング プラットフォームのプライベート ネットワーキング

ユーザーが Gemini Enterprise アプリへのリクエストを開始すると、カスタム ルート エージェントからサブエージェントとツールへのリクエストが開始されます。カスタム エージェント ホスティング プラットフォームは、Gemini Enterprise と VPC ネットワーク間のインターフェースを提供します。コンテナ化されたエージェントとツールのホスティング プラットフォームは、Vertex AI Agent Engine、Cloud Run、GKE です。

エージェント ホスティング プラットフォームを選択する際は、各プラットフォームのプライベート ネットワーキング パターン、セキュリティ制御、管理制御、カスタマイズのレベル、セキュリティ コンプライアンスを考慮する必要があります。AI エージェント ホスティング プラットフォームの選択方法については、生成 AI アプリケーションのモデルとインフラストラクチャを選択するとエージェント型 AI アーキテクチャ コンポーネントを選択するをご覧ください。

使用するエージェント ホスティング プラットフォームに応じて、さまざまなメカニズムを使用してプライベート VPC 接続を確立します。

• Vertex AI Agent Engine のカスタム エージェント: Private Service Connect インターフェースは、Vertex AI Agent Engine ランタイムを VPC ネットワークに接続します。VPC ネットワークのサブネットにネットワーク アタッチメントを作成し、Vertex AI Agent Engine にアタッチする権限を付与します。Vertex AI Agent Engine から送信されたトラフィックは、アタッチメントのサブネット IP アドレスから発信されたかのように VPC ネットワークに表示されます。VPC ネットワークは、トラフィックを適切な宛先 IP アドレスにルーティングします。
• Cloud Run のカスタム エージェント: Cloud Run ダイレクト VPC 下り（外向き）は、Cloud Run サービス インスタンスを VPC ネットワークに接続します。Cloud Run サービスのデプロイ時に指定された VPC ネットワークは、Cloud Run サービス プロジェクトまたはその共有 VPC ホスト プロジェクトのいずれかから取得できます。Cloud Run から送信されたトラフィックは、ダイレクト VPC 下り（外向き）のサブネット IP アドレスから発信されたかのように VPC ネットワークに表示されます。VPC ネットワークは、トラフィックを適切な宛先 IP アドレスにルーティングします。
• GKE のカスタム エージェント: GKE クラスタは VPC ネットワークに直接存在し、ローカル サブネット IP アドレスを使用します。デフォルトでは、GKE 下り（外向き）トラフィックは Pod IP アドレスを送信元 IP アドレスとして使用します。マスカレードを構成すると、GKE 下り（外向き）トラフィックはノード IP アドレスを送信元 IP アドレスとして使用します。すべての GKE 下り（外向き）トラフィックは VPC ネットワークによってルーティングされます。

以降のセクションでは、各エージェント ホスティング プラットフォームの VPC ネットワークとの間の上り（内向き）リクエストと下り（外向き）リクエストを管理するための追加のガイダンスを提供します。ネットワークに関する考慮事項は、ルート エージェントとサブエージェントの両方の機能に適用されます。

Vertex AI Agent Engine ネットワーキング

このセクションでは、Vertex AI Agent Engine でホストされているルート エージェントとサブエージェントのプライベート ネットワーキングについて説明します。Vertex AI Agent Engine を使用してルート エージェントをホストする場合は、Gemini Enterprise と Vertex AI Agent Engine を同じプロジェクトにデプロイする必要があります。

Vertex AI Agent Engine は、VPC ネットワーク外の Google インフラストラクチャでコンテナをホストします。他のエージェントへのプライベート接続を有効にするには、次の方法でエージェントを VPC ネットワークに接続します。

• Vertex AI Agent Engine エージェントのトラフィックが VPC ネットワークに下り（外向き）できるようにするには、Private Service Connect インターフェースを使用します。
• VPC ネットワークを介して転送されるエージェント トラフィックが Vertex AI Agent Engine エージェントに上り（内向き）できるようにするには、Google API 用の Private Service Connect エンドポイントを使用します。

エージェント間でのリクエストを許可するには、上記の両方の接続を設定します。

Vertex AI Agent Engine から VPC ネットワークへの下り（外向き）

Vertex AI Agent Engine は、ネットワーク下り（外向き）に Google が管理するテナント プロジェクトを使用します。テナント ネットワークは、エージェントから Google API への接続とパブリック インターネットの下り（外向き）を提供しますが、デフォルトでは顧客の VPC ネットワークに直接接続されていません。

VPC ネットワーク内のリソースにエージェントを接続するために、Vertex AI Agent Engine は Private Service Connect インターフェースを使用します。Vertex AI Agent Engine は、プロジェクト内のネットワーク アタッチメント リソースに接続するネットワーク インターフェースをテナント プロジェクトにデプロイします。この接続により、Vertex AI Agent Engine ランタイムと VPC ネットワークの間に安全なデータパスが作成されます。Vertex AI Agent Engine プロジェクトで Private Service Connect インターフェースを構成すると、システムは Google API 宛てではないすべてのエージェント トラフィックを VPC ネットワークに転送します。

注: Vertex AI Agent Engine リソースは、VPC ネットワークに下り（外向き）トラフィックを送信することなく、Google 本番環境ネットワーク経由で Vertex AI Agent Engine と Cloud Run でホストされているエージェントに直接アクセスできます。Vertex AI Agent Engine には、Google API とサービスへのプライベート パスがあり、Vertex AI Agent Engine の Vertex AI API と Cloud Run の .run.app URL にリクエストを転送します。このトラフィックには、VPC Service Controls の適用ポリシーが適用されます。VPC ネットワークによって適用される他のセキュリティ制御では、エージェント トラフィックが VPC ネットワークに送信される必要があります。デフォルトの動作をオーバーライドして、Google API と Cloud Run サービスのトラフィックを VPC ネットワークに転送するには、プライベート DNS ピアリングを使用します。

Vertex AI Agent Engine VPC ネットワークの下り（外向き）をデプロイするには、次のリソースをご覧ください。

• Vertex AI Agent Engine で Private Service Connect インターフェースを使用する。
• エージェントをデプロイする: Private Service Connect インターフェースを構成する。
• Vertex AI リソースの Private Service Connect インターフェースを設定する: プライベート DNS ピアリングを設定します。
• エージェントをデプロイする: 明示的なプロキシの環境変数を定義します。

Vertex AI Agent Engine の下り（外向き）用にエージェントと VPC ネットワークをさらに保護するには、このドキュメントの次のセクションをご覧ください。

• Cloud NGFW のポリシーとルールを使用します。
• VPC Service Controls で保護されたリソースを構成します。
• Model Armor スクリーニングを統合します。
• インターネット下り（外向き）用に Secure Web Proxy をデプロイします。

VPC ネットワークからの Vertex AI Agent Engine 上り（内向き）

Vertex AI Agent Engine で実行されるエージェントへのリクエストは、Vertex AI API エンドポイント（aiplatform.googleapis.com）を使用して行われます。VPC ネットワークからプライベート ネットワーク パスを使用して Google API エンドポイントにアクセスするには、プライベート Google アクセスを使用するか、Google API 用の Private Service Connect エンドポイントを使用します。

エージェントにクエリを行うプライベート ユーザーは、Vertex AI API エンドポイントのホスト名を プライベート Google アクセスのプライベート IP アドレス範囲または Google API 用の Private Service Connect エンドポイントの IP アドレスに解決する必要があります。googleapis.com のプライベート マネージド Cloud DNS ゾーンは、Vertex AI API のリクエストを解決します。VPC ネットワークは、リクエストを Google 本番環境ネットワーク経由で直接転送します。

限定公開の Google アクセスまたは Private Service Connect for Google API を使用している場合は、次のプロダクトと機能を使用して、VPC ネットワークから Vertex AI Agent Engine へのトラフィックを保護できます。

• Vertex AI API の認可
• VPC Service Controls
• Model Armor

Vertex AI Agent Engine のネットワークに関するその他の考慮事項

Private Service Connect インターフェースを使用する Vertex AI Agent Engine の下り（外向き）は、VPC ネットワーク内の RFC 1918 IP アドレス範囲にのみルーティングできます。Vertex AI Agent Engine 下り（外向き）でルーティングできない特定の宛先範囲については、サブネットワーク IP 範囲の要件をご覧ください。ルーティング不可能な IP アドレス範囲の宛先に到達するには、エージェントで明示的なプロキシ構成を使用し、VPC ネットワークでルーティング可能な IP アドレスを使用するプロキシ リソースをデプロイします。

Vertex AI Agent Engine が Private Service Connect インターフェースなしでデプロイされる場合、デフォルトでインターネットにアクセスできます。データの引き出しから保護するには、VPC Service Controls を有効にしてデフォルトのアクセスを無効にします。

Vertex AI Agent Engine が Private Service Connect インターフェースでデプロイされている場合、VPC Service Controls に関係なく、直接インターネット下り（外向き）は無効になります。Vertex AI Agent Engine が通常アクセスできない宛先（インターネットなど）にエージェントがアクセスする必要がある場合は、次の操作を行います。

1. VPC ネットワークの RFC 1918 サブネットで Secure Web Proxy を構成します。プロキシは明示的なプロキシ ルーティング モードで構成する必要があります。
2. Secure Web Proxy ホスト名の Cloud DNS レコードを作成します。
3. Vertex AI Agent Engine の DNS ピアリングを構成して、VPC ネットワーク内の Secure Web Proxy のプライベート アドレスへのエージェント DNS クエリ解決をサポートします。
4. エージェントをデプロイするときは、次の操作を行います。
   1. Secure Web Proxy のホスト名とポートを指定して、明示的なプロキシを使用する環境変数を定義します。
   2. 限定公開の宛先にアクセスする場合は、その宛先のプライベート DNS ゾーンを構成します。

Vertex AI Agent Engine の下り（外向き）トラフィックが VPC ネットワークに到達すると、VPC ネットワークでルーティング可能な任意のネットワーク宛先に到達できます。Vertex AI Agent Engine エージェントで使用できる下り（外向き）ネットワーク宛先の範囲を制限する方法については、このドキュメントの後半の Cloud NGFW をご覧ください。

Cloud Run ネットワーキング

このセクションでは、Cloud Run でホストされているルート エージェントとサブエージェントのプライベート ネットワーキングについて説明します。Cloud Run は、VPC ネットワークの外部にある Google インフラストラクチャでコンテナをホストします。他のエージェントへのプライベート接続を有効にするには、次の方法でエージェントを VPC ネットワークに接続します。

• Cloud Run エージェントのトラフィックが VPC ネットワークに下り（外向き）できるようにするには、ダイレクト VPC 下り（外向き）を使用します。
• VPC ネットワークを介してルーティングされるエージェント トラフィックが Cloud Run エージェントに上り（内向き）できるようにするには、 Google API 用の Private Service Connect エンドポイントを使用します。

エージェント間でのリクエストを許可するには、上記の両方の接続を設定します。

VPC ネットワークへの Cloud Run 下り（外向き）

Cloud Run 接続を VPC ネットワークに開始するには、ダイレクト VPC 下り（外向き）を使用することをおすすめします。ダイレクト VPC 下り（外向き）を使用すると、Cloud Run インスタンスは、ダイレクト VPC 下り（外向き）のデプロイ時に指定したサブネットの IP アドレスを使用して、共有 VPC ネットワークに直接接続します。

ダイレクト VPC 下り（外向き）を構成する場合は、次の操作を行います。

1. プライベート Google アクセスが有効になっているターゲット サブネットを構成します。
2. すべてのトラフィックを VPC ネットワークにルーティングするようにトラフィック ルーティングを構成します。

この構成では、プライバシー保護のためにすべてのトラフィックが VPC ネットワーク経由で送信され、Cloud Run から他の Google API へのリクエストは Google 内部ネットワーク経由で送信されます。

Cloud Run からのすべての DNS クエリは、VPC ネットワークに関連付けられている Cloud DNS ポリシーとゾーンを使用します。追加の DNS ピアリング構成は必要ありません。Cloud Run でホストされているエージェントは、すべての Cloud DNS 限定公開ゾーンと一般公開ホスト名を解決します。

Cloud Run 下り（外向き）用のエージェントと VPC ネットワークをさらに保護する方法については、このドキュメントの次のセクションをご覧ください。

• Cloud NGFW のポリシーとルールを使用します。
• VPC Service Controls で保護されたリソースを構成します。
• Model Armor スクリーニングを統合します。
• インターネット下り（外向き）用に Secure Web Proxy をデプロイします。

VPC ネットワークからの Cloud Run 上り（内向き）

Cloud Run は、VPC ネットワークの外部の環境で動作する Google マネージド プラットフォームです。この環境は、AI エージェントまたはツール ワークロードを実行する Cloud Run サービスの安定した *.run.app URL エンドポイントをホストします。これらのエンドポイントは、*.googleapis.com API サービスを提供するのと同じ GFE エントリ ポイントによって提供されます。Cloud Run は、限定公開の Google アクセスと Google API 用の Private Service Connect のプライベート接続を可能にする同じ基盤となるネットワーク パスを使用します。

エージェントまたはツールにクエリを行う VPC ネットワークのプライベート ユーザーは、run.app ホスト名を プライベート Google アクセスのプライベート IP アドレス範囲、または Google API の Private Service Connect エンドポイントの IP アドレスに解決する必要があります。run.app URL の限定公開マネージド Cloud DNS ゾーンは、Cloud Run サービスのリクエストを解決します。VPC ネットワークは、リクエストを Google 本番環境ネットワーク経由で直接転送します。

Cloud Run の上り（内向き）を [内部] に設定すると、検証済みの内部ソースからのリクエストのみを許可することで、サービスへのアクセスが制限されます。承認済みのソースは次のとおりです。

• Cloud Run サービス プロジェクトの VPC ネットワーク。
• ダイレクト VPC 下り（外向き）エンドポイントをホストする共有 VPC ネットワーク。
• 同じ VPC Service Controls 境界内のリソース。
• VPC ネットワーク内の内部アプリケーション ロードバランサ。
• サービス プロジェクトまたは VPC Service Controls の境界内にある Cloud Scheduler や Pub/Sub などの Google サービス。

呼び出し元サービスと呼び出し先サービスの両方を包含する共通の VPC Service Controls 境界を使用しない場合、Cloud Run サービス プロジェクトまたは共有 VPC 環境の外部からのトラフィックは外部トラフィックとして扱われます。このようなトラフィックには、Vertex AI Agent Engine などの他の Google Cloudサービスや他の Cloud Run サービスからのトラフィックが含まれます。Cloud Run 内部上り（内向き）チェックを満たすには、このトラフィックがターゲット サービスの VPC ネットワーク内から発信されたように見えるようにルーティングする必要があります。

必要な内部ネットワーク アトリビューションを提供するには、次のいずれかを行います。

• Private Service Connect エンドポイントを使用して、他の VPC またはプロジェクト内のサービスが VPC ネットワーク内のプライベート IP アドレスを使用して、Cloud Run サービスなどの Google API とサービスに接続できるようにします。
• Cloud Run サービスの前に VPC ネットワーク内に配置された内部アプリケーション ロードバランサを介してトラフィックを転送します。ロードバランサは、他のサービスからのリクエストを VPC ネットワーク経由で転送し、内部上り（内向き）の条件を満たすようにします。

サーバーレス ネットワーク エンドポイント グループ（NEG）バックエンドを使用する内部アプリケーション ロードバランサは、Cloud Run サービスに直接マッピングされる VPC リソースを作成します。このモデルでは、ロードバランサは信頼できる証明書を使用してクライアント TLS 接続を終了します。内部アプリケーション ロードバランサは、Cloud Armor のバックエンド セキュリティ ポリシーや追加の認可ポリシーなど、追加のセキュリティ制御をサポートしています。

デフォルトでは、すべての Cloud Run サービスへのアクセスには IAM 認証が必要です。サービスごとに ID を使用し、プリンシパルに Cloud Run 起動元 IAM ロール（roles/run.invoker）を付与することをおすすめします。

Cloud Run の上り（内向き）制御を構成する方法については、次のリソースをご覧ください。

• Cloud Run サービスのネットワーク エンドポイント上り（内向き）を制限する
• IAM を使用したアクセス制御
• プライベート ネットワークからリクエストを受信する
• Cloud Run を使用してリージョン内部アプリケーション ロードバランサを設定する

プライベート Google アクセスまたは Google API 用の Private Service Connect エンドポイントを使用して VPC ネットワークから Cloud Run にトラフィックを送信する場合は、次のプロダクトと機能を使用してトラフィックを保護できます。

• Cloud Run 上り（内向き）コントロール
• Cloud Run 認証
• VPC Service Controls
• Model Armor

内部アプリケーション ロードバランサを使用して VPC ネットワークから Cloud Run にトラフィックを送信する場合は、次のプロダクトと機能を使用してトラフィックを保護できます。

• Cloud Run 上り（内向き）コントロール
• Cloud Run 認証
• VPC Service Controls
• Model Armor
• ロードバランサの証明書の検証
• Cloud Armor バックエンド セキュリティ ポリシー
• ロードバランサの認可ポリシー

GKE ネットワーキング

このセクションでは、GKE ベースのエージェントのネットワーキングについて説明します。

GKE と Gemini Enterprise

AI エージェントとツールのホストとして、GKE はネットワークとセキュリティの制御のための高度にカスタマイズ可能なプラットフォームを提供します。GKE にデプロイされたマルチエージェント AI システムは、大規模な運用効率を実現できます。他の Kubernetes アプリや大規模なマイクロサービス アーキテクチャと緊密に統合できます。

GKE クラスタは、VPC ネットワークのサブネット内で実行される Compute Engine VM ノードです。Gemini Enterprise アプリは、VPC ネットワーク外のホスト環境で動作するマネージド リソースです。Gemini Enterprise アプリが GKE でホストされているカスタム エージェントを呼び出せるようにするには、パブリック IP アドレスと DNS 名を使用して外部 Gateway を安全に公開する必要があります。トラフィックは Gemini Enterprise の下り（外向き）から Google エッジ ネットワークに流れ、GKE 外部ロードバランサへの最適化されたルートをたどります。

強力な認証と認可、Cloud Armor、制限付き権限を使用して GKE エンドポイントを保護することが重要です。GKE で実行される AI エージェントを保護するための包括的な多層防御モデルを構築するには、次のセクションで説明するセキュリティ管理を検討してください。

GKE のオペレーション モード

GKE では、管理と制御のバランスを取るために、次の運用モードが用意されています。

• Autopilot: Google は、コントロール プレーン、ノード プロビジョニング、セキュリティ強化、スケーリングなど、GKE クラスタ インフラストラクチャ全体を自動化します。
• Standard: Google がコントロール プレーンを管理します。マシンタイプの選択、OS イメージの管理、手動スケーリングなど、ノードプールの構成はすべてお客様の責任となります。

インフラストラクチャとコントロール プレーンの強化

• 限定公開 GKE クラスタ: パブリック IP アドレスのないノードをプロビジョニングします。これにより、ランタイム環境がインターネットに直接公開されないようにします。
• マスター承認済みネットワーク: Kubernetes API への管理アクセスを特定の信頼できる IP アドレス範囲に制限し、不正な構成変更からコントロール プレーンを強化します。 Google Cloudの IAM と VPC Service Controls を使用して、Kubernetes API の DNS エンドポイントを保護します。

ID とアクセス（ゼロトラスト）

• IAP: ロードバランサ レベルでゲートキーパーとして機能します。これにより、適切な IAM 権限を持つ認証済みユーザーのみがエージェント エンドポイントにアクセスできるようになります。このアプローチでは、セキュリティ境界がネットワークから個々のユーザーとそのデバイスのコンテキストに効果的に移行します。

エッジ保護とトラフィック管理

• Cloud Armor: 悪意のあるペイロードのブロックに役立つウェブ アプリケーション ファイアウォール（WAF）ルール、稼働時間の確保に役立つ DDoS 保護、サービス停止の防止に役立つレート制限など、堅牢なエッジ セキュリティを提供します。
• Model Armor: LLM の安全性を確保するために特別に設計された Model Armor は、プロンプト インジェクションやデータの引き出しを防ぐために、プロンプトとレスポンスをリアルタイムで検査してサニタイズします。

内部ネットワークの分離

• Kubernetes ネットワーク ポリシー: マイクロサービス間のきめ細かい最小権限の通信を適用します。デフォルトでは、ポリシーは明示的に許可しない限りすべてのトラフィックを拒否するため、クラスタ内のラテラル ムーブメントを防ぐことができます。

VPC ネットワークへの GKE 下り（外向き）

VPC ネットワークは、GKE でホストされているエージェントからのアウトバウンド接続をルーティングします。GKE クラスタのデフォルトのネットワーク モードは VPC ネイティブです。このモードには次の属性があります。

• GKE クラスタはエイリアス IP アドレス範囲を使用します。
• Pod IP アドレスは、Pod IP 範囲を指定することで予約されます。
• Pod の IP アドレスは、クラスタの VPC ネットワークと、接続されている他の VPC ネットワーク内でネイティブにルーティングできます。

エージェント Pod が同じノード内のサブエージェント Pod と通信している場合、トラフィックはノード ネットワーク Namespace 内でローカルにルーティングされます。宛先エージェント Pod がクラスタ内の別のノードにある場合、トラフィックは VPC ネットワーク ルーティング テーブルを使用してルーティングされます。エージェント Pod がロードバランサや Private Service Connect エンドポイントなどの他の VPC リソースと通信するには、ファイアウォール ルールに従って、同じ標準 VPC ルーティングを使用して宛先に到達できます。

次のプロダクトとサービスを使用すると、GKE クラスタから送信されるトラフィックを保護できます。

• Model Armor
• Cloud NGFW
• GKE ネットワーク ポリシー
• 限定公開 GKE クラスタ

VPC ネットワークからの GKE 上り（内向き）

Kubernetes Service は、GKE リソースへのアクセスを提供します。マルチエージェント AI システムには、GKE Gateway または GKE Inference Gateway を使用することをおすすめします。Gateway は、トラフィック制御、リソースの運用分離、セキュリティ統合などの機能強化を提供します。ただし、システム要件に応じて、他の上り（内向き）サービス オプションを利用できます。

Gateway リソースはアプリケーション ロードバランサを作成し、必要なロード バランシング コンポーネントをすべてプロビジョニングします。サービスのバックエンド ネットワーク エンドポイント グループは、コンテナに直接ロード バランシングを提供するように接続されています。VPC ネットワークから送信されたトラフィックに対してサービスを内部的に公開するには、リージョン内部アプリケーション ロードバランサ（gke-l7-rilb）またはクロスリージョン内部アプリケーション ロードバランサ（gke-l7-cross-regional-internal-managed-mc）の Gateway クラスを使用します。

アプリケーション ロードバランサは、GKE クラスタでホストされている AI エージェントとツールを保護するための追加のセキュリティ制御ポイントを提供します。

• Cloud Armor: Gateway で管理されているバックエンド サービスに Cloud Armor セキュリティ ポリシーを適用して、サービスを保護します。トラフィックが GKE クラスタまたは IAP に到達する前に、WAF スクリーニング、IP アドレスと地域ベースのフィルタリング、DDoS 対策、レート制限を提供します。
• IAP: バックエンド サービスで有効にすると、IAM 認証情報を使用してアプリへのアクセスを制御できます。IAP はゼロトラスト アクセス ポリシーを適用します。IAP は、Gemini Enterprise アプリ、カスタム エージェント、外部リソースなど、クラスタ リソースにアクセスする AI エージェントを認証して認可します。呼び出し元は、IAM によって認証された ID を持ち、バックエンド サービスにアクセスするための承認済み権限を持っている必要があります。

VPC ネットワークから Gateway を介して GKE サービスにトラフィックを送信する場合、次のプロダクトと機能を使用してトラフィックを保護できます。

• IAP
• Cloud Armor
• VPC Service Controls
• Model Armor

VPC ネットワークから GKE サービスにトラフィックを送信するために Gateway を使用しない場合は、次のプロダクトとサービスを使用してトラフィックを保護できます。

• VPC Service Controls
• Model Armor
• Cloud NGFW
• GKE ネットワーク ポリシー
• GKE ネットワーク分離
• 限定公開 GKE クラスタ

GKE の保護の詳細については、ネットワーク セキュリティのベスト プラクティスと GKE のネットワーク セキュリティについてをご覧ください。

エージェントのネットワーク セキュリティ

マルチエージェント AI システムのネットワークを保護するには、VPC ネットワークと API サーフェスの両方で通信を保護する必要があります。VPC ネットワーク データプレーンは、エージェントとツールが安全に接続する方法を扱います。API サーフェスは、許可される ID とデータ交換のタイプを定義します。VPC ネットワークと API サーフェスの両方にアクセス制御をレイヤリングすることで、高度に制御された復元力のあるセキュリティ ポスチャーを適用できます。

Cloud NGFW

Cloud NGFW は、A2A 通信と MCP 通信を保護するネットワーク レベルのゲートキーパーとして機能します。ファイアウォールは、他のエージェントやツールとの間のすべての受信接続と送信接続を検証することで、承認されたトラフィックのみがエージェント エンドポイントに到達できるようにします。

Cloud NGFW は、VPC ネットワーク ファブリックに組み込まれた分散型ファイアウォール サービスです。ネットワーク スタックのさまざまなレイヤで動作する次の機能階層が用意されています。

• Cloud Next Generation Firewall Essentials: ステートフル ファイアウォール パケット フィルタリングを提供します。ポリシー ルールは、IP アドレス（L3）、プロトコル、ポート（L4）に基づいて定義されます。
• Cloud Next Generation Firewall Standard: 完全修飾ドメイン名（FQDN）オブジェクト、位置情報オブジェクト、Google Threat Intelligence のフィードを使用して IP ベースの適用を行い、既知の悪意のあるアドレスをブロックします。
• Cloud Next Generation Firewall Enterprise: TLS 復号と侵入検知および防止システム（IDPS）の機能により、高度な脅威シグネチャに対してペイロードを分析する真のアプリ（L7）インスペクション機能を提供します。

Cloud NGFW は VPC ネットワークに適用して、使用したエージェント ホスティング プラットフォームをターゲットにするために必要なルールに基づいてファイアウォール ポリシーを適用できます。

• Vertex AI Agent Engine: Vertex AI Agent Engine で実行されるエージェントは、Private Service Connect ネットワーク アタッチメントを使用して VPC ネットワークに接続します。これらのアタッチメントにより、エージェント ネットワーク インターフェースが VPC ネットワーク内のサブネット内に表示されます。Cloud NGFW ネットワーク ファイアウォール ポリシーは VPC ネットワークに適用されます。ポリシーは、Private Service Connect ネットワーク アタッチメント専用のサブネットの送信元 IP アドレスに基づいてトラフィックをフィルタします。トラフィック照合には、送信元 IP アドレスと宛先 IP アドレスの範囲を使用できます。
• Cloud Run: ダイレクト VPC 下り（外向き）を使用する Cloud Run サービスは、VPC ネットワークで指定されたサブネット内で実行されるインスタンスからトラフィックを直接送信します。Cloud NGFW ネットワーク ファイアウォール ポリシーは、Cloud Run がトラフィックのフィルタリングに使用するサブネットに適用されます。トラフィックの照合には、送信元 IP アドレスと宛先 IP アドレスの範囲を使用できます。
• GKE: VPC ネイティブの GKE クラスタは、VPC ネットワークのセカンダリ IP アドレス範囲から直接 Pod に IP アドレスを付与します。ネットワーク ファイアウォール ポリシーは、GKE ノードと Pod の IP アドレス範囲に基づいてトラフィックをフィルタできます。また、ポリシーではセキュアタグとサービス アカウントを使用できます。安全なタグは、GKE ノードとして機能する VM インスタンスにバインドされます。ファイアウォール ルールは、特定のタグを持つノードからのトラフィックをターゲットにしたり、そのノードからのトラフィックを送信元にしたりできます。ファイアウォール ルールは、ノードプールに関連付けられているサービス アカウント ID に基づいて、GKE ノードからのトラフィックをターゲットにしたり、ソースにしたりすることもできます。

デフォルトの拒否下り（外向き）ポリシー

デフォルト拒否戦略の実装は、最小権限の原則に準拠したセキュリティのベスト プラクティスです。この戦略により、明示的に許可されたネットワーク トラフィックのみが許可され、他のすべてのトラフィックはデフォルトでブロックされます。この実装は、既知の正当なフロー用の優先度の高い ALLOW ルールと、優先度の低いキャッチオール DENY ルールを使用してファイアウォール ルールを構造化することで実現されます。Cloud NGFW のすべての階層で、送信元と宛先の IP アドレス範囲に基づくルールが許可されます。

ファイアウォール ポリシー ルールは、Vertex AI Agent Engine ネットワーク アタッチメント サブネットと Cloud Run ダイレクト VPC 下り（外向き）サブネットからの送信元トラフィックを効果的に照合できます。

デフォルト拒否の下り（外向き）ポリシーの例を次に示します。

• ネットワーク ファイアウォール ポリシーとルールを作成する: グローバルまたはリージョンのファイアウォール ポリシーを作成し、VPC ネットワークに関連付けます。送信元 IP アドレス範囲（--src-ip-ranges=SRC_IP_RANGES）と宛先 IP アドレス範囲（--dest-ip-ranges=DEST_IP_RANGES）に基づいて、下り（外向き）方向（--direction=EGRESS）のトラフィックをターゲットとするファイアウォール ポリシー ルールを作成します。
• 特定の ALLOW ルール: 優先度の低い数値（100 ～ 1000 など）を使用します。これらのルールにより、AI エージェントが機能するために必要なネットワーク トラフィックを正確に許可できます。このトラフィックには、他の内部サービス、ロードバランサ、必要な Google API、正当な外部エンドポイントへの通信が含まれます。Vertex AI Agent Engine ネットワーク アタッチメント サブネットまたは Cloud Run ダイレクト VPC 下り（外向き）サブネットからの送信元トラフィックを目的の宛先に一致させるルールを作成します。
• 一般的な DENY ルール: ルールが評価順序の最後になるように、優先度の数値に最大値（2147483647 など）を使用します。このルールは、上記の ALLOW ルールに一致しない宛先（--dest-ip-ranges=0.0.0.0/0）へのトラフィックを拒否します。

デフォルトの拒否外向きポリシーにより、AI エージェントは明示的に承認されていないネットワーク接続を行うことができなくなり、データ漏洩や悪意のあるサイトへのアクセスがブロックされます。このポリシーにより、ホストされているエージェントは承認済みのエンドポイントとのみ通信できるようになります。これは、自律型ワークロードの制御を維持するために不可欠です。

Cloud NGFW ポリシーに関するその他の考慮事項

すべての Cloud NGFW 階層で利用可能なデフォルトの拒否戦略に加えて、有料階層の機能を使用すると、マルチエージェント AI ネットワーク セキュリティをさらに強化できます。

• Cloud NGFW Standard の標準機能:
  • 動的エンドポイントの FQDN オブジェクト: AI エージェントは、IP アドレスが変更される可能性のある外部 API、モデル エンドポイント、データソースとやり取りすることがよくあります。ドメイン名で必要なサービスに一貫してアクセスするには、ALLOW ルールで FQDN オブジェクトを使用します。
  • 位置情報制御: AI エージェントにコンプライアンス要件がある場合や、特定の地理的リージョンのサービスとやり取りしないようにする必要がある場合は、ファイアウォール ルールで位置情報オブジェクト（--src-region-codes=SRC_COUNTRY_CODES）を使用して、それらの場所との間のトラフィックを制限します。
  • Google Threat Intelligence: 下り（外向き）フィルタで Google Threat Intelligence を使用して、エージェントがコマンド＆コントロール（C2）サーバー、Tor などの匿名化ツール、マルウェア配布サイトなどの既知の悪意のある宛先に接続するのを自動的にブロックします。Google Threat Intelligence を使用すると、不正使用された可能性のあるエージェントの影響を封じ込めることができます。これらの宛先フィルタは、優先度の高い数値（評価順序が低い）の DENY ルールに含めることをおすすめします。
• Cloud NGFW Enterprise の機能:
  • レイヤ 7 の検査: センシティブ データを処理するエージェントや、リスクの高いエージェントについては、ネットワーク層のファイアウォール ルールで分析されないマルウェア、スパイウェア、セキュリティ上の脆弱性を利用した不正プログラムなどの脅威について、パケット ペイロードを検査します。
  • TLS インスペクション: インスペクション エンジンが暗号化されたトラフィックを分析できるようにするには、TLS インスペクションを有効にします。最新の攻撃と C2 通信のほとんどが暗号化されているため、TLS インスペクションの使用は非常に重要です。

環境に適用される可能性のある実装に関するその他の考慮事項や制限事項については、次のリソースをご覧ください。

• URL フィルタリング サービス
• 侵入検知および防止サービス
• TLS インスペクション

IAP

IAP は、AI アプリの一元的な認証および認可レイヤを提供することで、GKE クラスタへの上り（内向き）リクエストを保護します。IAP は、Gateway 宛てのすべての HTTPS リクエストを傍受し、呼び出し元の ID と権限を確認します。IAP では、認証および認可されたリクエストのみがバックエンド サービス ワークロードに渡されます。Gateway ロードバランサの IAP は、クラスタ外からのトラフィックのみを保護します。クラスタ内の通信は IAP を通過しません。

GKE でホストされ、IAP で保護されている AI アプリにアクセスするには、プリンシパル ユーザー ID に、IAP で保護されたバックエンド サービス リソースに対する IAP で保護されたウェブアプリ ユーザー IAM ロール（roles/iap.httpsResourceAccessor）が付与されている必要があります。デプロイされたエージェントの ID としてカスタム サービス アカウントを構成することをおすすめします。カスタム サービス アカウントを使用すると、最小権限の原則に従って権限をより正確に割り当てることができます。

IAP で保護されたウェブアプリ ユーザー IAM ロールは、GKE BackendConfig カスタム リソースでホストされている他のエージェントとツールにアクセスできるエージェントのサービス アカウントにのみ直接付与します。Gemini Enterprise アプリにアクセスを許可するには、Gemini Enterprise プロジェクトの IAM ロール Discovery Engine サービス アカウント（roles/discoveryengine.serviceAgent）をバインドして権限を付与します。

VPC Service Controls

VPC Service Controls は、Google API へのアクセスを厳密に制御することで、データの引き出しのリスクを軽減します。サポートされているすべてのサービスを含む単一のマクロ境界をデプロイすることをおすすめします。このアプローチは、データ漏洩に対する最も堅牢な防御を提供します。共有 VPC アーキテクチャで一貫したポリシー適用を確保するには、ホスト プロジェクトと関連するすべてのサービス プロジェクトを同じサービス境界内に含めることが重要です。

注: VPC Service Controls の境界を実装するには、組織の計画、データ収集、テストが必要です。この組織的な取り組みには、特定のアクセス パターンとユースケースをマッピングするためのワークロード チームの文書化とインタビューが含まれます。新しい環境または既存の環境にサービス境界を実装する方法については、VPC Service Controls を有効にするためのベスト プラクティスをご覧ください。

プロジェクト境界を越えて Gemini Enterprise と Cloud Run 間のやり取りを保護するには、次の推奨事項を検討してください。

• Gemini Enterprise プロジェクトと Cloud Run プロジェクトの両方を含む単一の VPC Service Controls 境界をデプロイします。
• サポートされているすべての VPC Service Controls サービスを制限付きサービスのリストに追加します。このアプローチは、不正な管理変更を防ぐのに役立ちます。
• 内部の上り（内向き）と認可の設定を適用して、Cloud Run サービスへの公共のインターネット アクセスをすべてブロックします。

Cloud Run サービスは IAM によって保護されています。呼び出し元は認証され、ターゲット サービスに対する Cloud Run 起動元 IAM ロール（roles/run.invoker）が必要です。ロールは、Authorization ヘッダーのトークンを検証することで確認されます。Cloud Run サービスを正常に呼び出すには、 Gemini Enterprise で使用されるサービス アカウントなどのサービス アカウントに、Cloud Run 起動元ロールも付与する必要があります。

Gemini Enterprise と Cloud Run が異なるプロジェクトにデプロイされている場合、Cloud Run 上り（内向き）を内部に設定するには、VPC Service Controls 境界が必要です。この境界がない場合、Gemini からのクロス プロジェクト呼び出しは外部トラフィックとして扱われるため、Cloud Run 上り（内向き）を [すべて] に設定する必要があります。これにより、サービスが公共のインターネットに公開されます。

• Cloud Run 上り（内向き）all は、次の両方が真の場合にサポートされます。
  • VPC Service Controls が有効になっていない。
  • Cloud Run と Gemini Enterprise が同じプロジェクトにない。
• 他のすべての構成でサポートされているのは、Cloud Run 上り（内向き）internal のみです。

VPC Service Controls のその他の考慮事項

Cloud Run が VPC Service Controls の境界内にデプロイされている場合は、包括的な保護を確保するために、次のポリシー ガードレールを実装することをおすすめします。

• 許可される上り（内向き）設定を制限する: run.allowedIngress 組織のポリシーの制約を設定して、デベロッパーが公開エンドポイントを誤ってデプロイすることを防ぎます。この制約は新しいデプロイにのみ適用されます。以前のデプロイは準拠していない可能性があります。境界内の既存の Cloud Run サービスを監査し、必要な上り（内向き）と下り（外向き）の設定を満たしていないサービスを再デプロイまたは更新することをおすすめします。
  • 内部リクエストのみを許可するには、値を internal に設定します。
  • 外部アプリケーション ロードバランサを介してリクエストを許可するには、値を internal-and-cloud-load-balancing に設定します。
• 許可される VPC 下り（外向き）設定を制限する: すべてのアウトバウンド リクエストを VPC 経由で転送して、境界ファイアウォール ルールで検査できるようにするには、run.allowedVPCEgress 組織のポリシー制約値を all-traffic に設定します。この設定では、すべての Cloud Run リビジョンでダイレクト VPC 下り（外向き）またはサーバーレス VPC アクセス コネクタを使用する必要があります。この制約は、新しいデプロイにのみ適用されます。以前のデプロイが準拠していない可能性があります。境界内の既存の Cloud Run サービスを監査し、必要な上り（内向き）と下り（外向き）の設定を満たしていないサービスを再デプロイまたは更新することをおすすめします。
• コンテナ イメージとサービスをコロケーションする: コンテナ イメージを含む Artifact Registry リポジトリは、Cloud Run サービスと同じ境界内に存在する必要があります。明示的な上り（内向き）ルールと下り（外向き）ルールを設定しない限り、境界を越えたイメージの pull は自動的にブロックされます。
• アクセスレベルを管理する: IAM プリンシパル ID に依存する VPC Service Controls の上り（内向き）ポリシールールとアクセスレベルは、Cloud Run 呼び出しではサポートされていません。代わりに、ネットワークベースの条件またはデバイスベースのアクセスレベルを使用してアクセスを管理する必要があります。

Model Armor

Model Armor は、AI アプリのセキュリティと安全性を強化する API ベースのサービスです。AI エージェントは、LLM に送信する前にユーザー プロンプトをサニタイズし、ユーザーに返す前にモデル レスポンスをサニタイズする呼び出しを行うことで、Model Armor とやり取りします。Model Armor は LLM のプロンプトとレスポンスを積極的にスクリーニングします。これは、新たなリスクを検出するための重要な検査ポイントとなり、責任ある AI 標準を実装するためのコントロール ポイントとなります。Model Armor を使用して、データ所在地要件とデータ主権の法的規制を確実に遵守することをおすすめします。VPC Service Controls の境界内で Model Armor を使用するには、VPC ネットワーク内の Model Armor リージョン エンドポイントに Private Service Connect エンドポイントを構成する必要があります。

Model Armor は、VPC ネットワーク内のリージョン Private Service Connect エンドポイントを介してプライベートにアクセスされるリージョン サービスです。たとえば、us-central1 サービスは、リージョン エンドポイント modelarmor.us-central1.rep.googleapis.com を使用して呼び出されます。リージョン エンドポイントは、データ所在地を保証するのに役立ちます。

エージェントのアクセスを有効にするには、Model Armor サービスが必要なすべてのリージョンで次のコンポーネントを構成します。

1. Model Armor サービスが配置されている VPC ネットワーク リージョンに RFC 1918 サブネットを作成または特定します。
2. RFC 1918 サブネットにリージョン エンドポイントを作成します。
3. Cloud DNS 限定公開ゾーンと、リージョン エンドポイントの IP アドレスに解決される Model Armor リージョン エンドポイントのホスト名（modelarmor.us-central1.rep.googleapis.com など）のレコードを作成します。
4. Vertex AI Agent Engine の相互運用性については、Vertex AI Agent Engine から VPC ネットワークに関連付けられている Cloud DNS プライベート ゾーンへの DNS ピアリングを確立します。エージェントが Model Armor にリクエストを送信すると、Cloud DNS はホスト名リクエストを VPC ネットワーク内の Private Service Connect リージョン エンドポイントの IP アドレスに解決します。Cloud Run と GKE でホストされているエージェントの場合、この手順は必要ありません。

Gemini Enterprise を Model Armor と統合するには、Gemini Enterprise と同じプロジェクトに Model Armor テンプレートを作成します。テンプレートのロケーションと Gemini Enterprise アプリのロケーションは同じである必要があります。

Model Armor の有効化の詳細については、次のリソースをご覧ください。

• Gemini Enterprise との Model Armor の統合
• Gemini Enterprise で Model Armor を有効にする
• サポートされているリージョンでサポートされている Google API
• Google Cloud サービスとの Model Armor の統合
• データ所在地とエンドポイント

Cloud Armor

Cloud Armor は、リクエストがバックエンド サービス ランタイムに到達する前に、ロードバランサの背後にあるアプリとサービスを保護する分散ネットワーク セキュリティ サービスです。AI エージェント ワークロードには、A2A、MCP、API 呼び出しを使用するサービス間通信が大量に含まれます。Cloud Armor の保護は、レート制限、WAF スクリーニング、想定されるエージェント リクエストに準拠するカスタムルールにより、セキュリティ設計に復元力の追加レイヤを提供します。Cloud Armor セキュリティ ポリシーをアプリケーション ロードバランサのバックエンド サービスに適用すると、悪意のあるリクエストのトラフィックをフィルタリングし、レート制限で制御して、DDoS 攻撃を緩和できます。

Cloud Armor は、次のシナリオでエージェント ネットワーク アーキテクチャにデプロイできます。

• 内部アプリケーション ロードバランサを使用する Cloud Run: サーバーレス NEG バックエンドを使用する内部アプリケーション ロードバランサを使用して、Cloud Run で実行されるエージェントとツールを保護します。バックエンド セキュリティ ポリシーをサーバーレス NEG に適用して、内部トラフィックとレート制限に WAF ルールを適用します。エージェント通信を制御するには、IP アドレスとヘッダーに基づいて追加のカスタムルールを定義します。
• Gateway: ゾーン NEG バックエンドを使用するグローバルまたはリージョン外部アプリケーション ロードバランサの Gateway リソース定義を使用して、GKE で実行されるエージェントとツールを保護します。Kubernetes Gateway API を使用して、定義された Cloud Armor セキュリティ ポリシーを含む GCPBackendPolicy リソースを適用します。リージョン外部アプリケーション ロードバランサを使用する場合、Cloud Armor は WAF ルール、IP アドレスと地理情報に基づく制御、レート制限を含むバックエンド セキュリティ ポリシーをサポートします。グローバル外部アプリケーション ロードバランサは、Google Cloud Armor Adaptive Protection と Google Threat Intelligence を使用したバックエンド セキュリティ ポリシーと追加のエッジ セキュリティ ポリシーをサポートしています。

安全なウェブプロキシ

Secure Web Proxy は、VPC ネットワーク内にデプロイされ、VPC ネットワーク内または接続されたネットワーク内で発生する HTTP/S トラフィックをフィルタするリージョン マネージド サービスです。一元化されたプロキシとセキュリティ適用ポイントとして機能し、アウトバウンドのインターネット トラフィックに対するきめ細かい制御と可視性を提供します。また、内部サービス通信の明示的なプロキシとしても機能します。

Secure Web Proxy は、明示的なプロキシ ルーティング モード、Private Service Connect サービス アタッチメント モード、ネクストホップ モードの 3 つのデプロイ モードをサポートしています。このドキュメントで説明する 明示的なプロキシ ルーティング モードで Secure Web Proxy を使用することをおすすめします。このモードでは、HTTP クライアントが Secure Web Proxy の IP アドレスまたはホスト名を直接指すように明示的に構成されている必要があります。

VPC ネットワークに Secure Web Proxy をデプロイするには、フロントエンド サブネットとプロキシ専用サブネットを構成する必要があります。Secure Web Proxy はフルマネージド サービスです。Secure Web Proxy がデプロイされると、プロキシ リソースとの特定の統合のために、VPC ネットワークに Cloud Router と Cloud NAT が自動的にデプロイされ、構成されます。この構成では、インターネットに送信される前に、すべての送信リクエストが Secure Web Proxy を通過する必要があります。

明示的なプロキシとして Secure Web Proxy を使用すると、Vertex AI Agent Engine Private Service Connect インターフェース、Cloud Run ダイレクト VPC 下り（外向き）、VPC ネイティブ GKE クラスタから送信されるエージェント リクエストがサポートされます。エージェントが HTTP CONNECT メソッドを使用して Secure Web Proxy にリクエストを送信すると、TCP セッション トラフィックがプロキシにトンネリングされ、セキュリティ ポリシー ルールが適用されます。トラフィックが許可されている場合、Secure Web Proxy は、制御されたインターネット下り（外向き）または VPC ネットワークでルーティング可能なプライベート ネットワークの宛先にトラフィックを送信します。

明示的なプロキシ ルーティング

Vertex AI Agent Engine の下り（外向き）では、エージェントが VPC ネットワーク内のインターネット宛先またはルーティング不可能な IP アドレス範囲に到達するために、明示的なプロキシ構成を使用する必要があります。Vertex AI Agent Engine の相互運用性については、VPC ネットワークのフロントエンド サブネットの RFC 1918 IP アドレスを使用して、Secure Web Proxy リソースを構成することをおすすめします。この構成により、Secure Web Proxy は Vertex AI Agent Engine から直接アクセスできるようになります。これにより、VPC ネットワークまたは接続されたネットワーク内のルーティング不可能な IP アドレス宛先への接続をプロキシできます。

明示的なルーティング モードで Secure Web Proxy を使用するエージェント ホスティング プラットフォームをサポートするには、次のネットワーク リソースを構成します。

1. Secure Web Proxy リソースをホストする RFC 1918 サブネットを VPC ネットワークに作成するか、識別します。
2. Secure Web Proxy リソースの IP アドレスに解決される Secure Web Proxy ホスト名（swp.example.com など）の Cloud DNS レコードを作成します。
3. Vertex AI Agent Engine の相互運用性については、Vertex AI Agent Engine から VPC ネットワークに関連付けられている Cloud DNS プライベート ゾーンへの DNS ピアリングを確立します。エージェントが Secure Web Proxy にリクエストを行うと、Cloud DNS はホスト名リクエストを VPC ネットワーク内の Secure Web Proxy リソースの IP アドレスに解決します。Cloud Run と GKE でホストされているエージェントの場合、この手順は必要ありません。

エージェントのプロキシ設定

エージェント アプリが HTTP(S) プロキシを使用するように構成する標準的な方法は、次の環境変数を設定することです。

• HTTP_PROXY: HTTP トラフィック用の明示的なプロキシ サーバーの URL（例: http://swp.example.com:8888）。この設定では、クライアントからプロキシへの HTTP CONNECT メソッドを使用します。HTTP が指定されていても、エージェント ランタイムからターゲット エンドポイントまでのプロキシを介して TLS 暗号化がエンドツーエンドで維持されます。
• HTTPS_PROXY: HTTPS トラフィックの明示的なプロキシ サーバーの URL（例: https://swp.example.com:8888）。HTTP_PROXY 設定と同様に、HTTPS_PROXY 設定ではデフォルトで TLS が使用されます。ただし、デフォルトの TLS の上に独自の TLS 暗号化を有効にすることで、暗号化のレイヤを追加できます。詳細については、Certificate Authority Service をご覧ください。
• NO_PROXY: プロキシを経由しないホスト名または IP アドレスのカンマ区切りのリスト。たとえば、NO_PROXY リストに metadata.google.internal と 169.254.169.254 を追加すると、ワークロードは Google API とサービスに対する認証と認可のためにメタデータ サービスに直接アクセスできます。

env_vars 引数を使用してデプロイ中に変数を設定すると、エージェントのランタイム環境内で使用できるようになります（たとえば、Python で os.environ を使用する場合など）。ほとんどの標準 HTTP クライアント ライブラリは、これらの環境変数を自動的に検出して使用し、指定されたプロキシを介してトラフィックをルーティングします。このアプローチは、Python アプリや requests などの HTTP クライアント ライブラリで一般的です。エージェントをデプロイするときに、エージェントがアクセスする必要があるプライベート ドメインで Secure Web Proxy を使用するための環境変数を定義します。限定公開ドメインの宛先が Cloud DNS にも含まれていることを確認します。

次の例は、エージェント オブジェクトからの Vertex AI Agent Engine プロキシ デプロイを示しています。

## specify environment variables (dictionary)
env_vars = {
    "OTHER_VARIABLE": "OTHER_VALUE",
    "HTTP_PROXY": "http://swp.example.com:8888",
    "HTTPS_PROXY": "http://swp.example.com:8888",
    "NO_PROXY": "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"
}

remote_agent = aiplatform.agent_engines.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

Cloud Run は、サービス リビジョン レベルでの環境変数の設定をサポートしています。このアプローチでは、コンテナ イメージ内で設定された同じ名前の環境変数がオーバーライドされます。このアプローチは、サービス インスタンスの起動時にプロキシ変数などの運用パラメータを設定する場合に便利です。

次の例は、Cloud Run サービスをデプロイするときに環境変数を設定するコマンドを示しています。

gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--set-env-vars="HTTP_PROXY=http://swp.example.com:8888,HTTPS_PROXY=http://swp.example.com:8888,NO_PROXY=localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

GKE Pod に明示的なプロキシ構成を実装するには、プロキシ変数を指定する ConfigMap リソースを定義します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

ConfigMap キーを Pod に適用するには、コンテナ マニフェストの envFrom フィールドを使用します。この仕様では、実行時に環境変数がコンテナに挿入されます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: subagent-app
spec:
  template:
    spec:
      containers:
      -   name: my-container
        image: my-agent-app:latest
        envFrom:
        -   configMapRef:
            name: agent-proxy-config

CA Service

TLS 検査用に Secure Web Proxy または Cloud NGFW が構成されている場合は、CA Service（CA Service）が必要です。TLS インスペクションが有効になっていて、ワークロードの宛先が TLS を使用している場合、CA Service はその宛先の証明書を作成して署名します。実際の宛先の暗号化されたトラフィックが Secure Web Proxy または Cloud NGFW に到達すると、パケットが復号され、検査されてから、ポリシーが適用されます。ポリシーでパケットが許可されている場合、サービスは最終的な宛先に対してパケットを再暗号化します。CA Service を使用して、他の Google マネージド サービスに証明書を提供することもできます。

CA サービスはマネージド サービスです。CA Service が構成されると、ルート CA 証明書の有効期限が切れるまで、リーフ証明書の署名が処理されます。ルート CA 証明書は、有効期限が切れないように更新する必要があります。

CA Service は、マルチエージェント AI アーキテクチャでトラフィック検査と証明書管理を大規模に実現するために、次の機能をサポートしています。

• TLS インスペクション: 完全な TLS インスペクションには、プライベート CA の使用が必要です。HTTPS ペイロードを完全に復号して分析するには、中間プロキシ デバイス（Secure Web Proxy または Cloud NGFW）がクライアントとの TLS セッションを終了する必要があります。プロキシは、リクエストされたドメインに対してクライアントが信頼できると認める有効な証明書を提示する必要があります。

  CA Service は、リクエストされたサイトのサイト固有の偽装証明書を動的に生成して署名できます。クライアントのトラストストアにプライベート ルート CA 証明書がインストールされている場合、クライアントはこの動的に作成された証明書を有効なものとして受け入れます。クライアントはプロキシから送信された証明書を信頼するため、リクエストを送信します。プロキシは TLS セッションを終了し、パケットを復号してコンテンツを検査し、ポリシーを適用します。

• 証明書の配布: Vertex AI Agent Engine、Cloud Run、GKE で実行される AI エージェントなどの内部クライアント リソースには、ローカル トラストストアに追加されたプライベート ルート CA 証明書が必要です。ルート CA 証明書の公開鍵を Secret Manager に保存することで、AI エージェントは起動時に証明書を取得して、システムのトラストストアに追加できます。

  内部アプリケーション ロードバランサなどの内部サーバー リソースは、信頼できるサーバー エンドポイントとして機能し、クライアント TLS セッションを終了するために、プライベート CA によって発行された証明書を必要とします。アプリケーション ロードバランサは、Certificate Manager の発行構成と統合して、CA Service が証明書リクエストに署名し、ロードバランサにデプロイする処理を自動化します。

証明書オペレーションの詳細については、次のリソースをご覧ください。

• Cloud Run: サービスのシークレットを構成する
• GKE: プライベート CA 証明書を使用して限定公開レジストリにアクセスする
• Secure Web Proxy: TLS インスペクションを有効にする
• Cloud NGFW: TLS インスペクションの概要

A2A 接続のセキュリティ

ルート エージェントは、さまざまなランタイム ホスティング プラットフォームにデプロイされたさまざまなサブエージェントと MCP サーバーと通信します。各環境には、A2A レイヤまたは MCP レイヤで抽象化する必要がある独自のネットワーキング要件とセキュリティ要件があります。

次の図は、この設計ガイドでサポートされているコンポーネントと接続パスを示しています。

上の図は、これらの接続の可能性をまとめたものです。

• ユーザーは Gemini Enterprise アプリを介してエージェント システムとやり取りします。
• Gemini Enterprise アプリは、Google インフラストラクチャを使用して、GKE、Cloud Run、Vertex AI Agent Engine で実行されるルート エージェントに接続します。
• Gemini Enterprise アプリとルート エージェントは、Google インフラストラクチャを使用して、Vertex AI の Model Armor と Gemini LLM に接続します。
• ルート エージェントは、Google インフラストラクチャを使用して、Cloud Run または Vertex AI Agent Engine で実行されるサブエージェントに接続できます。
• ルート エージェントは、プライベート IP アドレスを使用して、Vertex AI Agent Engine、Cloud Run、GKE で実行されるサブエージェントに接続できます。これらの接続は VPC ネットワーク経由で転送する必要があります。
• ルート エージェントとサブエージェントの両方が、Cloud Run または GKE で実行されている MCP サーバーに接続できます。MCP サーバーに接続するエージェントは、Google インフラストラクチャまたは VPC ネットワークを使用できます。MCP サーバーは、Google Cloud、オンプレミス、別のクラウド、またはインターネットでホストされているツールへのアクセスを提供します。
• インターネットでホストされているサービスには、Secure Web Proxy を介して直接アクセスできます。

以降のセクションでは、安全な A2A 連携に必要なランタイム データパスとセキュリティ コントロールのリソースについて説明します。この情報は、プライベート接続を確立し、エージェント間のエンドツーエンドのデータパスを保護するために必要な多層防御を実装するためのアーキテクチャ標準として機能します。

GKE ソース エージェント

次の表に、GKE がソース エージェントの場合にトラフィックを保護するのに役立つリソースを示します。このトラフィックは、GKE クラスタをホストする VPC ネットワークを通過します。

宛先エージェント（データパス）	セキュリティ対策
Vertex AI Agent Engine（内部）	VPC Service Controls Model Armor
Cloud Run（内部）	VPC Service Controls Model Armor
Cloud Run（Google API 用の Private Service Connect）	VPC Service Controls Model Armor Cloud NGFW
Cloud Run アクセス（サーバーレス NEG）	VPC Service Controls Model Armor Cloud NGFW 内部アプリケーション ロードバランサの証明書の承認 Cloud Armor Private Service Connect エンドポイント
GKE	VPC Service Controls Model Armor Cloud NGFW 内部アプリケーション ロードバランサの証明書の承認 Cloud Armor Private Service Connect エンドポイント
VPC ネットワーク経由のインターネット	VPC Service Controls Model Armor Cloud NGFW 安全なウェブプロキシ

Vertex AI Agent Engine（内部）ソース エージェント

次の表に、Vertex AI Agent Engine がソース エージェントで、トラフィックが Google インフラストラクチャを直接通過する場合に、トラフィックの保護に役立つリソースを示します。これらのパスでは、VPC ネットワークは使用されません。

宛先エージェント（データパス）	セキュリティ対策
Vertex AI Agent Engine（内部）	VPC Service Controls
Cloud Run（内部）	VPC Service Controls

Vertex AI Agent Engine（Private Service Connect インターフェース）ソース エージェント

次の表に、Vertex AI Agent Engine が送信元エージェントで、トラフィックが Private Service Connect インターフェースを使用して VPC ネットワークを通過する場合に、トラフィックを保護するのに役立つリソースを示します。

宛先エージェント（データパス）	セキュリティ対策
Cloud Run（Private Service Connect GoogleAPIs）	VPC Service Controls Model Armor Cloud NGFW
Cloud Run アクセス（サーバーレス NEG）	VPC Service Controls Model Armor Cloud NGFW 内部アプリケーション ロードバランサの証明書の承認 Cloud Armor Private Service Connect エンドポイント
GKE	VPC Service Controls Model Armor Cloud NGFW 内部アプリケーション ロードバランサの証明書の承認 Cloud Armor Private Service Connect エンドポイント
VPC ネットワーク経由のインターネット	VPC Service Controls Model Armor Cloud NGFW 安全なウェブプロキシ

Cloud Run（内部）ソース エージェント

次の表に、Cloud Run がソース エージェントで、トラフィックが Google インフラストラクチャを直接通過する場合に、トラフィックを保護するのに役立つリソースを示します。これらのパスでは、VPC ネットワークは使用されません。

宛先エージェント（データパス）	セキュリティ対策
Vertex AI Agent Engine（内部）	VPC Service Controls
Cloud Run（内部）	VPC Service Controls

Cloud Run（ダイレクト VPC 下り（外向き））ソース エージェント

次の表に、Cloud Run が送信元エージェントで、トラフィックがダイレクト VPC 下り（外向き）を使用して VPC ネットワークを通過する場合に、トラフィックを保護するのに役立つリソースを示します。

宛先エージェント（データパス）	セキュリティ対策
Cloud Run（Google API 用の Private Service Connect）	VPC Service Controls Model Armor Cloud NGFW
Cloud Run アクセス（サーバーレス NEG）	VPC Service Controls Model Armor Cloud NGFW 内部アプリケーション ロードバランサの証明書の承認 Cloud Armor Private Service Connect エンドポイント
GKE	VPC Service Controls Model Armor Cloud NGFW 内部アプリケーション ロードバランサの証明書の承認 Cloud Armor Private Service Connect エンドポイント
VPC ネットワーク経由のインターネット	VPC Service Controls Model Armor Cloud NGFW 安全なウェブプロキシ
Google API 用の Vertex AI Agent Engine Private Service Connect	VPC Service Controls Model Armor Cloud NGFW

MCP 接続のセキュリティ

次のリストは、エージェント ランタイムと MCP サーバー間のデータパスの保護に関与するホスティング プラットフォームと多層防御制御の概要を示しています。Vertex AI Agent Engine、Cloud Run、または GKE のソース エージェントの場合は、宛先 MCP サーバーに応じて次のセキュリティ制御を使用します。

• インターネット:
  • VPC Service Controls
  • Model Armor
  • Cloud NGFW
  • 安全なウェブプロキシ
• Google MCP:
  • VPC Service Controls
  • Model Armor

次のステップ

• エージェント システムの構築方法については、以下をご覧ください。
  • エージェント型 AI アーキテクチャのコンポーネントを選択します。
    • エージェント型 AI システムの設計パターンを選択します。
    • Google Cloudのマルチエージェント AI システム。
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。

寄稿者

著者:

• Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
• Michael Larson | カスタマー エンジニア、ネットワーキング スペシャリスト
• Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング

その他の寄稿者:

• Christine Sizemore | クラウド セキュリティ アーキテクト
• Aspen Sherrill | クラウド セキュリティ アーキテクト
• Assaf Namer | プリンシパル クラウド セキュリティ アーキテクト
• David Tu | カスタマー エンジニア
• Ammett Williams | デベロッパー リレーションズ エンジニア
• Mark Schlagenhauf | テクニカル ライター、ネットワーキング