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

TL;DR

Agent Registry への Non-a2a 登録自体はできた（URN 確認）
GE から使うには Agent Gateway の構成が必要と思われる（プロジェクト全体に影響しそうな設定）
正式な統合には A2A プロトコル対応が必要（今回の構成では A2A 未設定）
スケジューラーへの道は Agent Registry 経由でも簡単ではなかった

背景と仮説

前回の記事で、ADK エージェントを GE（Gemini Enterprise）に Agent Runtime として登録しましたが、スケジュール実行の方法は見つかりませんでした。

GE のウェブアプリでエージェントを開くと、3点リーダー（⋮）のメニューに「編集」があります。
そこから Agent Builder に入ることでスケジュールを設定できます。

ADK エージェント（Agent Runtime）にはこの「編集」がありません。
原因として最も有力、というよりほぼ事実として、GE で作成したエージェントでなければ「編集」メニューが出ないという設計上の制限があります。

しかし、ここで引き下がるわけにはいきません。
手がかりを探して GE の管理画面を改めて見直すと、気になる警告が表示されていました。

このエージェントは Agent Registry と統合されておらず、ゲートウェイポリシーは適用されません。

GE で作成したエージェントにはこの警告がありません。
この違いが「編集」メニューの有無に関係しているのではないか。統合すれば「編集」メニューが出るのではないかと考えました。

【仮説】
GE で作成したエージェント
  → Agent Registry の情報あり → 「編集」メニューあり → スケジューラー ✅

ADK エージェント（Agent Runtime として登録）
  → Agent Registry の情報なし → 「編集」メニューなし → スケジューラー ❌

∴ Agent Registry に統合すれば「編集」メニューが出るのでは？

今回はこの仮説を検証しました。

Agent Registry とは

まず整理します。

サービス	役割
Agent Runtime	ADK エージェントを実行する環境（`reasoningEngines/xxxxx`）
Agent Registry	エージェント・MCP サーバー・ツールを登録・検索・管理するカタログ

Agent Registry は Google Cloud 上のエージェントの「名簿」のようなもので、GE はここを参照してエージェントを管理します。

検証：Agent Registry への登録を試みる

Step 1：Agent Registry にエージェントを登録する

https://console.cloud.google.com/agent-platform/agent-registry/agents から「Add agent」を押すと、登録フォームが表示されました。

Type：Non-a2a / a2a
Name
Description
リージョン
エンドポイント

今回の ADK エージェントは A2A（Agent2Agent）プロトコルの設定をしていないため、Non-a2a を選択し、エンドポイントに既存の Agent Runtime の URL を入力して登録しました。

https://us-central1-aiplatform.googleapis.com/v1/projects/your-project/locations/us-central1/reasoningEngines/xxxxxxxxxx

登録後、2つの URN を確認できました。

urn:agent:...:agentregistry:services:agent-your-agent-xxxx-xxxxxxxxxxxx
urn:agent:...:aiplatform:reasoningEngines:xxxxxxxxxx

Step 2：GE から使うには Agent Gateway の構成が必要と表示された

GE の画面（https://console.cloud.google.com/gemini-enterprise）でアプリを選び、「エージェント」→「エージェントを追加」を開きます。
「Agent Registry のエージェント」を選ぶと、次のメッセージが表示されました。

Agent Gateway を構成すると、プロジェクトの Agent Gateway レジストリからエージェントを検出して使用できます。

「Agent Gateway を構成」を押すと、セキュリティ設定ページに遷移しました（CMEK・Model Armorなどの構成がまとめて並んでいるページです）。
プロジェクト全体に影響しそうと判断し、今回は断念しました。

公式ドキュメントで分かったこと

Agent Gateway を設定すればよいかもしれませんが、そもそも Non-a2a 登録で正式に統合できるのかが気になりました。
公式ドキュメントを調べると、重要な要件が書かれていました。

Agent Registry の公式ドキュメントによると、カスタム ADK エージェントを正式に Agent Registry に統合するには A2A プロトコルへの対応が必要です。

Agent Registry がカスタムエージェントの機能を認識できるようにするには、エージェントが Agent2Agent（A2A）プロトコルを使用してメタデータと使用可能なスキルを公開する必要があります。

具体的には：

エージェントが /.well-known/agent-card.json でエージェントカードを公開する必要がある（ADK の A2A サーバープラグインを使うと自動生成できる）
エージェントカードをローカル JSON として保存し、gcloud agent-registry services create で --agent-spec-type=a2a-agent-card --agent-spec-content=agent-card.json などを指定して登録する

今回の ADK エージェントは Agent Runtime にデプロイした状態で A2A 対応の設定をしていませんでした。
Non-a2a として登録する形を試みましたが、これが正式な Agent Registry 統合として機能するかは不明のままです。

結果

確認事項	結果
Agent Registry への登録（Non-a2a）	登録自体はできた（URN 確認）
GE から使うための要件	Agent Gateway の構成が必要と思われる（プロジェクト全体に影響しそう）
「編集」メニューが出るか	未確認（Agent Gateway 設定まで至らなかった）
正式な Agent Registry 統合の要件	A2A プロトコル対応が必要（今回の構成では A2A 未設定）

Agent Gateway を設定すれば「編集」メニューが出るかもしれませんが、A2A 対応の設定をしないままでは正式な統合にはならない可能性もあり、確認できませんでした。

まとめ

ADK エージェントを GE のスケジューラーに繋げるために Agent Registry への統合を試みましたが、以下の障壁が判明しました。

Agent Gateway の構成が必要と思われる — GE から Agent Registry のエージェントを使うために必要と思われる。プロジェクト全体に影響しそうと判断し今回は断念
A2A プロトコル対応が必要 — 正式な Agent Registry 統合には A2A プロトコル対応が必要。今回の構成では A2A 対応の設定をしていなかった

スケジューラーへの道は当初の想定より複雑でした。
ADK エージェントをそのまま GE のスケジューラーに繋げる方法は、見つけられませんでした。

結局 Cloud Run Job + Cloud Scheduler に切り替えましたが、その判断は改めて正しかったと感じています。

参考