お客様のDXの推進やクラウド活用をサポートする
NRIグループのプロフェッショナルによるブログ記事を掲載

Agent Development Kit (ADK) と MCP サーバー を Cloud Run で動かすための実践ガイド

坪井 宏樹 - Google Cloud Partner Top Engineer 2025

 

はじめに

こんにちは。Google Cloud Partner Top Engineer 2025 の General カテゴリに選出いただきました、NRI の坪井です。 先日ラスベガスで開催された Google Cloud Next '25 にご招待いただき参加してきました。現地では生成 AI、特に自律的にタスクを実行する「AI エージェント」に関する発表が相次ぎ、その重要性がますます高まっていることを肌で感じました。

同イベントで発表された Agent Development Kit (ADK) は、まさにこのような AI エージェントの開発とデプロイのための、柔軟でモジュール化されたフレームワークです。

さらに、エージェントが外部ツールやデータソースと連携するためには、Model Context Protocol (MCP) というプロトコルが重要になりますが、MCP も発表されてから日が浅い技術のため、ローカルで MCP サーバーを起動してそこに接続することを前提とした実装が多く見られます。この記事では、Cloud Run というサーバーレスプラットフォーム上で、ADK アプリケーション と MCP サーバー (サイドカー) を HTTP 経由で連携 させる構成に関する技術的な知見、具体的な実装方法、そして得られた学びを共有します。Google Cloud Next '25 で示された AI エージェントの未来を、具体的なコードと共に探求していきます。

想定読者

  • Google Cloud Run の基本的な利用経験がある方
  • ADK や MCP についてはこれから学びたい、あるいは興味がある方
  • Google Cloud Next '25 の発表内容を見て、AI エージェント開発を始めたいと考えている方
  • 生成 AI エージェント開発のスケーラブルな実行環境を模索している方

この記事でわかること

  • ADK、MCP、そして Cloud Run (マルチコンテナ) の基本的な概念
  • ADK アプリケーションと MCP サーバーサイドカーを HTTP で連携させるシステム構成
  • ADK (Python) 側での MCP サーバー (HTTP エンドポイント) への接続方法 (コード例含む)

 AI エージェント開発の新たな可能性を探る一助となれば幸いです。

 

コア技術の紹介

本記事で取り上げる主要な技術要素について、簡単にご紹介します。


Agent Development Kit (ADK)
とは?

Google Cloud Next '25 で発表された Agent Development Kit (ADK) は、AI エージェントの開発とデプロイのための、柔軟でモジュール化されたフレームワークです。公式には次のように説明されています。

ADK は Gemini と Google のエコシステムに最適化されているものの、モデルやデプロイ環境に依存せず、他のフレームワークとの互換性も考慮して構築されています。ADK は、エージェント開発をよりソフトウェア開発のように感じられるように設計されており、開発者が単純なタスクから複雑なワークフローに至るまで、エージェント指向のアーキテクチャを簡単に作成、デプロイ、オーケストレーションできるようにします。

つまり、ADK を使うことで、開発者はより効率的に、そしてソフトウェア開発のベストプラクティスを取り入れながら、複雑な AI エージェントを構築できるようになります。

Model Context Protocol (MCP) とは?

Model Context Protocol (MCP) は、AI モデル (エージェント) が外部のツールやデータソースとやり取りするための標準化された方法を提供するプロトコルです。エージェントが必要とする機能 (例: ファイル操作、データベース検索、API 呼び出しなど) を「ツール」としてカプセル化し、MCP サーバーを介してエージェントに提供します。
これにより、エージェントのコアロジックと外部機能の実装を分離でき、再利用性や保守性が向上します。ADK は MCP とシームレスに連携するように設計されており、MCP サーバーが提供するツールを簡単にエージェントから利用できます。

Cloud Run
で動かすメリット

Cloud Run は、コンテナ化されたアプリケーションをスケーラブルかつサーバーレスで実行できる Google Cloud のサービスです。

コンテナサービスとしてのCloud Run を選択した主なメリットは以下の通りです。

  • スケーラビリティ: リクエスト数に応じて自動的にスケールイン/アウトするため、エージェントへのアクセスが増減しても安心です。
  • マルチコンテナサポート: Cloud Runはサイドカーコンテナをサポートするため、ADK アプリケーションコンテナに加えて MCP サーバーコンテナをサイドカーコンテナとして一つのサービス内でまとめてデプロイ・管理できます。これにより、MCP サーバーコンテナの不要な外部公開を避けつつ、簡単にAIエージェントからのMCP呼び出しをサポートすることができます。
  • コスト効率: リクエスト処理中にのみ課金されるため、アイドル時のコストを抑えられます (最小インスタンス設定による考慮点はあります)。
  • マネージドサービス: インフラ管理の手間が少なく、アプリケーション開発に集中できます。
  • VPCとの親和性: Cloud RunはDirect VPC Egressを代表とするVPCアクセスの構成をサポートするほかVPC Service Controlsにも対応しているため、既存のVPC上のリソースへのアクセスとの親和性が非常に高いです。

これらの点から今回はCloud Run上にADKを用いたアプリケーションのデプロイを試してみました。次のセクションでは、具体的なシステム構成について見ていきましょう。

 

システム構成

今回構築したシステムの全体像は以下のようになります。Cloud Run のマルチコンテナ機能を活用し、ADK アプリケーションコンテナと、機能を提供する MCP サーバーコンテナをサイドカーとして同じインスタンス内にデプロイしています。



※1:Google CloudのAPI経由でCloud SQLに接続することもできますが、今回はDirect VPC Egress経由でpsql接続する方式を採用

※2:Cloud Storageへの接続はCloud RunへのCloud Storageボリュームのマウントを利用し、Filesystem MCP サーバーからはローカルのファイルシステムへのアクセスのようにラップする方式を採用

ポイント:

  • ADK アプリケーションコンテナ: ユーザーからのリクエスト (Cloud Run サービスが HTTPS/443 で受け付け、コンテナ内のポート8080に転送) を処理し、エージェントのロジックを実行します。
  • MCP サイドカーコンテナ:
    • Filesystem MCP サーバーコンテナ: GCS へのファイル操作を提供します。supergateway というラッパーを介して、ポート 8000 の /sse エンドポイントで SSE (Server-Sent Events) 通信を受け付けます。
    • Cloud SQL MCP サーバーコンテナ: Googleが開発したデータベース用のオープンソースMCP サーバーの genai-toolbox(MCP Toolbox for Databases)を利用します。今回はgenai-toolboxのCloud SQL接続機能を利用してCloud SQL へのクエリ実行機能を提供します。genai-toolboxのプロセスが直接ポート 5000 で HTTP リクエストを受け付けます。
    • HTTP 連携: ADK アプリケーションは、ローカルホスト (localhost) 上の各 MCP サイドカーのポート (8000, 5000) に対して HTTP リクエスト (SSE または通常の HTTP) を送信することで、ツールを利用します。これにより、標準的なプロセス間通信 (stdio) の制約を受けずに、Cloud Run 環境で MCP サーバーを利用可能にしています。

この構成は、Cloud Run のサービス定義ファイルによって実現されます。次のセクションでは、この Cloud Run の設定と、実際の 各コンテナの設定、ADK アプリケーション側のコードを見ていきましょう。

 

実装

ここからは、実際にこのシステムを構築するための主要なステップと設定、コードのポイントを解説していきます。

1. (前提) 環境準備

詳細な手順は割愛しますが、以下の準備が整っていることを前提とします。

  • Google Cloud プロジェクトと課金の有効化
  • gcloud CLI のインストールと認証
  • Docker のインストール
  • Python 開発環境
  • (必要に応じて) Cloud SQL インスタンス、GCS バケット

2. MCP サーバーの準備 (コンテナイメージと Cloud Run 定義)

ADK アプリケーションから利用するツールを提供する MCP サーバーを、Cloud Run のサイドカーコンテナとしてデプロイします。今回は例として、ファイルシステム操作用の MCP サーバーと、Cloud SQL 操作用の MCP サーバーを用意します。

  • コンテナイメージのビルド:

まず、各 MCP サーバーの機能を持つコンテナイメージをビルドし、Artifact Registry などのコンテナリポジトリにプッシュします。

  • Filesystem MCP サーバーコンテナ:

公式の @modelcontextprotocol/server-filesystem (npm パッケージ) を使用します。これはファイルシステム操作のための MCP サーバーです。このサーバーは標準入出力 (stdio) で通信するため、そのままでは Cloud Run のサイドカーとして他のコンテナから HTTP でアクセスできません。
そこで supergateway を利用します。supergateway は、stdio ベースの MCP サーバーを HTTP (SSE または WebSocket) 経由でアクセス可能にするためのラッパーツールです (supercorp-ai/supergateway)。ADK アプリケーションは supergateway が公開する SSE エンドポイントに接続し、supergateway が内部で mcp-server-filesystem と stdio で通信します。
以下は、supergateway と mcp-server-filesystem を含む Docker イメージを作成する Dockerfile の例です。

クリックでコードサンプル展開
# build stage
FROM node:22-alpine as builder
# supergateway と mcp-server-filesystem を npm でグローバルインストール
RUN npm install -g \
 @latitude-data/supergateway@latest \
 @modelcontextprotocol/server-filesystem@latest
# runtime stage
FROM node:22-alpine
WORKDIR /app
# ビルドステージから必要なファイルをコピー
COPY --from=builder /usr/local/lib/node_modules/usr/local/lib/node_modules
COPY --from=builder /usr/local/bin /usr/local/bin
# supergateway がリッスンするポート
ENV GATEWAY_PORT=8000
EXPOSE ${GATEWAY_PORT} 
ENTRYPOINT [ "supergateway" ]

 

  • Cloud SQL MCP サーバーコンテナ:

Google が提供する genai-toolbox のイメージをそのまま使用します。
このサーバーは HTTP インターフェースを持つため、直接利用できます。

注意点
genai-toolbox は起動時に設定ファイル (例: tools.yaml) を必要とします。このファイルにはデータベース接続情報などのシークレットが含まれる可能性があるため、コンテナイメージに直接含めるのではなく、Cloud Run の Secret Manager 連携機能やGCSボリュームマウント等を利用して安全に渡すことを推奨します。

 

  • Cloud Run サービス定義:

次に、Cloud Run サービスを定義する YAML ファイルを作成します。これが今回の構成の核心部分です。ADK アプリケーションコンテナと MCP サーバーサイドカーコンテナを一つのサービス内に定義します。

クリックでコードサンプル展開
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: adk-mcp-service # サービス名
  annotations:
    run.googleapis.com/ingress: internal # 必要に応じて internal / all を設定
    # 重要: コンテナ間の起動依存関係を定義
    run.googleapis.com/container-dependencies: '{"adk-app":["filesystem-mcp","cloudsql-mcp"]}'
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: "5" # スケーリング設定
        # ... その他アノテーション ...
    spec:
      containers:
        # --- ADK Application Container ---
        - image: YOUR_ADK_APP_IMAGE_URL # ADKアプリのイメージURL
          name: adk-app # メインコンテナ名
          ports:
            - containerPort: 8080 # アプリがリッスンするポート
          resources:
            limits:
              cpu: 1000m
              memory: 512Mi
          # ... 環境変数、Secret設定など ...
        # --- Filesystem MCP Sidecar Container ---
        - image: YOUR_SUPERGATEWAY_IMAGE_URL # 上記DockerfileでビルドしたイメージURL
          name: filesystem-mcp # サイドカー名 (依存関係定義で使用)
          args:
            - --port
            - "8000" # supergatewayがリッスンするポート
            - --stdio
            - mcp-server-filesystem /storage # 内部で実行するstdioベースのMCPサーバーコマンド
          resources:
            limits:
              cpu: 1000m
              memory: 512Mi
          volumeMounts: # GCSバケットをマウントする場合
            - mountPath: /storage
              name: gcs-volume
        # --- Cloud SQL MCP Sidecar Container (genai-toolbox) ---
        - image: YOUR_GENAI_TOOLBOX_IMAGE_URL # genai-toolbox のイメージURL
          name: cloudsql-mcp # サイドカー名 (依存関係定義で使用)
          command: ["/toolbox"] # サーバー起動コマンド
          args:
            - --address
            - 0.0.0.0:5000 # toolboxがリッスンするアドレスとポート
            - --config_file=/path/to/tools.yaml # 設定ファイルのパスを指定
            # ... その他 toolbox への起動引数 ...
          volumeMounts: # 設定ファイルやシークレットをマウントする場合
            - name: tools-yaml
              mountPath: /path/to/ # 設定ファイルが格納されるディレクトリ
          resources:
            limits:
              cpu: 1000m
              memory: 512Mi
          # ... Cloud SQL Proxy等の設定が必要な場合はここに追加 ...
      # Secret Managerをマウントするためのボリューム定義
      volumes:
      - name: gcs-volume
        csi:
          driver: gcsfuse.run.googleapis.com
          volumeAttributes:
            bucketName: 
      - name: tools-yaml
        secret:
          secretName: TOOLS_YAML
          items:
          - key: latest
            path: tools.yaml

# ... ServiceAccount, Traffic設定など ...


重要なポイント:

  • containers 配列: adk-app, filesystem-mcp, cloudsql-mcp の 3 つのコンテナを定義しています。
  • run.googleapis.com/container-dependencies アノテーション: adk-app コンテナが起動する前に、filesystem-mcp と cloudsql-mcp サイドカーが起動完了していることを保証します。これにより、ADK アプリは起動直後から MCP サーバーを利用できます。
  • Filesystem MCP サーバーコンテナの設定:
    • supergateway を含むイメージを使用し、起動引数でポート 8000 を指定し、内部で mcp-server-filesystem コマンドを実行するように設定しています。
    • GCS バケットをマウントする場合は volumeMounts と volumes を設定します。
  • Cloud SQL MCP サーバーコンテナの設定:
    • genai-toolbox の toolbox イメージを使用し、起動コマンドと引数でポート 5000 でリッスンするように設定しています。
    • リッスンアドレス: 起動引数 --address 0.0.0.0:5000 のように 0.0.0.0 を指定することが必要です。デフォルトは 127.0.0.1 になっており、同じインスタンス内の他のコンテナ (ADK アプリケーションコンテナ) からアクセスできません。
    • 設定ファイルの管理: 起動引数 --config_file で設定ファイルのパスを指定します。この設定ファイルにシークレット情報を含む場合は、Secret Manager からボリュームマウントするなどして安全にコンテナ内に配置することを推奨します。
  • ポート: 各コンテナがリッスンするポート (8080, 8000, 5000) が衝突しないように設定します。ADK アプリは localhost:8000 や localhost:5000 にアクセスすることで、サイドカーと通信します。

この YAML ファイルを gcloud run services replace コマンドなどでデプロイすることで、マルチコンテナ構成の Cloud Run サービスが起動します。

3. ADK アプリケーションの開発 (MCP クライアント部分)

次に、ADK アプリケーション側で、Cloud Run 上の MCP サーバーサイドカーに接続し、ツールを利用する部分の実装を見ていきます。

MCP ツールセットの取得:

エージェントが利用するツールセットを、サイドカーとして動作している MCP サーバーから取得します。以下のコードは、Filesystem MCP サーバーと Cloud SQL MCP サーバーの両方に接続するエージェントをsample_agentとして実装する例です。
クリックでコードサンプル展開
# sample_agent/agent.py (抜粋)
from google.adk.agents.agent import Agent # Agent base class
from google.adk.agents.llm_agent import LlmAgent
from google.adk.agents.loop_agent import LoopAgent
from google.adk.agents.sequential_agent import SequentialAgent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset, SseServerParams
from google.adk.tools.toolbox_tool import ToolboxTool

async def get_tools_async():
  """Cloud Run上のMCPサイドカーからツールを取得する"""
  print("Attempting to connect to MCP Filesystem server (Sidecar)...")
  # Filesystem MCP (supergateway@localhost:8000) へSSEで接続
  filesystem_tools, exit_stack = await MCPToolset.from_server(
      connection_params=SseServerParams(url="http://localhost:8000/sse") # localhost:8000/sse を指定
  )
  print("Filesystem MCP Toolset created successfully.")

  print("Attempting to connect to Cloud SQL MCP server (Sidecar)...")
  # Cloud SQL MCP (toolbox@localhost:5000) へHTTPで接続
  toolbox = ToolboxTool("http://localhost:5000") # localhost:5000 を指定
  cloudsql_tools = toolbox.get_toolset(toolset_name="all_toolset") # Toolboxからツールセット取得
  print("Cloud SQL MCP Toolset created successfully.")

  return filesystem_tools, cloudsql_tools, exit_stack

async def create_agent():
  """MCPから取得したツールを使ってエージェントを作成"""
  filesystem_tools, cloudsql_tools, exit_stack = await get_tools_async()

  GEMINI_MODEL = 'gemini-2.5-pro-preview-03-25' # モデル名は適宜変更

  # --- エージェント定義 ---
  filesystem_agent = LlmAgent(
      # ... (name, description, instructionなど)
      model=GEMINI_MODEL,
      tools=filesystem_tools,
  )

  cloudsql_agent = LlmAgent(
      # ... (name, description, instructionなど)
      model=GEMINI_MODEL,
      tools=cloudsql_tools,
  )

  # 全体を統括するルートエージェント
  root_agent = Agent(
      model=GEMINI_MODEL, # Assuming root agent needs LLM
      sub_agents=[filesystem_agent, cloudsql_agent] # 上で定義したエージェントをサブエージェントとして指定
  )

  return root_agent, exit_stack # ルートエージェントと exit_stack を返す
  


重要なポイント:

  • 接続先 URL: MCP サーバーへの接続先として、localhost と cloudrun.yaml で定義した各サイドカーのポート (8000, 5000) を指定しています。Cloud Run の同一インスタンス内では、コンテナは localhost を通じて互いに通信できます。
  • Filesystem MCP サーバー接続:
    • MCPToolset.from_server を使用します。
    • connection_params として SseServerParams を渡し、supergateway が公開している SSE エンドポイント(http://localhost:8000/sse) を URL に指定します。ADK は SSE を通じて supergateway と通信し、supergateway がそれを内部の mcp-server-filesystem の stdio に変換します。
  • Cloud SQL MCP サーバー接続:
    • ToolboxTool を使用します。
    • 初期化時に toolbox サーバーがリッスンしている HTTP エンドポイント(http://localhost:5000) を直接指定します。
    • get_toolset() メソッドでツール定義を取得します。
  • 非同期処理: ツールセットの取得 (get_tools_async) やエージェントの作成 (create_agent) は非同期 (async def) で定義されています。ADK アプリケーションのエントリーポイント (例: main.py) で非同期処理を適切に実行する必要があります。

このように、ADK が提供するクライアントライブラリ (MCPToolset, ToolboxTool) を利用することで、HTTP エンドポイントとして公開されている MCP サーバーにも容易に接続できることがわかります。

ADK アプリケーションのエントリーポイント (main.py):

ADK アプリケーションを Cloud Run でホストするためのエントリーポイントです。ADKが提供する get_fast_api_app を利用すると、エージェントの初期化、HTTP エンドポイントの公開、セッション管理などを簡単に行えます。

クリックでコードサンプル展開
# main.py
import os
import uvicorn
from fastapi import FastAPI
from google.adk.cli.fast_api import get_fast_api_app

AGENT_DIR = os.path.dirname(os.path.abspath(__file__))
# セッションDB URL (e.g., SQLite)
SESSION_DB_URL = "sqlite:///./sessions.db"
# CORS設定(例)
ALLOWED_ORIGINS = ["http://localhost", "http://localhost:8080", "*"]
# WEBインターフェースを利用するか
SERVE_WEB_INTERFACE = True

app: FastAPI = get_fast_api_app(
    agent_dir=AGENT_DIR,
    session_db_url=SESSION_DB_URL,
    allow_origins=ALLOWED_ORIGINS,
    web=SERVE_WEB_INTERFACE,
)

if __name__ == "__main__":
    # Cloud Runに与えられるPORT環境変数を利用する
    uvicorn.run(app, host="0.0.0.0",port=int(os.environ.get("PORT", 8080)))


Dockerfile
の準備:

この ADK アプリケーション (main.py と 先ほど作成したsample_agent) をコンテナ化するための Dockerfile です。

クリックでコードサンプル展開
# Dockerfile (例)
FROM python:3.13-slim
WORKDIR /app
RUN adduser --disabled-password --gecos "" myuser && \
    chown -R myuser:myuser /app # requirements.txt をコピー (プロジェクトルートにあると仮定) COPY requirements.txt .
USER myuser ENV PATH="/home/myuser/.local/bin:$PATH" # 依存関係のインストール RUN pip install --no-cache-dir -r requirements.txt # pythonソースをコピー COPY . . # コンテナ起動時にWebサーバーを実行 CMD ["sh", "-c", "uvicorn main:app --host 0.0.0.0 --port $PORT"]


これで、ADK アプリケーション側の準備は完了です。ビルドしたイメージを Cloud Run にデプロイすれば、MCP サイドカーと連携して動作する AI エージェントサービスが構築できます。

 

開発時のポイントと注意点

実際にこの構成で開発を進める中で、いくつか注意すべき点や Tips があります。

ローカル開発から Cloud Run への移行

ADK の Getting Started など、多くのドキュメントはローカル環境での実行を前提としています。Cloud Run へ移行する際には、以下の点を考慮する必要がありました。

  • MCP サーバーへの接続: ローカルでは subprocess などで起動した MCP サーバープロセスに stdio で接続することが多いですが、Cloud Run ではサイドカーコンテナの localhost:<port> に HTTP (または SSE) で接続するように、agent.py の get_tools_async 関数などを修正する必要があります。
  • 環境変数とシークレット: ローカルでは .env ファイルで管理していた API キーやデータベース接続情報などの機密情報は、Cloud Run の Secret Manager を利用し、環境変数またはボリュームマウントで安全にコンテナに渡すように変更することが推奨されます。

HTTP 経由の MCP 通信

stdio の代わりに HTTP で MCP サーバーと通信する今回の構成特有のポイントです。

  • stdio vs HTTP: stdio はシンプルですが、プロセス管理やスケーリングの点で制約があります。HTTPを使うことで、Cloud Run のようなマネージド環境との親和性が高まり、デプロイやスケーリングが容易になります。一方で、HTTP 通信のためのラッパー (supergateway) や、MCP サーバー側の HTTP 対応が必要になります。
  • supergateway の利用: stdio ベースの MCP サーバー (例: mcp-server-filesystem) を HTTP/SSE で公開するための便利なツールです。Cloud Run でMCP サーバーコンテナをサイドカーとして定義し、ADK 側からは MCPToolset や SseServerParams で接続します。
  • genai-toolbox (toolbox) の利用:  genai-toolboxはCloud SQL などの Google Cloud 上のデータベース向け MCP ツールを提供し、HTTP インターフェースを持っています。ADK 側からは ToolboxTool で接続します。
    • リッスンアドレス: サイドカーとして使う場合、起動時に --address 0.0.0.0:<port> を指定し、他のコンテナからのアクセスを許可する必要があります。
    • 設定ファイル: データベース接続情報などを含む設定ファイルを、Secret Manager などを使って安全に渡す必要があります。
  • ポート管理: 各コンテナ (ADK アプリ、supergateway、toolbox など) が使用するポートが衝突しないように Cloud Run の設定で管理します。

デバッグ

マルチコンテナ環境でのデバッグは少し複雑になります。

  • Cloud Logging: 各コンテナの標準出力・標準エラー出力は Cloud Logging に集約されます。Cloud Run の設定で各コンテナに name を付けておくと、ログのフィルタリングが容易になります。
  • ローカルでのテスト: Cloud Run 環境を完全にローカルで再現するのは難しい場合がありますが、Docker Compose などを使って、マルチコンテナ構成をローカルで擬似的に起動し、コンテナ間の通信を確認することは可能です。ただし、Google Cloud サービス連携 (IAM 認証、GCS マウント、Secret Manager など) の再現は困難な場合があります。

これらの点を押さえておくことで、ADK x MCP x Cloud Run 構成の開発をよりスムーズに進めることができるはずです。

 

まとめ

本記事では、Google Cloud Agent Development Kit (ADK) と Model Context Protocol (MCP) サーバーを、Cloud Run のマルチコンテナ機能とサイドカーパターンを活用し、HTTP 経由で連携させる構成について解説しました。
主なポイントは以下の通りです。

  • ADK MCP: エージェント開発を加速する ADK と、ツール連携を標準化する MCP は強力な組み合わせです。
  • Cloud Run サイドカー: MCP サーバーをサイドカーとしてデプロイすることで、スケーラブルな Cloud Run 環境で ADK と MCP を連携させることができます。
  • HTTP 連携: stdio の制約を回避するため、supergateway (SSE 変換)を利用して MCP サーバーと HTTP で通信するアーキテクチャを採用しました。
  • 実装上の注意点: Cloud Run の定義 (container-dependencies, ポート設定, リッスンアドレス)、ADK 側のクライアント実装 (MCPToolset, ToolboxTool)、設定ファイルの安全な管理などが重要です。

この構成は、特に Cloud Run のスケーラビリティやマネージドな特性を活かしたい場合に有効な選択肢となり得ます。ADK と MCP はまだ発展途上の技術ですが、AI エージェント開発の可能性を大きく広げるものです。

Google Cloud Next '25 で示された AI の未来に向けて、本記事が ADK や MCP、そして Cloud Run を活用した新しいエージェント開発に挑戦する方々の一助となれば幸いです。

 

参考リンク:

 

各種SNSでも情報を発信しています。ぜひフォローをお願いいたします。

 

        

 

atlax では、ソリューション・サービス全般に関するご相談やお問い合わせを承っております。

 

・atlax / クラウドの取り組み / Google Cloud

・atlax blogs / 2025/04/25 / 「Google Cloud 認定資格を週一ペースで取得、全冠してみた」

※ 記載された会社名 および ロゴ、製品名などは、該当する各社の登録商標または商標です。
※ アマゾン ウェブ サービス、Amazon Web Services、AWS および ロゴは、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
※ Microsoft、Azure は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
※ Google Cloud、Looker、BigQuery および Chromebook は、Google LLC の商標です。
※ Oracle、Java、MySQL および NetSuite は、Oracle Corporation、その子会社および関連会社の米国およびその他の国における登録商標です。NetSuite は、クラウド・コンピューティングの新時代を切り開いたクラウド・カンパニーです。