VPC 接続を使用して Agent Gateway を設定する

このドキュメントでは、Agent Gateway をデプロイするときに VPC 接続を構成して、組織内の VPC ネットワークとプライベートに通信できるようにするプロセスについて説明します。

VPC 接続を設定すると、次のことができます。

  • トラフィックに VPC 下り（外向き）を適用する: PRIVATE_RANGES_ONLY モードまたは ALL_TRAFFIC モードを使用して、エージェントから発信されたトラフィックを Private Service Connect ネットワーク アタッチメント経由で VPC ネットワークに転送します。
  • 静的送信元 IP アドレス範囲: 下り（外向き）トラフィックは、Private Service Connect ネットワーク アタッチメント サブネットのプライベート IP アドレス範囲を送信元 IP アドレスとして使用します。この静的送信元 IP 範囲を使用すると、ゲートウェイからのトラフィックを制御するように VPC ネットワークのファイアウォール ポリシーを構成できます。
  • カスタム DNS の解決: Cloud DNS ピアリングを使用して、エージェントから内部プライベート ドメイン名と外部ドメイン名を直接解決します。
  • 境界セキュリティ: VPC Service Controls のサービス境界を使用して、エージェント通信を保護します。
  • プライベート証明書または自己署名証明書の検証: プライベート CA または自己署名証明書を使用する宛先に接続します。

VPC 接続を構成するには、Agent Gateway 接続テンプレート（AgentConnectivityTemplate）を作成します。ここで、Agent Gateway インスタンスの下り（外向き）ネットワーク設定を定義して管理します。

VPC 接続の仕組み

接続テンプレートを使用して Agent Gateway をデプロイすると、ゲートウェイは Private Service Connect インターフェースを使用して、アウトバウンド エージェント トラフィックを指定された VPC ネットワークに転送します。

VPC 下り（外向き）モード

接続テンプレートの vpcEgress 設定を使用して、ゲートウェイがネットワーク アタッチメントを介してトラフィックをルーティングする方法を構成します。

  • プライベート IP アドレス範囲（PRIVATE_RANGES_ONLY）へのトラフィック: プライベート IP アドレス範囲宛てのトラフィックのみを VPC ネットワークに転送します。宛先 IP アドレスが次のいずれかの範囲に該当する場合にのみ、アウトバウンド トラフィックが VPC ネットワークに転送されます。

    • RFC 1918: 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
    • RFC 6598: 100.64.0.0/10
    • クラス E: 240.0.0.0/4
    • private.googleapis.com: 199.36.153.8/30
    • restricted.googleapis.com: 199.36.153.4/30
    • Google API 用の PSC エンドポイント: VPC ネットワーク内の内部プライベート IP アドレスを使用して Google API 用のカスタム Private Service Connect エンドポイントをデプロイすると、このエンドポイントへのトラフィックは VPC ネットワーク経由で転送されます。Agent Gateway が Google API ドメインを内部 PSC エンドポイントの IP アドレスに正しく解決するように、接続テンプレートで Cloud DNS ピアリングが構成されていることを確認します。

    標準の一般公開 Google API へのリクエストは、プライベート Google アクセスを使用して自動的に処理されます。インターネット宛てのトラフィックは、VPC ネットワークではなく、Agent Gateway を介して直接ルーティングされます。

  • すべての IP アドレス範囲（ALL_TRAFFIC）へのトラフィック: エージェントから発信されるすべての送信トラフィックを、パブリック インターネット、外部 SaaS API、RFC 1918 以外の IP アドレスなど、VPC ネットワーク経由で転送します。

    • ルーティングとセキュリティ: この設定では、すべてのアウトバウンド トラフィックが VPC に転送されるため、ルーティングとセキュリティの管理はユーザーの責任となります。このトラフィックをアウトバウンド ゲートウェイまたはセキュリティ アプライアンス（ネクストホップ ファイアウォールや Cloud Interconnect インターフェースなど）に転送するデフォルト ルート（0.0.0.0/0）が VPC ネットワークにあることを確認します。
    • パブリック インターネットの下り（外向き）: エージェント ゲートウェイは、アウトバウンド トラフィックを VPC ネットワークに送信します。このトラフィックは、Private Service Connect ネットワーク アタッチメント サブネットの Cloud NAT ゲートウェイを介してパブリック インターネットに送信されます。静的外部 IP アドレスを Cloud NAT ゲートウェイに割り当てると、リモート サービスはこれらの送信元 IP アドレスに基づいてエージェントの下り（外向き）トラフィックを許可リストに登録できます。
    • VPC Service Controls: VPC Service Controls のサービス境界をサポートするには、下り（外向き）モードを ALL_TRAFFIC に設定する必要があります。

DNS の解決とトラフィック ルーティング

デフォルトでは、Agent Gateway はパブリック再帰 DNS を使用してドメイン名を解決します。エージェントが VPC ネットワークのプライベート ドメイン名（corp.internal. や PSC エンドポイントなど）でホストされている内部ワークロード、プライベート ツール、Google API にアクセスする必要がある場合は、Cloud DNS ピアリングを構成して、DNS クエリをネットワークのプライベート Cloud DNS マネージド ゾーンに転送できます。

次の表に、VPC 接続が ALL_TRAFFIC モードで構成されている場合の、Cloud DNS ピアリングの要件とさまざまな宛先に対するトラフィック ルーティングの動作をまとめます。

表: ALL_TRAFFIC モードでの DNS の解決とトラフィック ルーティング
トラフィックの宛先 Cloud DNS ピアリングが必要ですか？ DNS の解決 下り（外向き）パス
プライベート IP サービス
（RFC 1918 / 内部）		 はい（例: corp.internal.） ターゲット VPC ネットワークのプライベート Cloud DNS マネージド ゾーンとの Cloud DNS ピアリングを使用して解決します。 トラフィックは、ネットワーク アタッチメントを介して VPC ネットワークに入り、内部ワークロードに接続します。
プライベート IP を使用した一般公開ホスト名
（スプリット ホライズン DNS）		 いいえ Cloud DNS ピアリングを必要とせずに、ゲートウェイ プロキシで標準のパブリック再帰 DNS を使用して解決します。 トラフィックは、ネットワーク アタッチメントを介して VPC ネットワークに入り、内部ワークロードに接続します。
パブリック インターネットと SaaS API
（外部ドメイン）		 いいえ Cloud DNS ピアリングを必要とせずに、ゲートウェイ プロキシで標準のパブリック再帰 DNS を使用して解決します。 トラフィックはネットワーク アタッチメントを介して VPC ネットワークに入り、サブネットで構成された Cloud NAT を使用して公共のインターネットに出ます。
Cloud de Confiance API
（標準、VPC Service Controls なし）		 いいえ Cloud DNS ピアリングを必要とせずに、ゲートウェイ プロキシで標準のパブリック再帰 DNS を使用して解決します。 トラフィックはネットワーク アタッチメントを介して VPC ネットワークに入り、サブネットで有効になっているプライベート Google アクセスを使用して非公開でルーティングされます。Cloud NAT や DNS ピアリングは使用されません。
Cloud de Confiance API
（VPC Service Controls を使用）		 はい（googleapis.com. の場合） プライベート Cloud DNS ゾーンを使用して、制限付き Google API 範囲（199.36.153.4/30）または内部 Private Service Connect エンドポイントに解決されます。 トラフィックは、ネットワーク アタッチメントを介して VPC ネットワークに入り、VPC Service Controls 境界のセキュリティ ルールを適用します。1

1 ホスト プロジェクトを参照する compute.googleapis.com または dns.googleapis.com で NETWORK_NOT_IN_SAME_SERVICE_PERIMETER や SECURITY_POLICY_VIOLATED などの VPC Service Controls の違反によりリクエストが失敗する場合は、ホスト プロジェクトがゲートウェイ プロジェクトと同じ境界内にあることを確認します。

TLS 証明書の要件

HTTPS 経由で下り（外向き）トラフィックをルーティングする場合、Agent Gateway は TLS ハンドシェイク中に宛先サーバーの TLS 証明書チェーンを検証します。HTTPS 接続の証明書の要件は、ターゲット エンドポイントが一般に信頼されている認証局（CA）を使用しているか、プライベート CA または自己署名 CA を使用しているかによって異なります。

  • パブリック CA: デフォルトでは、Agent Gateway は、標準のサーバー証明書の要件（ターゲット ホスト名と一致するサブジェクト代替名（SAN）を含む）を満たす公的に信頼できる認証局（CA）によって発行された証明書を信頼します。

  • プライベート CA と自己署名証明書: ターゲットの宛先（VPC ネットワーク内のエージェント、ツール、MCP サーバー）がプライベート CA または内部 PKI を使用している場合は、接続テンプレートの tlsConfig 設定を使用してカスタム信頼アンカーを構成できます。Certificate Manager の TrustConfig リソースを参照することで、特定プライベート CA のみを信頼するように Agent Gateway を構成したり、プライベート ルート CA と公的に信頼できる CA を組み合わせて、パブリック エンドポイントとプライベート エンドポイントの両方の信頼を確立したりできます。

    trustConfig を使用してプライベート CA を使用する宛先にトラフィックを転送する場合は、PEM ファイルを手動でローテーションする必要があります。Cloud de Confianceの Secret Manager などのシークレット マネージャーを使用した PEM ファイルの自動ローテーションはサポートされていません。

Agent Gateway が証明書チェーンを検証できない場合、接続は失敗します。

必要なロールと権限

エージェント ゲートウェイの VPC 接続を構成するには、プロビジョニングに使用される ID とゲートウェイ サービス エージェントに必要なロールがあることを確認します。

スタンドアロン プロジェクトのデプロイ

ゲートウェイ、ネットワーク アタッチメント、VPC ネットワークが同じプロジェクトに存在するスタンドアロン プロジェクトでは、標準の Agent Gateway 権限が適用されます。詳細については、必要な権限をご覧ください。

共有 VPC またはクロス プロジェクトのデプロイ

ターゲット VPC ネットワーク、ネットワーク アタッチメント、プライベート DNS ゾーンが中央ホスト プロジェクト（TARGET_VPC_PROJECT_ID）に存在する共有 VPC またはクロス プロジェクト設定を使用している場合は、標準の Agent Gateway 権限に加えて、次のロールが必要です。

表: 共有 VPC とプロジェクト間のデプロイに必要な権限
プリンシパルまたは ID プロジェクトに対する付与 必要な IAM ロール 目的
プロビジョニング ID1
（ユーザー アカウントまたはデプロイ サービス アカウント）		 ホスト プロジェクト（TARGET_VPC_PROJECT_ID）
  • Compute ネットワーク閲覧者（roles/compute.networkViewer）
  • DNS リーダー（roles/dns.reader）
  • Network Connectivity リージョン エンドポイント管理者（roles/networkconnectivity.regionalEndpointAdmin）
  • ネットワーク接続コンシューマー ネットワーク管理者（roles/networkconnectivity.consumerNetworkAdmin）
 ゲートウェイの作成または更新時に、ターゲット VPC ネットワーク、サブネット、ネットワーク アタッチメント、限定公開 DNS ゾーンのバックエンド検証を許可します。
ネットワーク アタッチメント作成者
（PSC アタッチメントを作成する管理者）		 ホスト プロジェクト（TARGET_VPC_PROJECT_ID）
  • Compute ネットワーク ユーザー（roles/compute.networkUser）
 ホスト プロジェクトの共有 VPC サブネットを使用して、Private Service Connect ネットワーク アタッチメントを作成できます。
サービス プロジェクトのネットワーク アタッチメント（推奨）
Agent Gateway サービス エージェント2 ホスト プロジェクト（TARGET_VPC_PROJECT_ID）
  • Compute ネットワーク ユーザー（roles/compute.networkUser）
  • DNS ピア（roles/dns.peer）
 Agent Gateway サービス エージェントが、ネットワーク アタッチメントにホスト プロジェクトのサブネットを使用し、Private Service Connect インターフェースを接続して下り（外向き）トラフィックをルーティングし、ホスト プロジェクトの限定公開 Cloud DNS ゾーンとピアリングできるようにします。
ホスト プロジェクトのネットワーク アタッチメント
Agent Gateway サービス エージェント2 ホスト プロジェクト（TARGET_VPC_PROJECT_ID）
  • Compute ネットワーク管理者（roles/compute.networkAdmin）、または次の権限を持つカスタムロール。
    • compute.networkAttachments.get
    • compute.networkAttachments.update
    • compute.regionOperations.get
  • DNS ピア（roles/dns.peer）
 Agent Gateway サービス エージェントがホスト プロジェクトのネットワーク アタッチメントを更新して、Agent Gateway テナント プロジェクトからの接続を許可し、下り（外向き）トラフィックをルーティングし、ホスト プロジェクトの限定公開 Cloud DNS ゾーンとピアリングできるようにします。

1 プロビジョニング ID の場合、ホスト プロジェクトの閲覧者（roles/viewer）や編集者（roles/editor）などの基本プロジェクト レベルのロールでも十分です。

2 Agent Gateway サービス エージェントの形式は service-AGENT_GATEWAY_PROJECT_NUMBER@gcp-sa-agentgateway.s3ns-system.iam.gserviceaccount.com です。

VPC 接続を構成する

接続テンプレートを使用して Agent Gateway をデプロイする手順は次のとおりです。

  1. ターゲット VPC ネットワークに Private Service Connect ネットワーク アタッチメントを作成します。

    ネットワーク アタッチメントが次の要件を満たしていることを確認します。

    • 接続の設定: 接続を自動的に受け入れるようにネットワーク アタッチメントを構成します。（--connection-preference=ACCEPT_AUTOMATIC）。
    • 同じ VPC ネットワークの要件: ネットワーク アタッチメント サブネットと DNS ピアリング（targetNetwork）用に構成されたターゲット ネットワークは、まったく同じ VPC ネットワーク内にある必要があります。ネットワーク アタッチメントのサブネットが DNS ピアリングのターゲット ネットワークとは異なるネットワークに属している場合、構成の検証は失敗します。
    • サブネットの要件: ネットワーク アタッチメントのサブネットには、次の要件があります。
      • サブネット範囲: ネットワーク アタッチメント サブネットは、すべての有効な範囲をサポートしています。
      • サブネット サイズ: Agent Gateway には、ネットワーク アタッチメント用に最小 /28 サブネットが必要です。/28 サブネットは 12 個の使用可能な IP アドレスを提供します。これは、単一の Agent Gateway インスタンスに十分な数です。複数のゲートウェイを同じネットワーク アタッチメントまたはサブネットに接続する場合は、より大きなサブネット（/26 や /24 など）を使用して、IP アドレスの枯渇を回避します。
      • プライベート Google アクセスの要件: ネットワーク アタッチメントをホストするサブネットでプライベート Google アクセス（private_ip_google_access = true）を有効にする必要があります。
    • 共有 VPC デプロイ: 共有 VPC デプロイについては、共有 VPC デプロイ トポロジをご覧ください。

    ネットワーク アタッチメントの URI をメモします。これは、後の手順で接続テンプレート リソースの PSC_NETWORK_ATTACHMENT_URI 属性を更新するときに必要になります。

  2. DNS ピアリングを設定する（省略可）: DNS ピアリングにより、Agent Gateway は VPC ネットワークの Cloud DNS 限定公開マネージド ゾーンのレコードを使用して DNS 名を解決できます。DNS ピアリングが必要になるのは、エージェントがプライベート内部ドメイン名（corp.internal. など）を解決する必要がある場合、または Google API（googleapis.com.）に VPC Service Controls を適用する場合のみです。公共のインターネット ドメインや、VPC Service Controls を使用しない標準の Google API には必要ありません。

    Agent Gateway は、単一の推移的ホップまでの推移的 DNS ピアリングのみをサポートします。つまり、最大 3 つの VPC ネットワークです。たとえば、vpc-net-a（Agent Gateway テナント ネットワーク）は vpc-net-b（接続されたネットワーク）とピアリングできます。vpc-net-b は vpc-net-c（リモート ネットワーク）とピアリングして、チェーン全体で DNS クエリを解決します。

    DNS ピアリングを設定する手順は次のとおりです。

    1. ターゲット VPC ネットワークにプライベート DNS ゾーンを設定します。プライベート DNS ゾーンに DNS レコードを追加するには、リソース レコードセットを追加するをご覧ください。

    2. ピアリングを有効にするように接続テンプレートを構成するには、次の情報を収集します。

      • ターゲット ネットワーク URI（targetNetwork）: ターゲット VPC ネットワークの完全なリソース URI。これは、ネットワーク アタッチメントを含む 同じ VPC ネットワークである必要があります。

      • ドメイン名: DNS ピアリングの 1 つ以上のドメイン サフィックス。各ドメインの末尾はドット（.）で終わる必要があります（例: corp.internal.、googleapis.com.）。

        domains フィールドの構成方法に関するその他のガイダンスについては、DNS ピアリング ドメイン パターンをご覧ください。共有 VPC などのプロジェクト間のデプロイについては、プロジェクト間の DNS ゾーンとピアリングの要件をご覧ください。

  3. TLS 信頼構成を設定する（プライベート CA と自己署名証明書を使用する宛先のみ）:

    移行先のターゲットでプライベート CA または自己署名証明書を使用する場合は、Certificate Manager で TrustConfig リソースを作成する必要があります。TrustConfig リソースは、Agent Gateway が TLS 接続の検証に使用する信頼アンカーと証明書を定義します。

    1. PEM 形式で証明書ファイルを準備します。

      • トラストストア: PEM 形式のルート CA 証明書または中間 CA 証明書。Agent Gateway は、信頼チェーンがこれらの CA 証明書のいずれかに続くサーバー証明書を信頼します。トラストストアには、少なくとも 1 つのルート CA 証明書または中間 CA 証明書が含まれている必要があります。
      • 許可リストに登録済みの証明書（省略可） : 自己署名証明書など、明示的に信頼するサーバー証明書（PEM 形式）。

    2. 次のコマンドを実行して、TrustConfig リソースを作成します。TrustConfig は、エージェント ゲートウェイと接続テンプレートと同じプロジェクトとリージョンに作成する必要があります。

      gcloud certificate-manager trust-configs create TRUST_CONFIG_NAME \
  --location=LOCATION \
  --trust-store="trust-anchors=ROOT_CERT_FILE" \
  --allowlisted-certificates=ALLOWLISTED_CERT_FILE

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

      • TRUST_CONFIG_NAME: TrustConfig リソースの名前。
      • LOCATION: 信頼構成のリージョン（例: europe-west1）。これは、Agent Gateway と接続テンプレートと同じリージョンである必要があります。
      • ROOT_CERT_FILE: PEM エンコードされたルート CA 証明書または中間 CA 証明書のパス。
      • ALLOWLISTED_CERT_FILE:（省略可）明示的に信頼する PEM エンコードされた証明書のパス。許可リストに登録済みの証明書を使用していない場合は、このフラグを省略します。

      信頼構成の管理の詳細については、信頼構成の作成と管理をご覧ください。

  4. Agent Gateway をデプロイする

    1. 接続テンプレート構成ファイルを作成します。

      agw-connectivity-template.yaml という名前の YAML ファイルを作成します。

      name: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
accessPath: AGENT_TO_ANYWHERE
deploymentModel: CENTRALIZED
egressNetworkConfig:
  networkAttachment: PSC_NETWORK_ATTACHMENT_URI
  dnsPeeringConfig:
    domains:
      - DOMAIN_NAME
    targetNetwork: TARGET_VPC_NETWORK_URI
  vpcEgress: VPC_EGRESS_MODE
  tlsConfig:
    trustConfig: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
    additionalRoots: ADDITIONAL_ROOTS_OPTION

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

      • AGENT_GATEWAY_PROJECT_NUMBER: ゲートウェイがデプロイされている Cloud de Confiance プロジェクトの数値プロジェクト番号。プロジェクト番号を取得するには、gcloud projects describe PROJECT_ID --format="value(projectNumber)" を実行します。

      • LOCATION: 接続テンプレートのリージョン（例: europe-west1）。

      • CONNECTIVITY_TEMPLATE_NAME: 接続テンプレート リソースの名前。

      • accessPath: 接続テンプレートの管理されたアクセスパス。AGENT_TO_ANYWHERE に設定します（接続テンプレートは下り（外向き）ゲートウェイでのみサポートされます）。

      • deploymentModel: ゲートウェイのデプロイ モデル。CENTRALIZED に設定します。

      • PSC_NETWORK_ATTACHMENT_URI: VPC への接続用の PSC インターフェース ネットワーク アタッチメント。ネットワーク アタッチメントが、ゲートウェイをデプロイしたプロジェクト（共有 VPC ホスト プロジェクトなど）とは異なるプロジェクトで作成されている場合は、ネットワーク アタッチメントの完全パス（projects/TARGET_VPC_PROJECT_ID/regions/REGION/networkAttachments/ATTACHMENT_NAME）を渡します。

      • DOMAIN_NAME:（省略可）DNS ピアリングの 1 つ以上のドメイン サフィックス（例: corp.internal.、googleapis.com.、.）。ピアリングするドメイン サフィックスごとに、domains の下にリスト項目を追加します。各値は末尾にドット（.）を付け、ターゲット ネットワークで承認された対応する限定公開 Cloud DNS マネージド ゾーンが必要です。

        domains フィールドの構成方法に関する追加のガイダンスについては、DNS ピアリング ドメイン パターンをご覧ください。

      • TARGET_VPC_NETWORK_URI: ネットワーク アタッチメントを作成したターゲット VPC ネットワーク。形式は projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME にする必要があります。targetNetwork は、プロジェクト番号ではなくプロジェクト ID（TARGET_VPC_PROJECT_ID）を使用して常に指定します。

      • VPC_EGRESS_MODE: 下り（外向き）ルーティング モードを設定します。PRIVATE_RANGES_ONLY または ALL_TRAFFIC のいずれかに設定します。

      • tlsConfig:（省略可）HTTPS 経由でプライベート エンドポイントに接続する際のサーバー証明書の検証用の TLS 構成。

        • TRUST_CONFIG_NAME: プライベート CA 証明書または信頼アンカーを含む Certificate Manager TrustConfig リソースの名前。
        • ADDITIONAL_ROOTS_OPTION: カスタム信頼構成に加えて、一般に信頼されている CA ルートを信頼するかどうかを指定します。trustConfig パラメータで検証された証明書と、公的に信頼できるすべての CA の両方を信頼する場合は、PUBLICLY_TRUSTED_ROOTS（デフォルト）に設定します。trustConfig パラメータで検証された証明書のみを信頼する場合は、NO_ADDITIONAL_ROOTS に設定します。

    2. 接続テンプレートを作成します。

      次のコマンドを実行して、接続テンプレートを作成します。

      gcloud network-services agent-connectivity-templates import CONNECTIVITY_TEMPLATE_NAME \
    --source="agw-connectivity-template.yaml" \
    --location=LOCATION

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

      • CONNECTIVITY_TEMPLATE_NAME: 接続テンプレート リソースの名前。
      • LOCATION: 接続テンプレート リソースを作成するロケーション。例: europe-west1

    3. Agent Gateway リソースを定義します。

      接続テンプレートを参照するゲートウェイ YAML 構成ファイル（my-agent-gateway-vpc-egress.yaml など）を作成して、AGENT_TO_ANYWHERE モードで新しい Agent Gateway リソースを定義します。

      name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
agentConnectivityTemplate: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
registries:
  - AGENT_REGISTRY_PATH

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

      • AGENT_GATEWAY_NAME: Agent Gateway リソースの名前。

      • AGENT_GATEWAY_PROJECT_NUMBER: ゲートウェイと接続テンプレートを作成した Cloud de Confiance プロジェクトの数値プロジェクト番号。プロジェクト番号を取得するには、gcloud projects describe PROJECT_ID --format="value(projectNumber)" を実行します。

      • LOCATION: 接続テンプレートのロケーション（例: europe-west1）。

      • CONNECTIVITY_TEMPLATE_NAME: 接続テンプレート リソースの名前。

      • AGENT_REGISTRY_PATH: エージェント レジストリのパス。Agent Gateway に最大 2 つのレジストリを構成できます。2 つのレジストリを構成する場合、1 つはグローバル レジストリでなければならず、もう 1 つはリージョン レジストリまたはマルチリージョン レジストリのいずれかになります。レジストリ パスは次のようにフォーマットする必要があります。

        • リージョン レジストリ: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
        • グローバル レジストリ: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
        • マルチリージョン レジストリ: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

    4. Agent Gateway をインポートしてデプロイする:

      次のコマンドを実行して、YAML 仕様に基づいて Agent Gateway リソースを作成します。

      gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
    --source="my-agent-gateway-vpc-egress.yaml" \
    --location=LOCATION

      LOCATION は、Agent Gateway リソースを作成するロケーションに置き換えます。例: europe-west1

アーキテクチャとネットワーキングに関する考慮事項

このセクションでは、VPC 接続を使用して Agent Gateway をデプロイするためのアーキテクチャ ガイダンスと高度なネットワーキング パターンについて説明します。

VPC 下り（外向き）設定を更新する

接続テンプレートが Agent Gateway によって参照されている間は、変更できません。

  • 変更可能な VPC 下り（外向き）設定（DNS ピアリング構成、VPC 下り（外向き）モード、TLS 構成など）を更新するには、同じ networkAttachment を使用する新しい接続テンプレートを作成し、新しいテンプレートを参照するように Agent Gateway を更新する必要があります。

  • networkAttachment 自体は、Agent Gateway で構成すると変更できません。別のネットワーク アタッチメント（またはターゲット VPC ネットワーク）に切り替えるには、新しい接続テンプレートと新しい Agent Gateway を作成する必要があります。

共有 VPC のデプロイ トポロジ

共有 VPC アーキテクチャでは、サービス プロジェクト（推奨）またはホスト プロジェクトのいずれかにネットワーク アタッチメントを作成できます。

VPC Service Controls 準拠

エージェント通信に VPC Service Controls の境界を適用するには、次のことを確認します。

  • 接続テンプレートで vpcEgress を ALL_TRAFFIC に設定します。

  • Google API リクエストを restricted.googleapis.com IP 範囲（199.36.153.4/30）または Google API の内部 Private Service Connect エンドポイントに転送します。

  • googleapis.com の DNS の解決を構成します。VPC ネットワークに *.googleapis.com を restricted.googleapis.com にマッピングする限定公開 Cloud DNS ゾーンを作成し、接続テンプレートの domains フィールドに googleapis.com. を含めます。

    DNS 構成の詳細については、プライベート Google アクセスのドキュメントの googleapis.com の DNS を構成するをご覧ください。

  • 共有 VPC デプロイの場合、ネットワーク アタッチメントのサブネットと dnsPeeringConfig.targetNetwork を所有するホスト プロジェクトは、Agent Gateway をデプロイするプロジェクトと同じサービス境界に存在する必要があります。これは、サブネットと VPC ネットワークがホスト プロジェクトに属しているため、サービス プロジェクトでネットワーク アタッチメントを作成する場合にも適用されます。限定公開 DNS ゾーンが別の DNS プロジェクトでホストされている場合は、そのプロジェクトも境界に含めます。

DNS ピアリング ドメイン パターン

このセクションでは、ドメイン解決パターンと、接続テンプレートの domains フィールドを構成するためのオプションについて説明します。

ドメイン名の構成: 次の考慮事項に基づいて、接続テンプレートの domains フィールドを構成します。

  • プライベート内部ドメイン: VPC ネットワークでホストされているプライベート内部サービス（service.corp.internal など）を解決するには、内部ドメイン サフィックス（corp.internal. など）を指定します。このドメインの完全一致のプライベート Cloud DNS マネージド ゾーンは、ターゲット VPC ネットワークに対して承認されている必要があります。

  • スプリット ホライズン DNS（RFC 1918 IP を使用したパブリック ドメイン）: パブリック DNS ゾーンを使用して、内部プライベート IP を指すレコード（mcp.example.com が Certificate Manager パブリック証明書の RFC 1918 アドレスに解決されるなど）をホストする場合、ゲートウェイは DNS ピアリングを必要とせずに、パブリック再帰 DNS を使用してこれらのレコードを自動的に解決します。

  • VPC Service Controls を使用するCloud de Confiance API: ALL_TRAFFIC が VPC Service Controls を適用するように構成されている場合、Google API リクエストは restricted.googleapis.com IP 範囲（199.36.153.4/30）または内部 PSC エンドポイントに解決される必要があります。VPC ネットワークで *.googleapis.com を restricted.googleapis.com にマッピングするプライベート Cloud DNS ゾーンを作成し、接続テンプレートの domains フィールドに googleapis.com. を含めます。

  • マルチドメイン解決パターン: 複数のプライベート ドメイン サフィックスの解決が必要な場合は、次のいずれかのパターンを選択します。

    • 複数の個々のドメインをピアリングする: dnsPeeringConfig の domains フィールドにドメイン サフィックスのリストを指定します（例: corp.internal.、prod.internal.、googleapis.com.）。リスト内の各ドメインは、末尾のドット（.）で終わる必要があり、ターゲット VPC ネットワークに対して承認された対応する限定公開 Cloud DNS マネージド ゾーンが必要です。
    • 統合された親接尾辞（推奨）: 内部サービスを共有の親ドメイン接尾辞（*.internal. や *.corp.internal. など）の下に統合し、その親ドメインを domains リストに含めます。

    • プライベート転送ゾーンを使用したキャッチオール ルート ピアリング: 接続テンプレートの domains フィールドに "." を含め、VPC ネットワークのルートドメイン（.）に Cloud DNS プライベート転送ゾーンを構成して、アップストリームの再帰リゾルバ（8.8.8.8 や内部エンタープライズ リゾルバなど）を参照します。VPC 内のより具体的な限定公開ゾーンは、最長サフィックス マッチングによって最初に照合されます。一致しない一般公開クエリは、アップストリーム フォワーダーを介して解決されます。

プロジェクト間の DNS ゾーンとピアリングの要件

接続テンプレートの dnsPeeringConfig 設定は、プロジェクト間の Cloud DNS ピアリングを直接サポートしていません。接続テンプレートをインポートするときに、targetNetwork が networkAttachment と異なるプロジェクトにある場合、またはサービス プロジェクトまたは外部プロジェクトからのクロス プロジェクト DNS ゾーン バインディングに依存している場合、検証は失敗します。

ドメインのマネージド ゾーンは、targetNetwork を所有するホスト プロジェクトに作成する必要があります。マネージド ゾーンは、次のいずれかのゾーンタイプにできます。

  • 権威のある限定公開ゾーン
  • 転送ゾーン
  • Cloud DNS ピアリング ゾーン: ホスト プロジェクトの VPC ネットワークに関連付けられ、宛先 VPC ネットワークをターゲットにする必要があります。宛先 VPC は、権威のある限定公開ゾーンを使用してクエリを直接解決する必要があります。別の DNS ピアリング ゾーンにクエリを転送する（チェーン）ことはサポートされておらず、NXDOMAIN エラーが発生します。

次のステップ

ガイド

安全でガバナンスが適用された接続のために、Agent Gateway を介して Agent Runtime トラフィックをルーティングする方法について説明します。

Codelab

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

Codelab

VPC ネットワーク内の宛先にアクセスする AI エージェントの Agent Gateway 下り（外向き）ガバナンスについて説明します。

ガイド

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

ガイド

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

ガイド

Gemini Enterprise トラフィックを Agent Gateway 経由でルーティングする方法について説明します。