Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

始める前に

Agent Runtime にエージェントをデプロイする方法を理解しておいてください。
Agent Gateway について学習します。 . Agent Gateway を Agent-to-Anywhere（下り）モードで使用すると、ツール、モデル、API、他のエージェントへの下りトラフィックを含む、すべてのアウトバウンド通信を保護し、管理できます。Client-to-Agent（上り）モードでゲートウェイを使用すると、エージェントにアクセスできるクライアントを制御できます。ゲートウェイを使用すると、これらのやり取りに適用する必要がある IAP ポリシーと Model Armor テンプレートを選択できます。

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

制限事項

Agent Gateway は、2026 年 4 月 29 日より前に作成された Runtime 推論エンジンにバインドできません。
1 つのプロジェクトとリージョンで複数の Agent-to-Anywhere（下り）と Client-to-Agent（上り）の Agent Gateway インスタンスをホストできますが、同じプロジェクトとリージョン内にデプロイされたすべての Agent Runtime エージェントは、同じ特定の下りおよび上りの Agent Gateway インスタンスにバインドする必要があります。

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

この同じバインディングルールは、プロジェクトとリージョン内の上りゲートウェイにも適用されます。
エージェントで Agent Gateway が有効になっている場合、Security Command Center Agent Engine Threat Detection サービスは使用できません。
Client-to-Agent（上り）モードでは、Agent Gateway は Agent Runtime の query メソッドと streamQuery メソッドのみを管理できます。サポートされていない他のメソッド（asyncQuery など）を保護するには、アプリケーションまたはエージェントから Model Armor テンプレートを直接適用します。プロンプトとレスポンスのサニタイズまたは Model Armor を使用して安全なエージェントシステムを構築するの Codelab をご覧ください。
VPC Service Controls は Agent Gateway ではサポートされていません。

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

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

Agent Gateway リソースを作成し、必要に応じて承認ポリシーをアタッチします。ゲートウェイは、Agent-to-Anywhere（下り）モードまたは Client-to-Agent（上り）モードで作成できます。エージェントとゲートウェイは、同じプロジェクトとリージョンに作成する必要があります。手順については、Agent Gateway を設定するをご覧ください。

ゲートウェイがデプロイのニーズを満たすように構成されていることを確認します。たとえば、エージェントに LLM アクセスが必要な場合は、このアクセスを許可するようにゲートウェイを構成して、Agent Runtime のデプロイが失敗する可能性を防ぎます。
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/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME},
        # "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,
      }
  },
)
```
  AGENT_GATEWAY_TO_ANYWHERE_NAME は、Agent-to-Anywhere（下り）モードで作成した Agent Gateway の名前に置き換えます。
  
  Client-to-Agent（上り）モードでゲートウェイを作成した場合は、代わりに client_to_agent_config フィールドを使用し、AGENT_GATEWAY_CLIENT_TO_AGENT_NAME を上り用に作成した Agent Gateway の名前に置き換えます。
- 既存のエージェントの場合
  
  注: 既存の推論エンジンを更新して agentGatewayConfig を設定しても、変更されません。identity_typeエンジンが最初に identity_type=AGENT_IDENTITYなしで作成された場合、パッチを適用しても Semantic Governance Policies の対象にすることはできません。エージェントの作成時に agent_gateway_config と identity_type=AGENT_IDENTITY の両方を設定して、新しい推論エンジンを再デプロイする必要があります。
  Agent-to-Anywhere
  次の 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/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME" } } } } }' \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"
  
  次のように置き換えます。
  
  PROJECT_ID: プロジェクト ID
  
  REGION: エージェントがデプロイされているリージョン
  
  AGENT_GATEWAY_TO_ANYWHERE_NAME: Agent-to-Anywhere（下り）モードで作成した Agent Gateway の名前
  
  RESOURCE_ID: エージェントのリソース ID
  Client-to-Agent
  次の 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/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"
  
  次のように置き換えます。
  
  PROJECT_ID: プロジェクト ID
  
  REGION: エージェントがデプロイされているリージョン
  
  AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: Client-to-Agent（上り）で作成した Agent Gateway の名前
  
  RESOURCE_ID: エージェントのリソース ID
エージェントとゲートウェイと同じプロジェクトとリージョンにある Agent Registry インスタンスに登録します。
```
gcloud agent-registry services create SERVICE_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --display-name="DISPLAY_NAME" \
  --endpoint-spec-type=no-spec \
  --interfaces='[{url="https://REGION-aiplatform.mtls.googleapis.com",protocolBinding="jsonrpc"}]' \
  --format="value(registryResource)"
```
次のように置き換えます。
- SERVICE_NAME: リソースに付ける名前（allow-aiplatform-region-eu3 など）。
- PROJECT_ID: プロジェクト ID。
- REGION: レジストリリージョン。
- DISPLAY_NAME: エンドポイントの人間が読める名前。
詳細については、エージェントを登録するをご覧ください。
エージェントの Agent-to-Registry IAM ポリシーバインディングを作成します。
```
gcloud iap web add-iam-policy-binding \
  --resource-type=agent-registry \
  --endpoint=ENDPOINT_ID \
  --region=REGION \
  --project=PROJECT_ID \
  --member=MEMBER \
  --role=roles/iap.egressor
```
次のように置き換えます。
- ENDPOINT_ID: 登録済みエージェントのサービスエンドポイント ID。これは、前の手順の出力から取得します。
- MEMBER: ロールを付与するエージェント ID プリンシパル。通常、形式は: principal://TRUST_DOMAIN/resources/aiplatform/projects/PROJECT_ID/locations/REGION/reasoningEngines/ENGINE_ID です。
  
  注: プロジェクト内のすべてのエージェントをレジストリにバインドする場合（すべての Runtime エージェント、Gemini Enterprise エージェント、今後作成されるその他のエージェントを含む）、IAM ポリシーを principal://TRUST_DOMAIN/attribute.container/projects/PROJECT_ID にバインドできます。
この時点で、エージェントトラフィックは Agent Gateway 経由で転送されます。ただし、Agent Gateway はデフォルトで拒否ポリシーを採用しています。特定の Agent Platform 機能を有効にするには、エージェントが次のエンドポイントと通信できることを確認する必要があります。
- Cloud Trace が有効になっている場合、Agent Gateway はエンドポイント 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
注意: ベース URI（ https://REGION-aiplatform.googleapis.com/ など）を登録すると便利ですが、これにより、エージェントがそのドメインのすべてのサービスにアクセスできる広範なアクセスポリシーが提供されます。ベース URI を登録した場合でも、そのリージョンバリアントと mTLS バリアントをすべて登録する必要があります。

エンドポイントを登録する方法については、エンドポイントを登録するをご覧ください。また、エージェントにこれらのエンドポイントの IAP Egressor ロールがあることを確認する必要があります。手順については、エージェントからエンドポイントへの下りポリシーを作成するをご覧ください。
エージェントの構成を確認します。
コンソール
1. コンソールで、Agent Platform の [デプロイ] ページに移動します。 Google Cloud
  [デプロイ] に移動
2. デプロイしたエージェントの名前をクリックします。
3. [サービス構成] をクリックします。エージェントの [オブザーバビリティ] ペインが開きます。
4. [デプロイの詳細] をクリックします。Agent Gateway の上り構成と下り構成は、[デプロイ仕様] フィールドにあります。
gcloud
次の REST API リクエストを使用して、エージェントがゲートウェイに関連付けられていることを確認します。返された出力が null の場合、Runtime はゲートウェイにバインドできませんでした。
curl -s -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID" \ | jq '.spec.deploymentSpec.agentGatewayConfig'
次のように置き換えます。
- 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 コンテナイメージを構成する手順は次のとおりです。

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

CA ルート証明書の PEM 文字列を Agent Gateway リソースの agentGatewayCard.rootCertificates フィールドから直接エクスポートします。
```
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/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME" \
   | jq -r '.agentGatewayCard.rootCertificates[]'
```
次のように置き換えます。
- AGENT_GATEWAY_NAME: 下り Agent Gateway の名前
- REGION: ゲートウェイがデプロイされているリージョン
- PROJECT_ID: プロジェクト ID
CA 証明書を信頼するように Dockerfile を更新します。

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

注: 次の例では、Debian または Ubuntu ベースのコンテナイメージを想定しています。別の Linux ディストリビューション（RHEL、CentOS、Alpine など）を使用している場合、CA ストアを更新するコマンド（update-ca-certificates と update-ca-trust など）、証明書ファイルのディレクトリ、システム証明書バンドルのパスが異なる場合があります。これらのコマンドとパスは、ディストリビューションのドキュメントに従って調整してください。
```
# 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
```

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

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

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 のリポジトリ名とイメージ名に置き換えます。

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

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

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

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

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

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

Agent-to-Anywhere

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。

カスタム制約を適用します。
```
gcloud org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH
```
EGRESS_CONSTRAINT_PATH は、前の手順で作成したカスタム制約ファイルのフルパスに置き換えます。
制約を適用する組織のポリシーを作成します。組織のポリシーを定義するには、policy-agent-gateway-egress.yaml という名前のポリシー YAML ファイルを作成します。この例では、この制約をプロジェクトレベルで適用しますが、組織レベルまたはフォルダレベルで設定することもできます。
```
name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine
spec:
  rules:
  - enforce: true
```
AGENT_PROJECT_ID は、実際のプロジェクト ID に置き換えます。
組織のポリシーを適用します。
```
gcloud org-policies set-policy EGRESS_POLICY_PATH
```
EGRESS_POLICY_PATH は、前の手順で作成した組織のポリシー YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

Client-to-Agent

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

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。

カスタム制約を適用します。
```
gcloud org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH
```
INGRESS_CONSTRAINT_PATH は、前の手順で作成したカスタム制約ファイルのフルパスに置き換えます。
制約を適用する組織のポリシーを作成します。組織のポリシーを定義するには、policy-agent-gateway-ingress.yaml という名前のポリシー YAML ファイルを作成します。この例では、この制約をプロジェクトレベルで適用しますが、組織レベルまたはフォルダレベルで設定することもできます。
```
name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine
spec:
  rules:
  - enforce: true
```
AGENT_PROJECT_ID は、実際のプロジェクト ID に置き換えます。
組織のポリシーを適用します。
```
gcloud org-policies set-policy INGRESS_POLICY_PATH
```
INGRESS_POLICY_PATH は、前の手順で作成した組織のポリシー YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。

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

次のステップ

Codelab

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

始める前に

制限事項

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

Agent-to-Anywhere

Client-to-Agent

コンソール

gcloud

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

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

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

Agent-to-Anywhere

Client-to-Agent

次のステップ

Codelab: Agent Platform でエージェントワークロードを管理する

Agent Gateway の承認を委任する

Agent Gateway をモニタリングする

Agent Gateway のトラブルシューティング

Agent Runtime トラフィックを Agent Gateway 経由で転送する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

制限事項

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

Agent-to-Anywhere

Client-to-Agent

コンソール

gcloud

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

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

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

Agent-to-Anywhere

Client-to-Agent

次のステップ

Codelab: Agent Platform でエージェント ワークロードを管理する

Agent Gateway の承認を委任する

Agent Gateway をモニタリングする

Agent Gateway のトラブルシューティング

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

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

Codelab: Agent Platform でエージェントワークロードを管理する