Agent Runtime トラフィックを Agent Gateway 経由で転送する

このページでは、Agent Gateway を介して Agent Runtime トラフィックをルーティングする方法について説明します。Agent Gateway は、Gemini Enterprise Agent Platform エコシステムのネットワーキングとセキュリティの中心的なコンポーネントです。ユーザーとエージェント間、エージェントとツール間、エージェント間のいずれのやり取りでも、安全でガバナンスが適用された接続を提供します。

始める前に

  • エージェント ランタイムへのエージェントのデプロイについてよくご確認ください。

  • Agent Gatewayについて学習する。Agent-to-Anywhere（下り（外向き））モードで Agent Gateway を使用すると、ツール、モデル、API、他のエージェントへの下り（外向き）トラフィックを含むすべての下り（外向き）通信を保護して制御できます。クライアントからエージェントへの（上り）モードでゲートウェイを使用して、エージェントにアクセスできるクライアントを制御します。ゲートウェイを使用すると、これらのインタラクションに適用する必要がある IAP ポリシーと Model Armor テンプレートを選択できます。

    単一の Runtime インスタンスは、Agent-to-Anywhere（下り）ゲートウェイと Client-to-Agent（上り）ゲートウェイの両方に同時にバインドできます。

  • Agent Gateway に関連付けられている Runtime デプロイに関連する制限事項を確認します。

Agent Runtime トラフィックを Agent Gateway 経由でルーティングする

Agent Runtime トラフィックを Agent Gateway 経由でルーティングする手順は次のとおりです。

  1. Agent Gateway を作成する

    エージェント ゲートウェイ リソースを作成し、必要に応じて認可ポリシーを関連付けます。ゲートウェイは、Agent-to-Anywhere（下り）モードまたは Client-to-Agent（上り）モードで作成できます。

    • クライアントからエージェントへの（上り）モードの場合、エージェントとゲートウェイは同じプロジェクトとリージョンに作成する必要があります。
    • Agent-to-Anywhere（下り）モードの場合、ゲートウェイはエージェントとは異なるプロジェクトに作成できますが、同じリージョンに作成する必要があります。関連付けられたエージェント レジストリの登録と IAM ポリシー バインディングは、エージェント ゲートウェイと同じプロジェクトで作成する必要があります。

    手順については、エージェント ゲートウェイを設定するをご覧ください。

    デプロイのニーズに合わせてゲートウェイが構成されていることを確認します。たとえば、エージェントで LLM へのアクセスが必要な場合は、このアクセスを許可するようにゲートウェイを構成して、Agent Runtime のデプロイの失敗を防ぎます。

  2. 省略可: プロジェクト間の下り（外向き）ゲートウェイ アクセスを構成する

    Agent-to-Anywhere（下り）ゲートウェイが Runtime エージェントとは異なるプロジェクトにある場合は、次の手順で Runtime サービス エージェントに下り（外向き）ゲートウェイ プロジェクトへのアクセス権を付与します。

    1. Agent Gateway プロジェクトにカスタム IAM ロールを作成します。

      gcloud iam roles create ar_agw_cross_project_sa \
  --project=AGENT_GATEWAY_PROJECT_ID \
  --title="Runtime Agent Gateway Cross-Project SA" \
  --description="Custom role for the cross-project service agent to access Agent Gateway" \
  --permissions="networkservices.agentGateways.get,networkservices.operations.get"

      AGENT_GATEWAY_PROJECT_ID は、Agent Gateway がデプロイされているプロジェクト ID に置き換えます。

    2. ゲートウェイ プロジェクトのカスタムロールを、エージェント プロジェクトのエージェント ランタイム サービス エージェントに割り当てます。

      gcloud projects add-iam-policy-binding AGENT_GATEWAY_PROJECT_ID \
  --member="serviceAccount:service-AGENT_RUNTIME_PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com" \
  --role="projects/AGENT_GATEWAY_PROJECT_ID/roles/ar_agw_cross_project_sa"

      AGENT_RUNTIME_PROJECT_NUMBER は、Runtime エージェントがデプロイされているプロジェクトのプロジェクト番号に置き換えます。

  3. Agent Gateway 経由でトラフィックをルーティングするようにエージェントを構成する

    新しいエージェントをデプロイするか、既存のエージェントを構成するかに応じて、次のいずれかのオプションを選択します。

    • 新しいエージェントの場合

      エージェントのデプロイ時にゲートウェイ リソースを指定します。たとえば、Agent Runtime にエージェントをデプロイするには、client.agent_engines.create を使用して local_agent オブジェクトとオプションの構成を渡します。

      このエージェントで Model Armor や Semantic Governance Policies などのゲートウェイを介したプラットフォーム機能を使用する場合は、この例に示すように、作成呼び出しで agent_gateway_config と identity_type=AGENT_IDENTITY の両方を設定します。identity_type=AGENT_IDENTITY がないと、Runtime インスタンスの effectiveIdentity はデフォルトの Vertex AI サービス アカウントにフォールバックし、Semantic Governance Policies はエージェントをポリシー作成セレクタから自動的に除外します。

      エージェントから任意の宛先へ

      remote_agent = client.agent_engines.create(
  agent=local_agent,
  config={
      "agent_gateway_config": {
        "agent_to_anywhere_config": {"agent_gateway": projects/AGENT_GATEWAY_PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME}
      },
      "identity_type": types.IdentityType.AGENT_IDENTITY,
      # Other optional configuration ...
      # "requirements": requirements,
      # "gcs_dir_name": gcs_dir_name,
      # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa
      "env_vars": {
        "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
      }
  },
)

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

      • AGENT_GATEWAY_PROJECT_ID: Agent Gateway がデプロイされているプロジェクト ID
      • REGION: エージェントとゲートウェイがデプロイされているリージョン
      • AGENT_GATEWAY_TO_ANYWHERE_NAME: エージェントから任意の宛先へ（外向き）モードで作成したエージェント ゲートウェイの名前

      クライアントからエージェントへ

      remote_agent = client.agent_engines.create(
  agent=local_agent,
  config={
      "agent_gateway_config": {
        "client_to_agent_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME}
      },
      "identity_type": types.IdentityType.AGENT_IDENTITY,
      # Other optional configuration ...
      # "requirements": requirements,
      # "gcs_dir_name": gcs_dir_name,
      # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa
      "env_vars": {
        "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
      }
  },
)

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

      • PROJECT_ID: エージェントとゲートウェイがデプロイされているプロジェクト ID
      • REGION: エージェントとゲートウェイがデプロイされているリージョン
      • AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: クライアントからエージェントへ（内向き）モードで作成したエージェント ゲートウェイの名前

    • 既存のエージェントの場合

      エージェントから任意の宛先へ

      次の REST API リクエストを使用して、既存のエージェントを上り（内向き）の Agent-to-Anywhere ゲートウェイに関連付けます。

      curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{
  "spec": {
    "deploymentSpec": {
      "agentGatewayConfig": {
        "agentToAnywhereConfig": {
          "agentGateway": "projects/AGENT_GATEWAY_PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME"
        }
      }
    }
  }
}' \
"https://REGION-aiplatform.googleapis.com/v1/projects/AGENT_RUNTIME_PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"

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

      • AGENT_GATEWAY_PROJECT_ID: ゲートウェイがデプロイされているプロジェクト ID
      • AGENT_RUNTIME_PROJECT_ID: エージェントがデプロイされているプロジェクト ID
      • REGION: エージェントとゲートウェイがデプロイされているリージョン
      • AGENT_GATEWAY_TO_ANYWHERE_NAME: Agent-to-Anywhere（外向き）モードで作成した Agent Gateway の名前
      • RESOURCE_ID: エージェントのリソース ID

      クライアントからエージェントへ

      次の REST API リクエストを使用して、既存のエージェントを上り（内向き）の Client-to-Agent ゲートウェイに関連付けます。

      curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{
  "spec": {
    "deploymentSpec": {
      "agentGatewayConfig": {
        "clientToAgentConfig": {
          "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME"
        }
      }
    }
  }
}' \
"https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"

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

      • PROJECT_ID: エージェントとゲートウェイがデプロイされているプロジェクト ID
      • REGION: エージェントとゲートウェイがデプロイされているリージョン
      • AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: クライアントから Agent Gateway へ（内向き）で作成した Agent Gateway の名前
      • RESOURCE_ID: エージェントのリソース ID

  4. エージェントを Agent Registry に登録する

    エージェントが、Agent Gateway と同じプロジェクトとリージョン内のエージェント レジストリ インスタンスに登録されていることを確認します。

    gcloud agent-registry services create RUNTIME_AGENT_SERVICE_NAME \
  --project=AGENT_GATEWAY_PROJECT_ID \
  --location=REGION \
  --display-name="RUNTIME_AGENT_DISPLAY_NAME" \
  --endpoint-spec-type=no-spec \
  --interfaces=url="https://REGION-aiplatform.mtls.googleapis.com/v1/projects/RUNTIME_AGENT_PROJECT_NUMBER/locations/REGION/reasoningEngines/ENGINE_ID",protocolBinding="jsonrpc" \
  --format="value(registryResource)"

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

    • RUNTIME_AGENT_SERVICE_NAME: レジストリ内のエージェント エントリに付ける名前
    • AGENT_GATEWAY_PROJECT_ID: ゲートウェイがデプロイされているプロジェクト ID
    • REGION: エージェントとゲートウェイがデプロイされているリージョン
    • RUNTIME_AGENT_DISPLAY_NAME: レジストリ内のエージェント エントリの人間が読める形式の表示名
    • RUNTIME_AGENT_PROJECT_NUMBER: Runtime エージェントがデプロイされているプロジェクトのプロジェクト番号
    • ENGINE_ID: エージェントのリソース ID

    詳細については、エージェントを登録するをご覧ください。

  5. エージェントとレジストリの IAM ポリシー バインディングを作成する

    この手順は、Agent Gateway と同じプロジェクトとリージョンで実行します。

    gcloud iap web add-iam-policy-binding \
  --resource-type=agent-registry \
  --endpoint=AGENT_ENDPOINT_ID \
  --region=REGION \
  --project=AGENT_GATEWAY_PROJECT_ID \
  --member=MEMBER \
  --role=roles/iap.egressor

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

    • AGENT_ENDPOINT_ID: 登録済みエージェントのサービス エンドポイント ID。これは、前の手順の出力から取得します。

    • MEMBER: ロールを付与するエージェント ID プリンシパル。通常、形式は principal://TRUST_DOMAIN/resources/aiplatform/projects/PROJECT_ID/locations/REGION/reasoningEngines/ENGINE_ID です。

  6. ランタイム オペレーションに必要な API を許可リストに登録する

    この時点で、エージェント トラフィックは Agent Gateway 経由で転送されるようになります。ただし、Agent Gateway はデフォルトで拒否するポリシーを採用しています。特定の Agent Platform 関数を有効にするには、エージェントが次のエンドポイントと通信できることを確認する必要があります。

    • エージェント、MCP サーバー、エンドポイントの自動検出を有効にするには、Agent Gateway でエンドポイント https://agentregistry.googleapis.com/ へのトラフィックを許可する必要があります。

    • Cloud Trace が有効になっている場合、エージェント ゲートウェイはエンドポイント https://telemetry.googleapis.com/ へのトラフィックを許可する必要があります。

      GOOGLE_API_USE_CLIENT_CERTIFICATE 環境変数と GOOGLE_API_USE_MTLS_ENDPOINT 環境変数が設定されている場合は、https://telemetry.mtls.googleapis.com/ へのトラフィックも許可されていることを確認します。

    • Cloud Logging が有効になっている場合、Agent Gateway はエンドポイント https://logging.googleapis.com/ へのトラフィックを許可する必要があります。

      GOOGLE_API_USE_CLIENT_CERTIFICATE 環境変数と GOOGLE_API_USE_MTLS_ENDPOINT 環境変数が設定されている場合は、https://logging.mtls.googleapis.com/ へのトラフィックも許可されていることを確認します。

    また、エージェントが LLM を呼び出している場合や、セッションやメモリバンクなどの機能を使用している場合は、エージェントがこれらのサービスで使用されているエンドポイントと通信できることを確認する必要があります。次に例を示します。

    • セッションの場合: https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/sessions
    • メモリバンクの場合: https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/memories

    セキュリティ上の理由から、エージェントがアクセスする特定の URI のみを登録して許可リストに登録することをおすすめします。ゲートウェイはホスト名を直接照合するため、エージェント SDK が使用するすべてのバリアントを登録する必要があります。たとえば、SDK のバージョン、リージョン クライアントの構成、mTLS の使用状況に応じて、Google API は次のエンドポイント ホスト名を介して解決できます。

    • https://REGION-aiplatform.googleapis.com
    • https://REGION-aiplatform.mtls.googleapis.com
    • https://aiplatform.REGION.rep.googleapis.com

    エンドポイントを登録する方法については、エンドポイントを登録するをご覧ください。また、エージェントにこれらのエンドポイントの IAP 下り（外向き）ロールがあることを確認する必要があります。手順については、エージェントからエンドポイントへの下り（外向き）ポリシーを作成するをご覧ください。

  7. エージェントの構成を確認する

    コンソール

    1. Google Cloud コンソールで、Agent Platform の [デプロイ] ページに移動します。

      [デプロイメント] に移動

    2. デプロイしたエージェントの名前をクリックします。

    3. [サービス構成] をクリックします。エージェントの [オブザーバビリティ] ペインが開きます。

    4. [デプロイの詳細] をクリックします。Agent Gateway の上り（内向き）と下り（外向き）の構成は、[Deployment spec] フィールドで確認できます。

    gcloud

    次の REST API リクエストを使用して、エージェントがゲートウェイに関連付けられていることを確認します。返された出力が null の場合、Runtime がゲートウェイへのバインドに失敗したことを意味します。

    curl -s -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://REGION-aiplatform.googleapis.com/v1/projects/AGENT_RUNTIME_PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID" \
  | jq '.spec.deploymentSpec.agentGatewayConfig'

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

    • AGENT_RUNTIME_PROJECT_ID: プロジェクト ID
    • REGION: エージェントがデプロイされているリージョン
    • RESOURCE_ID: エージェントのリソース ID

Agent Gateway 用にカスタム コンテナ（BYOC）エージェントを構成する

カスタム コンテナ イメージ（Bring Your Own Container / BYOC）でデプロイされたエージェントのアウトバウンド トラフィックを Agent-to-Anywhere（下り（外向き））Agent Gateway 経由で転送する場合は、ゲートウェイのルート認証局（CA）証明書をカスタム コンテナ イメージのトラストストアにベイクする必要があります。

Agent Gateway はアウトバウンド エージェント通信で TLS の復号と検査を行うため、非 BYOC（ソースベース）のエージェント デプロイでは、イメージの作成時に CA の証明書が自動的に挿入されます。カスタム コンテナ イメージの場合は、ゲートウェイの CA 証明書を明示的に取得し、Dockerfile 内のシステム CA トラストストアにインストールして、Python SDK、HTTP クライアント ライブラリ、gRPC で必要な証明書バンドル環境変数を設定する必要があります。

Agent Gateway の下り（外向き）用に BYOC コンテナ イメージを構成する手順は次のとおりです。

  1. Agent Gateway リソースからルート証明書を取得します。

    Agent Gateway リソースの agentGatewayCard.rootCertificates フィールドから CA ルート証明書の PEM 文字列を直接エクスポートします。

    export AGW_CERT=$(gcloud network-services agent-gateways describe AGENT_GATEWAY_NAME \
   --location=REGION \
   --project=PROJECT_ID \
   --format="value[delimiter=\\n](agentGatewayCard.rootCertificates)")

    また、REST API を使用してゲートウェイ リソースを取得することもできます。

    curl -s -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://networkservices.googleapis.com/v1/projects/AGENT_GATEWAY_PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME" \
   | jq -r '.agentGatewayCard.rootCertificates[]'

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

    • AGENT_GATEWAY_NAME: 下り（外向き）Agent Gateway の名前
    • REGION: ゲートウェイがデプロイされているリージョン
    • AGENT_GATEWAY_PROJECT_ID: ゲートウェイがデプロイされているプロジェクト ID

  2. CA 証明書を信頼するように Dockerfile を更新します。

    Dockerfile に AGENT_GATEWAY_ROOT_CERTIFICATES ビルド引数を追加します。ビルドコマンドは、証明書を個別のファイルに分割し、update-ca-certificates を使用してインストールし、OpenSSL、Python HTTP クライアント ライブラリ（requests、httpx）、gRPC がカスタム CA を認識するように環境変数を設定します。

    # Install root certificates under root user
USER root

ARG AGENT_GATEWAY_ROOT_CERTIFICATES
RUN if [ -n "$AGENT_GATEWAY_ROOT_CERTIFICATES" ]; then \
     echo "Installing Agent Gateway root certificates..."; \
     printf "%b" "$AGENT_GATEWAY_ROOT_CERTIFICATES" | awk 'BEGIN {c=0} /BEGIN CERTIFICATE/ {c++} c > 0 { print > "/usr/local/share/ca-certificates/agw-" c ".crt" }'; \
     update-ca-certificates; \
   fi

# Configure SSL/TLS trust paths for Python HTTP libraries, OpenSSL, and gRPC
ENV GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
ENV REQUESTS_CA_BUNDLE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
ENV SSL_CERT_FILE=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}
ENV AGENT_GATEWAY_ROOT_CERT_302034098528=${AGENT_GATEWAY_ROOT_CERTIFICATES:+/etc/ssl/certs/ca-certificates.crt}

# Switch back to application execution user
USER 1000

  3. Cloud Build を使用してコンテナ イメージをビルドします。

    置換を使用してルート証明書文字列を Cloud Build に渡す cloudbuild.yaml ファイルを作成します。

    steps:
- name: 'gcr.io/cloud-builders/docker'
  args:
  - 'build'
  - '--build-arg'
  - 'AGENT_GATEWAY_ROOT_CERTIFICATES=${_AGW_CERT}'
  - '-t'
  - '$_IMAGE_URI'
  - '.'

images:
- '$_IMAGE_URI'

    コンテナ イメージのビルドを Cloud Build に送信します。

    export IMAGE_URI="REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME:latest"

gcloud builds submit \
   --project=PROJECT_ID \
   --region=REGION \
   --config=cloudbuild.yaml \
   --substitutions=_IMAGE_URI="$IMAGE_URI",_AGW_CERT="$AGW_CERT" \
   .

    REPOSITORY_NAME と IMAGE_NAME は、Artifact Registry のリポジトリ名とイメージ名に置き換えます。

  4. コンテナ化されたエージェントをデプロイします。

    デプロイ リクエストで、ビルドされたコンテナ イメージの URI と Agent Gateway 構成を指定します（spec.deploymentSpec の agent_gateway_config を使用するか、SDK デプロイ呼び出しを使用します）。

Agent Runtime を承認済みの Agent Gateway に制限する

カスタムの組織ポリシーの制約を作成して、エージェントのデプロイ時に使用できる対象となる Agent Gateway リソースのセットを定義できます。

カスタムの組織のポリシー制約を作成する

この例では、事前承認済みのゲートウェイのリストとの間のトラフィックのみを許可するカスタム制約を作成します。

エージェントから任意の宛先へ

  1. Agent-to-Anywhere モード（下り）のカスタム制約を定義するには、constraint-agent-gateway-egress.yaml という名前のファイルを作成します。

    次の例では、condition フィールドは、Agent Gateway リソースが指定されている（フィールドが存在し、空ではない）場合、および指定されたゲートウェイが事前承認済みリストにある場合にのみ、オペレーションが許可されることを指定しています。

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedEgressAgentGatewaysForAgentEngine
resource_types:
- aiplatform.googleapis.com/ReasoningEngine
condition: >-
has(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway) &&
resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway != '' &&
(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway in [
  'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
  'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
])
method_types:
- CREATE
- UPDATE
action_type: ALLOW
display_name: Restrict Reasoning Engine Egress to Approved Agent Gateways
description: Reasoning Engines can only be bound to a pre-approved list of
Agent Gateway instances. Binding to any other gateway is denied.

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

    • ORGANIZATION_ID: 組織 ID。
    • AGENT_PROJECT_ID: プロジェクト ID。
    • REGION: ゲートウェイが作成されたリージョン。
    • AGENT_GATEWAY_ID: ゲートウェイ ID。

  2. カスタム制約を適用します。

    gcloud org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH

    EGRESS_CONSTRAINT_PATH は、前の手順で作成したカスタム制約ファイルのフルパスに置き換えます。

  3. 制約を適用する組織のポリシーを作成します。組織のポリシーを定義するには、policy-agent-gateway-egress.yaml という名前のポリシー YAML ファイルを作成します。この例では、この制約をプロジェクト レベルで適用しますが、組織レベルまたはフォルダレベルで設定することもできます。

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine
spec:
  rules:
  - enforce: true

    AGENT_PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  4. 組織のポリシーを適用します。

    gcloud org-policies set-policy EGRESS_POLICY_PATH

    EGRESS_POLICY_PATH は、前の手順で作成した組織のポリシーの YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

クライアントからエージェントへ

  1. クライアントからエージェントへのモード（上り（内向き））のカスタム制約を定義するには、constraint-agent-gateway-ingress.yaml という名前のファイルを作成します。

    次の例では、condition フィールドは、Agent Gateway リソースが指定されている（フィールドが存在し、空ではない）場合、および指定されたゲートウェイが事前承認済みリストにある場合にのみ、オペレーションが許可されることを指定しています。

    name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedIngressAgentGatewaysForAgentEngine
resource_types:
- aiplatform.googleapis.com/ReasoningEngine
condition: >-
has(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway) &&
resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway != '' &&
(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway in [
  'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1',
  'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2',
])
method_types:
- CREATE
- UPDATE
action_type: ALLOW
display_name: Restrict Reasoning Engine Ingress to Approved Agent Gateways
description: Reasoning Engines can only be bound to a pre-approved list of
Agent Gateway instances. Binding to any other gateway is denied.

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

    • ORGANIZATION_ID: 組織 ID。
    • AGENT_PROJECT_ID: プロジェクト ID。
    • REGION: ゲートウェイが作成されたリージョン。
    • AGENT_GATEWAY_ID: ゲートウェイ ID。

  2. カスタム制約を適用します。

    gcloud org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH

    INGRESS_CONSTRAINT_PATH は、前の手順で作成したカスタム制約ファイルのフルパスに置き換えます。

  3. 制約を適用する組織のポリシーを作成します。組織のポリシーを定義するには、policy-agent-gateway-ingress.yaml という名前のポリシー YAML ファイルを作成します。この例では、この制約をプロジェクト レベルで適用しますが、組織レベルまたはフォルダレベルで設定することもできます。

    name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine
spec:
  rules:
  - enforce: true

    AGENT_PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  4. 組織のポリシーを適用します。

    gcloud org-policies set-policy INGRESS_POLICY_PATH

    INGRESS_POLICY_PATH は、前の手順で作成した組織のポリシーの YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

カスタムの組織のポリシー制約の使用方法については、カスタム制約を作成するをご覧ください。

制限事項

  • プロジェクト間のガバナンスには次の制限があります。

    • エージェントと Gateway 間のプロジェクト間のバインディングは、エージェントから Anywhere（下り（外向き））モードでのみサポートされます。クライアントからエージェントへの（上り）モードでは、エージェントとエージェント ゲートウェイが同じプロジェクトに存在する必要があります。
    • エンドツーエンドのクロス プロジェクト ガバナンスを構成するには、REST API または gcloud を使用する必要があります。 Google Cloud Google Cloud コンソールでは、プロジェクト間の IAM ポリシー バインディングやエージェント レジストリ エントリの作成はサポートされていません。

  • Agent Gateway を 2026 年 4 月 29 日より前に作成された Runtime Reasoning Engine にバインドすることはできません。

  • 単一のプロジェクトとリージョンで複数の Agent-to-Anywhere（下り（外向き））と Client-to-Agent（上り（内向き））の Agent Gateway インスタンスをホストできますが、同じプロジェクトとリージョン内にデプロイされたすべての Agent Runtime エージェントは、同じ特定の下り（外向き）と上り（内向き）の Agent Gateway インスタンスにバインドする必要があります。

    たとえば、プロジェクトとリージョンに egress-gateway-X と egress-gateway-Y が含まれている場合、そのプロジェクトとリージョンのすべてのエージェントは、下り（外向き）に同じゲートウェイを使用するように構成する必要があります。つまり、すべてのエージェントが egress-gateway-X を使用するか、すべてのエージェントが egress-gateway-Y を使用します。egress-gateway-X を使用するように agent-A を構成したり、egress-gateway-Y を使用するように agent-B を構成したりすることはできません。

    このバインディング ルールは、プロジェクトとリージョン内の上り（内向き）ゲートウェイにも適用されます。

  • エージェントで Agent Gateway が有効になっている場合、Security Command Center Agent Engine Threat Detection サービスは使用できません。

  • クライアントからエージェントへの（内向き）モードでは、エージェント ゲートウェイはエージェント ランタイムの query メソッドと streamQuery メソッドのみを制御できます。サポートされていない他のメソッド（asyncQuery など）を保護するには、アプリケーションまたはエージェントから Model Armor テンプレートを直接適用します。プロンプトとレスポンスをサニタイズするまたは Model Armor を使用して安全なエージェント システムを構築するに関するこちらの Codelab をご覧ください。

  • エージェント ゲートウェイでは VPC Service Controls はサポートされていません。

  • Agent Gateway は、リビジョンを使用している Agent Runtime エージェントではサポートされていません。Agent Gateway がエージェントの構成に関連付けられている場合、トラフィック分割構成やリビジョンごとのクエリなどのバージョン管理関連機能は使用できません。

    推論エンジン ID を変更したり、ポリシー バインディングを解除したりせずにエージェントを更新するには、Agent Runtime インスタンスの更新の説明に従って、エージェント インスタンスをインプレースで更新します。

次のステップ

Codelab

Gemini Enterprise Agent Platform の Agent Gateway を使用してエージェント ワークロードを管理する方法について説明します。

ガイド

Agent Gateway の認可を IAP、Model Armor、または独自のカスタム認可サービスに委任する方法について説明します。

ガイド

Agent Gateway をモニタリングする方法について説明します。

トラブルシューティング

Agent Gateway の接続に関する問題のトラブルシューティング方法について説明します。