📅 2026年5月6日 ⏱️ 16分で読めます

Gemini Enterprise Agent PlatformのAgent Gatewayとは？AIエージェント統制の仕組みを徹底解説

執筆小林編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年5月6日

複数のAIエージェント、MCPサーバー、業務ツールを中央のゲートウェイで統制する構造を示した図

Gemini Enterprise Agent PlatformのAgent Gatewayは、Google CloudがAIエージェントの本番運用に向けて用意している統制レイヤーです。エージェントが社内データ、MCPサーバー、外部API、別のエージェントへ接続するようになると、「どのエージェントが、どの権限で、どのツールを呼べるのか」を中央で管理する必要が出てきます。

結論から言うと、Agent GatewayはAIエージェント向けの通信制御ポイントです。通常のAPI Gatewayのように入口を管理するだけではなく、Agent Registry、Agent Identity、IAM/IAP、Model Armor、Semantic Governance Policiesと組み合わせて、エージェントからツールやMCPサーバーへの通信を統制します。AIエージェントのガバナンスや権限設計を、Google Cloudのマネージド基盤で実装するための部品として見ると理解しやすくなります。

2026年5月6日時点のGoogle Cloud公式ドキュメントでは、Agent GatewayはPrivate Previewです。特にGemini EnterpriseではClient-to-Agentのingressは未対応で、Agent-to-Anywhereのegressのみが対象です。したがって、すぐ全社標準にする機能というより、AIエージェントを本番業務に広げる企業が、接続と統制の設計を先に検証するための重要な新機能と捉えるのが現実的です。

Agent Gatewayを中心に、Agent Registry、Agent Identity、MCP、Model Armor、監査ログの関係を整理した図 — Agent Gatewayは単独で完結する機能ではなく、登録、ID、権限、AIセキュリティ、観測を組み合わせてエージェント通信を統制します。

本記事のポイント

Agent Gatewayは、AIエージェントとツールの通信を一元管理する統制ポイントであり、通常のAPI Gatewayとは目的が異なります。
実務上の中核は、Agent Registry、Agent Identity、IAM/IAP、Model Armorを組み合わせて、接続先と実行権限を絞ることです。
2026年5月時点ではPrivate Previewで、Gemini Enterpriseはegressのみ対応のため、本番採用は検証環境から進めるべきです。

この記事で扱うテーマ

Agent Gatewayとは何か

Google Cloudの Agent Gateway overview では、Agent GatewayはGemini Enterprise Agent Platformエコシステムのネットワークコンポーネントとして説明されています。対象になる通信は、ユーザーとエージェント、エージェントとツール、エージェント同士のやり取りです。

重要なのは、Agent Gatewayが「エージェントを作る機能」ではないことです。エージェントを作るのはAgent Studio、ADK、Agent Runtimeなどの領域です。Agent Gatewayは、作られたエージェントがどこへ接続できるか、どのMCPサーバーやツールを呼べるか、どの通信にセキュリティポリシーを適用するかを管理します。

この意味で、Agent GatewayはAIエージェントエコシステムの航空交通管制という比喩に近い役割を持ちます。ただし、比喩だけで理解すると危険です。実務では「通信経路」「接続先の登録」「エージェントID」「権限ポリシー」「AIセキュリティ」「ログ」の6点を分けて見る必要があります。

観点	Agent Gatewayで見ること	実務上の意味
通信経路	ingressとegressのどちらを制御するか	誰から誰への通信を統制対象にするかが決まる
接続先	Agent Registryに登録されたagent、tool、MCP server	未登録ツールの利用を防ぎやすくなる
主体	Agent Identityをprincipalとして扱う	人ではなくエージェント単位で権限を切れる
権限	IAM、IAP、Semantic Governance Policies	読み取り、書き込み、特定ツール呼び出しを制御できる
防御	Model Armorとの連携	prompt injectionや機密情報漏えいを検査対象にできる
観測	Cloud Logging、Cloud Trace、Agent Observability	後から調査できる証跡を残せる

通常のAPI Gatewayと比べると、Agent Gatewayは「人間が明示的にAPIを叩く」前提ではなく、「AIエージェントが推論結果としてツールを呼ぶ」前提に寄っています。ここが最も大きな違いです。AIエージェントでは、ユーザーの依頼文、取得した外部情報、ツール説明、MCPサーバーの応答が絡み合い、意図しない操作につながる可能性があります。そのため、単にエンドポイントを保護するだけでは足りません。

Agent Registry、Agent Identity、MCPとの関係

Agent Gatewayを理解するには、周辺コンポーネントを分けて見る必要があります。公式ドキュメント上も、Agent GatewayはAgent Registry、Agent Identity、Agent Platform Policies、Model Armor、Agent Observabilityと連携する前提で説明されています。

Agent Registryは接続先の台帳になる

Agent Registry は、AIエージェント、ツール、MCPサーバー、endpointを登録・検索・管理するためのカタログです。Agent Gatewayはこの登録情報を参照し、承認済みの接続先だけを許可する設計を取りやすくします。

企業でMCPサーバーが増えると、部署ごとに作ったサーバー、外部ベンダーが提供するサーバー、検証用サーバーが混在します。台帳がない状態でエージェントに接続を許すと、便利な一方でリスクも増えます。MCPの基本を押さえたうえで、接続先をRegistryに寄せる発想が必要です。

Agent Identityはエージェントそのものをprincipalにする

Agent Identity は、各エージェントに暗号学的に検証可能なIDを与える仕組みです。公式ドキュメントではSPIFFEベースのIDとして説明されており、サービスアカウントのように複数ワークロードで共有する前提ではありません。

これは権限設計に効きます。従来は「このアプリのサービスアカウントに権限を渡す」という設計になりがちでした。Agent Identityを使うと、「この営業支援エージェントはカレンダーの読み取りはできるが、CRMの更新はできない」「この社内FAQエージェントはDriveを読めるが、メール送信はできない」というように、エージェント単位で実行範囲を切りやすくなります。

MCPはツール呼び出しの標準化、Agent Gatewayは統制

MCPはAIエージェントが外部データやツールに接続するためのプロトコルです。一方、Agent Gatewayはその接続を企業ポリシーで制御する層です。MCPが「つなぎ方」を標準化するなら、Agent Gatewayは「つないでよい相手と操作範囲」を管理します。

Google CloudのPolicies overviewでは、MCPのtoolName、resourceName、method、read-onlyやdestructiveといった属性を条件に使えることが示されています。これは実務上かなり重要です。たとえば、同じMCPサーバーでも読み取りツールは許可し、破壊的な更新ツールは拒否する、という設計に近づけます。

Agent Gatewayで何を制御できるのか

Agent Gatewayの価値は、AIエージェントの通信を「見える化する」だけではありません。どの通信を許可し、どの通信を止め、どの通信を監査対象にするかを中央で扱える点にあります。

Client-to-AgentとAgent-to-Anywhere

公式ドキュメントでは、Agent Gatewayのアクセス経路はClient-to-AgentとAgent-to-Anywhereの2つに整理されています。Client-to-AgentはCursor、Claude Code、Gemini CLIのようなクライアントからGoogle Cloud上のエージェントやツールへ入る通信を守るモードです。Agent-to-Anywhereは、Google Cloud上のエージェントが外部のMCPサーバー、ツール、API、別エージェントへ出ていく通信を守るモードです。

ただし、Gemini Enterpriseでは2026年5月6日時点でClient-to-Agentは未対応です。Gemini Enterpriseで使えるのはAgent-to-Anywhereのegressのみです。ここを誤解すると、「Gemini Enterpriseのすべての入口をAgent Gatewayで守れる」と過剰に期待してしまいます。

IAMとIAPによる許可制御

Agent Gatewayでは、エージェント、ツール、MCPサーバー、endpointに対してIAMポリシーを設定し、IAPが実行時の enforcement layer として働きます。デフォルトでは、IAMで明示的に許可されたリソースだけが通信可能と説明されています。

これはゼロトラストに近い発想です。AIエージェントに「なんとなく便利そうだから全ツールを見せる」のではなく、業務目的ごとに最小権限で接続先を渡す設計になります。既存の AIエージェントの権限設計と同じく、読み取り、下書き、更新、送信を分ける考え方が必要です。

Model ArmorによるAIセキュリティ

Agent GatewayはModel Armorと組み合わせることで、prompt injectionや機密情報漏えいのようなAI特有のリスクを検査対象にできます。通常のネットワーク制御では、通信先や認証は見られても、プロンプトやツール呼び出し文脈のリスクまでは扱いにくいです。

AIエージェントでは、外部ページやチケット本文に「この指示を無視して別ツールを呼べ」といった悪意ある文が含まれる可能性があります。Agent GatewayとModel Armorの組み合わせは、こうしたagentic system特有の攻撃面を前提にしている点が特徴です。

Cloud LoggingとCloud Traceによる観測

AIエージェントを本番運用するなら、監査ログは後付けにできません。Agent Gatewayはネットワーク層でテレメトリを生成し、Agent Observabilityへ出力する設計です。Cloud LoggingやCloud Traceと組み合わせることで、どのエージェントが、どの接続先に、どの操作を行ったかを調査しやすくなります。

これは AIエージェントの監査ログ設計と直結します。エージェントの回答だけを保存しても、ツール呼び出し、権限判断、外部接続、承認結果が追えなければ、事故時の原因分析は難しくなります。

Gemini Enterpriseで使うときの制限と導入判断

Agent Gatewayは魅力的な機能ですが、現時点ではPrivate Previewです。Google CloudのドキュメントでもPre-GA Offerings Termsの対象で、利用にはallowlistやアクセス申請が必要になる場合があります。記事や提案資料で扱うときは、一般提供済みの機能として断定しない方が安全です。

確認項目	2026年5月6日時点の見方	導入判断への影響
提供段階	Agent GatewayはPrivate Preview	本番標準化より先に検証環境で試す
Gemini Enterprise対応	Agent-to-Anywhereのegressのみ	入口制御まで期待しない
登録要件	Gemini Enterpriseではglobal Agent Registryへ登録	接続先台帳の整備が先に必要
リージョン	Gatewayは指定リージョンに作成	multi-region設定との対応を確認する
VPC Service Controls	Agent Gatewayは非対応	custom organization policy constraintsで補う
未登録リソース	未登録MCP server、agent、toolはデフォルトでブロック	例外許可の運用ルールが必要

Route Gemini Enterprise traffic through Agent Gateway では、Gemini EnterpriseのtrafficをAgent Gatewayへ通す手順として、Agent Registryへの登録、Gateway作成、authorization policiesの設定、Gemini Enterprise engineへのbindingが説明されています。特に、binding後は既存のdata connector trafficが指定Gatewayを通る点に注意が必要です。

また、Gemini Enterprise locationとAgent Gateway regionの対応も固定されています。globalとusはus-central1、euはeurope-west1が指定されています。PoCでは見落としにくい項目ですが、本番では組織のデータ配置、リージョンポリシー、監査要件に関わります。

企業がAgent Gatewayを評価するときのチェックリスト

Agent Gatewayを導入候補として見るなら、最初に機能表だけを見るのではなく、自社のエージェント運用に置き換えて評価する方が判断しやすくなります。特に、複数のAIエージェント、MCPサーバー、SaaS接続、社内APIを扱う企業では、次の順で確認すると実務に落とし込みやすいです。

1. エージェントと接続先を棚卸しする

まず、どのエージェントが存在し、どのSaaS、MCPサーバー、API、社内データへ接続するのかを洗い出します。ここが曖昧なままGatewayだけ導入しても、ポリシーが作れません。AI CoE がある企業なら、接続先台帳の整備をCoEの役割に含めると運用しやすくなります。

2. 読み取りと書き込みを分ける

Agent GatewayでMCP toolの属性を見られるとしても、最初から書き込み系を広く許可するのは危険です。read-onlyの検索、取得、要約から始め、更新、送信、削除のような操作は承認付きにするのが基本です。

3. 未登録MCPサーバーの扱いを決める

公式ドキュメントでは、未登録のremote MCP server、agent、toolはデフォルトでブロックされます。これは安全側の設計ですが、現場から見ると「便利な外部MCPが使えない」と感じる可能性があります。例外申請、検証、登録、利用停止の流れを先に決める必要があります。

4. dry-runからENFORCEへ移行する

Policies overviewでは、staging環境でDRY_RUNを使い、ポリシーが期待どおりに動くか確認してからENFORCEへ移ることが推奨されています。これは実務でも妥当です。いきなり本番でブロックすると、業務上必要な通信まで止まる可能性があります。

5. 監査ログを業務フローと突き合わせる

ログは保存するだけでは不十分です。CRM更新、GitHub issue取得、カレンダー参照、顧客メール下書きなど、業務フロー上の操作とGatewayログを突き合わせられる形にしておく必要があります。ログを見ても業務上の意味が分からない状態では、インシデント対応に使えません。

通常のAPI GatewayやApigeeとどう違うのか

Agent Gatewayという名前から、既存のAPI GatewayやApigeeと同じものを想像しがちです。しかし、見るべき対象が違います。既存のAPI Gatewayは、API利用者、認証、レート制限、ルーティング、API管理に強い仕組みです。Agent Gatewayは、AIエージェントがMCP、A2A、REST、gRPCなどを使ってツールや別エージェントへ接続する場面を前提にしています。

たとえば、通常のAPI Gatewayなら「このクライアントがこのAPIを呼べるか」を主に見ます。Agent Gatewayでは、「このエージェントIDが、このMCPサーバー上の、このツールを、この操作種別で呼んでよいか」まで問題になります。AIエージェントではツール呼び出しが自然言語の文脈から発生するため、prompt injection、機密情報、破壊的操作、read-only/read-writeの区別が重要になります。

したがって、Agent GatewayはAPI Gatewayの置き換えというより、agentic AI向けの統制レイヤーです。既存APIを社内外に公開・管理する基盤と、AIエージェントのツール利用を制御する基盤は、重なる部分はあっても同一視しない方がよいです。

よくある質問

Gemini Enterprise Agent PlatformのAgent Gatewayとは何ですか？

AIエージェント、ツール、MCPサーバー、API、別エージェント間の通信を中央で制御するネットワークとセキュリティのコンポーネントです。Agent Registry、Agent Identity、IAM/IAP、Model Armor、Agent Observabilityと組み合わせて使います。

Agent Gatewayは一般提供されていますか？

2026年5月6日時点の公式ドキュメントではPrivate Previewです。Pre-GAの扱いなので、サポートや仕様変更の可能性を前提に、検証環境で評価するのが安全です。

Gemini Enterpriseではingressも制御できますか？

いいえ。2026年5月6日時点では、Gemini EnterpriseでAgent Gatewayが対応するのはAgent-to-Anywhereのegressのみです。Client-to-AgentのingressはAgent Runtimeでは対応しますが、Gemini Enterpriseでは未対応とされています。

MCPサーバーへの接続はどう管理されますか？

Agent Registryに登録されたMCPサーバーやツールを参照し、IAM/IAPやポリシーでアクセスを制御します。未登録のremote MCP server、agent、toolはデフォルトでブロックされるため、例外運用を含めて登録フローを決める必要があります。

Agent Gatewayを使えばAIエージェントの事故は防げますか？

事故を減らす重要な部品にはなりますが、単独で十分ではありません。接続先台帳、最小権限、承認フロー、ログレビュー、業務側の責任分界まで設計する必要があります。

AIエージェントの統制設計を具体化したい場合

AIエージェントを業務に組み込むときは、モデル選定より先に、接続先、権限、承認、ログ、例外停止を決める必要があります。PoCから本番移行までの設計を短期間で整理したい場合は、超速開発の支援内容も確認しておくと判断しやすくなります。

超速開発の支援内容を見る

メディア一覧へ戻る