Agent Gateway でエージェントを管理する

Agent Gateway を使用すると、Cloud Run で構築してホストする AI エージェントからのアウトバウンド トラフィックを管理できます。Cloud Run サービスからの下り（外向き）トラフィックを、Secure Web Proxy で実行されるセルフマネージド Agent Gateway を介してルーティングすることで、一元化されたアクセス ポリシーを適用し、コンテンツの安全性に関するペイロードを検査して、エージェント ワークロード全体でオブザーバビリティ テレメトリーを収集できます。

このドキュメントでは、Cloud Run で Agent Gateway の一元化されたアーキテクチャを構成する方法について説明します。また、次の方法についても説明します。

アーキテクチャ

一元化されたセルフマネージド デプロイでは、Secure Web Proxy はポリシー適用ポイントとして機能し、Virtual Private Cloud（VPC）ネットワーク内で実行されます。アンビエント ネットワーキング サイドカー コンテナは、Cloud Run エージェントからのアウトバウンド トラフィックをインターセプトし、ダイレクト VPC 下り（外向き）を介して Secure Web Proxy インスタンスに転送します。Secure Web Proxy は、Identity-Aware Proxy（IAP）や Model Armor などのポリシー決定ポイントからアクセスルールとコンテンツ ルールを適用します。

エージェント コンテナとアンビエント サイドカー プロキシ コンテナを備えた Cloud Run サービスが、ダイレクト VPC Egress を介して、VPC ネットワーク内の Secure Web Proxy をバックエンドとするセルフマネージド Agent Gateway にトラフィックをルーティングするアーキテクチャ図。
図 1. Cloud Run エージェントのセルフマネージド Agent Gateway アーキテクチャ。

このアーキテクチャでトラフィックをルーティングして管理するには、次のコンポーネントを構成します。

  • ダイレクト VPC 下り（外向き）とアンビエント ネットワーキング: Cloud Run サービスは、--vpc-egress=all と --ambient-networking を使用して VPC ネットワークに接続します。デフォルトではリージョン スコープが使用され、すべてのアウトバウンド トラフィックが VPC ネットワークにルーティングされます。
  • セルフマネージド Agent Gateway: セルフマネージド モードの論理 Agent Gateway リソースは、VPC ネットワーク内の Secure Web Proxy インスタンスを指します。
  • 下り（外向き）ルーティング ポリシー: Network Services API の EgressRouting ポリシーは、Cloud Run サービスから Secure Web Proxy インスタンスにアウトバウンド トラフィックを転送します。

始める前に

  1. Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、アカウントを作成して、実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

  5. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  6. To initialize the gcloud CLI, run the following command: 

    gcloud init

  7. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  8. Verify that billing is enabled for your Google Cloud project.

  9. Install the Google Cloud CLI.

  10. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  11. To initialize the gcloud CLI, run the following command: 

    gcloud init

  12. Cloud Run Admin API、Network Services API、ネットワーク セキュリティ API、Service Extensions API、Model Armor API、Certificate Authority Service API、Certificate Manager API、Cloud Resource Manager API、App Hub API、Identity and Access Management API、Identity-Aware Proxy API、Compute Engine API、Traffic Director API、Cloud DNS API、Network Connectivity API、Agent Registry API の API がまだ有効になっていない場合は、有効にします。

    API を有効にするために必要なロール

    API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を介してこの権限を取得できます。ロールを付与する方法を確認する。

    API を有効にする

  13. サブネットでプライベート Google アクセスが有効になっている VPC ネットワークとサブネットを作成します。
  14. プロジェクトまたは組織で Agent Registry を設定します。
  15. Google Cloud CLI をインストールして初期化します。
  16. gcloud CLI コンポーネントを更新します。
    gcloud components update

必要なロール

Cloud Run 用の Agent Gateway の構成に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

共有 VPC を使用してプロジェクト間のデプロイを構成する場合は、組織レベルまたはフォルダレベルで roles/compute.xpnAdmin を付与するよう管理者に依頼してください。

セルフマネージド Agent Gateway を作成する

Agent Gateway リソースを作成する前に、Agent Gateway として Secure Web Proxy をデプロイするの説明に従って、VPC ネットワークに Secure Web Proxy インスタンスをデプロイして構成します。

  1. TLS インスペクションを設定し、TlsInspectionPolicy をアタッチするゲートウェイ セキュリティ ポリシーを作成します。Secure Web Proxy のセキュリティ ポリシー ルールや URL リストは必要ありません。
  2. allowOpen: false と mtlsPolicy.clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT を使用して ServerTlsPolicy リソースを作成する。clientValidationTrustConfig を設定しないでください。
  3. ゲートウェイの作成時に addresses、ports、certificateUrls、gatewaySecurityPolicy、serverTlsPolicy を構成して、明示的なプロキシ ルーティング モードで Secure Web Proxy インスタンスをデプロイします。これにより、Cloud Run はエージェントの Workload Identity を mTLS 経由で Secure Web Proxy と IAP に渡します。

Secure Web Proxy インスタンスの準備ができたら、Secure Web Proxy インスタンスを指すセルフマネージド Agent Gateway リソースを作成します。

  1. my-agent-gateway.yaml という名前の YAML 構成ファイルを作成します。

    name: AGENT_GATEWAY_NAME
registries:
  - "//agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION"
selfManaged:
  resourceUris:
    - "projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME"

    次のように置き換えます。

    • AGENT_GATEWAY_NAME: Agent Gateway リソースに割り当てる名前。
    • PROJECT_ID: Secure Web Proxy インスタンスをホストするプロジェクト ID。
    • REGION: Secure Web Proxy インスタンスのリージョン（us-central1 など）。
    • SWP_NAME: Secure Web Proxy インスタンスの名前。

  2. Agent Gateway の構成をインポートします。

    gcloud beta network-services agent-gateways import AGENT_GATEWAY_NAME \
   --source="my-agent-gateway.yaml" \
   --location=REGION \
   --project=PROJECT_ID

  3. Agent Gateway リソースを確認します。

    gcloud beta network-services agent-gateways describe AGENT_GATEWAY_NAME \
   --location=REGION \
   --project=PROJECT_ID

    次のセクションに進む前に、出力に selfManaged 構成と Secure Web Proxy インスタンスのリソース URI が表示されていることを確認します。

Traffic Director API にアクセスするように Cloud Run アンビエント ネットワーキングを構成する

ダイレクト VPC 下り（外向き）と --vpc-egress=all を使用して Cloud Run サービスを構成すると、コンテナ インスタンスからのすべてのアウトバウンド接続が VPC ネットワーク経由で転送されます。これには、trafficdirector.REGION.rep.googleapis.com への Envoy サイドカー接続が含まれます。

サイドカーが Traffic Director API を解決してアクセスできるようにするには、環境で VPC Service Controls を使用しているかどうかに基づいて、VPC ネットワークにプライベート Cloud DNS ゾーンを構成します。

VPC Service Controls を使用しない場合

プロジェクトで VPC Service Controls を使用していない場合は、trafficdirector.REGION.rep.googleapis.com のリクエストを Secure Web Proxy ゲートウェイの IP アドレスにルーティングするプライベート Cloud DNS ゾーンを作成します。これにより、Secure Web Proxy はトラフィックを通過させます。

  1. Secure Web Proxy ゲートウェイの内部 IP アドレスを取得します。

    SWP_IP=$(gcloud network-services gateways describe SWP_NAME \
 --project="PROJECT_ID" \
 --location="REGION" \
 --format="value(addresses[0])")

    次のように置き換えます。

    • SWP_NAME: Secure Web Proxy インスタンスの名前。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: デプロイのリージョン。

  2. Traffic Director API 用のプライベート Cloud DNS マネージド ゾーンを作成します。

    gcloud dns managed-zones create td-swp-zone \
 --project="PROJECT_ID" \
 --dns-name="trafficdirector.REGION.rep.googleapis.com." \
 --description="Private DNS zone routing control plane traffic to SWP" \
 --visibility="private" \
 --networks="VPC_NETWORK_NAME"

    VPC_NETWORK_NAME は、VPC ネットワークの名前に置き換えます。

  3. Traffic Director API のリージョン ドメインを Secure Web Proxy の IP アドレスに転送する A レコードを追加します。

    gcloud dns record-sets create "trafficdirector.REGION.rep.googleapis.com." \
 --project="PROJECT_ID" \
 --zone="td-swp-zone" \
 --type="A" \
 --ttl=300 \
 --rrdatas="${SWP_IP}"

  4. DNS レコードセットが限定公開ゾーンで有効になっていることを確認します。

    gcloud dns record-sets list \
 --project="PROJECT_ID" \
 --zone="td-swp-zone"

    trafficdirector.REGION.rep.googleapis.com. の A レコードが Secure Web Proxy の IP アドレスに解決されることを確認します。

VPC Service Controls を使用

VPC Service Controls 環境の場合は、VPC サブネット内のリージョン Traffic Director API をターゲットとする Private Service Connect リージョン エンドポイントをプロビジョニングし、プライベート Cloud DNS ゾーンを使用してドメインをマッピングします。

  1. リージョン Traffic Director API をターゲットとする Private Service Connect リージョン エンドポイントを作成します。

    gcloud network-connectivity regional-endpoints create td-rep-endpoint \
 --project="PROJECT_ID" \
 --region="REGION" \
 --network="projects/PROJECT_ID/global/networks/VPC_NETWORK_NAME" \
 --subnetwork="projects/PROJECT_ID/regions/REGION/subnetworks/VPC_SUBNET_NAME" \
 --target-google-api="trafficdirector.REGION.rep.googleapis.com"

    次のように置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: デプロイのリージョン。
    • VPC_NETWORK_NAME: VPC ネットワークの名前。
    • VPC_SUBNET_NAME: VPC サブネットの名前。

  2. リージョン エンドポイントの内部 IP アドレスを取得します。

    TD_ENDPOINT_IP=$(gcloud network-connectivity regional-endpoints describe td-rep-endpoint \
 --project="PROJECT_ID" \
 --region="REGION" \
 --format="value(address)")

  3. Traffic Director API 用のプライベート Cloud DNS マネージド ゾーンを作成します。

    gcloud dns managed-zones create td-psc-zone \
 --project="PROJECT_ID" \
 --dns-name="trafficdirector.REGION.rep.googleapis.com." \
 --description="Private DNS zone for regional endpoint" \
 --visibility="private" \
 --networks="VPC_NETWORK_NAME"

  4. Traffic Director API リージョン ドメインをリージョン エンドポイントの IP アドレスに解決する A レコードを追加します。

    gcloud dns record-sets create "trafficdirector.REGION.rep.googleapis.com." \
 --project="PROJECT_ID" \
 --zone="td-psc-zone" \
 --type="A" \
 --ttl=300 \
 --rrdatas="${TD_ENDPOINT_IP}"

  5. リージョン エンドポイントと DNS レコードセットを確認します。

    gcloud dns record-sets list \
 --project="PROJECT_ID" \
 --zone="td-psc-zone"

    trafficdirector.REGION.rep.googleapis.com. の A レコードがリージョン エンドポイントの IP アドレスを指していることを確認します。

アンビエント ネットワーキングとダイレクト VPC 下り（外向き）を使用して Cloud Run サービスをデプロイまたは更新する

Cloud Run エージェントを VPC ネットワークの Secure Web Proxy インスタンスに接続するには、ダイレクト VPC 下り（外向き）とリージョン アンビエント ネットワーキングの両方を有効にし、エージェント ID を使用してサービスを構成します。--functional-type=agent と --identity-type=agent-identity を使用してデプロイすると、Cloud Run は roles/run.agentDefaultAccess を付与します。これには roles/trafficdirector.client 権限と roles/cloudtrace.agent 権限が含まれます。

  1. 新しい Cloud Run エージェント サービスをデプロイするか、既存のサービスを更新して、リージョン アンビエント ネットワーキング、すべての送信トラフィックのダイレクト VPC 下り（外向き）、エージェント ID を有効にします。

    新しいサービス

    gcloud beta run deploy SERVICE_NAME \
 --image=IMAGE_URL \
 --network=VPC_NETWORK_NAME \
 --subnet=VPC_SUBNET_NAME \
 --vpc-egress=all \
 --functional-type=agent \
 --identity-type=agent-identity \
 --ambient-networking \
 --set-env-vars="GOOGLE_API_USE_CLIENT_CERTIFICATE=false,GOOGLE_API_USE_MTLS_ENDPOINT=never" \
 --region=REGION \
 --project=PROJECT_ID

    既存のサービス

    gcloud beta run services update SERVICE_NAME \
 --network=VPC_NETWORK_NAME \
 --subnet=VPC_SUBNET_NAME \
 --vpc-egress=all \
 --functional-type=agent \
 --identity-type=agent-identity \
 --ambient-networking \
 --update-env-vars="GOOGLE_API_USE_CLIENT_CERTIFICATE=false,GOOGLE_API_USE_MTLS_ENDPOINT=never" \
 --region=REGION \
 --project=PROJECT_ID

    次のように置き換えます。

    • SERVICE_NAME: Cloud Run エージェント サービスの名前。
    • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG の形式です。
    • VPC_NETWORK_NAME: Secure Web Proxy インスタンスをホストする VPC ネットワークの名前。VPC ネットワークとサブネットの作成については、VPC ネットワークの作成と管理をご覧ください。
    • VPC_SUBNET_NAME: Secure Web Proxy インスタンスが到達可能な VPC サブネットの名前。
    • REGION: サービスのリージョン。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

  2. Cloud Run サービスがアンビエント ネットワーキング、ダイレクト VPC 下り（外向き）、エージェント ID を使用していることを確認します。

    gcloud beta run services describe SERVICE_NAME \
   --region=REGION \
   --project=PROJECT_ID

    出力に、ダイレクト VPC 下り（外向き）サブネット、all-traffic 下り（外向き）、リージョン アンビエント ネットワーキング、割り当てられたエージェント ID プリンシパルが表示されていることを確認します。

Agent Gateway を信頼するように Cloud Run エージェントを構成する

Secure Web Proxy で HTTPS ペイロードを検査してポリシーを適用するには、エージェントからのアウトバウンド TLS セッションを終了する必要があります。Cloud Run エージェント コンテナは、CA Service またはプライベート エンタープライズ PKI の Secure Web Proxy TLS インスペクション ポリシーに関連付けられたルートまたは下位の認証局（CA）証明書を信頼する必要があります。

  1. Secure Web Proxy インスタンスの CA Service プールから PEM でエンコードされた CA 証明書をエクスポートします。

    gcloud privateca pools get-ca-certs CA_POOL_NAME \
   --location=REGION \
   --project=PROJECT_ID \
   --output-file=agent-gateway-root.crt

    次のように置き換えます。

    • CA_POOL_NAME: Secure Web Proxy TLS インスペクション ポリシーに関連付けられている CA プールの名前。
    • REGION: CA プールのリージョン。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

  2. 環境変数で証明書の内容を渡すように Cloud Run サービスを更新します。

    gcloud beta run services update SERVICE_NAME \
   --region=REGION \
   --project=PROJECT_ID \
   --update-env-vars="AGENT_GATEWAY_ROOT_CERT=$(cat agent-gateway-root.crt)"

    次のように置き換えます。

    • SERVICE_NAME: Cloud Run エージェント サービスの名前。
    • REGION: サービスのリージョン。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

    たとえば、次の Debian または Ubuntu コンテナのエントリポイント スクリプト entrypoint.sh は、アプリケーションを起動する前に、AGENT_GATEWAY_ROOT_CERT をシステム トラストストアにインストールし、Python クライアントと gRPC クライアントの CA バンドルパスをエクスポートします。

    #!/usr/bin/env bash
set -e
if [ -n "${AGENT_GATEWAY_ROOT_CERT}" ]; then
 printf '%s\n' "${AGENT_GATEWAY_ROOT_CERT}" > /usr/local/share/ca-certificates/agent-gateway.crt
 update-ca-certificates
 export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
 export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
 export GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=/etc/ssl/certs/ca-certificates.crt
fi
exec "$@"

  3. サービスが AGENT_GATEWAY_ROOT_CERT 環境変数を設定していることを確認します。

    gcloud beta run services describe SERVICE_NAME \
   --region=REGION \
   --project=PROJECT_ID \
   --format="yaml(spec.template.spec.containers[0].env)"

外向きトラフィックを Agent Gateway にルーティングする

Cloud Run サービスと Agent Gateway を構成したら、Network Services API EgressRouting ポリシーを作成して、Cloud Run サービスから Secure Web Proxy ゲートウェイにアウトバウンド トラフィックを転送します。

  1. EgressRouting リソースを作成します。

    gcloud alpha network-services egress-routings create my-run-egress-routing \
   --location=REGION \
   --project=PROJECT_ID \
   --gateway="//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME" \
   --sources="workloadUri=//run.googleapis.com/projects/PROJECT_ID/locations/REGION/services/SERVICE_NAME"

    次のように置き換えます。

    • REGION: Cloud Run サービスとゲートウェイのリージョン。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • SWP_NAME: 基盤となる Secure Web Proxy の Gateway リソースの名前（AgentGateway リソースではありません）。
    • SERVICE_NAME: Cloud Run エージェント サービスの名前。プロジェクト内のすべての Cloud Run サービスを単一のポリシーでゲートウェイ経由でルーティングするには、workloadUri を //run.googleapis.com/projects/PROJECT_ID または //run.googleapis.com/projects/PROJECT_NUMBER に設定します。

    EgressRouting が有効になると、Cloud Run サービスからのすべてのアウトバウンド トラフィックが Secure Web Proxy を経由してルーティングされます。次のセクションでポリシーを構成して、アウトバウンド リクエストを許可して管理します。

  2. EgressRouting リソースがアクティブであることを確認します。

    gcloud alpha network-services egress-routings describe my-run-egress-routing \
   --location=REGION \
   --project=PROJECT_ID

    sources に Cloud Run ワークロード URI が一覧表示され、gateway が Secure Web Proxy ゲートウェイ リソースを参照していることを確認します。

Agent Gateway でポリシーを構成する

Agent Gateway を介して下り（外向き）トラフィックをルーティングしたら、認可ポリシーと Service Extensions 拡張機能バインディングを Agent Gateway リソースに接続して、エージェントのアウトバウンド リクエストを管理します。

  • ベースライン トラフィックと MCP ツール フィルタリング: ALLOW 認可ポリシーを使用して、モデル エンドポイントと承認済みの Model Context Protocol（MCP）メソッドとツールを許可します。
  • ID ベースのアクセス制御: IAP を ExtensionBinding リソースにバインドし、IAM 統合アクセス ポリシーを構成して、特定のエージェントが特定の MCP サーバー、ツール、エンドポイントを呼び出せるように制御します。
  • コンテンツ セキュリティ: Model Armor を ExtensionBinding リソースにバインドして、プロンプト インジェクション、機密データの漏洩、ポリシー違反がないかプロンプトとレスポンスを検査してサニタイズします。

基盤となる Secure Web Proxy Gateway リソースに接続されている認可ポリシーまたはゲートウェイ セキュリティ ポリシー ルールは無視されます。ExtensionBinding リソースを作成または更新した後、変更がゲートウェイに反映されるまでに最大 5 分かかることがあります。ネットワーク ルール、TLS 検査、拡張機能バインディング、HTTP ルールにわたるルール評価シーケンスについては、認可ルールの評価順序をご覧ください。

ベースラインの下り（外向き）トラフィックと MCP トラフィックを許可する

Secure Web Proxy は、Agent Gateway リソースの ALLOW AuthzPolicy で許可されるまで、デフォルトで 403 Forbidden エラーを伴うすべての送信トラフィックを拒否します。

Cloud Run サービスは --vpc-egress=all を使用するため、MCP ツール呼び出しや LLM リクエストなど、すべてのアウトバウンド コンテナ トラフィックがゲートウェイ経由でルーティングされます。両方のトラフィック タイプについて、ALLOW 認可ポリシーを Agent Gateway リソースに接続します。

IAP 下り（外向き）ポリシーを構成する

Agent Gateway は、IAP をポリシー決定エンジンとして使用して、IAM 統合アクセス ポリシーを評価します。エージェント ID ポリシーを適用するには、IAM 統合アクセス ポリシーでアクセスルールを定義し、IAP をゲートウェイにバインドします。

  1. Cloud Run サービスのエージェント ID プリンシパル principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/run/projects/PROJECT_NUMBER/locations/REGION/services/SERVICE_NAME を使用して IAM 統合アクセス ポリシーを作成し、IAM アクセス ポリシーを作成すると統合アクセス ポリシーをプロジェクトにバインドするの手順に沿って、ポリシーをプロジェクトまたはゲートウェイにバインドします。
  2. IAP を Agent Gateway にバインドするの手順に沿って、ExtensionBinding を使用して IAP（iap.googleapis.com）を Agent Gateway にバインドします。

--vpc-egress=all は REGION-aiplatform.googleapis.com などのモデル呼び出しをゲートウェイ経由で送信するため、IAP ExtensionBinding のスコープ matchConditions を prefix: "urn:mcp" に設定して、モデル呼び出しが IAP 評価をバイパスするようにします。エージェント間のトラフィックも管理するには、prefix: "urn:agent" を追加します。拡張機能バインディングが他のホストと一致する場合は、IAM 統合アクセス ポリシー（destination.unregistered.host == 'REGION-aiplatform.googleapis.com' など）に各ホストの許可ルールを追加します。例については、エージェントから未登録エンドポイントへのポリシーを作成するをご覧ください。

Model Armor ポリシーを構成する

Agent Gateway を通過するプロンプトとレスポンスを検査してサニタイズするには、Model Armor テンプレートを作成してゲートウェイにバインドします。

  1. ゲートウェイで Model Armor を構成するの手順に沿って、リージョン Model Armor リクエスト テンプレートとレスポンス テンプレートを作成し、Service Extensions サービス エージェントに必要なロールを付与します。
  2. プロンプトとレスポンスのサニタイズ用に Model Armor をバインドするの手順に沿って、ExtensionBinding を使用してテンプレートを Agent Gateway にアタッチします。

共有 VPC を使用して一元化されたプロジェクト間デプロイを構成する

マルチプロジェクト組織では、1 つ以上のサービス プロジェクトに Cloud Run エージェントをデプロイし、共有 VPC を使用して専用のネットワーキング ホスト プロジェクトで Agent Gateway、Secure Web Proxy インスタンス、Agent Registry をホストできます。

  • プロジェクト A、エージェント サービス プロジェクト: Cloud Run エージェント サービスとローカル EgressRouting ポリシーをホストします。
  • プロジェクト B、ゲートウェイとネットワーキングのホスト プロジェクト: 共有 VPC ホスト プロジェクトとして機能し、Agent Gateway、Secure Web Proxy インスタンス、Agent Registry、ExtensionBinding リソース、IAM ポリシー バインディングをホストする必要があります。
プロジェクト A が Cloud Run サービスと下り（外向き）ルーティング ポリシーをホストし、共有 VPC ネットワークを介して Agent Gateway、Secure Web Proxy、Agent Registry をホストするプロジェクト B に接続されていることを示す、プロジェクト間のアーキテクチャ図。
図 2.共有 VPC を使用したプロジェクト間の Agent Gateway のデプロイ。

これらの手順を開始する前に、プロジェクト A で run.googleapis.com、compute.googleapis.com、networkservices.googleapis.com、trafficdirector.googleapis.com を有効にします。エージェントが Vertex AI を呼び出す場合は、aiplatform.googleapis.com も有効にします。プロジェクト B で、セルフマネージド Agent Gateway を作成するの説明に従って、共有 VPC ネットワークに Secure Web Proxy インスタンスと Agent Gateway リソースをデプロイします。また、Traffic Director API にアクセスするように Cloud Run アンビエント ネットワーキングを構成するの説明に従って、DNS または Private Service Connect ルーティングを構成します。これにより、プロジェクト A のアンビエント サイドカーが Traffic Director API にアクセスできるようになります。

クロスプロジェクト デプロイを構成する手順は次のとおりです。

  1. プロジェクト B を共有 VPC ホスト プロジェクトとして構成し、プロジェクト A をサービス プロジェクトとして接続して、Secure Web Proxy インスタンスをホストするサブネットを共有します。共有 VPC を有効にしてサービス プロジェクトを接続するには、組織レベルまたはフォルダレベルで roles/compute.xpnAdmin が必要です。手順については、ダイレクト VPC 下り（外向き）を使用して共有 VPC ネットワークにトラフィックを送信すると共有 VPC をプロビジョニングするをご覧ください。

  2. プロジェクト B で、共有サブネットに対する roles/compute.networkUser をプロジェクト A の Cloud Run サービス エージェントに付与します。

    gcloud compute networks subnets add-iam-policy-binding SHARED_SUBNET_NAME \
   --project=PROJECT_B_ID \
   --region=REGION \
   --member="serviceAccount:service-PROJECT_A_NUMBER@serverless-robot-prod.iam.gserviceaccount.com" \
   --role="roles/compute.networkUser"

    次のように置き換えます。

    • SHARED_SUBNET_NAME: プロジェクト B の共有サブネットの名前。
    • PROJECT_B_ID: プロジェクト B（ゲートウェイと共有 VPC ホスト プロジェクト）のプロジェクト ID。
    • REGION: 共有サブネットのリージョン。
    • PROJECT_A_NUMBER: エージェント サービス プロジェクトであるプロジェクト A のプロジェクト番号。

  3. プロジェクト B の共有サブネットを指す Cloud Run エージェント サービスをプロジェクト A にデプロイします。

    gcloud beta run deploy SERVICE_NAME \
   --project=PROJECT_A_ID \
   --image=IMAGE_URL \
   --subnet=projects/PROJECT_B_ID/regions/REGION/subnetworks/SHARED_SUBNET_NAME \
   --vpc-egress=all \
   --functional-type=agent \
   --identity-type=agent-identity \
   --ambient-networking \
   --set-env-vars="GOOGLE_API_USE_CLIENT_CERTIFICATE=false,GOOGLE_API_USE_MTLS_ENDPOINT=never" \
   --region=REGION

    次のように置き換えます。

    • SERVICE_NAME: プロジェクト A の Cloud Run エージェント サービスの名前。
    • PROJECT_A_ID: エージェント サービス プロジェクトであるプロジェクト A のプロジェクト ID。
    • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG の形式です。

    サービスをデプロイしたら、Agent Gateway を信頼するように Cloud Run エージェントを構成するの手順に沿って、プロジェクト B の Secure Web Proxy インスタンスのルート CA 証明書を信頼するようにプロジェクト A のエージェントを構成します。

  4. プロジェクト A で、プロジェクト B の Secure Web Proxy ゲートウェイを参照する EgressRouting ポリシーを作成します。プロジェクト A に roles/networkservices.admin が必要です。

    gcloud alpha network-services egress-routings create my-central-egress-routing \
   --location=REGION \
   --project=PROJECT_A_ID \
   --gateway="//networkservices.googleapis.com/projects/PROJECT_B_ID/locations/REGION/gateways/CENTRAL_SWP_NAME" \
   --sources="workloadUri=//run.googleapis.com/projects/PROJECT_A_ID/locations/REGION/services/SERVICE_NAME"

    CENTRAL_SWP_NAME は、プロジェクト B の Secure Web Proxy ゲートウェイの名前に置き換えます。プロジェクト A のすべての Cloud Run サービスをプロジェクト B のゲートウェイ経由でルーティングするには、workloadUri を //run.googleapis.com/projects/PROJECT_A_ID または //run.googleapis.com/projects/PROJECT_A_NUMBER に設定します。

  5. プロジェクト A でプロジェクト間の EgressRouting リソースがアクティブであることを確認します。

    gcloud alpha network-services egress-routings describe my-central-egress-routing \
   --location=REGION \
   --project=PROJECT_A_ID

  6. Agent Gateway でポリシーを構成するの説明に従って、プロジェクト B の Agent Gateway リソースで一元化されたベースライン、IAP、Model Armor ポリシーを構成します。

    • ベースラインの下り（外向き）トラフィックと MCP トラフィックを許可するの手順に沿って、プロジェクト B の Agent Gateway リソースでベースライン MCP とモデル トラフィックを許可します。
    • プロジェクト A のエージェントがプロジェクト B に登録されている MCP サーバーを呼び出すことを認可するには、プロジェクト B で IAM 統合アクセス ポリシーを作成します。このポリシーの principals リストでプロジェクト A のプロジェクト番号 principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/run/projects/PROJECT_A_NUMBER/locations/REGION/services/SERVICE_NAME を参照し、ポリシーをプロジェクト B またはその Agent Gateway リソースにバインドして、プロジェクト B の IAP ExtensionBinding をアタッチします。
    • プロジェクト B に一元化された Model Armor ガードレールを適用するには、リージョン Model Armor テンプレートを作成し、プロジェクト B の Service Extensions サービス エージェントに必要なロールを付与して、プロジェクト B の Agent Gateway リソースに Model Armor ExtensionBinding をアタッチします。

ログとトレースを表示する

Agent Gateway を経由してルーティングされるアウトバウンド エージェント インタラクションは、ログと分散トレースを生成します。これにより、ポリシーに関する決定をモニタリングし、エージェントの動作をデバッグできます。

アウトバウンド リクエストが失敗するか、ゲートウェイをバイパスする場合は、Agent Gateway のトラブルシューティングをご覧ください。

サポートされるリージョン

Cloud Run の Agent Gateway は、次のリージョンで使用できます。

  • europe-west1
  • us-central1

制限事項

アンビエント ネットワーキングの制限事項と、Secure Web Proxy を Agent Gateway としてデプロイするの Secure Web Proxy に関する考慮事項に加えて、Cloud Run で Agent Gateway を使用する場合は、次の制限事項が適用されます。

  • TLS 検査を行う Secure Web Proxy インスタンスを介して *.mtls.googleapis.com エンドポイントと *.mtls.run.app エンドポイントにルーティングされたアウトバウンド エージェント リクエストは、503 エラーで失敗します。これは、Secure Web Proxy がクライアント証明書を転送せずに TLS セッションを終了して再開するためです。
  • 各リージョン セルフマネージド Agent Gateway は、registries リストで最大 1 つのリージョン Agent Registry をサポートします。
  • デフォルトでは、各プロジェクトはリージョンごとに最大 10 個のリージョン AgentGateway リソースと 10 個のリージョン EgressRouting リソースをサポートします。新しいプロジェクトは、リージョンごとに 2 つの上限で開始される場合があります。割り当ての増加をリクエストするには、アカウント チームにお問い合わせください。
  • CA Service プールまたはプライベート エンタープライズ PKI からルート証明書または下位証明書をエクスポートし、それを信頼するようにエージェント コンテナを構成する必要があります。

次のステップ