はじめに
このブログではGoogle Cloud Next 2026で発表されたGemini Enterprise Agent Platformと余談程度にagents-cliを実際に触ってみた内容をまとめています。ハンズオン形式で説明しているので、実際に触りながら読んでみてください。
今回の内容は2026年5月時点の内容になります。今後アップデートが見込まれますので、最新の情報は公式ドキュメントなどで確認してみてください。
なお、今回はエンジニアじゃなくてもわかるように説明しているのでエンジニアの方には少し物足りない内容になっているかもしれません。
次世代のエージェントを推進するGemini Enterprise Agent Platform
Google Cloud Next 2026でGemini Enterprise Agent Platformが発表されました。
参考：次世代のエージェントを推進するGemini Enterprise Agent Platform を発表
Gemini Enterprise Agent Platformは簡単に説明すると、より手軽にそして安全にそしてもっと容易にAIエージェントを運用するためのサービスです。
公式では以下のように説明されています。
Gemini Enterprise Agent Platform は、エンタープライズ グレードの AI エージェントとモデルベースのソリューションを構築、デプロイ、管理、最適化するための統合プラットフォームです。Agent Platform の進化版として、200 以上の基盤モデルへのアクセスからエージェントのデプロイと管理まで、AI ライフサイクル全体をサポートします。
なぜこのサービスが必要なのかを考えるとAIエージェントをデプロイするためのさまざまな課題に行き着きます。果たしてその課題とはなんでしょうか。
AIエージェントをデプロイするためのさまざまな課題
AIエージェントをデプロイするためのさまざまな課題とはつまり、AIエージェントを決まった形で観測可能な形で見える場所に置く方法がないということです。また、AIのレスポンスというのは確率論的なところがあります。どんなレスポンスが返ってくるのか見当もつかないうえに評価も難しいです。
すなわち、まとめると具体的には以下のとおりです。
- AIエージェントを決まった場所（プラットフォーム）に配置して管理すること
- 今どれだけのエージェントが誰に使われているのか（可観測性）を管理すること
- AIエージェントを誰がどう使って良いのか、アクセス範囲（認証・認可）を管理すること
- エージェントのエコシステムを構築すること
- 継続的に誰でもデプロイ(CI/CD)できてAIエージェントの評価（ソフトウェアテスト+LLMOps）ができること
上記のように本格的にAIエージェントを運用するためにはやることがたくさんあります。
ハンズオンでする利用サービス
- Gemini Enterprise Agent Platform
— App Builder
— Agent Runtime - Cloud Run
- Artifact Registry
- Cloud Storage
事前に有効化すべきAPIもあります。
事前に有効化すべきAPI
Gemini Enterprise Agent Platformで有効にすべきAPIは以下のとおりです。
Agent Registry API Agent Platform API App Hub API App Topology API Cloud API Registry API Cloud Trace API Compute Engine API Dataform API Identity and Access Management (IAM) API IAM Connectors API Cloud Identity-Aware Proxy API Cloud Logging API Model Armor API Cloud Monitoring API Network Security API Network Services API Notebooks API Observability API Cloud Storage Telemetry API Cloud Text-to-Speech API
これらのAPIはGemini Enterprise Agent Platformのコンソール上から有効化できるようになっています。
有効にするをクリックします。
Google Cloud コンソールからGemini Enterprise Agent Platformにアクセスする
Google Cloudのコンソールを開いてAgentまで入力してサービスを検索します。
スタジオ機能を開くため、キラキラマークをクリックします。
App Builderを開く
マークをクリックしたあと、Agent Studioと表示された画面に遷移します。この画面にあるApp Builderを使ってAIアプリケーションを開発します。App Builderをクリックします。
用意されたプロンプトで始める
App Builderではユーザーの指示に基づいてAIアプリケーションをノーコードで開発できますが、あらかじめ用意されたプロンプトでもアプリケーションの開発を始めることができます。
今回は用意されたプロンプトでアプリを開発し、変更を加えてお好みのアプリを開発する流れで進めていきます。ではまず、画面上にあるウェブサイト chatbotをクリックします。
するとプロンプト送信UIにプロンプトが挿入されるのでそのまま送信ボタンで送信します。
するとファイルが生成されます。どうやらTypeScriptベースのアプリケーションのようですが、気にすることはありません。そのまま進めましょう。
実行までされるとプレビュー画面にチャットボットとやりとりするための画面が表示されます。今回はせっかくなのでモデル名を変更しましょう。仕様をクリックします。
ビルド手順という画面が表示されるのでモデルを変更していきます。デフォルトではgemini-3.1-pro-previewでした。
※ちなみにリンクされたソースという項目ではAgent Registryに保存されたエージェントにアクセスできるようです。「マネージドなAgent2Agentプロトコル接続かな？」という印象を受けました。
他の設定は変更せず、モデル名をgemini-3.1-flash-liteに変更します。
Cloud Runにデプロイ
🚀 マークをクリックしてCloud Runにデプロイします。手順は簡単！アプリとしてデプロイという項目が選択できます。Cloud Runにカーソルを合わせるとアプリとしてデプロイという項目が表示されるのでクリックします。
※デプロイには数分かかるのでお茶でも飲みながら待ちましょう。
次に生成されたアプリをデプロイします。
生成されたアプリのデプロイ
デフォルトでは公開アクセスを許可するとなっています。このままでは全世界公開になってしまうので変更します。※なお、社内限定 or 特定の環境にアクセスを限定しない場合はこのままでデプロイでOK
認証を必須にするという項目を設定するとIdentity Aware Proxyといういわゆるプロキシ経由でアクセスになります。設定したらアプリをデプロイするをクリックしてアプリケーションをデプロイします。
アクセス制御、認証を設定する
このままの設定ではIAPというプロキシに阻まれてせっかくの素晴らしいアプリにアクセスができません。この素晴らしいアプリケーションへアクセスするためのアクセス制御を設定します。
認証が必要のすぐ右側にあるペンマークをクリックします。
するとCloud Runのサービス画面が新しいタブで開きます。Cloud RunはサーバーレスでマネージドのGoogle Cloudのサービスです。今回はGemini Enterprise Agent Platformの画面からCloud Runのサービス画面にジャンプしています。
では、前説はこのあたりにして手順を進めていきます。やることは2つです。
- IAMの確認
- IAPの有効化確認
ジャンプした画面ではCloud Runのセキュリティ項目を表示しています。2つにチェックが入っていることを確認します。
次にアクセスポリシーを設定してアクセスできるように事前の準備をしていきます。
少しスクロールすると保存というボタンがありますのでクリックします。その後、警告が表示されていますのですべて付与をクリックします。
ポリシーの編集をクリックして次に進みます。
アクセスポリシーの設定
アプリケーションにアクセス制御を設定します。今回は自分のみアクセスできるようにしてみます。
弊社はGoogle Workspaceが社員に提供されていますのでドメイン丸ごと登録することも可能です。ドメインで登録すると同じドメインのアカウント（Chromeでアクセスしている場合はChromeプロファイルに紐づいているアカウント）からのみアクセスできるようになります。
設定が終わりましたら保存をクリックします。
元の画面に戻ります。ステータスが準備完了となっていれば、デプロイが完了しています。
生成されたアプリを触ってみる
ウェブアプリの管理からOpenをクリックしてアプリを開きます。
よくある質問というのがあるので今回は質問集から選択してみましょう。
今回はNISAとiDeCoについてクリックで聞いてみます。
するとズラズラと回答が流れてきます。これでチャットボットのデプロイは完了です。
質問
NISAとiDeCoの主な違いは何ですか？
回答（長いので一部記載、回答は環境や実行タイミング、モデルによって異なります。）
NISAとiDeCoは、どちらも税制優遇を受けながら資産形成ができる国の制度ですが、目的や仕組みにいくつかの重要な違いがあります。 主な違いを以下の表にまとめました。 （以下略）
アプリを修正して動きを変えてみる
チャットボット新規作成のハンズオンは以上ですが、あっという間にできてしまって少し退屈かもしれませんのでアプリケーションに手を加えてみましょう。
変更の流れ
現在はさまざまな種類の投資口座に関する質問に回答できる、金融サービス ウェブサイト用の chatbotとなっています。お金に関することは大変重要なことではありますが、社内に提供するのであれば、業務に関係することにしたほうが良さそうです。
とはいえ、「変更となるとコードを書いたりしないといけないのでは？」と思うかもしれません。実はそんな必要もなく簡単に変更ができます。変更の流れとしては以下のとおりです。
1.プロンプトを修正する
2.プロンプトを送信する
3.Geminiにアプリを修正してもらう
4.プレビュー画面で動作確認
5.Cloud Runにデプロイ
プロンプトを修正する方法についてはさまざまあります。一番得意な方法でやってみるかあるいはGemini Enterprise Agent PlatformのStudio機能にあるプロンプト作成サポートを使うのもありです。
プロンプトを修正する
今回は複雑なことをせずに思いつきでプロンプトを修正します。まずは振り返りとしてアプリ生成時のプロンプトは見てみましょう。
さまざまな種類の投資口座に関する質問に回答できる、金融サービス ウェブサイト用の chatbot を作成します。
これをアレンジして特定の技術質問について冷静にそして根拠をもってわかりやすく説明してくれるチャットボットに修正していきましょう。
変更後のプロンプトは以下のとおりです。
さまざまな技術質問（クラウド、ITの基礎技術、IT用語など）に対して 冷静にそして根拠をもってわかりやすく説明してくれるテクニカルサポート用の chatbot を作成します。 回答は野球実況者のように熱く語ってください。
このプロンプトを仕様変更時に使用した画面で使います。
プロンプトを送信する
では、作成したプロンプトを送信します。仕様変更時に使用した画面で
変更を加えるか、新しい機能追加し...というプロンプトの送信UIが見つかるはずです。（以下）
プロンプトをコピーして貼り付け、送信します。
しばらくすると新規作成のときと同様に画面の変更が開始されます。なお、すぐにデプロイされる（自分以外の人が触れる状況になる）ことはないため、安心して変更ができます。プレビューが表示されるまでしばらく待ちましょう。
プレビューから変更後のアプリを触ってみる
プレビュー画面が表示されましたら、プレビュー画面から質問を投げてみます。
前回同様、よくある質問があるのでAPIについて質問してみます。
すると思考中...フルスイングの準備だ！と表示されます。回答が出るまでしばらく待ちましょう。
レスポンスは以下のとおりです。
🏟️ レストランのウェイターに例えてみよう！ これだけでは、まだ少し抽象的かもしれませんね！では、もっと身近な例に例えて、このAPIという名の難解な変化球を、見事に打ち返してみせましょう！ あなたがレストランに行った時のことを想像してください。 あなた（利用したいアプリA）：お腹が空いて、美味しい料理（特定の機能やデータ）が食べたい！ ウェイター（API）：あなたは直接厨房に行って料理を作ることはできませんよね？そこで、ウェイターを呼びます。ウェイターは、あなたの注文（「〇〇が欲しい」「〇〇をしてほしい」というリクエスト）を聞き取ります。 厨房（提供元のアプリBやサービス）：ウェイターは、あなたの注文を厨房に正確に伝えます。厨房は、ウェイターから受け取った指示（「〇〇という料理を作ってくれ」）に従って料理を作り、ウェイターに渡します。 ウェイター（API）：ウェイターは、出来上がった料理（リクエストした結果のデータや処理）を、あなたに運びます。 この例で言うと、「ウェイター」こそがAPIの役割なんです！ あなたは、厨房の中身がどうなっているか、シェフがどうやって料理を作っているか、知る必要はありません。ウェイターに注文を伝えるだけでOKです。 ウェイターは、注文の仕方（メニューの提示、注文の聞き方）という「ルール」に従って動きます。 厨房も、ウェイターからの指示（APIの仕様）に従って料理を作ります。 このように、APIがあるおかげで、**「複雑な内部の仕組みを知らなくても、定められたルールに従ってリクエストを送れば、必要な機能やデータを利用できる」**ようになるわけです！
アプリを更新して公開する
これまでの手順でプロンプトを変更し、プレビューで変更後のアプリを確認しました。しかし、アプリを公開するという手順を踏んでいないため、今のままでは自分しか閲覧できません。では、実際にアプリを更新して公開してみましょう。
プレビュー画面にある🚀マークから操作します。
確認をクリックします。
ステータスが準備完了になっていることを確認したら、閉じるをクリックします。
最後にアプリを開くをクリックするとアプリを開くことができます。
アプリの更新はバックエンドにあるCloud Runのサービスに変更を加えることになりますが、このようにGemini Enterprise Agent Platformの画面から簡単に変更ができます。
なお、この更新作業では再度アプリケーションをデプロイする流れにはなりますが
Cloud Runの設定は変わっていないため、認証設定含めそのままです。つまり社内公開であれば、社内公開のままということでインフラを調整する必要はありません。
デプロイまで実際にやってみて思ったこと
ここからは開発からデプロイまでの間で「注意すべきかもしれない」と思ったところをつらつらと書いていきます。
- Cloud Runのサービスアカウントには注意
- 社内公開ならば認証の設定に注意
- Cloud Runの設定（スケーリングとリソース、課金）
- 生成されたアプリにはテストが書かれていない
- 認証がうまくいかない
Cloud Runのサービスアカウントには注意
Google Cloudの認証・認可の仕組み(IAM)にはサービスアカウントというものがあります。そのなかにはコンピューティング向けのデフォルトサービスアカウントというものがあり、Google Cloud上のリソースを作成・変更・削除できるとても権限が広いものになっています。
※デフォルトではCompute Engine default service accountという名前で定義されているアカウントになっているはずです。
つまり、チャットボットからのプロンプトインジェクション（プロンプトを使ったセキュリティ攻撃）をすることでGoogle Cloudのリソースにアクセスできる可能性があります。
本番運用の際にはセキュリティエンジニアと相談するかプロジェクト管理者とよく相談してサービスアカウントを作成して利用するようにしましょう。
社内公開ならば認証の設定に注意
ハンズオンをやっていくなかで認証の設定に触れる場面があったと思います。
親切なことにパブリックに公開する際はパブリックに公開される旨のチェックボックスがあります。警告を読んで対応していれば、何も問題ありません。
しかし、Cloud Run自体は昔からあるサービスでgcloudというコマンドを使ってわずか数行でデプロイすることが可能です。
昨今はAIツールによるデプロイもあってかそこまで詳しくなくてもデプロイできることもありますのでどのような設定でデプロイされるかには注意が必要です。
Cloud Runの設定（スケーリングとリソース、課金など）
Cloud Runの設定について少し触れたのでもうひとつかふたつ…etcに触れたいと思います。
まずはスケーリングについてです。Cloud Runはスケールトゥーゼロという使っていないときはコンピューティングリソースを消費しないという性質を持っていることは前述のとおりです。
最小のコンピューティングリソースについてはそのとおりですが、注意しないといけないところとしては最大数です。Gemini Enterprise Agent Platformでデプロイした場合、デフォルトでは100となっています。
つまり、大量のアクセスが見込める場合は100台までリソースを消費することになりますので意図していない場合は設定を変更するようにしましょう。
（※ちなみにデフォルトでは1台あたり512MB、vCPUは1です。）
生成されたアプリにはテストが書かれていない
実際にアプリケーションのテストをしたことがない方にはあまりピンと来ない内容かもしれませんが、基本的にアプリケーションにはテストが書かれています。
この場合のテストとはソフトウェアテストのことを指します。ソフトウェアテストとは何かについて説明するとここでは長くなってしまうので割愛しますが、ソフトウェアテストを行うことで想定した動作をアプリケーションができているかを確認できます。
昨今ではソフトウェアにAIが組み込まれることも多くなってきたので従来のソフトウェアテストに含めてAIエージェントの評価も必要になっています。
なお、Gemini Enterprise Agent PlatformではAIエージェントの評価も可能ですので本番デプロイまで考えている方は評価にも対応しましょう。
認証がうまくいかない
ハンズオンの最中にうっかり、認証の設定を忘れて後で設定した場合は反映まで時間がかかることがあります。そんなときは認証を設定したあとにアプリの更新を試してみてください。
これはおそらく、Cloud Runのようなサーバーレスにありがちなものです。Cloud Runは使うときだけ動作するように使えるという性質を持っています。使われないときは動作せず、ユーザーからのリクエストがあったときのみ動作します。
そして、しばらく動作がない状態が続くと一度アプリケーションがシャットダウンされます。このとき認証のセッションも切れます。アプリの更新ではこのシャットダウン動作を実行できます。
余談
ここからは実際にエージェントを作った際に聞かれそうなことやもっと応用的なことやりたい人向けにいくつか余談を書きます。
エンジニアやソフトウェアに詳しい人に仕組みを聞かれたら？
サクッとデプロイできると何がどうなっているのかわからないと思います。
そこで説明を求められてしまうと言葉に詰まってしまい、せっかくのアプリが公開できない！なんてことになりかねません。そこでいくつか想定されそうな疑問点を書いておこうと思います。
- チャットボットが動作している実行環境
- 認証・認可の設定
- 他のサービスとの連携
- ハンズオンで作成したチャットボットの可観測性
- ハンズオンで作成したチャットボットの評価
- Gemini Enterprise Agent Platformからデプロイされているかどうかの確認
順番に見ていきましょう。
チャットボットが動作している実行環境
今回のハンズオン手順をなぞってデプロイした場合はGemini Enterprise Agent PlatformのApp BuilderからのデプロイになるのでCloud Runです。
Cloud Runのドキュメントを参照するようにしてください。
認証・認可の設定
Gemini Enterprise Agent Platformからエージェントを作成したということで新しく認可のサービスを使っているかというとそうではなく、従来どおりGoogle CloudのIAMが利用できます。今回のハンズオンのようにチャットボットを作成する場合は権限を絞って本番にデプロイしましょう。
他のサービスとの連携
MCPを使った方法で可能です。Agent RegistryにはMCPサーバーを管理する機能があるため、MCPサーバーを統制・管理しながら利用することが可能です。
ハンズオンで作成したチャットボットの可観測性
Cloud RunでデプロイされているのでCloud Runから確認できます。もちろん、Cloud Loggingからログも確認できます。
また、エージェントに変換することでGemini Enterprise Agent PlatformのAgent Runtime上でトレースを確認することもできるようになります。
ハンズオンで作成したチャットボットの評価
評価方法としては3通りです。
- エージェントに変換してAgent Runtimeで評価
- Google Colab Enterpriseにインポートして評価
- ADK/agents-cli evalの評価機能を利用して評価
まず、ハンズオンで作成したチャットボットはエージェントに変換することが可能です。
（変換する項目はお馴染みの🚀マークからいけます。）
エージェントに変換してGemini Enterprise Agent PlatformのAgent Runtime上で実行できますのでAgent Runtimeによる評価が可能です。
2つめにGoogle Colab Enterpriseにインポートすることによりブラウザ上で評価が可能です。
※create_genai_agent_evaluation.ipynbによる評価になります。
3つめにagents-cli evalの評価機能を利用して評価することもできます。
Gemini Enterprise Agent Platformからデプロイされているかどうかの確認
Cloud Runの設定画面からデプロイ元を確認できます。デプロイ元でGemini Enterprise Agent Platformからデプロイされているかどうかがわかります。
agents-cliについて
もっとAgentを作りたい！CLIも触れます！という方はagents-cliを使うと良いでしょう。最低限の解説はしますが、もっと知りたいという方は以下の公式ドキュメント集を参照してください。
- google/agents-cli: The CLI and skills that turn any coding assistant into an expert at creating, evaluating, and deploying AI agents on Google Cloud.
- agents-cli
- getting-started
では、実際にagents-cliを見ていこうと思います。
Overview
agents-cliとはなんでしょうか。GitHubのREADME.mdによると以下のように説明されています。
お気に入りのコーディングアシスタントを、Google Cloud 上でエージェントを構築およびデプロイするエキスパートに変えましょう。Agent Platform の Agents CLI (agents-cli) を使用すると、コーディングエージェントにエンタープライズグレードのエージェントを構築、拡張、管理、最適化するためのスキルとコマンドが提供されるため、すべての CLI とサービスを自分で学習する必要はありません。Gemini CLI、Claude Code、Codex、Antigravity、およびその他のコーディングエージェントとシームレスに連携します。
※翻訳にて記載
つまり、既存のコーディングエージェントとうまくつながってAIエージェント開発ができるというものです。説明を聞くより、やってみるほうが早いかもしれません。
agents-cliのハンズオン
agents-cliについてハンズオンしながら解説します。
前提となる環境
- MacBook
- Mac純正Terminal
- シェル：zsh
- gcloudコマンド
- uv
gcloudコマンドのバージョンは以下のとおりです。
Google Cloud SDK 565.0.0 alpha 2026.04.10 bq 2.1.31 core 2026.04.10 gcloud-crc32c 1.0.0 gsutil 5.36
なお、VPN環境下でハンズオンしている方はgcloudにカスタム証明書の登録等を忘れないようにしてください。
gcloud config set core/custom_ca_certs_file [PATH_TO_CUSTOM_CA]
参考：プロキシ / ファイアウォールの背後で gcloud CLI を使用する場合の構成
筆者の環境では証明書ファイルを独自で作成しています。
以下のコマンドでPythonの証明書を検索、Pythonの証明書（certifiで取得できる証明書）を自社の証明書に追記して利用しています。
python -c "import certifi; print(certifi.where())"
uvバージョンは以下のとおりです。インストール方法はココを参照
uv --version # 0.11.6 (65950801c 2026-04-09 aarch64-apple-darwin)
セットアップ
まずは環境を構築します。今回はuvとローカル環境をセットアップします。
大まかな手順としては以下のとおりです。
1.プロジェクトIDをセット
2.ロケーションをセット
3.gcloud authで認証
まずはプロジェクトIDをセットします。
gcloud config set project {PROJECT_ID}
つぎにGoogle Cloudのリソースが動作するリージョン（ロケーション）をセットします。
export GOOGLE_CLOUD_LOCATION=us-central1 # ついでにPROJECT_IDという環境変数も作成しておきます export PROJECT_ID=`gcloud config list --format 'value(core.project)'` && echo $PROJECT_ID
最後にgcloud authで認証します。このとき、一つ前に作成したPROJECT_IDを使って認証します。
認証するために以下のコマンドを実行します。
gcloud auth application-default login --billing-project=$PROJECT_ID --scopes="https://www.googleapis.com/auth/cloud-platform"
Google Agents CLI を試してみる
セットアップが完了したら実際にGoogle Agents CLI を試してみましょう。新しいターミナルを起動します。
PROJECT_IDのセット
まずは環境変数PROJECT_IDをセットします。
export PROJECT_ID=`gcloud config list --format 'value(core.project)'` && echo $PROJECT_ID # PROJECT_IDが入っているかを確認
google-agents-cli setup
次にagents-cliをセットしていきます。なお、agents-cliはgoogle-agents-cliで実行できますが、短縮形でagents-cliでも実行できます。
今回はあえて長いほうのコマンドを使っていきます。
uvx google-agents-cli setup
実行結果
Installed 62 packages in 196ms ⚠️ Skills version mismatch — CLI is v0.2.0, but 7 skill(s) differ: - google-agents-cli-adk-code (v0.1.3) - google-agents-cli-deploy (v0.1.3) - google-agents-cli-eval (v0.1.3) - google-agents-cli-observability (v0.1.3) - google-agents-cli-publish (v0.1.3) - google-agents-cli-scaffold (v0.1.3) - google-agents-cli-workflow (v0.1.3) Run 'agents-cli update' to sync. 〜〜〜〜 ~/.agents/skills/google-agents-cli-adk-code │ ~/.agents/skills/google-agents-cli-deploy │ ~/.agents/skills/google-agents-cli-eval │ ~/.agents/skills/google-agents-cli-observability │ ~/.agents/skills/google-agents-cli-publish │ ~/.agents/skills/google-agents-cli-scaffold │ ~/.agents/skills/google-agents-cli-workflow │ Done! Review skills before use; they run with full agent permissions.
実行結果は長いため省略していますが、~/.agents/skillsというディレクトリにスキルがインストールされていることが実行結果からわかります。
バージョンを確認します。
uvx google-agents-cli --version # agents-cli, version 0.2.0
helpの確認方法は以下のとおりです。
uvx google-agents-cli --help
helpを実行するとcreateというサブコマンドが見つかります。Create GCP-based AI agent projects from templates.ということでテンプレートからAIエージェントを作成できるようです。このコマンドを試してみましょう。
uvx google-agents-cli create
createというサブコマンドでAIエージェントをサクッと試していきましょう。まずは以下のコマンドを実行します。（詳細は省きます）
uvx google-agents-cli create my-collaborative-agent --agent=adk_a2a --yes
実行結果
✅ Success! Your agent project is ready. 📖 Documentation README: cat my-collaborative-agent/README.md 💡 Tip Once ready for production, run: agents-cli scaffold enhance 🚀 Get Started cd my-collaborative-agent && agents-cli install && agents-cli playground
補足：認証が切れている場合
ハンズオン中に離席して認証が切れている場合は再度認証してあげる必要があります。その際はADC(Application Default Credential)を更新します。
※参考：アプリケーションのデフォルト認証情報の仕組み
gcloud auth login --update-adc
AIエージェントをセットする
ここまでの手順でmy-collaborative-agentが作成されていることを確認します。
ls -la # my-collaborative-agent という表示があるかを確認してください。
ディレクトリを移動してAIエージェントが利用する依存パッケージをインストールします。
# ディレクトリの移動 cd my-collaborative-agent # 依存関係のインストール（ヘルプにあった install コマンドを uvx 経由で叩く） uvx google-agents-cli install
uvのPythonバージョンを下げる
証明書を使って接続している環境下でPython3.13を利用していると以下のようにCERTIFICATE_VERIFY_FAILEDが発生する場合があります。
google.auth.exceptions.TransportError: HTTPSConnectionPool(host='oauth2.googleapis.com', port=443): Max retries exceeded with url: /token (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Missing Authority Key Identifier (_ssl.c:1032)')))
これはPython3.13から証明書の設定が厳格になったことが背景にあります。バージョンを3.12に下げて対応します。
バージョンを下げるにあたって、pyproject.tomlをrequires-python = ">=3.12,<3.13"に修正します。
# .python-versionファイルを作成 echo "3.12" > .python-version # pyproject.tomlのrequires-pythonを更新 # requires-python = ">=3.12,<3.13" # uvでPython 3.12をインストール uv python install 3.12 # 既存の仮想環境を削除して再作成 rm -rf .venv uv sync
これでWeb UIを起動する準備ができました。
補足：根っことなるそもそもPythonバージョンを下げる場合
Python3.12がすでにインストールされている場合はエイリアスを変更することで改善する場合があります。
変更方法は以下のとおりです。
alias python=python3.12
また、gcloudはPythonをコアとして使っています。このPythonが3.13になっている場合はgcloudコマンドの実行でSSL: CERTIFICATE_VERIFY_FAILEDのエラーが出る可能性があります。このエラーを回避する場合は環境変数CLOUDSDK_PYTHONを変更します。
一時的に変更を行う場合は環境変数を定義、シェルの設定(zshなら.zshrc)なら以下のコマンドを書き込みます。
export CLOUDSDK_PYTHON=`/usr/local/bin/python3.12`
Web UIを起動
次にローカル用のプレイグラウンドを起動します。このローカル用のプレイグラウンドでAIエージェントとチャットができます。
# ローカル用のプレイグラウンド（Web UI）を起動！ uvx google-agents-cli playground # Error: No pyproject.toml found in the current directory or its parents.となる場合は以下 uvx google-agents-cli@latest playground
実行結果
│ Starting your agent playground... │ │ │ │ Running command: uv run adk web . --host 127.0.0.1 --port 8080 --allow_origins '*' --reload_agents │ │ Will be available at: http://127.0.0.1:8080/dev-ui/?app=app
実行結果を見てみると、adk webを使っていることがわかります。内部的にはGoogle ADKのadk webを実行しているようです。
# adk webをuvで実行（コマンド実行履歴を抜粋） # uv run adk web . --host 127.0.0.1 --port 8080 --allow_origins '*' --reload_agents
ローカルホストにアクセスして動作を確認します。
チャットしてみる
プレイグラウンドを試します。今回はKDDIアイレットについて教えてください。という質問をぶつけてみます。
KDDIアイレット（アイレット株式会社 iret Co., Ltd.）は、KDDIグループに属する企業で、クラウドインテグレーション事業を主に行っている会社です。 以下に、主な特徴と事業内容をまとめます。 1. 事業内容の概要 アイレットは、AWS（Amazon Web Services）やGCP（Google Cloud Platform）、Microsoft Azureといった主要なパブリッククラウドサービスに関する設計、構築、運用、保守、監視までをワンストップで提供しています。 2. 有名なサービス「cloudpack」 （以下略）
レスポンスが返ったあとに実行ログをみると.adk/session.dbという形でセッションDBが作成されていることやVertex AI(旧称)からgemini-flash-latestのモデルを呼び出していることがわかります。
2026-05-21 14:10:06,712 - INFO - local_storage.py:60 - Creating local session service at /Users/ke-yamada/Desktop/work/my-collaborative-agent/app/.adk/session.db 2026-05-21 14:10:06,717 - INFO - adk_web_server.py:867 - New session created: 85d01eee-6ddd-4bde-8ae5-34fff3324003 INFO: 127.0.0.1:59554 - "POST /apps/app/users/user/sessions HTTP/1.1" 200 OK INFO: 127.0.0.1:59554 - "POST /run_sse HTTP/1.1" 200 OK 2026-05-21 14:10:06,815 - INFO - google_llm.py:208 - Sending out request, model: gemini-flash-latest, backend: GoogleLLMVariant.VERTEX_AI, stream: True /Users/ke-yamada/Desktop/work/my-collaborative-agent/.venv/lib/python3.12/site-packages/google/adk/models/google_llm.py:259: UserWarning: [EXPERIMENTAL] feature FeatureName.PROGRESSIVE_SSE_STREAMING is enabled.
google-agents-cli deploy
ここまでの手順でエージェントを作成できたと思います。今回作成したエージェントをGoogle CloudのAgent Runtime（旧称:Vertex AI Agent Engine）にデプロイします。
# Google Cloudへデプロイ！
uvx google-agents-cli deploy
# Error: No pyproject.toml found in the current directory or its parents.となる場合は以下
uvx google-agents-cli@latest deploy --no-confirm-project
# Error: About to deploy to Google Cloud project '{プロジェクト名}' (resolved from `gcloud config`) — confirmation required.というエラーが出る場合は以下
# プロジェクトを指定する場合は以下
uvx google-agents-cli@latest deploy --project $PROJECT_ID
デプロイを実行すると実行結果がいくつか出力されます。（一部抜粋、環境変数に関する出力）
📋 Deployment Parameters:
Project: {プロジェクト名}
Location: us-east1
Display Name: my-collaborative-agent
Min Instances: 1
Max Instances: 10
CPU: 4
Memory: 8Gi
Container Concurrency: 9
🌍 Environment Variables:
AGENT_VERSION: 0.1.0
GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY: true
GOOGLE_CLOUD_REGION: us-east1
NUM_WORKERS: 1
OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT: true
INFO:root:Introspecting app.agent_runtime_app.agent_runtime via subprocess
それ以外にも所要時間の表示もありました。
Creating agent: my-collaborative-agent (this can take 5-10 minutes)...
なお、以下のコマンドで経過時間を観察できるようです。
uvx google-agents-cli@latest deploy --status
実行結果
⏳ Deployment still in progress (3m 49s elapsed) Operation: XXXXXXX Run 'agents-cli deploy --status' again to check.
デプロイされたエージェントを見る。
デプロイされると以下のようにアクセスするためのURLや情報が発行されます。
# uvx google-agents-cli@latest deploy --no-confirm-project後の実行結果 # ✅ Deployment successful! Test your agent: notebooks/adk_a2a_app_testing.ipynb # Agent Runtime ID: projects/XXXXX 🪪 Agent Card URL: https://us-east1-aiplatform.googleapis.com/v1beta1/projects/XXXXX/card Agent Runtime ID: projects/XXXXX Service Account: XXXXXX 📊 View in Console: https://console.cloud.google.com/vertex-ai/agents/agent-engines/locations/XXXXX
プレイグラウンドで試すことが可能ですが、実際に試してみたところ、メッセージを送信した際にレスポンスが一瞬だけ映って消えてしまいました。プレビューとあるのでひょっとすると不具合かもしれません。
※送信した際に発行されるセッションIDは確認できるため、動作していることは確認できます。
まとめ
今回はGemini Enterprise Agent Platformを使ってチャットボットを作成し、プロンプトを変更してアプリを更新するところまでやってみました。さらに、agents-cliを使ってローカル環境でAIエージェントを作成し、Google Cloudにデプロイするところまでやってみました。
Gemini Enterprise Agent PlatformはもともとVertex AIということでしたが、Vertex AI時代を知っている筆者からするとかなり別物に化けたという印象です。
実際に触ってみた感想としてはサービスだけではなく、UI/UXも変わったという印象もあります。「これは？！」と思ったところの変化としてはVertex AI WorkbenchがColab Enterpriseとセットで利用できるように変化したところでVertex AI Workbenchを使ったことがある人であれば、意外な印象を受けると思います。
いろいろと変わって便利な反面、扱うために相当な習熟が必要だと感じる側面もありましたが、総じて良さがあふれるアップデートだと感じました。今後のアップデートにも期待です。今回は以上です。
簡単30秒