IAM・Cloud Run設定は必要——Google CloudでAIエージェントをデプロイする「Cloud Run × Gemini Agent Platform」構成の実装ガイド

8月13日、GDGが「Managed Inference on Google Cloud: Pairing the Gemini Enterprise Agent Platform with Cloud Run」と題した記事を公開した。GPUやモデルサーバーのプロビジョニングをGoogle Cloud側に委ねながら、AIエージェントをCloud Runへデプロイするアーキテクチャと実装手順を詳しく解説した内容だ。ただし「管理不要」と言っても、IAM設定・サービスアカウント管理・Cloud Runの構成といった運用作業は依然として開発者の責務となる。その前提を踏まえた上で、構成の全体像と要点を紹介する。

GPUもモデルサーバーも管理不要——「Managed Inference」の考え方

Managed Inferenceとは、AIモデルの推論実行をクラウドプロバイダーに委ねる方式だ。リクエストを送れば、プラットフォーム側がコンピュートを処理して結果を返す。Google Cloudにおける現時点のクリーンな実装パターンは、Gemini Enterprise Agent PlatformとCloud Runを組み合わせることにある。

Gemini Enterprise Agent PlatformはVertex AIプラットフォームの上に構築されたサービス群であり、「旧Vertex AI」ではない。Vertex AI自体は引き続き有効なサービスとして存在しており、Agent PlatformはそのVertex AIを基盤として、エージェント特有のオーケストレーション・メモリ・推論管理を担う上位レイヤーとして位置づけられている。

アーキテクチャの分担はシンプルだ。

[ Client / Web UI ] ──> [ Cloud Run Service ] (App Logic / Tool Front End)
                                │
                                ▼
        [ Gemini Enterprise Agent Platform — Agent Runtime ]
            (Orchestration, Intent Analysis, Memory)
                                │
                                ▼
              [ Managed Inference / Model Garden ]
                 (Gemini Pro / Flash models)

Cloud Run：ビジネスロジック、クライアント向けエンドポイント、MCPサーバーなど、開発者が書くコードを動かす層
Agent Platform（Agent Runtime）：エージェントの状態管理、長期メモリ、モデルの推論ステップ管理など、Googleが運用するフルマネージドの層

用語補足：MCP（Model Context Protocol）とは
Anthropicが提唱したオープン仕様で、AIモデルが外部ツールやデータソースと標準化されたプロトコルで通信するための取り決めだ。MCPサーバーをCloud Run上に立てることで、エージェントが社内DBやAPIなど外部リソースを一貫した方法で呼び出せるようになる。詳細は公式仕様リポジトリを参照されたい。

この分割の利点は、各層が独立してスケールし、独立して障害を封じ込められる点にある。トラフィックスパイク時にフロントエンドだけスケールアップできるし、モデルを差し替えてもアプリケーションコードの再デプロイは不要だ。セキュリティ境界としても機能し、クライアントはCloud Runとしか通信しない。

エージェントのコード定義——ツールはただのPython関数

エージェントの動作定義にはオープンソースの**Agent Development Kit（ADK）を使う。最も重要な概念は「ツールは普通のPython関数**である」という点だ。ADKは各関数のdocstringを読んで、いつ・どのように呼び出すかを判断する。つまりdocstringはドキュメントの体裁をとった「エージェントロジックの一部」だ。

# agent.py
from google.adk.agents import Agent

def call_internal_business_system(query: str) -> str:
    """Invokes secure business workflows deployed on Cloud Run."""
    # Logic to securely call your Cloud Run service URL
    return "Data retrieved from secure internal backend."

root_agent = Agent(
    name="enterprise_inference_agent",
    model="gemini-2.5-flash",  # 元記事のモデル名を確認の上、現在サポートされているモデルを指定
    instruction="You are a data processing assistant using managed inference.",
    tools=[call_internal_business_system],
)

注意：モデル名の指定について
元記事で使用されているモデル名は原文を直接参照されたい。Gemini 1.0および1.5系（gemini-1.5-pro含む）はすでに廃止されておりエラーを返す。Model Gardenで現在サポートされているモデル一覧を確認の上、利用するモデルを指定すること。

4つのフィールドの役割：

name：ログやトレースで使われる識別子
model：推論を担当するGeminiモデル。Flashは高速・低コスト、Proはより複雑な推論向け
instruction：全リクエストに適用されるシステムプロンプト
tools：モデルが呼び出せるPython関数の一覧。ユーザーのリクエストがdocstringと一致したとき、モデルがその関数を呼び出す

Cloud Runへのデプロイ——1コマンドで完結

IAMパーミッションの設定（最重要、忘れると詰まる）

Google Cloudではサービス間の信頼はデフォルトで存在しない。Cloud RunインスタンスがAgent Platformのエンドポイントを呼べるよう、明示的に権限を付与する必要がある。これが「管理不要」ではない代表的な手順だ。

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="serviceAccount:YOUR_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

記事では「デプロイ後にパーミッションエラーが出たらここに戻れ」と明記されており、この手順を踏み忘れるケースが多いようだ。サービスアカウントの作成・管理自体も開発者の責任となる点に注意が必要だ。

ビルドとデプロイ

ADKにはワンコマンドのデプロイパスが同梱されている。内部的にはコンテナイメージのビルド、Artifact Registryへのプッシュ、Cloud Runサービスの作成（または更新）を一括で行う。

adk deploy cloud_run \
    --project="YOUR_PROJECT_ID" \
    --region="us-central1" \
    --service_name="agent-inference-backend" \
    path/to/your/agent

推論モードの選択——Online vs Batch

デプロイ後、推論をトリガーする方法は2つある。判断基準は「今すぐ人間が答えを必要としているか」だ。

Online inference（低レイテンシ）：Cloud Runのフロントエンドからエージェントエンドポイントへ同期APIコールを行う。カスタマーサポートチャットボットなど、レイテンシが重要なリアルタイム用途向け
Batch inference（大量データ処理）：Agent Platform SDK経由で非同期のバッチ予測ジョブを投入する。プラットフォームが専用コンピュートをプロビジョニングし、結果をCloud Storageに書き出して自動的にリソースを解放する。10万件のサポートチケットを夜間に一括分類するようなユースケース向け

目安として「2秒以内のレスポンスが必要ならOnline、数分〜数時間待てるならBatch」という判断基準が紹介されている。Batchはリクエストあたりのコストが大幅に安くなる。

本番運用のためのセキュリティと監視

イングレスの保護：Cloud RunエンドポイントをIAP（Identity-Aware Proxy）でラップする。IAPはトラフィックがコードに到達する前にGoogleアイデンティティを検証する。エージェントからツールへのトラフィックにはAgent Gatewayを使い、MCPサーバーとのmTLS（相互TLS認証）を実現できる

用語補足：Agent Gatewayとは
Google Cloud上でエージェントと外部ツール・MCPサーバー間のトラフィックを仲介するコンポーネントだ。認証・認可・暗号化を一元的に管理し、各ツール呼び出しのセキュリティ境界を担う。

トレースログの集中管理：OpenTelemetryトレーシングを有効にすることで、推論タスクにおける各推論ステップ・モデル呼び出し・ツール呼び出しをDAG（有向非循環グラフ）として可視化できる。エージェントが予期しない回答を返したとき、原因究明に使える

まとめ

記事が示すアーキテクチャは「Cloud Runに自分のコード、Agent Platformにオーケストレーション」という役割分担の徹底にある。ADKを使えばツールはPython関数として定義でき、デプロイは1コマンドで完結する。

このアーキテクチャが特に有効なのは、すでにCloud RunやGCPのエコシステムを使っているチームが、MLインフラの構築・運用コストをかけずにエージェント機能を既存サービスへ組み込みたい場面だ。一方で、IAM設定・サービスアカウント管理・Cloud Runのインフラ設定は依然として開発者が担う必要があり、「すべてが自動的に管理される」わけではない点は把握しておきたい。ゼロからMLインフラを構築することに比べれば運用負荷は大幅に軽減されるが、GCPの基本的な権限管理の知識は前提として求められる。

まず1つのツールだけを持つ最小構成のエージェントをadk deploy cloud_runでデプロイし、リクエストを投げてみることが推奨されている。

詳細はManaged Inference on Google Cloud: Pairing the Gemini Enterprise Agent Platform with Cloud Runを参照していただきたい。