キャディ株式会社のデータ解析チームで、MLモデル開発をしている藤田です。 本記事では、私たちのチームで取り組んだ生産性改善の話をします。 1. 電線を張らずに電波塔を建てる？ アフリカの一部地域では、固定電話網が普及する前に携帯電話が一気に広まりました。電線を張り巡らせるという「これまで当たり前だった工程」を飛ばして、いきなり電波塔を建てることで通信インフラを整えたのです。いわゆる「リープフロッグ（蛙飛び）」と呼ばれる現象です。 新しい技術は、既存の工程を「速くする」だけでなく、ときに工程そのものを不要にすることがあります。 今回、私たちは機械学習の開発プロセスで、これと同じことをやりました。これまで、既存モデルのアップデートを自動化するには、ML パイプラインを構築するといった相応の開発が必要でした。しかし Agent Skills を使うことで、そのパイプライン開発という工程そのものをスキップして、効率的に自動化できたのです。電線（ML パイプライン）を張り巡らせる代わりに、電波塔（Agent Skills）を建てた、というわけです。 結果として、1モデルあたりの開発工数はおよそ半分（生産性は約2倍）になりました。この記事では、次の3点を紹介します。 なぜ、これまで自動化が続かなかったのか（ジレンマ） Agent Skills で何をやったか（電波塔を建てる） どれだけ効いたか（効果） 2. 本取り組みでの「生産性」とは 私たちのチームのミッションは、認識モデルを開発し、その成果物を素早く・安全にプロダクトへ届け続けることです。この生産性を測る指標の1つが 開発リードタイム（精度・速度が十分なモデルの平均開発期間）で、今回はこの短縮に絞って取り組みました。 3. どの作業に時間がかかっているか？ まず、工程を分解して、工数を圧迫している作業を洗い出しました。その中でも特に重かったのが「学習の実行」です。原因は大きく2つありました。 学習が自動化できておらず、手作業になっている ：実行のたびに人が張り付く必要がある。 既存コードの実行環境が古い ：既存モデルの精度を改善しようにも、当時のコードの実行環境（Docker image やライブラリのバージョン）が古く、そのままでは動かない。 実際には他にも様々なボトルネックに対策を打ちましたが、この記事では「学習の実行」に絞って紹介します。 4. これまでの取り組み 過去数年、学習の自動化（ML パイプライン構築）を何度か試みました。しかし、あまりうまくいきませんでした。 理由はシンプルで、「アップデートするための仕組みを作る・メンテナンスすること自体に工数がかかる」からです。 モデルごとに要件がバラバラ ：入力データも評価指標も学習手順もモデルごとに違うため、一度作った仕組みを他のモデルに使い回しにくい。汎用化しようとするほど、作り込みの工数が膨らむ。 メンテナンスコストがかさむ ：データやモデルの前提が変わるたびにパイプラインの改修が必要になり、工数がかかる。 ML パイプラインを一度組めば以降の再学習は自動化できます。しかし、その仕組みを作る工数があれば、その工数で手作業のモデルのアップデートや再学習ができてしまう。だったら手でやったほうが早い——そういう判断になりがちでした。 こうして、多くの試みは「割に合わない」か「作っても長続きしない」という形で終わっていきました。つまり私たちは、自動化したい気持ちはあるのに、自動化への投資が回収できないというジレンマをずっと抱えていたのです。 5. 対策：ML 開発で「電波塔」を建てる そこで目をつけたのが「Agent Skills」です。 専用のパイプラインをわざわざ開発しなくても、Agent Skills を用意しておけば、エージェントがその場に応じて作業を進めてくれる。ポイントは、新しく仕組みを作るのではなく、すでにある資産（README や学習コード）をエージェントにそのまま動かさせることです。これが、まさに「電線を張らずに電波塔を建てる」に相当します。 このやり方なら、これまで自動化が続かなかった原因そのものを避けられます。 初期工数が小さい ：パイプラインを作り込まないので「割に合わない」になりにくい。 壊れても直せる ：環境が古くて動かなくても、エージェントがエラーを解析し、修正案まで出してくれる。 対策①：Agent Skills で学習・評価・レポート作成を自動化 我々のチームでは、学習の実行から評価・レポート作成までの手順をREADMEに記載しています。そのREADMEに沿って学習を実行するようにエージェントに任せました。 学習実行 ：README の手順どおりに学習を実行する。 評価 ：精度・速度を測定する。 レポート作成 ：結果のレポートを作成する いずれも既存の Agent Skills を再利用でき、2件目以降のモデルはこのインフラに相乗りするだけで済みます。 対策②：学習実行 CI で「動く状態」を維持 README の手順どおりに学習を実行する Agent Skills を、hosted-runner 上でエージェントに動かさせます。ライブラリや実行環境が古くて動かないときは、エージェントがエラーを解析し、修正案まで出してくれます。これで、コードを常に「動く状態」に保てます。 %%{init: {'sequence': {'mirrorActors': false}}}%% sequenceDiagram participant Dev as エンジニア participant GH as Github participant GHA as Github Actions participant Agent as AIエージェント on hosted-runner Dev->>GH: コード修正、ライブラリのアップデート, etc GH->>GHA: readme実行のGithub Actionsを起動 GHA->>Agent: readme実行の Agent Skills を使い、学習を実行 Agent-->>GHA: 成功・失敗、実行結果レポート、改善案を提示 GHA-->>GH: 結果を返す フローは次のとおりです。 エンジニアが変更をプッシュ ：コード修正やライブラリのアップデートなどを Github に反映する。 CI が起動 ：その変更をトリガーに、README 実行用の Github Actions が走る。 エージェントが学習を実行 ：hosted-runner 上で、README 実行の Agent Skills を使ってエージェントが学習を回す。環境が古くて動かないときは、エージェントがエラーを解析し、修正案を組み立てる。 結果を返す ：成功・失敗の判定に加え、実行結果レポートと改善案を Github に返す。 これにより、変更が入るたびに「本当に動くか」を自動でチェックでき、コードを常に「動く状態」に保てます。 エージェントが作成する実行結果レポートのイメージがこちらです。エラーが出ても修正案まで示してくれるので、直すのがぐっと楽になります。 🧪 スモークテスト結果 — FAIL README 手順別サマリ README の手順 結果 備考（スキップ/失敗の理由・修正内容） セットアップ ✅ データ準備 ✅ 学習 ✅ test_run=True で 1 iteration 完了 export (TorchScript) ✅ det-gpu.pt 生成完了。 推論 ❌ 下記バグにより TypeError 発生。 発生したエラー（推論で TypeError） File "inference.py", line 1061, in main TypeError: 'NoneType' object is not iterable 原因 inference.py L985 の entry.get("results", []) は、Phase 1 で検出なしの画像に対して "results": null が JSON に書き込まれるため、キーは存在するが値が None になる。 修正提案 （以下のパッチで解消を確認） diff --git a/inference.py b/inference.py index 12038b3..a1d697d 100644 --- a/inference.py +++ b/inference.py @@ -982,7 +982,7 @@ def main( for entry in tqdm(entries): image_name = entry["file_name"] gcs_path = entry.get("gcs_path", "") - detection_results = entry.get("results", []) + detection_results = entry.get("results") or [] 新しく仕組みを作らず、既存資産（README・学習コード）を動かし続けることで、環境の再現性を保ちました。 6. 効果 結論から言うと、実際に生産性がおよそ2倍になりました。 過去に実際にかかった、既存モデル改善プロジェクトごとの工数と、今回かかった工数を、ざっくり比較すると、1モデルあたりの工数がおよそ半分——つまり生産性が約2倍になりました。 ※ 本来はプロジェクトごとに要件や状況が異なるため、単純比較はできません。ここではそれらをあえて無視した、ざっくりとした概算です。 効果が大きいのには理由があります。 「学習の実行」の自動化・環境維持が、工数削減に大きく寄与する 既存 Agent Skills を一度作ってしまえば、全てのプロジェクトで使うことができる まさに「電波塔を一度建ててしまえば、次からは同じインフラに相乗りできる」という構図です。最初のモデルで Agent Skills を整備しておけば、2件目以降はそのインフラに乗るだけで、劇的に軽くなります。 まとめ 新しい技術は、既存の工程を「速くする」だけでなく、ときに「工程そのものを不要にする」力を持っています。 アフリカが電線を飛び越えて電波塔で通信インフラを整えたように、私たちは ML パイプライン開発を飛び越えて、Agent Skills で機械学習の開発プロセスを自動化しました。その結果、1モデルあたりの工数はおよそ半分になり、生産性を約2倍に引き上げることができました。とくに既存モデル改善では、一度作った Agent Skills を再利用することで大きな工数削減を実現できています。 これからも Agent Skills のような新しい技術を開発プロセスに取り入れて、生産性を上げていきたいと思います。

G-gen の佐々木です。当記事では、Cloud Run にデプロイした AI エージェントや MCP サーバーにエージェント ID を割り当て、Agent Registry に自動登録する「 Cloud Run の Agent Platform 機能 」について解説します。 前提知識 Cloud Run とは Gemini Enterprise Agent Platform とは Agent Platform の概要 Agent Identity Agent Registry Cloud Run の Agent Platform 機能とは Agent Platform 機能の基本 機能タイプとアイデンティティタイプ 組み合わせによる挙動 エージェント ID への権限付与 自動付与される事前定義ロール Agent Registry への自動登録 注意点 制限事項 設定手順 当記事で扱う手順 事前準備 エージェントのデプロイ MCP サーバーのデプロイ 既存サービスの移行 エージェント ID の確認 Agent Registry での確認 エージェントの認証 Google Cloud API への認証 他の Cloud Run 上のエージェント・MCP サーバーへの認証 バインドトークンによる保護の強化 動作確認 検証構成 エージェントのソースコード デプロイ エージェントの呼び出し ロール付与前の動作 ロールの付与 ロール付与後の動作 監査ログでの確認 前提知識 Cloud Run とは Cloud Run は、コンテナを実行するための Google Cloud のフルマネージドなサーバーレスコンピューティングサービスです。サーバーの管理を必要とせず、コンテナイメージを指定するだけでアプリケーションを実行できます。 Cloud Run にはユースケースに応じたリソースタイプが存在し、Web アプリケーションや API のホスティング向けの Cloud Run services（以下、 サービス と記載）、バッチ処理やスケジュール実行向けの Cloud Run jobs（以下、 ジョブ と記載）、メッセージキューの pull 型処理向けの Cloud Run worker pools、長時間動作するエージェントなど、スケールしない単一プロセスの常駐向けの Cloud Run instances が提供されています。 Cloud Run の基本については、以下の記事を参照してください。 blog.g-gen.co.jp Gemini Enterprise Agent Platform とは Agent Platform の概要 Gemini Enterprise Agent Platform （旧称 Vertex AI、以下 Agent Platform と記載）は、AI エージェントの構築・デプロイ・管理のための機能群を提供する Google Cloud のプラットフォームです。 このうち、エージェントの統制を担う機能として、エージェント固有の ID を発行する Agent Identity 、エージェントやツールを登録して検出可能にする Agent Registry 、これらを参照して通信を制御する Agent Gateway があります。 Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、Agent Platform のワークロード認証コンポーネントです。AI エージェントや MCP サーバーなどのワークロードに、ワークロードごとに固有で、証明書によって検証可能な ID（ エージェント ID ）を割り当てます。 エージェント ID は SPIFFE（Secure Production Identity Framework for Everyone）標準に基づく書式を持ち、IAM 許可ポリシーでは principal:// から始まるプリンシパル識別子として指定します。 エージェント ID は、サービスアカウントと異なり、複数のワークロード間で共有されず、権限借用もできず、長期キーも生成できません。Google Cloud API 向けのアクセストークンはワークロードの X.509 証明書と結び付けて発行されるため、トークンが窃取されても他のワークロードから再利用できません。 当記事では、この Agent Identity を Cloud Run のサービスやジョブで有効にし、割り当てられたエージェント ID で認証する方法を解説します。 Agent Identity の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Registry Agent Registry は、組織内で承認されたエージェントやツールを登録し、他の開発者やエージェントから検出可能にする Agent Platform の中央ライブラリです。エージェントはエージェントカタログに、MCP サーバーは MCP サーバーカタログに登録されます。Google Cloud 上のエージェントだけでなく、サードパーティの MCP サーバーも登録できます。 登録されたメタデータは、Agent Gateway がアクセス制御を行う際にも参照されます。ただし、2026年9月現在、Agent Gateway が通信を制御できるランタイムは Agent Runtime（旧称 Agent Engine）と Gemini Enterprise のみで、Cloud Run 上のエージェントは制御の対象外です。 当記事では、Cloud Run のワークロードが Agent Registry に自動登録される仕組みと、登録されたエントリの確認方法を解説します。 Agent Registry、Agent Gateway の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp Cloud Run の Agent Platform 機能とは Cloud Run の Agent Platform 機能 （Agent Platform features for Cloud Run）は、Cloud Run のサービスやジョブで Agent Identity と Agent Registry を有効にする機能です。対象となるワークロードは、AI エージェントと MCP サーバーです。デプロイ時にワークロードの用途（エージェントまたは MCP サーバー）と ID の種類を宣言するだけで、以下の2つが自動で行われます。 ワークロードに対して、ワークロード固有で、証明書によって本物であることを検証できるエージェント ID が割り当てられる ワークロードがプロジェクトの Agent Registry に自動登録され、他の開発者やエージェントから検出可能になる 従来、Cloud Run のワークロードは、サービスアカウントを使用して他のサービスや Google Cloud API への認証を行っていました。Agent Platform 機能を使用すると、エージェントはサービスアカウントの代わりに自身専用のエージェント ID で他のエージェント・ツール・Google Cloud API に認証できます。 なお、Cloud Run には4種類のリソースタイプがありますが、2026年9月現在、Agent Platform 機能を設定できるのはサービスとジョブの2種類です。 参考 : Configure Agent Platform features for Cloud Run 参考 : Authenticate your AI agents この機能は2026年9月1日に Preview 公開されました。Preview 段階の機能は、サポートが限定される場合や、GA までに仕様が変わる可能性があるため、本番環境での使用は推奨されません。 参考 : Cloud Run release notes - September 01, 2026 参考 : Preview版のサービスを使うとはどういうことなのか Agent Platform 機能の基本 機能タイプとアイデンティティタイプ Agent Platform 機能は、Cloud Run のサービスやジョブに 機能タイプ （functional type）と アイデンティティタイプ （identity type）の2つのプロパティを設定することで構成します。gcloud CLI では、デプロイ時に --functional-type と --identity-type の2つのフラグで指定します。 # 機能タイプとアイデンティティタイプを指定してデプロイ # 機能タイプ=agent、アイデンティティタイプ=agent-identity の例 $ gcloud beta run deploy < サービス名 > \ --image =< コンテナURL > \ --functional-type = agent \ --identity-type = agent-identity \ --region = asia-northeast1 --project =< プロジェクトID > エージェントと MCP サーバーそれぞれのデプロイコマンドは、後述の設定手順で解説します。 機能タイプは、ワークロードの主な用途を宣言するプロパティです。一度設定すると変更や解除ができません。 機能タイプ 意味 制約 agent ワークロードを AI エージェントとして登録する アイデンティティタイプは agent-identity が必須 mcp-server ワークロードをユーザー管理の MCP サーバーとして登録する どちらのアイデンティティタイプも使用できる アイデンティティタイプは、ワークロードに割り当てる ID の種類を指定するプロパティです。 アイデンティティタイプ 意味 agent-identity システム管理のエージェント ID を割り当てる。ID 証明書がデフォルトで有効になる service-account 従来どおりの Google Cloud サービスアカウントを使用する agent-identity を指定してデプロイすると、Agent Platform はワークロードの ID 証明書（X.509 証明書）をデフォルトで有効にします。証明書を使用しない場合は、 --no-identity-certificate フラグを付けるか、アノテーション run.googleapis.com/identity-certificate-enabled: "false" を設定します。 機能タイプ mcp-server では、アイデンティティタイプに service-account を指定するか省略すると、従来どおりサービスアカウントで動作します。この場合、MCP サーバーから Google Cloud API や他のサービスへの認証は、これまでと同じくサービスアカウントで行われます。 組み合わせによる挙動 機能タイプとアイデンティティタイプの組み合わせによって、ワークロードの挙動は以下のように変わります。 機能タイプ アイデンティティタイプ 挙動 agent agent-identity Agent Registry にエージェントとして登録され、エージェント ID が割り当てられる agent その他、または未指定 エラーになる mcp-server agent-identity 、 service-account 、または未指定 Agent Registry に MCP サーバーとして登録される。未指定の場合はサービスアカウントが使用される 未指定 service-account 通常の Cloud Run サービスまたはジョブとして動作する 機能タイプに agent を指定してアイデンティティタイプを省略すると、デプロイはサーバー側で拒否されます。gcloud CLI はデプロイ前に警告を表示しますが処理は止まらず、以下のエラーで失敗します。 ERROR: (gcloud.beta.run.deploy) spec.template.spec.identity_type: Identity type must be AGENT when functional type is AGENT. エージェント ID への権限付与 agent-identity を設定した Cloud Run のワークロードには、以下の形式のエージェント ID が割り当てられます。ワークロードが Google Cloud API や他の Cloud Run サービスにアクセスするための権限は、サービスアカウントの代わりにこのエージェント ID に対して付与します。IAM 許可ポリシーでは、この文字列をそのままプリンシパルとして指定します。 principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/services/<サービス名> エージェント ID で動作するリビジョンでは、サービスアカウントは使用されません。サービスアカウントに付与していたロールは残りますが、そのリビジョンからは参照されないため、必要なロールはエージェント ID に付け直します。 サービスアカウントではなくエージェント ID に権限を付与する利点は、権限の付与先とワークロードが1対1で対応する点です。エージェント ID はワークロードごとにシステムが自動で割り当てるため、サービスアカウントを作成して管理する手間がなく、複数のワークロードで1つの ID を共有して権限が過剰になることもありません。 また、権限借用や長期キーの発行ができないうえ、アクセストークンはワークロードの X.509 証明書に紐づくため、認証情報の漏洩や再利用のリスクも抑えられます。 監査ログにはプリンシパルとしてエージェント ID が記録されるため、どのワークロードが操作したかを個別に追跡できます。 組織に属さないプロジェクトでは、トラストドメイン（ principal:// の直後から /resources/ までの部分）の org-<組織ID> が project-<プロジェクト番号> になります。 principal://agents.global.project-<プロジェクト番号>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/services/<サービス名> なお、Cloud Run のジョブの場合は末尾が jobs/<ジョブ名> になります。 principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/jobs/<ジョブ名> ジョブに割り当てられた ID は、ジョブ自体ではなく実行（execution）の詳細に表示されます。gcloud CLI では gcloud beta run jobs executions describe 、コンソールではジョブの「実行」タブから実行を選択して確認します。 エージェント ID は Agent Runtime や Gemini Enterprise のエージェントにも割り当てられますが、 resources/ 直後のサービス名の部分が run になっている点が Cloud Run の ID の特徴です。 参考 : エージェント ID の概要 参考 : Principal identifiers 自動付与される事前定義ロール プロジェクトで初めて機能タイプ agent のワークロードをデプロイすると、Google Cloud はそのプロジェクトの IAM ポリシーに以下のロールバインディングを自動で追加します。 ロール プリンシパル Cloud Run Agent - Agent Default Access Role（ roles/run.agentDefaultAccess ） principalSet://agents.global.org-<組織ID>.system.id.goog/attribute.platformContainer/run/projects/<プロジェクト番号> プリンシパルの principalSet:// 形式は、そのプロジェクトの Cloud Run 上で動作するすべてのエージェント ID をまとめて指すプリンシパルセットです。 このロールには、Agent Platform の推論（ aiplatform.endpoints.predict ）に加えて、Cloud Logging・Cloud Monitoring・Cloud Trace への書き込み権限が含まれます。 # 自動付与された事前定義ロールの内容を表示（2026年9月現在） $ gcloud iam roles describe roles/run.agentDefaultAccess ----- 出力例 ----- description: Default role for Cloud Run Agent identities providing basic AI and telemetry access. includedPermissions: - aiplatform.endpoints.predict - cloudtrace.traces.patch - logging.logEntries.create - logging.logEntries.route - monitoring.metricDescriptors.create - monitoring.metricDescriptors.get - monitoring.metricDescriptors.list - monitoring.monitoredResourceDescriptors.get - monitoring.monitoredResourceDescriptors.list - monitoring.timeSeries.create - telemetry.traces.write - trafficdirector.networks.getConfigs - trafficdirector.networks.reportMetrics name: roles/run.agentDefaultAccess stage: ALPHA title: Cloud Run Agent - Agent Default Access Role プロジェクト内の Cloud Run に紐づくエージェント ID 全てに Cloud Run Agent - Agent Default Access Role ロールが付与されている このため、Cloud Run 上のエージェントは追加のロール付与なしで、Agent Platform 経由で Gemini モデルの generateContent を呼び出せます。一方で、Cloud Storage や BigQuery など他の Google Cloud API へのアクセスには、後述の手順でエージェント ID に個別のロールを付与する必要があります。 Agent Registry への自動登録 機能タイプを agent または mcp-server に設定してデプロイした Cloud Run のリソースは、同じプロジェクトの Agent Registry に自動登録されます。エージェントはエージェントカタログ（ /agents ）に、MCP サーバーは MCP サーバーカタログ（ /mcpServers ）に登録されます。なお、自動登録の対象は同じプロジェクト内のリソースのみで、他のプロジェクトにデプロイしたエージェントを登録するには手動登録が必要です。 登録先のロケーションは Cloud Run のリソースと同じリージョンです。Cloud Run のジョブも、機能タイプ agent で作成するとエージェントとして登録されます。 Agent Registry は、登録時にエージェントからメタデータの取得を試みます。A2A プロトコルに対応したエージェントでは、 /.well-known/agent-card.json の Agent Card からスキルなどのメタデータが取り込まれます。A2A に対応していないエージェントでは、登録されたエントリに ID とランタイムへの参照（ RuntimeReference ）が設定されるだけで、説明やスキルなどのメタデータは自動では取り込まれません。 参考 : エージェントを登録する - 自動登録 参考 : 自動登録を使用する 注意点 機能タイプとアイデンティティタイプは一度設定すると変更や解除ができません。たとえば機能タイプ agent のサービスを mcp-server に変更しようとすると、以下のエラーになります。 ERROR: (gcloud.beta.run.services.update) spec.functional_type: Functional type cannot be updated or unset once set. また、サービスアカウントで動作している既存のサービスに、あとから Agent Platform 機能を設定してエージェント ID に切り替える場合、Cloud Run はそのサービスに新しいエージェント ID を割り当てます。 このエージェント ID は、以前のサービスアカウントに付与されていた権限を引き継ぎません。 接続断を避けるため、Policy Analyzer で必要なロールを洗い出して事前に付与するか、 --no-traffic フラグを付けて更新し、権限を付与してからトラフィックを移行してください。 参考 : 許可ポリシー用の Policy Analyzer 制限事項 2026年9月現在、以下の制限があります。 Agent Platform 機能を設定できるのは Cloud Run のサービスとジョブのみ。worker pools と instances には設定できない Agent Gateway の制御対象となるランタイムは Agent Runtime と Gemini Enterprise のみで、Cloud Run 上のエージェントは対象外。Cloud Run のエージェントに対する通信制御は、IAM ポリシーによる呼び出し元の制限や Identity-Aware Proxy（以下、IAP と記載）で行う 設定に使用する gcloud CLI のコマンドは、公式ドキュメントでは gcloud beta run コマンド群で案内されている Agent Identity の制限として、Cloud Storage のレガシー バケットロール（ roles/storage.legacyBucketReader など）はエージェント ID に付与できない 設定手順 当記事で扱う手順 当記事では、gcloud CLI を使用して Cloud Run のサービスに Agent Platform 機能を設定し、割り当てられたエージェント ID で Google Cloud API と他の Cloud Run サービスに認証する手順を扱います。 動作確認では、Agent Development Kit（以下、ADK と記載）で作成した BigQuery のデータ分析エージェントをエージェント ID 付きでデプロイし、ロール付与の前後で BigQuery へのアクセスがどう変わるかを示します。 開発者のローカル環境から IAP 経由で MCP サーバーに接続する手順と、Agent Identity auth manager を使ってエージェントがユーザーの代理で外部サービスに認証する方法は、当記事では扱いません。auth manager については、以下のドキュメントを参照してください。 参考 : エージェント ID 認証マネージャーの概要 参考 : ツールとリソースに対する認証 なお、当記事の記述については、記事を執筆した2026年9月現在のプロダクト仕様に基づいている点に注意してください。最新の製品仕様やアーキテクチャ、ベストプラクティスについては公式ドキュメントを参照し、確認してください。 事前準備 プロジェクトで以下の API を有効化します。 # 必要な API を有効化 $ gcloud services enable \ run.googleapis.com \ iam.googleapis.com \ agentregistry.googleapis.com \ apphub.googleapis.com \ --project =< プロジェクトID > Agent Registry API を有効化すると、そのプロジェクトで Agent Registry が使用できるようになります。 参考 : エージェント レジストリを設定する エージェントのデプロイ 機能タイプに agent 、アイデンティティタイプに agent-identity を指定してサービスをデプロイします。 # エージェントとしてサービスをデプロイ $ gcloud beta run deploy agent-a \ --image =< コンテナURL > \ --functional-type = agent \ --identity-type = agent-identity \ --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- WARNING: Updating the functional type to an agent also requires updating its identity to agent_identity. Make sure to update the IAM policies on the agent_identity to ensure no issues with connectivity to other services. Deploying container to Cloud Run service [ agent -a] in project [< プロジェクトID >] region [ asia-northeast1 ] Deploying new service... Creating Revision.................................................................................done Routing traffic.....done Done. Service [ agent -a] revision [ agent-a-00001-nmz ] has been deployed and is serving 100 percent of traffic. Service URL: https://agent-a- < プロジェクト番号 > .asia-northeast1.run.app 冒頭の WARNING は、アイデンティティタイプを正しく指定していても毎回表示されます。エージェント ID に対する IAM ポリシーの整備を促す内容で、デプロイ自体は正常に完了します。 MCP サーバーのデプロイ 機能タイプに mcp-server を指定します。アイデンティティタイプは任意で、省略した場合はサービスアカウントが使用されます。 # MCP サーバーとしてサービスをデプロイ（アイデンティティタイプは省略） $ gcloud beta run deploy mcp-a \ --image =< コンテナURL > \ --functional-type = mcp-server \ --region = asia-northeast1 --project =< プロジェクトID > MCP サーバーにもエージェント ID を割り当てる場合は、 --identity-type=agent-identity を追加します。Cloud Run で MCP サーバーをホストする方法については、以下のドキュメントを参照してください。 参考 : Cloud Run で MCP サーバーをホストする 既存サービスの移行 サービスアカウントで動作している既存のサービスをエージェント ID に切り替える場合は、 --no-traffic を付けて更新します。新しいリビジョンはトラフィックを受けない状態で作成されます。 # 既存サービスをエージェント ID に更新（トラフィックは移行しない） $ gcloud beta run services update plain-svc \ --functional-type = agent \ --identity-type = agent-identity \ --no-traffic \ --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- WARNING: Updating the functional type to an agent also requires updating its identity to agent_identity. Make sure to update the IAM policies on the agent_identity to ensure no issues with connectivity to other services. Deploying... Creating Revision......................done Routing traffic.....done Done. Service [ plain-svc ] revision [ plain-svc-00002-k94 ] has been deployed and is serving 0 percent of traffic. リビジョンの一覧を確認すると、新しいリビジョンは作成済みですが、トラフィックを受けているのは旧リビジョンのままです。 # リビジョンの一覧を表示 $ gcloud run revisions list --service = plain-svc --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- REVISION ACTIVE SERVICE DEPLOYED DEPLOYED BY ✔ plain-svc-00002-k94 plain-svc 2026-09-02 01:14:45 UTC < ユーザー > ✔ plain-svc-00001-k5k yes plain-svc 2026-09-02 01:11:48 UTC < ユーザー > この状態で新しいエージェント ID に必要なロールを付与し、その後にトラフィックを移行します。 # 最新リビジョンにトラフィックを移行 $ gcloud run services update-traffic plain-svc --to-latest --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Updating traffic... Routing traffic.......................................................................................................................done Done. URL: https://plain-svc- < ハッシュ > -an.a.run.app Traffic: 100 % LATEST ( currently plain-svc-00002-k94 ) エージェント ID の確認 割り当てられたエージェント ID は、リビジョンの describe で確認できます。サービスの describe には ID の値が表示されないため、リビジョンを指定してください。 # リビジョンの詳細を表示 $ gcloud beta run revisions describe agent-a-00001-nmz --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- ✔ Revision agent-a-00001-nmz in region asia-northeast1 Container < コンテナ名 > Image: < コンテナURL > Port: 8080 Memory: 512Mi CPU: 1000m Startup Probe: TCP every 240s Port: 8080 Initial delay: 0s Timeout: 240s Failure threshold: 1 Type: Default Identity: //agents.global.org- < 組織ID > .system.id.goog/resources/run/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/agent-a Identity Type: agent-identity Identity Certificate Enabled: true Concurrency: 80 Timeout: 300s Execution Environment: Second Generation ✔ Deploying revision succeeded in 6 .28s. Identity の値は principal:// の接頭辞を除いた形式で表示されます。IAM ポリシーに指定する際は、先頭に principal: を付けて principal://agents.global... の形式にします。 Google Cloud コンソールでは、サービスの「リビジョン」タブでリビジョンを選択し、「セキュリティ」タブの「Identity」フィールドに表示されます。 Agent Registry での確認 自動登録されたエージェントは、gcloud CLI の gcloud agent-registry agents list コマンドで一覧できます。 一覧には Google Workspace エージェントなどの Google 提供のエージェントや、Agent Runtime 上のエージェントも含まれるため、以下の例では agentId に run: を含むエントリだけを表示しています。 # Agent Registry に登録された Cloud Run のエージェントを一覧 $ gcloud agent-registry agents list \ --location = asia-northeast1 --project =< プロジェクトID > \ --filter =" agentId ~ 'run:' " \ --format =" table(agentId,createTime) " ----- 出力例 ----- AGENT_ID CREATE_TIME urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:jobs:agent-job 2026-09-02T01:10:13.286069Z urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:agent-a 2026-09-02T01:07:49.566835Z urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:agent-b 2026-09-02T01:11:58.117538Z urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:plain-svc 2026-09-02T01:11:48.365980Z MCP サーバーは、gcloud CLI では gcloud agent-registry mcp-servers list 、API では agents の代わりに mcpServers を指定して一覧します。 mcpServerId は urn:mcp:...:run:services:<サービス名> の形式です。 エージェントの認証 Google Cloud API への認証 エージェントは、Cloud Run のメタデータサーバーから取得したアクセストークンで Agent Platform や Cloud Storage などの Google Cloud API に認証します。 この仕組みは従来のサービスアカウントと同じで、アプリケーションコードでは標準の Google Cloud クライアントライブラリを使用するだけで済みます。クライアントライブラリは Application Default Credentials（ADC）の仕組みでメタデータサーバーから短期のアクセストークンを自動取得します。 必要なロールは、エージェント ID をプリンシパルとして付与します。以下は Agent Platform ユーザー（ roles/aiplatform.user ）をプロジェクトレベルで付与する例です。 # エージェント ID に Agent Platform ユーザーのロールを付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" <エージェントID> " \ --role =" roles/aiplatform.user " # 例 : プロジェクト myproject のサービス myagent のエージェント ID に付与 $ gcloud projects add-iam-policy-binding myproject \ --member =" principal://agents.global.org-111111111111.system.id.goog/resources/run/projects/222222222222/locations/asia-northeast1/services/myagent " \ --role =" roles/aiplatform.user " 前述のとおり、Agent Platform 経由の Gemini モデルの generateContent は、自動付与される事前定義ロールの権限で呼び出せます。Storage オブジェクト閲覧者（ roles/storage.objectViewer ）など、それ以外のアクセスには対象リソースに対して個別にロールを付与してください。 参考 : アプリケーションのデフォルト認証情報の仕組み 他の Cloud Run 上のエージェント・MCP サーバーへの認証 エージェント ID を持つ Cloud Run 上のエージェントや MCP サーバーが、Cloud Run 上の別のエージェントや MCP サーバーを呼び出す場合は、ID トークン（JWT）を使用し、Cloud Run 組み込みの Cloud Run 起動元（ roles/run.invoker ）による IAM チェックで検証します。A2A プロトコルに準拠したエージェントを呼び出す場合も同様です。 これは Cloud Run のサービス間認証と同じ仕組みで、呼び出し元のプリンシパルがエージェント ID になる点だけが異なります。 まず、呼び出し元エージェントの ID に対して、呼び出し先サービスの Cloud Run 起動元をサービスレベルで付与します。 # 呼び出し元エージェント ID に呼び出し先サービスの起動元ロールを付与 $ gcloud run services add-iam-policy-binding < 呼び出し先のサービス名 > \ --member =" <呼び出し元のエージェントID> " \ --role =" roles/run.invoker " \ --region = asia-northeast1 --project =< プロジェクトID > # 例 : プロジェクト myproject のサービス myagent のエージェント ID を呼び出し元として指定 $ gcloud run services add-iam-policy-binding < 呼び出し先のサービス名 > \ --member =" principal://agents.global.org-111111111111.system.id.goog/resources/run/projects/222222222222/locations/asia-northeast1/services/myagent " \ --role =" roles/run.invoker " \ --region = asia-northeast1 --project = myproject <呼び出し元のエージェントID> には、 principal:// から始まるエージェント ID の文字列をそのまま指定します。呼び出し先が MCP サーバーの場合も、コマンドの第1引数に MCP サーバーのサービス名を指定する点以外は同じです。 次に、呼び出し元のコンテナ内で、呼び出し先サービスの URL を audience に指定して ID トークンを取得し、 Authorization ヘッダーに付けてリクエストします。トークンの取得先はサービスアカウントの場合と同じメタデータサーバーで、アプリケーションコードの変更は不要です。 # 呼び出し先の URL を audience にして ID トークンを取得 $ TOKEN = $( curl -s -H " Metadata-Flavor: Google " \ " http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=<呼び出し先のサービスのURL> " ) # 取得したトークンで呼び出し先を呼び出す $ curl -H " Authorization: Bearer $TOKEN " < 呼び出し先のサービスのURL > 参考 : サービス間認証 参考 : Authenticate MCP servers バインドトークンによる保護の強化 前述の手順で取得した ID トークンは非バインドトークンと呼ばれる標準的なものです。エージェント ID を持つワークロードでは、これに加えてバインドトークンを使用できます。 方式 内容 非バインドトークン メタデータサーバーが生成する、audience 付きの標準的な ID トークン。サービス間認証・エージェント間認証のデフォルト バインドトークン mTLS により、トークンをワークロードの証明書と結び付ける。呼び出し元がリクエストに自身の証明書チェーンを含める どちらもメタデータサーバーが発行する ID トークンで、呼び出し元が誰かを証明する点は同じです。違いは、トークンを持っているだけで使えるかどうかにあります。非バインドトークンは、有効期限内であればトークンを持つ誰もが使えます。 一方、バインドトークンには呼び出し元のワークロード証明書のフィンガープリント（証明書のハッシュ値）が埋め込まれており、呼び出し先は TLS の接続時に提示された証明書がそのフィンガープリントと一致するかを検証します。証明書の秘密鍵はコンテナの外に出ないため、トークンだけが漏洩しても第三者は再利用できません。 どちらの方式になるかは、呼び出し先に指定する URL で決まります。通常の URL（ run.app ）を指定すると非バインドトークン、mTLS 用 URL（ mtls.run.app ）を指定するとバインドトークンを使用します。 標準の Google Cloud クライアントライブラリは、証明書がある環境では自動でバインドトークンを取得して証明書を提示する ため、通常は方式を意識せずに済みます。ID 証明書を無効化したワークロードや、サービスアカウントで動作する呼び出し元には証明書がないため、非バインドトークンのみ使用できます。 同じ仕組みは Google Cloud API への認証でも働いています。後述の動作確認では、BigQuery のクライアントライブラリが接続先として bigquery.mtls.googleapis.com を自動で選択しており、エージェント ID による Google Cloud API へのアクセスがデフォルトで mTLS になっていることを確認できます。curl でバインドトークンを手動取得する手順は、公式ドキュメントに記載されています。 参考 : Authenticate your AI agents - Fetch a bound ID token (mTLS) 参考 : A2A エージェントを Cloud Run にデプロイする 動作確認 検証構成 エージェント ID による認証の挙動を確認するため、ADK で作成した BigQuery のデータ分析エージェントを、エージェント ID を有効にした Cloud Run サービスにデプロイしました。エージェントは Gemini の呼び出しと BigQuery のクエリ実行の両方に、サービスアカウントではなくエージェント ID で認証します。 リソース 設定 役割 Cloud Run サービス bq-agent --functional-type=agent --identity-type=agent-identity ADK エージェント。ADK の API サーバーとして HTTP で質問を受け付ける Gemini（ gemini-3.5-flash 、asia-northeast1） 事前定義ロールで呼び出し可能 質問の解釈とツールの選択 BigQuery 公開データセット bigquery-public-data.samples.shakespeare エージェント ID に BigQuery ジョブユーザーを付与 エージェントがクエリを実行する対象 検証は以下の順で行いました。 エージェントをデプロイし、割り当てられたエージェント ID を確認する ロールを付与する前に、Gemini だけを使う質問と BigQuery を使う質問を送る エージェント ID に BigQuery ジョブユーザー（ roles/bigquery.jobUser ）を付与する 同じ質問を送り、結果を比較する Cloud Audit Logs で、BigQuery へのアクセスがエージェント ID として記録されていることを確認する エージェントのソースコード ディレクトリ構成は以下のとおりです。ADK の公式ドキュメントにある Cloud Run へのデプロイ構成に従っています。 bq-agent/ ├── bq_agent/ │ ├── __init__.py │ └── agent.py ├── main.py ├── requirements.txt └── Dockerfile エージェント本体は agent.py です。BigQuery ツールセットの認証情報には ADC を使用します。Cloud Run 上では、メタデータサーバーを通じてエージェント ID の認証情報が使われます。 # bq_agent/agent.py import os import google.auth from google.adk.agents import Agent from google.adk.tools.bigquery import BigQueryCredentialsConfig, BigQueryToolset from google.adk.tools.bigquery.config import BigQueryToolConfig, WriteMode # クエリを実行するプロジェクト PROJECT_ID = os.environ[ "GOOGLE_CLOUD_PROJECT" ] # Application Default Credentials を使用する # Cloud Run 上ではメタデータサーバー経由でエージェント ID の認証情報が使われる credentials, _ = google.auth.default() bigquery_toolset = BigQueryToolset( credentials_config=BigQueryCredentialsConfig(credentials=credentials), bigquery_tool_config=BigQueryToolConfig(write_mode=WriteMode.BLOCKED), tool_filter=[ "get_dataset_info" , "get_table_info" , "execute_sql" ], ) root_agent = Agent( name= "bq_agent" , model= "gemini-3.5-flash" , description= "BigQuery のデータについて質問に答えるエージェント" , instruction=( "あなたは BigQuery のツールを使ってデータの質問に答えるデータ分析エージェントです。" f "ツールの project_id には常に {PROJECT_ID} を指定してください。" "ツールの実行がエラーになった場合は再試行せず、エラーメッセージをそのまま回答に含めてください。" ), tools=[bigquery_toolset], ) # bq_agent/__init__.py from . import agent main.py は、ADK が提供する FastAPI アプリケーションをそのまま起動します。 # main.py import os import uvicorn from google.adk.cli.fast_api import get_fast_api_app AGENT_DIR = os.path.dirname(os.path.abspath(__file__)) app = get_fast_api_app(agents_dir=AGENT_DIR, web= False ) if __name__ == "__main__" : uvicorn.run(app, host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 8080 ))) 依存関係は google-adk[gcp] の1行です。BigQuery ツールセットは BigQuery と Dataplex のクライアントライブラリを必要とし、これらは google-adk の gcp extra に含まれます。 # requirements.txt google-adk[gcp] # Dockerfile FROM python:3.13-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [ " sh ", " -c ", " uvicorn main:app --host 0.0.0.0 --port $PORT " ] デプロイ ソースから直接デプロイします。機能タイプとアイデンティティタイプのフラグに加えて、Gemini を Agent Platform 経由で呼び出すための環境変数を設定します。 # ADK エージェントをエージェント ID 付きでデプロイ $ gcloud beta run deploy bq-agent \ --source . \ --functional-type = agent \ --identity-type = agent-identity \ --set-env-vars =" GOOGLE_CLOUD_PROJECT=<プロジェクトID>,GOOGLE_CLOUD_LOCATION=asia-northeast1,GOOGLE_GENAI_USE_ENTERPRISE=True " \ --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- WARNING: Updating the functional type to an agent also requires updating its identity to agent_identity. Make sure to update the IAM policies on the agent_identity to ensure no issues with connectivity to other services. Building using Dockerfile and deploying container to Cloud Run service [ bq-agent ] in project [< プロジェクトID >] region [ asia-northeast1 ] Building and deploying new service... Validating configuration..........done Uploading sources.........done Building Container.............................................done Creating Revision..............................................done Routing traffic.....done Done. Service [ bq-agent ] revision [ bq-agent-00001-9x6 ] has been deployed and is serving 100 percent of traffic. Service URL: https://bq-agent- < プロジェクト番号 > .asia-northeast1.run.app リビジョンの詳細で、エージェント ID が割り当てられていることを確認します。 # リビジョンの詳細からエージェント ID を確認 $ gcloud beta run revisions describe bq-agent-00001-9x6 --region = asia-northeast1 --project =< プロジェクトID > | grep Identity ----- 出力例 ----- Identity: //agents.global.org- < 組織ID > .system.id.goog/resources/run/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/bq-agent Identity Type: agent-identity Identity Certificate Enabled: true コンソールから Cloud Run リビジョンのエージェント ID を確認する Agent Registry にも、エージェントとして自動登録されています。 # Agent Registry の登録を確認 $ gcloud agent-registry agents list \ --location = asia-northeast1 --project =< プロジェクトID > \ --filter =" agentId ~ 'bq-agent' " ----- 出力例 ----- --- agentId: urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:bq-agent attributes: agentregistry.googleapis.com/system/RuntimeReference: uri: //run.googleapis.com/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/bq-agent createTime: ' 2026-09-02T16:43:08.933443Z ' displayName: bq-agent name: projects/ < プロジェクトID > /locations/asia-northeast1/agents/agentregistry-00000000-0000-0000-da87-53c426078b85 uid: agentregistry-00000000-0000-0000-da87-53c426078b85 updateTime: ' 2026-09-02T16:54:39.553087Z ' コンソールからエージェントが Agent Registry に自動登録されていることを確認する エージェントの呼び出し ADK の API サーバーは、セッションを作成してから /run に質問を送る形式です。サービスは未認証のリクエストを許可していないため、呼び出し側のユーザーの ID トークンを Authorization ヘッダーに付けます。当記事では、Cloud Run 管理者のユーザーで gcloud auth print-identity-token を使用しました。トークンなしで呼び出すと、Cloud Run が403で拒否します。 # ID トークンを取得 $ TOKEN = $( gcloud auth print-identity-token ) $ URL =https://bq-agent- < プロジェクト番号 > .asia-northeast1.run.app # セッションを作成 $ curl -s -X POST -H " Authorization: Bearer $TOKEN " -H " Content-Type: application/json " \ " $URL /apps/bq_agent/users/u1/sessions/s1 " -d ' {} ' # 質問を送る $ curl -s -H " Authorization: Bearer $TOKEN " -H " Content-Type: application/json " " $URL /run " \ -d ' {"app_name":"bq_agent","user_id":"u1","session_id":"s1","new_message":{"role":"user","parts":[{"text":"<質問>"}]}} ' /run の応答は、モデルの応答やツールの呼び出しと結果を含むイベントの配列です。以下では、応答からツールの呼び出し（ functionCall ）、ツールの結果（ functionResponse ）、最終回答（ text ）を抜粋して示します。 ロール付与前の動作 まず、BigQuery のツールを使わない質問を送ります。エージェント ID には Gemini の呼び出しに必要な権限が事前定義ロールで自動付与されているため、追加のロールなしで回答が返ります。 質問 : BigQuery のツールは使わずに答えてください。あなたは何ができますか。1文で答えてください。 回答 : 私は、BigQueryに格納されているデータに関する質問に対して、データの検索や分析を行ってお答えすることができます。 次に、BigQuery のクエリを必要とする質問を送ります。エージェントは SQL を組み立てて execute_sql ツールを呼び出しますが、エージェント ID にクエリを実行する権限が無いため、ツールの実行が403で失敗します。 質問 : bigquery-public-data.samples.shakespeare テーブルで、word_count の合計が最も多い corpus 上位3件を教えてください。 functionCall : execute_sql project_id : <プロジェクトID> query : SELECT corpus, SUM(word_count) AS total_word_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY corpus ORDER BY total_word_count DESC LIMIT 3 functionResponse : status : ERROR error_details : 403 POST https://bigquery.mtls.googleapis.com/bigquery/v2/projects/<プロジェクトID>/jobs?prettyPrint=false: Access Denied: Project <プロジェクトID>: User does not have bigquery.jobs.create permission in project <プロジェクトID>. 回答 : 申し訳ありませんが、クエリを実行したところ、以下のエラーが発生しました。 エラーメッセージ: Access Denied: Project <プロジェクトID>: User does not have bigquery.jobs.create permission in project <プロジェクトID>. プロジェクト <プロジェクトID> において bigquery.jobs.create 権限がないため、クエリを実行することができませんでした。 エラーメッセージ中の BigQuery のエンドポイントが bigquery.mtls.googleapis.com になっている点にも注目してください。クライアントライブラリがコンテナ内のワークロード証明書を検出し、Google Cloud API との通信に mTLS のエンドポイントを自動で選択しています。前述のとおり、エージェント ID による Google Cloud API へのアクセスがデフォルトで mTLS になるという Agent Identity の仕様どおりの動作です。 ロールの付与 エージェント ID をプリンシパルにして、BigQuery ジョブユーザー（ roles/bigquery.jobUser ）をプロジェクトレベルで付与します。公開データセットのテーブルは誰でも読み取れるため、クエリを実行するプロジェクトに対するジョブ作成の権限があれば足ります。 # エージェント ID に BigQuery ジョブユーザーを付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/asia-northeast1/services/bq-agent " \ --role =" roles/bigquery.jobUser " ----- 出力例 ----- Updated IAM policy for project [< プロジェクトID >] . bindings: // 省略 - members: - principal://agents.global.org- < 組織ID > .system.id.goog/resources/run/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/bq-agent role: roles/bigquery.jobUser // 省略 ロール付与後の動作 同じ質問を新しいセッションで送ると、ツールの実行が成功し、クエリ結果に基づく回答が返ります。 質問 : bigquery-public-data.samples.shakespeare テーブルで、word_count の合計が最も多い corpus 上位3件を教えてください。 functionCall : execute_sql project_id : <プロジェクトID> query : SELECT corpus, SUM(word_count) AS total_word_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY corpus ORDER BY total_word_count DESC LIMIT 3 functionResponse : status : SUCCESS rows : [{'corpus': 'hamlet', 'total_word_count': 32446}, {'corpus': 'kingrichardiii', 'total_word_count': 31868}, {'corpus': 'coriolanus', 'total_word_count': 29535}] 回答 : bigquery-public-data.samples.shakespeare テーブルにおいて、word_count の合計が最も多い corpus（作品）の上位3件は以下の通りです。 1. hamlet（ハムレット）: 32,446 2. kingrichardiii（リチャード三世）: 31,868 3. coriolanus（コリオレイナス）: 29,535 エージェントのコードには、サービスアカウントのキーや認証情報の設定は一切含まれていません。アイデンティティタイプを agent-identity にしてデプロイし、エージェント ID にロールを付与するだけで、クライアントライブラリが自動的にエージェント ID として認証しています。 監査ログでの確認 Cloud Audit Logs では、BigQuery へのアクセスがエージェント ID をプリンシパルとして記録されます。エージェント ID は principalEmail ではなく principalSubject フィールドに、 principal:// 形式で入ります。 # BigQuery の監査ログからエージェント ID のエントリを表示 $ gcloud logging read ' protoPayload.serviceName="bigquery.googleapis.com" AND protoPayload.authenticationInfo.principalSubject:"services/bq-agent" ' \ --project =< プロジェクトID > --limit = 2 --order = asc \ --format =" json(timestamp,protoPayload.methodName,protoPayload.status,protoPayload.authenticationInfo.principalSubject) " ----- 出力例 ----- [ { " protoPayload " : { " authenticationInfo " : { " principalSubject " : " principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/asia-northeast1/services/bq-agent " } , " methodName " : " jobservice.insert " , " status " : { " code " : 7 , " message " : " Access Denied: Project <プロジェクトID>: User does not have bigquery.jobs.create permission in project <プロジェクトID>. " } } , " timestamp " : " 2026-09-02T16:55:19.161262Z " } , { " protoPayload " : { " authenticationInfo " : { " principalSubject " : " principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/asia-northeast1/services/bq-agent " } , " methodName " : " jobservice.insert " , " status " : {} } , " timestamp " : " 2026-09-02T16:55:56.681213Z " } ] 1件目はロール付与前の拒否されたジョブ作成（ status.code が7、PERMISSION_DENIED）、2件目はロール付与後に成功したジョブ作成です。どちらもプリンシパルがエージェント ID になっており、どの Cloud Run サービスが BigQuery にアクセスしたかをサービス単位で追跡できます。 参考 : BigQuery tool for ADK 参考 : Cloud Run - Agent Development Kit (ADK) 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は法律の勉強にも目覚め、2級知的財産管理技能士を取得。最近は個人情報保護法を勉強中。 Follow @sasashun0805

Logstash の転送先や Python 等のアプリケーションから指定する Elasticsearch の接続先 URL（endpoint URL）は、運用形態（Self-Managed、Elastic Cloud Hosted、Elastic Cloud Serverless）ごとに取得方法や基本形式が異なります。 この記事では、それぞれの運用形態における接続先 URL の取得・確認手順をまとめて解説します。 目次 Self-Managed の場合 URLの基本形式 取得・確認手順 Elastic Cloud Hosted の場合 URLの基本形式 取得手順 Elastic Cloud Serverless の場合 URLの基本形式 取得手順 Self-Managed の場合 オンプレミスや VM（AWS EC2 など）、Docker 等の独自環境で構築した Elasticsearch へ接続する場合は、サーバーの IP アドレス（またはホスト名）とポート番号を組み合わせて接続先を指定します。 URLの基本形式 https://<ホスト名またはIPアドレス>:9200 （※ Elasticsearch 8.0 以降はデフォルトで TLS/HTTPS が有効です。セキュリティの観点から HTTP 接続は推奨されません。） 取得・確認手順 Elasticsearch が稼働しているサーバーの IP アドレスまたは FQDN（ドメイン名）を確認します（ローカル開発環境の場合は  localhost  や  127.0.0.1 ）。 設定ファイル（ elasticsearch.yml ）内の  network.host  および  http.port （標準は  9200 ）を確認し、接続可能ポートとして開放されているか確認します。 Elastic Cloud Hosted の場合 Elastic Cloud Hosted の場合は、管理コンソール画面からエンドポイント URL を直接取得できます。 URLの基本形式 https://**.<region>.<cloud-provider>.**.io:443 （ ※ ポート番号は構成により、443や  9243  などが利用されます。） 取得手順 Elastic Cloud コンソール  にログインします。 接続したい  Deployment（デプロイメント）  を選択します。 左のメニューの  Getting started  アイコンをクリックします。 Get started with Elasticsearch. 画面の Elasticsearch endpoint: の右下にあるコピーアイコンをクリックします。 ※別ルートとして、Kibana 画面右上のヘルプアイコン（ ? ）＞  Connection details  からコピーすることも可能です。 Elastic Cloud Serverless の場合 Elastic Cloud Serverless を使用している場合も、プロジェクトごとに固有のエンドポイントが割り当てられます。 URLの基本形式 https://<project-id>.es.<region>.<cloud-provider>.elastic.cloud:443 （※標準ポート:443） 取得手順 Elastic Cloud コンソールから対象の  Serverless Project  にアクセスします。 Home 画面が表示されていることを確認します（表示されていない場合、左メニューの Home アイコンをクリックします）。 3. Home 画面の右上の Elasticsearch: の接続先URL の横にあるコピーアイコンをクリックします。 ※別ルートとして、Kibana 画面右上のヘルプアイコン（ ? ）＞  Connection details  からコピーすることも可能です。 運用形態によってポート番号（ 9200 ,  9243 ,  443 ）やプロトコル（HTTP / HTTPS）の設定ルールが微妙に異なるため、Logstash やアプリケーションのクライアント設定（ hosts  プロパティなど）に記述する際は指定する形式に注意してください。 The post Elasticsearch の 3形態ごとの接続先URLの取得方法をまとめてみた。 first appeared on Elastic Portal .