Agent GatewayでAIエージェントとツールの通信を制御する

1. IAM権限を付けるだけでは足りない理由

IAMは、主体がGoogle Cloudのリソースに対してどの操作を行えるかを管理する仕組みです。エージェントへ必要最小限の権限を与えることは、通信を安全にするうえで欠かせません。

一方、エージェントが複数の接続先へ直接通信する構成では、IAMだけでは整理しにくい問題が残ります。MCPサーバー、業務API、別のエージェントで認証方式が異なることがあります。許可の判断や監査記録も接続先へ分散し、どのエージェントが何を呼び出したのかを横断して追いにくくなります。

さらに、エージェントがある接続先へ到達できることと、そこで提供されるすべての操作を実行してよいことは同じではありません。たとえば、情報を参照する操作は許可しても、更新を伴う操作は許可しない設計が考えられます。接続先へ到達する権限だけでなく、呼び出し元、接続先、操作内容を組み合わせて判断する仕組みが必要です。

Agent Gatewayは、こうした通信を経路上で集約し、認証、認可、セキュリティポリシーを適用するネットワークコンポーネントです。IAMを置き換えるのではなく、IAMによる権限管理を通信経路上で適用しやすくする関所として利用します。

2. Agent Gatewayを通信経路のどこに置くのか

Agent Gatewayには、Client-to-Agent（入口側）とAgent-to-Anywhere（出口側）という二つのアクセス経路があります。

Agent Runtimeでは両方の経路を利用できます。Gemini Enterpriseでは、現時点でAgent-to-Anywhere（出口側）のみが対象です。

本記事で扱うのは、主にAgent-to-Anywhere（出口側）です。Agent Runtime上のエージェントが接続先へ直接通信するのではなく、Agent Gatewayを経由する構成を考えます。Gatewayは、呼び出し元のID、接続先の登録情報、認可条件を確認し、許可された通信だけを接続先へ転送します。条件を満たさない通信は、接続先へ到達する前に拒否します。

図1　呼び出し元、接続先、ツールなどの条件に基づくAgent Gatewayの通信制御

この構成の目的は、通信を一か所へ集めることだけではありません。通信の経路を明確にし、どの条件で許可または拒否したかを確認できる状態にすることです。

3. Agent Runtime、Agent Identity、Agent Registryとの関係

Agent Gatewayを単独の製品として捉えると、それぞれの役割が分かりにくくなります。出口側の通信では、Agent Runtime、Agent Identity、Agent Registry、Agent Gatewayを次のように整理できます。

Agent Runtimeはエージェントを実行する場所

Agent Runtimeは、開発したエージェントをデプロイし、管理し、スケールさせる実行基盤です。エージェントの処理はRuntime上で実行され、外部のツールやAPIが必要になったときに通信を開始します。

Agent Identityは呼び出し元を識別するID

Agent Identityは、エージェントごとに暗号技術を用いた一意のIDを提供します。サービスアカウントは複数のワークロードで共有する設計も可能ですが、Agent Identityはエージェントごとに割り当てられ、個別の主体として識別することを前提としています。Agent Gatewayは、このIDを認可判断の主体として利用します。

Agent Identityとサービスアカウントは、どちらも「誰が呼び出しているか」を示すために利用できますが、同じものではありません。Agent Identityは個々のエージェントを確実に識別し、認証することを目的としており、エージェントのライフサイクルに結び付いたSPIFFE IDと証明書を使用します。一方、サービスアカウントはGoogle Cloudワークロードで広く利用されるIAMの主体です。採用するIDの種類にかかわらず、必要最小限の権限にすることが重要です。

Agent Registryは接続対象の情報を管理する場所

Agent Registryは、エージェント、MCPサーバー、ツール、エンドポイントを登録し、発見し、統制するためのカタログとして機能するサービスです。通信が順番に通過する中継装置ではありません。

Agent GatewayはRegistryの情報を参照し、接続先と登録済みリソースを対応付けます。未登録のMCPサーバー、エージェント、ツールは標準では拒否されます。ただし、未登録のMCPサーバーやツールへのアクセスを許可する設定もあるため、「未登録なら必ず拒否される」とは限りません。

Agent Gatewayは通信を通すか判断する統制点

Agent Identityが呼び出し元を示し、Agent Registryが接続対象の情報を示します。Agent Gatewayはそれらを認可ポリシーと組み合わせ、実際の通信を通すかどうかを判断します。

4. 認証と認可を分けて考える

認証は、通信している主体が誰であるかを確認することです。認可は、確認した主体に対して、その接続や操作を許可するかを判断することです。

Agent Identityやサービスアカウントによって呼び出し元を確認できても、その主体がすべての接続先と操作を利用してよいとは限りません。認証に成功した後で、接続先と操作に応じた認可が必要です。

Agent-to-Anywhere（出口側）では、Agent Gatewayで扱うIAMポリシーをIdentity-Aware Proxy（IAP）が適用します。明示的に許可したリソースへの通信だけを通す構成にでき、個々のエージェントについて、MCPサーバー、別のエージェント、エンドポイントなどへのアクセスを許可または拒否できます。

認可ポリシーは、最初から通信を遮断するだけでなく、ドライランで確認できます。ドライランでは、ポリシーに違反する通信をログへ記録しつつ、通信そのものは遮断しません。想定外の影響がないことを確認してから強制モードへ移行することで、設定誤りによる業務影響を抑えやすくなります。

5. MCPとA2Aをどこまで同じように扱えるか

Agent Gatewayは、MCPやA2Aを含むHTTPベースの通信を扱います。どちらもGatewayを経由させ、呼び出し元と接続先を統制し、通信を記録できる点は共通です。

違いは、プロトコル内部の情報を認可条件として利用できる範囲です。現時点で、Agent Gatewayがリクエストを解析し、プロトコル固有の属性を認可ポリシーへ渡せるのはMCPです。

MCPでは、たとえば次の情報を条件に利用できます。

公式のIAMポリシーでは、mcp.toolName、mcp.method、mcp.tool.isReadOnlyなどの属性が示されています。破壊的操作、冪等性、外部への影響についても、mcp.tool.isDestructive、mcp.tool.isIdempotent、mcp.tool.isOpenWorldという正式な属性があります。これらはMCPツールの定義に含まれる情報を基に判断するため、ツール側のメタデータを正しく管理することも必要です。

A2Aを含む他のHTTP通信もGatewayを通せますが、MCPと同じツール単位の属性ベース制御ができるとは限りません。MCPとA2Aを「どちらも経由できる」という理由だけで、同じ細かさで認可できると考えないことが重要です。

6. IAMやネットワーク制御と組み合わせる

Agent Gatewayは、IAM、VPC、ファイアウォールの代替ではありません。それぞれが判断する対象が異なります。

たとえば、ネットワーク上は到達可能なMCPサーバーであっても、Agent Gatewayのポリシーで特定のエージェントからの呼び出しを拒否できます。反対に、Gatewayで許可しても、VPCの経路や接続先側の認証が成立しなければ通信は完了しません。

また、Agent GatewayはVPC内の接続先への出口通信にも利用できますが、VPC Service Controlsには対応していません。サービス境界を利用している環境では、この制約を前提に構成を検討し、承認済みのGatewayだけを利用させる組織ポリシーなどの代替策も確認します。

7. ログで誰が何を呼び出したか確認する

Agent Gatewayのログには、Gatewayを通過したHTTPリクエスト、MCPのメソッドやツール名、対応したAgent Registryリソース、IAPやModel Armorなどの認可拡張に関する情報が記録されます。Observabilityダッシュボードでは、認可の試行数、失敗数、リクエスト数、403による拒否、未登録エンドポイントへの通信などを確認できます。

ただし、Agent Gatewayのログだけですべての処理を説明できるわけではありません。問題発生時には、次の記録を関連付けて確認します。

時刻、トレース情報、エージェントID、接続先、ツール名などを相関できるようにしておくと、Gatewayで拒否されたのか、接続先で失敗したのか、エージェントがそもそも呼び出しを行わなかったのかを切り分けやすくなります。

8. 導入前に確認する設計事項と制約

Agent Gatewayはリージョン単位のリソースです。Agent Runtimeと組み合わせる場合、エージェント、Gateway、Agent Registryを同じプロジェクトとリージョンに配置します。東京リージョンは、2026年8月2日時点の対応リージョンに含まれています。

導入前には、少なくとも次を確認します。

主な制約として、一つのAgent Gatewayが統制できるAgent Registryリソースは最大5,000件です。また、公開・非公開を問わず、自己署名証明書チェーンを使用する接続先はサポートされません。

Agent Runtimeとの組み合わせでは、2026年4月29日より前に作成されたRuntime Reasoning EngineへGatewayを関連付けられません。同じプロジェクトとリージョンに複数のGatewayを作成できる場合でも、その範囲にあるAgent Runtimeエージェントは、同じ特定の出口側Gatewayと入口側Gatewayへ関連付ける必要があります。

そのほか、Agent Gatewayを接続したAgent Runtimeではリビジョンを利用できません。トラフィック分割やリビジョン単位のクエリなどのバージョン管理関連機能も利用できず、Security Command Center Agent Engine Threat Detectionとの併用にも対応していません。

提供リージョンや制約は更新される可能性があります。設計時と導入直前に、利用する機能ごとの最新情報を確認してください。

9. まとめ

AIエージェントの安全性は、エージェントへ付与する権限だけでは決まりません。どの通信を、どの経路で、どの条件なら許可するかを設計し、実際の通信を監査できる状態にする必要があります。

Agent Identityやサービスアカウントは、呼び出し元が誰であるかを示します。Agent Registryは、接続するエージェント、サーバー、ツール、エンドポイントの情報を管理します。Agent Gatewayは、それらの情報と認可ポリシーを基に、通信を通すかどうかを経路上で判断します。

IAMによる権限管理、VPCやファイアウォールによる到達制御、Agent Gatewayによる通信単位の統制、複数のログによる監査を組み合わせることが重要です。MCPではツール名などを使った細かな認可も可能ですが、A2Aを含む他のHTTP通信へ同じ制御をそのまま適用できるわけではありません。通信方式と必要な認可単位を確認したうえで、経路とポリシーを設計してください。

参考情報

• Agent Gateway overview
• Gemini Enterprise Agent Platform release notes
• Route Agent Runtime traffic through Agent Gateway
• Delegate authorization with Service Extensions
• Monitor traffic through Agent Gateway
• IAM policies overview
• Agent Identity overview
• Agent Registry overview
• Supported locations for agents in Agent Platform