AIエージェントのセキュリティをコードで一元管理 — GoogleのAgent Gatewayで「エージェントごとにポリシーを書く」地獄から抜け出す

7月27日、Vijayender R. Somaが「Gemini Enterprise Agent Platform — Agent Gateway: Deploying a Governed AI Agent Architecture using Terraform」と題した記事を公開した。ガバナンスの責務をエージェントコードから完全に分離するというアーキテクチャ上の核心的メッセージを軸に、TerraformでGoogle CloudのAgent Gatewayを使ったガバナンス付きAIエージェントアーキテクチャをプロビジョニングする方法を解説している。

企業がAIエージェントをスケールさせるにつれ、エージェント間・エージェントとツール間のトラフィック管理は急速に複雑化する。本記事はその課題に正面から向き合い、Infrastructure as Code（IaC）で完結するガバナンスアーキテクチャの実装例を提示している。

エージェントガバナンスはいま業界全体で急務となっている領域だ。OpenAIやAnthropicといった各社もエージェント間通信の標準化・制御に取り組んでおり、GoogleもGemini Enterprise Agent Platformとしてこの領域への本格参入を進めている。本記事が扱うAgent Gatewayは、その中でもポリシー強制実施層を担う中核コンポーネントに位置づけられる。

※編集部の考察：エージェントごとにセキュリティポリシーを個別実装するアプローチは、エージェント数が増えるにつれてドリフト（設定の乖離）や監査困難が生じやすい。IaCによる集中管理はこの問題への現実的な解の一つだが、ポリシーの表現力やデバッグのしやすさはアーキテクチャ選定の重要な評価軸となる。

なぜ「集中管理」が必要なのか

エージェントが数百・数千規模に達すると、エージェントごとにセキュリティポリシーを管理するアプローチは破綻する。具体的な問題は3つだ。

リクエスト認可：呼び出し元エージェントのIDと権限の検証
コンテンツ認可：悪意あるペイロードやプロンプトインジェクションのブロック
データ流出防止：機密データの外部送信の抑止

これを解決するのがGemini Enterprise Agent Platformのガバナンス層であり、その中核がAgent Gatewayだ。

アーキテクチャの5つのコアコンポーネント

1. Agent Gateway：集中型の強制実施ポイント

Agent Gatewayは、エージェントからツールへの直接通信を排除し、すべてのアウトバウンドトラフィックをゲートウェイ経由にルーティングする集中型プロキシだ。今回の実装では「Agent-to-Anywhere（egress）」モードを使用し、アウトバウンドのツール・API呼び出しを管理する。

2. Agent Registry：承認済み資産のカタログ

Agent Registryは、企業内のAIエージェント・MCPサーバー・エンドポイントをインデックスする中央カタログだ。承認済みの資産のみが検索・利用可能になるため、監視されていないエンドポイントの乱立を防ぐ。

MCP（Model Context Protocol）はAnthropicが提唱しツール間通信の標準として普及しつつある仕様で、GoogleもこのプロトコルをAgent Platform上でサポートしている。

3. Agent Identity：暗号ベースの本人確認

Agent Identityは、各エージェントに一意の暗号IDを付与するフルマネージドサービスだ。ツール呼び出しや推論ステップはすべてこのIDに紐づけられ、IAMポリシーにマッピングされた監査トレイルが生成される。「誰が何をしたか」を追跡可能にする仕組みだ。

4. Governance Policies：2層のセキュリティ制御

ゲートウェイレベルで以下の2つのポリシーを強制適用する。

リクエスト認可（IAM + IAP）：Identity-Aware Proxyを使い、認証・認可済みのエージェントのみがアウトバウンド呼び出しを実行できるよう制限する
コンテンツ認可（Model Armor）：Model Armorがプロンプトとレスポンスをリアルタイムで検査し、機密データの漏洩・プロンプトインジェクション・有害コンテンツをバックエンド到達前にブロックする

5. Agent Runtime + BigQuery MCP：デモ構成のワーカーとツール

ガバナンス制御の動作検証用として、以下の構成をTerraformでデプロイする。

**Agent Runtime**：エージェントの推論ループを実行するサーバーレス環境。会話状態・実行メモリ・セキュリティ分離を管理する
BigQuery MCPサーバー：Model Context Protocol（MCP）の標準インターフェースを通じ、エージェントがGateway経由でBigQueryデータセットをクエリできるようにする。BigQuery公式のMCPサポートについてはBigQueryドキュメントを参照のこと

Terraformによる実装構成

ワークスペースは以下のディレクトリ構造で管理される。

workspace-root/
├── agent/
│   ├── agent.py
│   └── requirements.txt
├── agent_deployment.tf
├── agent_locals.tf
├── bq_data.tf
├── content_authz_policy.tf
├── content_authz_templates.tf
├── gateway.tf
├── main.tf
├── outputs.tf
├── providers.tf
├── registry.tf
├── request_authz.tf
├── terraform.tfvars
└── variables.tf

エージェントのアプリケーションコードはPython ADK（Agent Development Kit）で構築する。以下がそのコアだ。

bigquery_mcp_tools = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url='https://bigquery.googleapis.com/mcp'
    ),
    header_provider=get_auth_headers,
)

proj_cost_tracker_agent = LlmAgent(
    name='proj_cost_tracker_agent',
    model='gemini-2.5-flash',
    instruction=(
        'You are an intelligent, friendly assistant helping users query and manage project records '
        'and initiatives using your BigQuery tools.'
        ...
    ),
    tools=[bigquery_mcp_tools],
)

BigQuery MCPに対して動的にOAuth2トークンを取得し、認証済みリクエストとして送出する構造だ。バックエンドはBigQueryのdemo_recordsテーブルで、record_id・user_id・name・value・ssn（機密フィールド）を含む。ssnフィールドを含む点がミソで、Model Armorによるデータ保護の実効性を検証するためのデータ設計になっている。

Terraform実行に必要なIAMロール

Terraformコマンドを実行するユーザーまたはサービスアカウントには、以下のロールが必要だ。

roles/serviceusage.serviceUsageAdmin
roles/resourcemanager.projectIamAdmin
roles/networkservices.admin
roles/networksecurity.admin
roles/serviceextensions.admin
roles/iap.admin
roles/agentregistry.admin
roles/aiplatform.admin
roles/modelarmor.admin
roles/dlp.admin
roles/bigquery.admin

オブザーバビリティ（ログ・メトリクス・トレース）のためにGCPコンソールにアクセスするユーザーには、別途roles/logging.viewer・roles/monitoring.viewer・roles/cloudtrace.userが必要になる。

なお、providers.tfでは標準プロバイダーとbetaプロバイダーの両方を設定する。新しい認可ポリシー機能がbeta APIにしか存在しないためだ。またCloud Sensitive Data Protection（DLP）がクォータ属性の明示を要求するため、user_project_overrideとbilling_projectも設定が必要になる。

設計上の注目点

この構成で特徴的なのは、ガバナンスの責務をエージェントコードから完全に分離していることだ。エージェント側のコードはBigQueryへのクエリロジックのみを持ち、認証・認可・コンテンツ検査はすべてGatewayレイヤーがTerraform管理のポリシーとして処理する。エージェントの追加・変更があっても、ガバナンスポリシーの再実装が不要な構造になっている。

IaC（Infrastructure as Code）による宣言的なポリシー管理は、Terraformをはじめとするツールが広くDevOpsの現場に定着したことで実現しやすくなった手法だ。本記事の構成はその知見をAIエージェントのガバナンスに応用した実例として参照価値が高い。

詳細はGemini Enterprise Agent Platform — Agent Gateway: Deploying a Governed AI Agent Architecture using Terraformを参照していただきたい。