このページでは、Agent Runtime トラフィックを Agent Gateway 経由で転送する方法について説明します。Agent Gateway は、Gemini Enterprise Agent Platform エコシステムのネットワーキングとセキュリティの中心的なコンポーネントです。ユーザーとエージェント間、エージェントとツール間、エージェント間のすべてのエージェント操作に対して、安全で管理された接続を提供します。
始める前に
エージェント ランタイムへのエージェントのデプロイについてよくご確認ください。
エージェント ゲートウェイについて学習する。エージェントから任意の場所への（下り）モードで Agent Gateway を使用すると、ツール、モデル、API、他のエージェントへの下りトラフィックを含むすべての送信通信を保護して制御できます。クライアントからエージェントへの（上り）モードでゲートウェイを使用して、エージェントにアクセスできるクライアントを制御します。ゲートウェイを使用すると、これらのインタラクションに適用する必要がある IAP ポリシーと Model Armor テンプレートを選択できます。
このワークフローを試すには、専用のテスト プロジェクトを作成します。他の重要なワークロードにも使用する予定のプロジェクトは使用しないでください。
制限事項
単一のプロジェクトとリージョンで複数の 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 サービスは使用できません。
Runtime エージェントを Agent Gateway リソースからバインド解除することはできません。そのため、専用のテスト プロジェクトを使用してください。
Agent Runtime トラフィックを Agent Gateway 経由で転送する
Agent Runtime トラフィックを Agent Gateway 経由でルーティングする手順は次のとおりです。
エージェント ゲートウェイ リソースを作成し、必要に応じて認可ポリシーを関連付けます。ゲートウェイは、Agent-to-Anywhere（下り）モードまたは Client-to-Agent（上り）モードで作成できます。エージェントとゲートウェイは同じプロジェクトとリージョンに作成する必要があります。手順については、エージェント ゲートウェイを設定するをご覧ください。
デプロイのニーズに合わせてゲートウェイが構成されていることを確認します。たとえば、エージェントで LLM へのアクセスが必要な場合は、このアクセスを許可するようにゲートウェイを構成して、エージェント ランタイムのデプロイの失敗を防ぎます。
エージェントのデプロイ時にゲートウェイ リソースを指定します。たとえば、Agent Runtime にエージェントをデプロイするには、
client.agent_engines.createを使用して、local_agentオブジェクトとオプションの構成を渡します。また、この例に示すように
identity_typeパラメータを使用して、Runtime インスタンスにエージェント ID が割り当てられていることを確認する必要があります。remote_agent = client.agent_engines.create( agent=local_agent, config={ "agent_gateway_config": { "agent_to_anywhere_config": {"agent_gateway": AGENT_GATEWAY_TO_ANYWHERE_NAME}, # "client_to_agent_config": {"agent_gateway": 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（下り）モードで作成したエージェント ゲートウェイの完全パスに置き換えます。例:projects/PROJECT/locations/REGION/agentGateways/AGENT_GATEWAY_IDクライアントからエージェント（上り）モードでゲートウェイを作成した場合は、代わりに
client_to_agent_configフィールドを使用し、AGENT_GATEWAY_CLIENT_TO_AGENT_NAMEを上り用に作成したエージェント ゲートウェイのフルパスに置き換えます。エージェントとゲートウェイと同じプロジェクトとリージョンにある Agent Registry インスタンスにエージェントを登録します。詳細については、エージェントを登録するをご覧ください。
Agent Runtime を承認済みの Agent Gateway に制限する
カスタムの組織のポリシーの制約を作成して、エージェントのデプロイ時に使用できる対象となるエージェント ゲートウェイ リソースのセットを定義できます。
カスタムの組織のポリシー制約を作成する
この例では、事前承認済みのゲートウェイのリストとの間のトラフィックのみを許可するカスタム制約を作成します。
エージェントから任意の宛先へ
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 alpha 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: trueAGENT_PROJECT_IDは、実際のプロジェクト ID に置き換えます。組織のポリシーを適用します。
gcloud alpha org-policies set-policy EGRESS_POLICY_PATH
EGRESS_POLICY_PATH は、前の手順で作成した組織のポリシーの YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。
クライアントからエージェントへ
クライアントからエージェントへのモード（上り（内向き））のカスタム制約を定義するには、
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。
カスタム制約を適用します。
gcloud alpha 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: trueAGENT_PROJECT_IDは、実際のプロジェクト ID に置き換えます。組織のポリシーを適用します。
gcloud alpha org-policies set-policy INGRESS_POLICY_PATH
INGRESS_POLICY_PATH は、前の手順で作成した組織のポリシーの YAML ファイルのフルパスに置き換えます。ポリシーが有効になるまでに最大 15 分かかります。
カスタムの組織のポリシー制約の使用方法については、カスタム制約を作成するをご覧ください。
次のステップ
Codelab: Agent Platform でエージェント ワークロードを管理する
Gemini Enterprise Agent Platform の Agent Gateway を使用してエージェント ワークロードを管理する方法について説明します。