4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Gemini Enterprise に ADK エージェントを登録して、スケジュール実行を試みたら詰まった話

4
Last updated at Posted at 2026-07-25

本記事の情報は 2026年7月時点のものです。
GE および ADK は更新が速く、記事執筆後に状況が変わる可能性があります。

TL;DR

  • ADK エージェントを Gemini Enterprise(以下GE)に Agent Runtime(旧 Vertex AI Agent Engine) として登録することはできる
  • ただし GE から ADK エージェントをスケジュール実行させる方法は見つからなかった
  • adk deploy agent_engine には mcp パッケージを自動で含めないというハマりポイントがある
  • GE から Agent Runtime を呼ぶと 500 / 404 が返ることがある(原因不明)
  • 定期的に確実に動かしたいバッチ処理は、ADK より Cloud Run Job + Python スクリプトのほうが信頼性が高い

背景

検証環境: ADK 2.5.0 / Python 3.11

Google ADK(Agent Development Kit)でエージェントを構築しており、定期的にバッチ処理を実行させるスケジュール実行の方法を検討しました。

最初に以下の2案を検討しました。

  • A案: GE のスケジュール機能を ADK エージェントに直付けする
  • B案: Cloud Scheduler → Agent Runtime の REST API(:streamQuery)を定期的に叩く

A案のほうがシンプルなので、まず検証してみました。
結果的にはA案もB案も採用せず、Cloud Run Job に落ち着きましたが、その経緯を順に説明します。

GE への ADK エージェント登録手順

全体の流れ

① adk deploy agent_engine でデプロイ
        │
        ▼
② Agent Runtime にインスタンス作成
   (Resource: projects/your-project/locations/us-central1/reasoningEngines/xxxxxxxxxx)
        │
        ▼
③ GE 管理画面 → 「エージェントの追加」→「Agent Runtime」を選択
        │
        ▼
④ 推論エンジン(Resource name)を入力して登録

GE で選べるエージェント種別

GE の「エージェントの追加」では以下の種類が選べます(表示される種別は組織の設定や契約によって異なる場合があります)。

種別 説明
Agent Runtime 会社のポリシーに沿って自社で構築したエージェント
Dialogflow Dialogflow フレームワークを使用して構築されたエージェント
A2A A2A プロトコルで通信する、どこにでもデプロイできるカスタム エージェント
Marketplace すでに調達済みまたは Marketplace 経由で入手したエージェント
Agent Registry この GE インスタンス用に構成された Agent Gateway 内のレジストリのエージェント

「Agent Runtime」を選んで推論エンジンのリソース名を入力すると、ADK エージェントが GE のエージェント一覧に追加されます。

GE のウェブアプリで確認すると、3点リーダー(⋮)のメニューには「固定」と「情報」しかありません。

スクリーンショット 2026-07-25 11.42.39.png
ADK エージェント(Agent Runtime)のメニューは「固定」「情報」のみ

A案の検証結果:スケジュール実行の方法は見つからなかった

GE の管理画面にはスケジュール設定のタブはありませんが、これは GE で作成したエージェントも同様です。
スケジューラーに辿り着けないのは、GE ウェブアプリの「編集」メニューの有無にあります(次のセクションで説明します)。

スクリーンショット 2026-07-25 11.45.56.png
ADK エージェント(Agent Runtime)のコンソール詳細画面。スケジュール設定はない

→ A案はスケジュール実行の方法が見つかりませんでした。

GE で作成したエージェントとの違い

GE のUIで直接作成したエージェントは、3点リーダー(⋮)のメニューが異なります。

項目 ADK(Agent Runtime) GE で作成したエージェント
3点リーダー(⋮)のメニュー 固定・情報 固定・編集・共有・情報・削除
Agent Registry 未統合(警告あり) 統合済み

スクリーンショット 2026-07-25 12.01.08.png
GE で作成したエージェントは「編集」メニューから Agent Builder に入れる

GE で作成したエージェントは「編集」から Agent Builder(エージェント デザイナー)に遷移でき、そこでスケジュール設定が可能です。

スクリーンショット 2026-07-25 12.03.54.png
Agent Builder のスケジュール設定(繰り返し頻度・開始時刻・トリガープロンプトを指定できる)

ADK エージェント(Agent Runtime)にはこの「編集」メニューが存在せず、Agent Builder のスケジューラーに辿り着けません。
GE で作成したエージェントでないことが原因と考えられますが、詳細は未確認です。

adk deploy agent_engine でハマったこと

① mcp パッケージが Agent Runtime 環境に入らない

adk deploy agent_engine はエージェントフォルダに requirements.txt がないと mcp パッケージを含めません。

google.adk.tools.mcp_tool__init__.pytry/exceptmcp のインポートを囲んでおり、mcp がなくても黙って McpToolset が消えます
そのため、エージェントが実際に呼ばれたときに初めてエラーになります。

# google/adk/tools/mcp_tool/__init__.py(抜粋)
try:
    from .mcp_toolset import McpToolset
    __all__.extend(['McpToolset', ...])
except ImportError as e:
    logger.debug('MCP Tool is not installed')
    logger.debug(e)  # 黙ってログに流すだけ

実際に呼ぶと:

ImportError: cannot import name 'McpToolset' from 'google.adk.tools.mcp_tool'

対処: エージェントフォルダに requirements.txt を置く。

# your_agent/requirements.txt
mcp>=1.0.0
# ...その他のプロジェクト依存パッケージ

② GE から呼ぶと 500 / 404 が返る

GE から Agent Runtime を呼ぶと 500 Internal Server Error が返りました。
同じエンジンに対して時間をおいて試すと 404 Not Found になることもあり、原因は特定できていません。

Cloud Logging に以下のログが記録されます。

{
  "textPayload": "INFO: \"POST /api/stream_reasoning_engine HTTP/1.1\" 500 Internal Server Error",
  "resource": {
    "type": "aiplatform.googleapis.com/ReasoningEngine",
    "labels": {
      "resource_container": "XXXXXXXXXX",
      "location": "us-central1",
      "reasoning_engine_id": "XXXXXXXXXX"
    }
  },
  "logName": "projects/your-project/logs/aiplatform.googleapis.com%2Freasoning_engine_stdout"
}

GE と Agent Runtime の間に互換性の問題があると考えられますが、詳細は不明です。

結局どうしたか

A案はスケジュール実行の方法が見つかりませんでした。
B案(Cloud Scheduler → Agent Runtime REST)は、検討を進める中でそもそも定期バッチ処理に LLM を使うこと自体のデメリットが見えてきたため、試さずに Cloud Run Job に切り替えることにしました。

今回の検証で分かったのは、GE + ADK エージェント(Agent Runtime) の組み合わせはまだ成熟していないということです。

加えて、定期バッチ処理に LLM を使うことのデメリットも見えてきました。

観点 ADK エージェント(Agent Runtime) Cloud Run Job
実行の確実性 LLM 次第(ステップを飛ばす可能性) コードどおりに確定実行
コスト 毎回 LLM API 呼び出しが発生 Python 実行のみ
デバッグ ログが追いにくい 標準出力がそのままログ
スケジュール Cloud Scheduler → REST が必要 Cloud Scheduler → Job が直結

「漏れなく確実に通知する」という要件には、Cloud Run Job + Python スクリプトで決定的に実装するほうが信頼性が高いという結論になりました。

Cloud Scheduler(定期実行)
        │
        ▼
   Cloud Run Job(Python コンテナ)
        │
        ├─ 外部 API …… 対象データを検索
        └─ 外部 API …… 通知送信

まとめ

項目 ポイント
GE への登録 Agent Runtime として登録はできる
スケジュール GE から ADK エージェントをスケジュール実行させる方法は見つからなかった
原因 Agent Builder への経路(「編集」メニュー)がなく、スケジューラーに辿り着けない(GE で作成したエージェントでないことが原因と推測)
requirements エージェントフォルダに requirements.txt を置く(mcp 等を明示)
互換性問題 GE から Agent Runtime を呼ぶと 500 / 404 が返ることがある(原因不明)
バッチ処理 確実に動かすなら ADK より Cloud Run Job + Python

GE は面白いプラットフォームです。
バッチ定期実行との相性は、今後のアップデートが楽しみです。

続編

この記事の後、Agent Registry への統合を試みた話を書きました。
良かったらご覧ください。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?