Google CloudのAIエージェントを本番環境へ届ける3層アーキテクチャ — ADKからGemini Enterpriseまでのエンドツーエンド設計を解説

6月22日、Dr Roushanak Rahmatが「From ADK to Gemini Enterprise: Building Production-Grade AI Agents on Google Cloud」と題した記事を公開した。Google CloudのVertex AI Agent BuilderエコシステムとADK（Agent Development Kit）を使い、プロダクショングレードのAIエージェントを構築・デプロイするためのエンドツーエンドのアーキテクチャ設計について、実在する水インフラ企業を想定したケーススタディ「AquaFlow Systems」を軸に詳しく解説している。

単体のチャットボットから、複数のAPIやデータソースをまたいで自律的にタスクを実行する「エージェントシステム」への移行が、エンタープライズAI開発の主流になりつつある。しかしその実装には、セキュリティ、スケーラビリティ、UIとバックエンドの分離といった課題がつきまとう。本記事はその具体的な解法を体系的に示している。

なお、ADK（Agent Development Kit）はGoogleが提供するエージェント開発フレームワークであり、GitHubリポジトリで公開されている。また後述するReasoningEngineとは、Vertex AI上でエージェントのロジックをマネージドに実行するランタイム単位を指す概念で、Vertex AI Agent Engineの中核をなすコンポーネントだ。ADKが2025年4月にGA（一般提供）に達し、Vertex AI Agent Engineも同時期に正式サービス化されたことで、本記事が描くエンドツーエンドのパイプラインが実運用で利用可能になった。

3層アーキテクチャが設計の核心

記事が最も力を入れて説明しているのが、デカップルされた3層アーキテクチャの設計思想だ。

Layer 1（コード実行層）: ADKで記述されたPythonエージェントが動作するVertex AI Agent Engine
Layer 2（オーケストレーション層）: クエリのルーティングやReasoningEngineの管理を担うVertex AIマネージドランタイム
Layer 3（プレゼンテーション層）: 社員が実際に対話するGemini Enterpriseのチャットインターフェース

この分離により、UIを変えずにバックエンドロジックだけを更新したり、異なるエージェントを同一UIに接続したりできる。Vertex AI Agent Builder公式ドキュメントでは、この設計指針がプロダクション要件として推奨されている。

AquaFlow Systemsのケーススタディ

対象となる「AquaFlow Systems」は、スマート水インフラを管理する架空の企業だ。現場技術者向けに、次の機能を持つAIアシスタントを構築する想定である。

テレメトリデータを、現場エンジニアが即座に行動できる形に変換する
技術的なシステムアラートを「現場技術者の言葉」に書き換える
内部データベースからリアルタイムの運用データを取得する（将来的な拡張）

Step 1: ADKエージェントの実装

エージェントのコアロジックはPythonで記述する。モデルには低レイテンシを重視してGemini 2.5 Flashを採用している。

以下のコードは元記事が示す概念的なADKスタイルのサンプルであり、動作保証された実装コードではない点に注意されたい。実際の本番実装ではADK公式ドキュメントの仕様に従う必要がある。

# Conceptual ADK-style agent definition
from vertexai.preview import generative_models

def create_agent():
    system_instruction = """
    You are an expert field technician assistant for AquaFlow Systems.
    Your core responsibilities:
    1. Rewrite operational messages, alerts, and data logs into a friendly, simple, and helpful tone.
    2. Keep all responses short, actionable, and highly practical for engineers on-site.
    3. Avoid unnecessary corporate jargon or overly dense academic descriptions.
    """
    model = generative_models.GenerativeModel(
        model_name="gemini-2.5-flash"
    )
    return {
        "name": "AquaFlow Technician Assistant",
        "model": model,
        "instruction": system_instruction
    }

依存パッケージはgoogle-cloud-aiplatform、google-auth、pydantic、cloudpickleの4つだ。

Step 2: Vertex AI Agent Engineへのデプロイ

ローカルで動作確認したエージェントは、ADK CLIで1コマンドdeployできる。

adk deploy agent-engine \
  --display-name "AquaFlow Technician Agent" \
  --region us-central1 \
  aquaflow-agent

デプロイ時の内部動作は3段階だ。①PythonコードとdepsがGoogle Cloud Storageにコンテナとしてアップロードされ、②Vertex AI Agent Engineでランタイム環境が初期化され、③プラットフォームが一意のReasoning Engine IDを発行・登録する。

このIDは以下の形式で生成される：

projects/YOUR_PROJECT_ID/locations/us-central1/reasoningEngines/1234567890

この文字列がエージェントのグローバルアドレスとなり、以降のすべての接続設定で必要になる。必ず記録しておくこと。

Step 3: IAM認証とアクセス制御

エンタープライズ環境では、エージェントをそのまま外部に露出させることはできない。Gemini EnterpriseからAgent Engineを呼び出すには、以下2つのセキュリティ機構を適切に設定する必要がある。

IAMベースのサービス認証: サービスアカウントにroles/aiplatform.userロールを付与し、Gemini EnterpriseがAgent Engineリソースを安全に呼び出せるようにする
Workforce Identity FederationとOAuth: チャットインターフェースから入力するエンドユーザーが、エージェントのツール（インフラの機密データ等）を操作する組織権限を持っているかを検証する

Step 4: Gemini Enterpriseとの接続

認証設定が完了したら、Gemini Enterpriseの管理コンソール（Google Workspace管理画面内のGemini Enterprise設定ページ）から、Step 2で取得したReasoningEngineのリソースIDを登録する。登録後は、Gemini Enterpriseのチャットインターフェースに社員がクエリを送信すると、Layer 2のオーケストレーション層がそのクエリの内容を解釈し、登録済みのエージェントへ自動的にルーティングする仕組みだ。複数のエージェントを登録した場合は、クエリの意図に応じて適切なエージェントに振り分けられる。エンドユーザーから見れば、通常のGemini Enterpriseチャット画面を使うだけであり、バックエンドがADK製エージェントであることを意識する必要はない。

コードファーストか、ノーコードか

記事後半では、エンタープライズ設計で重要な選択基準としてコードファーストとノーコードの使い分けを解説している。Gemini Enterpriseは「Agent Designer」というUIも備えており、プロンプトベースのシンプルなエージェントをコードなしで構築できる。

記事の整理によれば、判断の軸はこうだ。複雑なオーケストレーション、企業APIとの統合、厳格なバージョン管理が必要な場合はコードファースト（ADK + Agent Engine）が適切であり、ビジネス部門が素早くプロトタイプを試したい場合はAgent Designerが有効だとしている。

詳細はFrom ADK to Gemini Enterprise: Building Production-Grade AI Agents on Google Cloudを参照していただきたい。