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

Last reviewed 2026-04-16 UTC

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

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

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

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

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

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

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

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

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

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

共有 VPC

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

共有 VPC アーキテクチャでは、ホスト プロジェクトに、VPC ネットワーク、Cloud Router、サブネット、ファイアウォール、Cloud DNS などの共有ネットワーク リソースが含まれます。管理者は、これらのリソースを使用するためのアクセス権をサービス プロジェクトに付与できます。サービス プロジェクトには、Agent Runtime、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 エンドポイント。
• プライベート IP アドレスを持つマネージド サービス（Cloud SQL など）。
• 内部ロードバランサのフロントエンドと 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 app からカスタム エージェントへ

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

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

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

• Agent Runtime のカスタム エージェント: Agent Platform Discovery Engine サービス エージェントには、Agent Runtime リソースを組み込み機能として呼び出すために必要な Agent Platform Identity and Access Management（IAM）ロールが含まれています。システムは、Agent Platform API サービスに対して行われたリクエストを、内部 API 呼び出しとして Google ネットワーク経由でルーティングします。
• Cloud Run のカスタム エージェント: Gemini Enterprise アプリは、Agent Platform 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 アプリは、Agent Platform 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 の本番環境ネットワークは、GKE へのリクエストを外部アプリケーション ロードバランサの Ingress の GFE にルーティングします。

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

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

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

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

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

• Agent Runtime のカスタム エージェント: Private Service Connect インターフェースは、Agent Runtime ランタイムを VPC ネットワークに接続します。VPC ネットワークのサブネットにネットワーク アタッチメントを作成し、Agent Runtime にアタッチする権限を付与します。Agent Runtime から送信されたトラフィックは、アタッチメントのサブネット 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 の下り（外向き）トラフィックは、送信元 IP アドレスとして Pod IP アドレスを使用します。マスカレードを構成すると、GKE の下り（外向き）トラフィックはノード IP アドレスを送信元 IP アドレスとして使用します。すべての GKE 下り（外向き）トラフィックは VPC ネットワークによってルーティングされます。

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

Agent Runtime ネットワーキング

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

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

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

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

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

Agent Runtime は、ネットワーク下り（外向き）に Google マネージド テナント プロジェクトを使用します。テナント ネットワークは、エージェントから Google API への接続と、公共のインターネットへの下り（外向き）接続を提供しますが、デフォルトでは、お客様の VPC ネットワークに直接接続されていません。

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

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

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

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

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

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

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

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

エージェントにクエリを実行するプライベート ユーザーは、Agent Platform API エンドポイントのホスト名を、プライベート Google アクセスのプライベート IP アドレス範囲または Google API の Private Service Connect エンドポイントの IP アドレスに解決する必要があります。googleapis.com の限定公開マネージド Cloud DNS ゾーンは、Agent Platform API のリクエストを解決します。VPC ネットワークは、Google 本番環境ネットワークを介してリクエストを直接ルーティングします。

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

• Agent Platform API の認証
• VPC Service Controls
• Model Armor

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

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

Private Service Connect インターフェースなしで Agent Runtime をデプロイすると、デフォルトでインターネットにアクセスできます。データ漏洩を防ぐには、VPC Service Controls を有効にしてデフォルトのアクセスを無効にします。

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

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

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

Cloud Run ネットワーキング

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

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

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

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

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 環境の外部からのトラフィックは外部として扱われます。このようなトラフィックには、Agent Runtime や他の Cloud Run サービスなどの他の Google Cloudサービスからのトラフィックが含まれます。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 権限を持つ認証済みユーザーのみが Agent Endpoint にアクセスできるようになります。このアプローチにより、セキュリティ境界がネットワークから個々のユーザーとそのデバイス コンテキストに効果的に移行されます。

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

• 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 Ingress

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 と、バックエンド サービスにアクセスするための承認された権限を持っている必要があります。

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

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

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

• 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 通信を保護するネットワーク レベルのゲートキーパーとして機能します。ファイアウォールは、他のエージェントやツールとの間のすべての受信接続または送信接続を検証することで、承認されたトラフィックのみが Agent Endpoint に到達できるようにします。

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

• Agent Runtime: Agent Runtime で実行されるエージェントは、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 アドレス範囲と宛先 IP アドレス範囲に基づくルールが許可されます。

ファイアウォール ポリシー ルールは、Agent Runtime のネットワーク アタッチメント サブネットと 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、正当な外部エンドポイントへの通信が含まれます。Agent Runtime のネットワーク アタッチメント サブネットまたは 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 は、次の両方が true の場合にサポートされます。
  • 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. Agent Runtime の相互運用性を確保するには、Agent Runtime から 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 app のロケーションは同じである必要があります。

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

• Model Armor と Gemini Enterprise の統合
• 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 適応型保護および Google Threat Intelligence を使用した追加のエッジ セキュリティ ポリシーをサポートしています。

Secure Web Proxy

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

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

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

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

1. Secure Web Proxy リソースをホストする VPC ネットワークに RFC 1918 サブネットを作成または特定します。
2. Secure Web Proxy リソースの IP アドレスに解決される Secure Web Proxy ホスト名（swp.example.com など）の Cloud DNS レコードを作成します。
3. Agent Runtime の相互運用性を確保するには、Agent Runtime から 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 暗号化は、Agent Runtime からターゲット エンドポイントまで、プロキシを介してエンドツーエンドで維持されます。
• HTTPS_PROXY: HTTPS トラフィックの明示的なプロキシ サーバーの URL（例: https://swp.example.com:8888）。HTTP_PROXY 設定と同様に、HTTPS_PROXY 設定ではデフォルトで TLS が使用されます。ただし、デフォルトの TLS に加えて独自の TLS 暗号化を有効にすることで、暗号化のレイヤを追加できます。詳細については、Certificate Authority Service をご覧ください。
• NO_PROXY: プロキシを経由しないホスト名または IP アドレスのカンマ区切りのリスト。たとえば、metadata.google.internal と 169.254.169.254 を NO_PROXY リストに追加すると、ワークロードはメタデータ サービスに直接アクセスして、Google API とサービスに対する認証と認可を行うことができます。

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

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

## 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 が構成されている場合は、Certificate Authority Service（CA Service）が必要です。TLS 検査が有効で、ワークロードの宛先が TLS を使用している場合、CA Service はその宛先の証明書を作成して署名します。実際の宛先の暗号化されたトラフィックが Secure Web Proxy または Cloud NGFW に到着すると、パケットが復号され、検査されて、ポリシーが適用されます。ポリシーでパケットが許可されている場合、サービスは最終宛先用にパケットを再暗号化します。CA Service を使用して、他の Google マネージド サービスに証明書を提供することもできます。

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

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

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

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

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

  内部アプリケーション ロードバランサなどの内部サーバー リソースには、信頼できるサーバー エンドポイントとして機能し、クライアント 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、または Agent Runtime で実行されるルート エージェントに接続します。
• Gemini Enterprise app とルート エージェントは、Google インフラストラクチャを使用して、Agent Platform の Model Armor と Gemini LLM に接続します。
• ルート エージェントは、Google インフラストラクチャを使用して、Cloud Run または Agent Runtime で実行されるサブエージェントに接続できます。
• ルート エージェントは、プライベート IP アドレスを使用して、Agent Runtime、Cloud Run、GKE で実行されているサブエージェントに接続できます。これらの接続は、VPC ネットワーク経由でルーティングする必要があります。
• ルート エージェントとサブエージェントは、Cloud Run または GKE で実行されている MCP サーバーに接続できます。MCP サーバーに接続するエージェントは、Google インフラストラクチャまたは VPC ネットワークを使用できます。MCP サーバーは、Google Cloud、オンプレミス、別のクラウド、またはインターネットでホストされているツールへのアクセスを提供します。
• インターネットでホストされているサービスには、Secure Web Proxy を介して直接アクセスできます。

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

GKE ソース エージェント

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

宛先エージェント（データパス）	セキュリティ対策
Agent Runtime（内部）	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 Secure Web Proxy

Agent Runtime（内部）ソース エージェント

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

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

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

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

宛先エージェント（データパス）	セキュリティ対策
Cloud Run（Private Service Connect Google API）	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 Secure Web Proxy

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

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

宛先エージェント（データパス）	セキュリティ対策
Agent Runtime（内部）	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 Secure Web Proxy
Google API 用の Agent Runtime Private Service Connect	VPC Service Controls Model Armor Cloud NGFW

MCP 接続のセキュリティ

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

• インターネット:
  • VPC Service Controls
  • Model Armor
  • Cloud NGFW
  • Secure Web Proxy
• 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 | テクニカル ライター、ネットワーキング