※本記事は、Google I/O 2026にて実施されたセッション「Agent-first workflows from prompt to production」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=CBL6KgCsQNY でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
本セッションには、Richard Seroter氏、Christina Lin氏、Denise Kwan氏の3名が登壇しています。Agentic codingは開発速度を飛躍的に高める一方で、デプロイの壁にぶつかれば、その速度も意味を持ちません。本セッションでは、AgenticなコーディングをProduction Powerhouseへと変える方法を紹介し、コードエディタから離れることなく、Google Cloud全体でAIネイティブなアプリケーションを安全にデプロイ・スケール・管理するための一連のライフサイクルを解説しています。
関連リソースは以下の通りです。
- Codelab → https://goo.gle/4nx2dCg
- Google I/O 2026のCloud関連セッション一覧 → https://goo.gle/Cloud-at-IO2026
- Google Cloud Tech チャンネル登録 → https://goo.gle/GoogleCloudTech
#GoogleIO イベント:Google I/O 2026 登壇者:Richard Seroter氏、Christina Lin氏、Denise Kwan氏 言及された製品:AI/Machine Learning、Cloud
1. オープニング:ライブデモとDay2問題の提起
1-1. ライブ負荷テストとクラッシュ
Richard Seroter: 皆さん、お集まりいただきありがとうございます。おそらく多くの方は会場の空調目当てでいらしたのだと思いますが、それでも今日は良い時間になるはずです。先ほどのデベロッパー基調講演をご覧になった方はお分かりの通り、Antigravity 2.0やAI Studioを使えば、プロンプトや音声、コンテキストだけからソフトウェアを作れる、本当に驚くべき時代になりました。まさに今は「作る」ことにとって最高の時期です。実は私たちも、AI Studioでこのゲームを先ほど作ったばかりです。基調講演でもゲーム制作のデモがありましたが、私たちもここで少し楽しんでみたいと思います。こうしてゲームを作ったら、Publishをクリックして、Cloud RunやFirebaseのようなところにデプロイする。クレジットカードも不要で、最初の2つのアプリケーションはすぐに出荷できてしまう。これは本当に素晴らしいことです。誰もが「1日目」は大好きです。出荷して、達成感を得られる。ただ問題は「2日目」です。実際のトラフィックが来て、想定していなかったエッジケースや、うまくいかないことが次々と出てくるのです。
Richard Seroter: そこで、今日は私の友人であるChristina LinとDenise Kwanにも手伝ってもらいます。二人ともこれまで素晴らしいものを作ってきました。まず皆さんにお願いしたいのは、スマートフォンを取り出して、このQRコードをスキャンして、実際にこのゲームをプレイしていただくことです。本気で、I/Oのトラフィックにこのアプリが耐えられるかどうかを試してみたいのです。正直、少し不安があります。Christinaの仕事がこれにかかっている、というのは冗談ですが、それくらいの気持ちで見てみましょう。
Denise Kwan: リーダーボードを見てみましょうか。どうなるか楽しみです。
Richard Seroter: Denise、君は本当にこのゲームが上手いですね。
Christina Lin: 10秒生き残ればいいだけですよ。
Richard Seroter: リーダーボードの様子はどうでしょう、ちゃんと持ちこたえていますか。
Denise Kwan・Christina Lin: ……あっ。(リーダーボードの確認中に、まさにその場でアプリがクラッシュしてしまう)
Richard Seroter: これは……Christinaにはこれまで本当にお世話になりました。給料と有給休暇はきちんと後でお渡ししますので(笑)。冗談はさておき、こういうことは実際に起こり得ます。「2日目」の問題であり、負荷がかかれば当然こうしたことも起きるわけです。
1-2. Day2問題の提起と3ワークフローの予告
Richard Seroter: それでいいのです。むしろ、ここからどう考えるかが重要です。多くの開発者に「AIを使ってどこに時間を使っていますか」と尋ねると、答えの多くは「2日目」に関するものではありません。デプロイやモニタリング、修正といった作業ではなく、「コードを書く」「ドキュメントを作る」といった構築作業にAIを使っている人がほとんどです。それ自体は素晴らしいことですが、まだ十分な数の人が「2日目」の journey にAIを活用できていません。
Richard Seroter: そこで、これから30分ほどをかけて、3つのエージェントファーストなワークフローをお見せしたいと思います。これらは、今回のような vibe coding によるプロトタイプを、より信頼性が高く、より本番運用に耐えうるものへと変えていくための取り組みです。AntigravityやGoogle Cloudの各種コンポーネントを使いながら、こうした vibe coding で作られたアプリを、きちんとしたものに仕上げていきます。まず最初に取り上げるのは、「エージェントファースト・デバッグ」です。
Richard Seroter: デバッグが好きな方もいらっしゃるかもしれません。そういう方はきっとパーティーでもこの話ばかりしているのでしょうが(笑)、Denise、実際のエージェントファーストなデバッグとはどのようなものか、皆さんに説明してもらえますか。
2. ワークフロー1:エージェントファースト・デバッグとデータ操作
2-1. 音声指示による障害調査・修正とMCPの仕組み
Denise Kwan: はい、何かがクラッシュしたとき、たいていの場合は大量のログを一つひとつ確認しなければなりません。正直、私はそんなことはしたくありません。設定に誤りがないかを確認し、パフォーマンスメトリクスを見てレイテンシに問題がないかも調べる。でも、誰もそんな作業はやりたくないはずです。そこで、私たちのエージェント型開発ツール、今回で言えばAntigravityにその作業をやらせてしまえばいいのではないか、と考えました。手作業をすべて自分でやる必要はどこにもありません。実際にゲームがクラッシュして、何が起きたのかを知りたい状況です。私は面倒くさがりなので、実際にキーボードで入力するのではなく、音声入力を使って「Dino Questの不具合を調べて」とだけ指示を出します。ここで送信します。ご注目いただきたいのは、私が「ログはどこにありますか」とも「Dino Questのサービスはどこですか」とも一切言っていない点です。何をすべきかを伝えるだけで、すべてやってくれるのです。これが可能になっている理由は、Googleが管理しているMCPサーバー群のおかげで、エージェント型ツールをCloud Runなどの各サービスに安全に接続できるからです。ご覧の通り、非常に多くのMCPサーバーが利用可能になっており、APIキーを個別に管理したり、コンソールに入って画面をクリックして回ったりする必要はありません。Google Cloud上のすべてのデータとサービスが、エージェントから利用できる状態になっています。
Denise Kwan: それでは、Antigravityの画面に戻って確認してみましょう。ご覧の通り、私たちが話している間にすべて完了していました。手作業でデバッグしていたら、こんなことが可能だったでしょうか。結果としては、原因は503、つまりサービス利用不可のエラーだということが分かりました。おそらく皆さんが今このゲームに負荷をかけてくださったことが原因の一つになっていると思います。原因が分かったので、次は実際に問題を修正してもらいます。再びAntigravityに対して、「Dino Questのコードを見て、原因となっている問題を修正して」と指示を送ります。これで送信し、Antigravityが作業を進めてくれます。ただ、これが処理されている間に、Richard、Developer Knowledge MCPについて皆さんに説明してもらえますか。とても良いMCPだと思うので。
Richard Seroter: はい、先ほどDeniseも触れていた通り、BigQueryからCloud Runまで、今日時点で50種類以上のGoogle管理MCPサーバーが利用可能になっています。その中でも、ぜひ皆さんに使っていただきたいのがDeveloper Knowledge APIあるいはDeveloper Knowledge MCPと呼ばれるものです。これは、AIからCloud、Firebaseに至るまで、十数種類のGoogleのドキュメントベースをまとめて扱うMCPサーバーです。「これが必要」と伝えるだけで、あらゆるドキュメントを検索し、最新のバージョンをコーディングツールに取り込んでくれます。これによって、自分が古いバージョンを使っているのか正しいバージョンを使っているのかを推測する必要がなくなります。最新でも8時間から12時間以内のスナップショットのドキュメントが、そのままエージェント型ツールに反映されるのです。しかも、Claude Codeを使っていようと、Codexを使っていようと、Antigravityを使っていようと関係ありません。最新のGoogleドキュメントをそのままツールに取り込んで、使いやすくすることができます。
Denise Kwan: それは本当に助かりますね。よくある問題の一つが、古い情報をそのまま使ってしまうことなんです。そうなると、エージェントが実際に期待通りの動作をしてくれなくなってしまいます。
Richard Seroter: それは私が一番避けたいことです。
Denise Kwan: さて、続けましょう。ちょうどAntigravityの処理が完了したようです。問題は実はリーダーボードの部分にあったとのことで、main.pyファイルに対して修正コードをすでに作成してくれています。私自身は何もする必要がありませんでした。ただ実行させただけです。通常であれば、この後GitHubにコミットして、再デプロイする流れになります。Antigravityにはそれも任せられるのですが、この後もう少し面白い見せ場を用意しているので、あえて今はデプロイしないでおきます。
Richard Seroter: いいですね。
Denise Kwan: Christina、お願いします。
Christina Lin: もちろんです。Googleは透明性を大切にしていますので、こういうことが起きた際には、皆さんに何かお返しをしたいと思っています。クラッシュに巻き込まれてしまった皆さんのために、ゲームの中で少しごちそうをお渡ししたいと思います。
2-2. Data Agent Kitによる自然言語データ操作
Christina Lin: ここにあるのがData Agent Kitです。Data Agent Kitを使うと、自分のデータソースに対する可視性が得られます。なぜデータソースの話をしているかというと、実はこのゲームを朝の3時に vibe coding で作ったからです。
Richard Seroter: それは大したものです。よく頑張りましたね。
Christina Lin: そうなんです、目の下のクマはそこから来ています(笑)。作業の終盤はかなり記憶が曖昧になっていて、どこに何を保存したのかを自分でも忘れてしまっていました。そこでこのツールが非常に役立ちました。自分でわざわざ調べに行かなくても、どこに何があるのかを把握できるからです。今、私のAntigravityにはData Agent Kitがインストールされています。Antigravityの画面に移動して、Data Agent Kitに対して、すべてのデータソースを調べて、ごちそうを追加するように依頼してみます。ご覧の通り、私はAI Studioで vibe coding をしていたので、ドキュメントデータベースが色々とあります。AI Studioは基本的にFirestoreをデータベースとして使うことが多く、これはドキュメント型のデータベースです。これを更新するのは、単純にSQLを一文書けば済むような話ではありません。場合によっては、ドキュメントを挿入するためのコードを自分で書く必要があり、少々面倒な作業になります。そこで自然言語を使いたいと思います。ここに移動して、「全ユーザーに5個のトリーツを追加して」と入力し、送信します。これによって、このData Agent KitはMCPサーバーへのアクセス権を持っているだけでなく、スキルも備えています。このスキルにはノウハウが組み込まれているので、単にサーバーと通信するだけでなく、正しいやり方で処理する方法も理解しています。ご覧の通り、エージェントはPythonファイルを実際に書き上げ、それを実行しようとしています。ただし、Antigravityは何が起きているかを把握しているため、無条件には実行しません。安全性の観点から、まず私に実行の許可を求めてきます。
Richard Seroter: それはいいですね。
Christina Lin: 許可を出して実行させます。これで3人のユーザーに対して5個ずつトリーツが挿入されるはずです。あれ、ユーザーは3人しかいないんですね。もっといると思っていました。
Richard Seroter: 3人しかいないところにクラッシュを起こしてしまったわけですね(笑)。
Christina Lin: そうなんです、失敗しました(笑)。それでは、実際にDino Questの画面に移動して、トリーツが追加されているか確認してみましょう。ご覧の通り、ユーザーにトリーツが5個追加されています。それから、皆さんにお知らせしたいアナウンスの件についてもお話しします。実は、このアナウンスの保存場所についても記憶が曖昧で、朝の3時にコーディングするのはあまり良い考えではないということがよく分かります(笑)。そこで、こちらもAntigravityに任せてしまいます。「タイトルを『クラッシュしてすみません』とし、それぞれ5個のトリーツを受け取れる旨のメッセージを添えたアナウンスを追加して」と依頼します。このエージェントは、すべてのデータストアを調べに行きます。幸いこれはそれほど複雑なケースではなかったため、アナウンスがどこに保存されているかをきちんと特定できました。そしてドキュメントを作成し、さらにメッセージの文面まで考えてくれました。私は英語があまり得意ではないので、とても丁寧なお詫びのメッセージを作ってくれたのは助かります。メッセージを確認したい方は、画面をリフレッシュしてみてください。ご覧の通り、メッセージがドキュメントに挿入されています。素晴らしいと思いませんか、Richard。
Richard Seroter: それは本当に素晴らしいですね。名誉挽回です。データベースを操作するというのは、誰もが持っているスキルではありませんが、それでもワークフローの中にスキルを組み込むことで、こうした作業がこなせてしまう。これは本当にすごいことです。こうしたエージェントファーストのワークフローは、いわば発想の転換であり、これまでの私たちの働き方とは異なる、新しいものだと感じます。ライブ環境に接続し、ログを取得し、それをもとに反復していく。こうした新しいデバッグへのアプローチ、そして仕様の計画・活用の仕方について考えることは、非常にエキサイティングだと思います。
3. ワークフロー2:エージェントファースト最適化(データ分析)
3-1. ゼロETLパイプラインの構築
Richard Seroter: さて、ここまでで嬉しいことに、ユーザーの皆さんが楽しんでプレイしてくれていると思います。もう一度試して、いろいろ触ってみていただければと思います。ここから先は、このアプリをどう成長させていくかという話です。どうやって修正し、最適化し、パフォーマンスを改善していくのか。私たちの2つ目のワークフローは「最適化」です。ユーザー行動をどう理解するのか、ゲームをより競争的で面白いものにするために、どうチューニングしていくのか。ログデータを見れば、ユーザーがどの恐竜をよく使っているのか、といったことが分かるはずです。ただし、ETLパイプラインを一から書いてデータを分析するのではなく、エージェントを使ったもっと良いやり方があるはずです。
Denise Kwan: 常により良いやり方があるものです。わざわざ手作業でやる理由はありません、時間の無駄ですから。そこで、ここでも再びData Agent Kitを使います。Data Agent KitはIDE用の拡張機能で、これを使うことでBigQuery関連の様々な機能にアクセスできます。今回はData Agent Kitに加えて、BigQuery MCP、そしてこの用途のために作ったカスタムのエージェントスキルを組み合わせて使います。ここに、そのスキルを開いた状態で表示していますので、単なる魔法ではなく、実際にどんな処理を行うスキルなのかをご覧いただけます。このスキルは、ゼロETLの分析パイプラインを自動構築するための設計図を与えてくれるものです。具体的には、まずログルーターのシンクを作成し、ライブログを直接BigQueryのデータセットにストリーミングします。これによって、手作業でのデータ配線は一切不要になります。続いて、BigQuery MCPを使って複数のクエリを並列に実行し、ログから得られたデータを抽出します。そして最後に、そのデータをもとにインタラクティブなダッシュボードを作成します。このスキルはAntigravity上で直接実行できるのですが、今回はデータ量が多く、実行にはある程度時間がかかるため、皆さんの前で実際に動かすのではなく、あらかじめ事前に実行しておきました。今の時刻を考えると、この場で9分ほど待っていただくのは現実的ではないと思ったからです。実行にあたって私が行ったのは、「Dino Questアプリ用にそのレポートを実行して」と伝えることだけです。すると、先ほど説明したパイプラインの通りに処理が進み、ログレポートが作成され、次のバージョンで何を改善すべきかを示す特徴分析(フィーチャーインサイト)が作られ、さらにインタラクティブなダッシュボードまで生成されました。
3-2. ダッシュボード分析結果と自然言語クエリ
Denise Kwan: それでは、実際に生成されたダッシュボードを見てみましょう。こちらです。トラフィックの概要として、リクエスト数やサーバーログの件数、そして恐竜のタイプ別の勝率が表示されています。どうやらSpeedyというタイプの勝率が54%で、もっと早くこちらを選んでおくべきだったようです。私はTankを選んでいましたが、そこまで悪い成績ではありませんでした。一方でBalancedというタイプが最も勝率が低いという結果になっています。
Christina Lin: そうですね。
Denise Kwan: さらに、結果別のトリーツ獲得数や、最もよく使われている恐竜のタイプも分かります。多くのプレイヤーがある恐竜を繰り返し使っているのであれば、それはおそらく強い恐竜だと推測できます。ここで重要なのは、このダッシュボードを作っただけでなく、BigQuery上のすべてのデータに対して、そのままAntigravityで自然言語による質問ができるようになっている点です。もうMySQLのクエリの書き方を調べる必要はありません。正直、SELECT文の書き方などをきちんと考えるのは久しぶりのことでした。そこで、そのまま質問を投げかけてみます。さらに、質問して情報を得るだけでなく、分布グラフをその場で描画することもできます。この良い点は、わざわざコンソールに戻ってSQLクエリを書き、それをグラフにする、といった作業をする必要が一切なく、すべてを一つの場所で完結できることです。コンテキストの切り替えが発生しません。先ほど9分ほどかかったと言いましたが、それでも手作業でこの短時間にこれだけのことをやるのは、まず不可能だったと思います。
Denise Kwan: どう思われますか。
Richard Seroter: とても印象的です。正直に聞きたいのですが、あなたはどれくらいデータ分析が専門なのでしょうか。今回のことの多くは、スキルやツールに助けられて、本来は自分の得意領域ではない部分をこなせた、ということなのでしょうか。それとも、皆さんに「かなり高度なことをやっている」と感じてもらうべきなのでしょうか。
Denise Kwan: SQLを触るのはしばらくぶりでした。私たちは普段、フロントエンド寄りのコーディングをすることが多く、こうした分析作業はあまりやりません。どんなクエリを組み立てればよいかを考えること自体、日常的に行っていることではないんです。
Richard Seroter: それはすごいことです。何百万件ものログという規模から、数分のうちに明確で actionable な特徴(フィーチャー)へとたどり着けたわけです。これこそ、こうしたエージェントファーストのワークフローにおけるスキルやツールから得られるレバレッジだと思います。もし1年前に同じアプリを作っていたとしたら、私自身は気後れしていたと思います。だからこそ先ほどのような質問をしたのです。BigQueryを使った高度なクエリやETLパイプラインの構築は、本来自分の得意領域ではありません。ですが、こうしたスキルやMCP、ツールを使うことで、多くの人が本来自分の専門ではない作業もこなせるようになる。これは非常に興味深いことだと思います。そして、このData Agent Kitはすべてマネージドで提供されているので、こうしたスキルやMCPは常に最新の状態にアップデートされ続けます。Googleが改善するたびに、その恩恵を受けられるということです。
4. ワークフロー3:エージェントファースト・リメディエーション
4-1. 自己修復システムの仕組みとセキュリティ設計
Richard Seroter: ここまでデバッグを行い、最適化も行いました。最後のデモでは、もう一段階レベルを上げてみたいと思います。エージェントファーストな「リメディエーション」、つまり問題を検知して自動的に修正するという考え方について見ていきましょう。
Denise Kwan: はい、誰しもクラッシュには遭遇したくないものですが、クラッシュはいつでも起こり得ます。今この瞬間にも、どこかのアプリでクラッシュが起きているかもしれません。そうでないことを願いますが、おそらく起きているはずです。そして誰も、今やっていることを全部放り出してまでデバッグに向かいたくはありません。真夜中であればなおさらです。Christinaは朝の3時でも起きているかもしれませんが、皆が皆、そんな時間にこうした問題をデバッグするために起きているわけではありません。誰もデバッグなどしたくないのです。では、もしこれまでの作業、つまりAntigravityを使った手作業でのデバッグをすべて自動的に、それも24時間365日、私たちが見ていないところでも行われるようにしたらどうなるでしょうか。そこで私たちは、自己修復するシステムを構築することにしました。ご紹介するのが「Dino agents」です。恐竜のゲームなので、恐竜にちなんだ名前にしました。このDino agentsには、Remediationエージェント、CIエージェント、CDエージェントという3種類のカスタムエージェントがあり、それぞれ異なる役割に特化しています。これらのエージェントはCloud Run上でホストしています。Dino Questのゲーム自体もCloud Run上にホストされているため、同じプラットフォーム上に置くことで、セキュアで低レイテンシ、かつコスト効率の良いアーキテクチャを実現できます。これによって、手作業でのトラブルシューティングを、インテリジェントでスケーラブルなアシスタントへと置き換えることができるのです。これらのDino agentsは、フレームワークとしてAgent Development Kit(ADK)を使っています。ADKを使うことで、状態管理やツールのルーティング、リトライロジックといった部分を自分たちでゼロから実装する必要がなくなります。さらに、ADKのスキル機能を活用することで、いわば恐竜たちの「専門知識」を持たせることができ、カスタムのドメイン別プレイブックを読み込ませることで、知識を再現可能なワークフローとしてコード化できます。これらのエージェントはすべて本番運用可能で、可観測性を備えたエージェントです。後ほど実際に動いている様子をお見せしますが、まずは最初のエージェントであるRemediationエージェントに焦点を当てましょう。このRemediationエージェントは、常時稼働しているSREのような存在で、障害を自ら検知し、根本原因を修正することができます。仕組みとしては、私たちのアプリは常にCloud Loggingへログを出力しています。これはデフォルトの挙動です。エラーが発生すると、Event ArcとPub/Subがトリガーされ、それによってRemediationエージェントが起動します。Remediationエージェントは問題を調査し、Geminiを使って修正を行います。すべての作業が完了すると、Remediationエージェントは修正内容をまとめたGitHub PRを作成し、Slackで通知します。つまり皆さんは、Slack通知を受け取るだけでよく、必ずしもパソコンの前にいる必要はありません。スマートフォンのSlackで確認することもできます。このように、これはすべて非同期のイベント駆動型のプロセスであり、あらゆるエラーを actionable なジョブへと変換してくれます。
Denise Kwan: それでは、実際の動作をお見せしましょうか。
Christina Lin: もちろんです。エージェントに実際に働いてもらいましょう。お二人が話している間に、私はDino agentsをシステムにデプロイしておきました。すみません、Richard、またあなたのアプリを壊すことになります。
Richard Seroter: また壊すんですね。
Christina Lin: また壊します。壊すのが好きなんです、そうせざるを得ませんので(笑)。それでは、実際にシステムを壊しにいってみましょう。今回は、Dino agentがついているので大丈夫だと思います。画面の左側に、Dino agentsが実際に稼働している様子を示す小さなコードが表示されています。
4-2. クラッシュ再現ライブデモとA2A連携
Christina Lin: さて、システムはクラッシュさせようと頑張って動いているようです。
Denise Kwan: クラッシュさせるために一生懸命動いていますね。
Christina Lin: そうなんです、クラッシュさせようと必死です。
Richard Seroter: あなたの朝3時のシステムは、まるで熱に浮かされた夢のような光景ですね。
Christina Lin: その通りです(笑)。あら、なぜかクラッシュしませんね。
Richard Seroter: クラッシュしないんですか。
Christina Lin: わざと壊すことができないみたいです。もしかすると、システム自身が自己修復しようとしているのかもしれません。
Denise Kwan: そうかもしれません。エージェントをデプロイしている間に、すでに自己修復が働いていた可能性がありますね。
Christina Lin: そうですね。とりあえず様子を見てみましょう。……あ、恐竜がクラッシュしましたね。よし、ちゃんと落ちました。
Richard Seroter: 落ちましたね。
Christina Lin: はい、こちらをご覧いただければと思います。ライブでご覧いただいて構いません。ここにエージェントの動作の様子を可視化しています。Remediationエージェントが、あらゆる問題をリッスンしている状態です。この画面で、まさに今起きたことを可視化してお見せします。Remediationエージェントが立ち上がり、システムがクラッシュしたことを検知し、「修復を手伝います」という形で動き出します。修復するだけでなく、Deniseが先ほど話していた通り、コードの修正まで行います。実際にコードを修正し、それだけでなくGitHubリポジトリへのプッシュまで行っています。ご覧の通り、リーダーボードに関するPR(プルリクエスト)が作成されています。何が問題だったのかを正確に教えてくれ、問題が起きたので修正するというところまで一貫して行ってくれます。とても分かりやすいブランチ名が付けられていて、今回のケースで修正されたコードがどれかが一目で分かるようになっています。さらに、Slackのメッセージにも、Dino Questから何が起きたのかを知らせる通知が届いています。皆さん、ここまでちゃんとついてきていただけていることを願います。ご覧の通り、エージェントたちがきちんと働いているんです。モニター画面を見ていて、エージェント同士が踊るように連携している様子にお気づきになりましたか。
Richard Seroter: ええ、気づきました。
Christina Lin: あれがA2A(エージェント間通信)の部分です。単一のエージェントだけが動いているのではなく、複数のエージェントが協力して動いているんです。ほら、あそこです。見えますか、協力し合っているのが。
Richard Seroter: あれがそうなんですね。
Christina Lin: そうです、だからこそ「エージェントの群れ(swarm)」と呼んでいます。ご覧の通り、エージェントたちも仲良く働いてくれています。
Richard Seroter: エージェントたち、落ち着いてください(笑)。
Christina Lin: その通りです(笑)。さて、Richard、ここまでで私たちが構築したものをご覧いただきました。この一連の、エージェントたちがダンスするような楽しい仕組みは、すべてADKで構築されています。そして、必要なセキュリティもすべて備わっています。すべてのエージェントはIAMのセキュリティを継承しています。ですので、私のCIエージェントが勝手にデプロイを行うことはありませんし、Remediationエージェントがイメージのビルド権限を持つこともありません。すべての権限がきちんと継承・制限された状態になっているため、想定外の動作をすることがないのです。さらに、メッセージングシステムやGitHubなど、多くの外部システムにアクセスする必要があるため、それに関わるシークレット(認証情報)はすべて、シークレットマネージャーという非常にセキュアな場所に保管しています。
Richard Seroter: 素晴らしいですね。本当に感動的でした。
Christina Lin: そうですね。皆さんが感動してくれているのは分かっていますが(笑)、それはさておき、引き続きエージェントの監視についてもお話しします。これらのエージェントはCloud Run上にデプロイされているのですが、Cloud Runの良いところは、使われていないときには休止状態になる点です。そしてエラーが発生すると、そこで初めて起動します。起動した後は何をするかというと、私の代わりにバグを修正してくれます。まさに私の代わりに働いてくれるわけです。おかげで、デートの最中や友人との食事中に緊急連絡を受ける必要がなくなります。作業が終われば、また自動的にシャットダウンします。つまり、使っていない間の料金を支払う必要もありません。
Richard Seroter: それは最高ですね。
Christina Lin: お金の話も大事だとは思いますが、皆さんのようなエンジニア気質の方であれば、きっとエージェントがどう構築されているかということ自体にも興味があるはずです。というわけで、私がどうやってこのエージェントを構築したのか、そのためのツールの一つをご紹介したいと思います。
4-3. Agent CLIによるエージェント構築デモ
Christina Lin: 私はすべてADKを使って構築しました。ただ、ゼロから構築するのは決して簡単なことではありません。そこで、構築を助けてくれるツールが必要になります。私が使っているのが「Agent CLI」というツールです。少し画面を大きくしますね、皆さんに見えるように。これはリアルタイムで入力しています。
Richard Seroter: もう少し拡大してもらえますか。
Christina Lin: ありがとうございます。このAgent CLIを使うことで、エージェントのガバナンス、スケーリング、最適化を行いやすくなります。それでは、実際に新しいエージェントを作る様子をお見せしましょうか。
Richard Seroter: ぜひ見たいです。
Christina Lin: 分かりました。ただ、あまり長々とやるつもりはないので、始め方だけご紹介します。まず新しいエージェントを作成しましょう。何と名付けましょうか。
Denise Kwan: 恐竜のゲームですし、テーマに合わせてT-rexエージェントにしましょう。
Christina Lin: いいですね。それでは「T-rex」という名前で作成します。ずっと話し続けていた気がするので、そのままプロトタイプを作成してみます。これで、必要なものがすべて揃ったボイラープレートコードが生成されます。T-rexのフォルダを開いて、中身を見てみましょう。すでに多くのものが自動生成されています。エージェントのコードが作られていて、ADKのコードや、エージェントに含まれる指示(instructions)の定義、つまりエージェントがどう振る舞うべきかを定めたもの、そして利用可能な各種ツールも含まれています。すべてが最初から揃った状態になっています。さらに、エージェントをテスト・評価するためのテストコードもすべて含まれています。
Richard Seroter: それは素晴らしいですね。
Christina Lin: ええ、素晴らしいでしょう。さらに、後でデプロイできるように、コンテナ化に必要なファイル一式も含まれています。
Richard Seroter: それはすごいです。
Christina Lin: さて、これでエージェントの準備が整いました。それでは続きをRichardにお返しします。
5. 自律型CI/CDパイプラインとクロージング
5-1. CI/CDパイプラインの実演とリビジョン削除事件
Richard Seroter: そういうわけで、Agent CLIをぜひチェックしてみてください。無料で、使い方も簡単です。皆さんはすでにData Agent Kitもご覧いただきましたが、こうしたツール群は総じて使いやすく、すぐに手を出せるものになっています。それに加えて、もう一つ皆さんに紹介したいものがあります。これは長らく皆さんから要望をいただいていたもので、お待たせして申し訳ないのですが、クラウドのコスト支出をどうコントロールするか、という話です。近日公開予定として、現在プライベートプレビュー中の「スペンドキャップ」という機能があります。これは、Cloud RunやGemini APIなどのサービスに対して、予算の設定と強制を可能にするものです。この上限に達すると、トラフィックが一時停止されるようになっています。つまり、予算を使い切ってしまい、翌朝起きたら支出計画が完全に崩壊していた、という事態を防げるということです。今後、こうした仕組みをさらに多くのサービスに追加していき、支出計画を壊さないという安心感を持っていただけるようにしていきます。
Richard Seroter: さて、ここまで素晴らしいエンジニアリングをご覧いただきました。Agent CLIも本当によくできています。ご覧いただいた通り、評価やコードについて一定の構造を持ったオピニオンのあるツールになっていますが、そうした部分も自由にカスタマイズすることができます。ここまででゲームは安定してきたわけですが、ここでさらに新しい機能や新しいレベルを追加するというのは、突拍子もない話でしょうか。実際にそれができるかどうか、別のブランチで新機能を出荷してみましょう。正直なところ、また壊れるのではないかと少し怖いのですが。
Denise Kwan: どうしてそうやって彼女に無理難題ばかり頼むんですか(笑)。
Richard Seroter: ハードルを上げて試し続けたいんです。
Denise Kwan: ええ、もちろんできます。私たちは自律型のCI/CDパイプラインを自分たちで構築しました。すでに詳細の一部は先ほどご覧いただいていますが、本題に入る前に、CI/CDパイプラインには多少時間がかかりますので、まず実行を開始してから、その間に詳しい説明をしていきたいと思います。今回は、Slackからこのパイプラインを起動してみます。つまり、いつでも、どこからでも起動できるということです。ここでSlackに向かい、「CI Agent, Run CI on branch level 2」と入力して実行します。画面下に表示されている様子をご覧ください。これが動いている間に、詳細を説明していきます。私たちが構築したのは、先ほどご紹介した2つのエージェントを活用したパイプラインです。まずCIエージェントがあり、これは継続的インテグレーションを担当します。そして、このエージェントは検出した問題の修復や、セキュリティスキャン、テストも行います。さらにCDエージェント、つまり継続的デリバリーを担うエージェントがあり、これはアプリのデプロイを行い、デプロイのパターンを学習し、自動ロールバックによる監視も行います。障害が発生した場合には、正常な状態までロールバックしてくれます。これらのエージェントはすべてA2A(エージェント間通信)でやり取りをしており、あたかも一人のジェネラルエージェントが別のエージェントに指示を伝えるだけの関係ではなく、チームメンバー同士が協力し合っているような形になっています。実際、人間同士のように会話することができるのです。また、ご覧の通りSlackとも連携しており、通知を受け取ったり、Slackからパイプラインを起動したりすることができます。これはSlackのWebhookを利用して実現しています。従来の静的なパイプラインと違い、これらのエージェントは非常にインテリジェントで、私たちの代わりに判断を下すことができます。つまり、常にこちらから逐一指示を出す必要はないのです。
Richard Seroter: いいですね。
Denise Kwan: 実際の動作をお見せしましょうか。
Christina Lin: もちろんです。これまでご紹介してきた2つのエージェントですが、実際にはこれ以外にも環境の中にはもっと多くのエージェントが存在し得ます。それらを協力させて働かせるには、まずそれぞれのエージェントがどこにいるのかを把握する必要があります。そこで用意しているのが「エージェントレジストリ」です。見た限り、私たちのエージェントはあまり友達が多くないようですね。少し社交性を身につけさせてあげたほうがいいかもしれません……いずれ、別の機会にでも(笑)。とにかく、ここには3つのエージェント、CIエージェント、CDエージェント、そしてSecOpエージェントがいます。レジストリを見ると、これらがいわば「友人一覧」のような形で管理されており、各エージェントがどこにいて、どうやって呼び出すのかが分かるようになっています。さらに、そのエージェントの「人格」、つまりそのエージェントが何を行い、どのように物事を処理するのかという説明も提供されています。それだけでなく、そのエージェントがアクセスできるすべてのツールについても確認できます。ですので、このエージェントを利用しようとする際に、何ができるのかが非常に明確になります。ここに私自身も登録されているようですね(笑)。それでは、私たちのCIエージェントを見てみましょう。CIエージェントは、他のエージェントから通知や依頼を受け取り、A2Aで通信を行います。また、Slackからのメッセージも受け取ります。これらの情報を組み合わせて判断を行い、スキルを使って物事を考えます。そして、Slackメッセージや他のエージェントから与えられた情報をもとに、どのテストを実行すべきかを決定します。たとえばフロントエンドのコードが多く変更されていれば、フロントエンドのテストを実行しますし、変更内容によってはセキュリティのチェックを行います。つまり、単純に1、2、3という順番で処理を行う従来型のパイプラインとは異なり、逐次的ではなく、エージェント自身が状況に応じて考えて判断しているのです。そのうえで、Google Cloud Buildのような実績のあるサービスを使ってイメージをビルドし、Artifact Registryにそのイメージを保管します。処理が終わると、CDエージェントに通知やメッセージを送ります。CDエージェントは、いわばリリースマネージャーの役割を担っています。
Christina Lin: 実は、こうして複数のエージェントを同時に動かして楽しんでいたときに、ちょっとしたミスをしてしまったことがありました。誤ってリビジョンの一つを削除してしまったのです。すると、CIエージェントはCDエージェントに対して「このイメージをデプロイしてほしい」と伝えたのですが、そのイメージ自体がもう存在しない状態になっていました。何が起きたと思いますか。CDエージェントは実際にCIエージェントに対して、「おい、どういうことだ、そんなメッセージは見ていないぞ」と返してきたのです。そこから両者が何度もやり取りを重ね、問題が何なのかを突き止めていきました。最終的にCIエージェントが処理全体をやり直し、CDエージェントが無事にリリースを完了させました。本当に賢い挙動で、私自身とても驚きました。エージェント同士がこうしてやり取りしながら踊るように連携している様子を見ることができ、テストをしていて非常に面白かったです。CDエージェント側では、変更内容を確認し、コードの変更点をすべて見た上でリスクスコアを算出します。このリスクスコアは、その変更を環境にデプロイした場合にどれだけリスクがあるか、何か問題が起きる可能性がどれくらいあるかを示すものです。このスコアをもとに、カナリアリリースの方針を決定します。そして、一定時間その状態を監視します。今回はデモなので30秒間だけ監視し、その後すべてを本番環境にデプロイします。これが私たちのCD パイプライン全体の流れになります。
Richard Seroter: すごいですね。かなりよくできたシステムです。学習していく様子は、正直少し怖くもありますが(笑)、それでも本当に素晴らしいと思います。今日のセッションを通じて、私たちはエージェント型のツールがさまざまなステップをこなしていく様子をお見せしてきました。MCPやスキルのおかげでAntigravityと連携し、ライブのログ情報を取得し、データベースへの問い合わせを行う。これは本当にすごいことです。皆さんも、ご自身のエージェント型ワークフローを構築することができます。今回、エージェント型のCLI、Agent CLIについてもお見せしました。皆さんもぜひ、これを使って自分自身のものを作ってみてください。「2日目」の作業にすべての時間を費やす必要はもうありません。こうしたツールを使い、エージェントを支えるプラットフォームを活用することで、生活がぐっと楽になります。私たちエンジニアが好きな「問題解決」という営み自体がなくなったわけではなく、その中身が少し移り変わっただけなのです。設計の作業を行い、計画を立て、システムとやり取りをする。それは非常に素晴らしいことだと思います。
5-2. コスト管理機能とまとめ
Richard Seroter: さて、話はこれくらいにして、レベル2の公開です。もう出荷できましたか。
Christina Lin: はい、できています。
Richard Seroter: それでは、こちらのQRコードを読み取っていただければ、恐ろしい火山の中で苦しむ恐竜たちを操作して、レベル2をプレイしていただけます。
Denise Kwan: レベル2に進むには、まずレベル1をクリアする必要がありますよ。
Richard Seroter: レベル1、クリアできてましたっけ(笑)。
Christina Lin: できていましたよ。
Richard Seroter: それは何よりです(笑)。
Christina Lin: レベル1をクリアするのは結構大変なんです。
Richard Seroter: 何か裏技はありますか。上、右、上、右、B、A、スタート……ダメですね(笑)。
Denise Kwan: それ、コードに仕込んでおけばよかったですね(笑)。
Richard Seroter: さて、皆さんも空いた時間にぜひプレイしてみてください。今日ご紹介した3つのエージェントファーストなワークフローを、皆さん自身のアプリケーションに組み込みたいという方は、こちらのQRコードから実際のチュートリアルにアクセスできます。今日デモした内容のコードがすべて含まれています。これは本当に素晴らしいことだと思います。私たちが実際に構築したものすべてを、皆さんが自分の手で試せるラボの形にまとめてくれました。少しの間このまま画面を表示しておきますので、ぜひご確認ください。今日ここで見ていただいただけで終わるのではなく、実際に「自分たちでもやってみよう」と思っていただくことが、このイベント全体の目的です。ハンズオンで実際に手を動かし、自信をつけていただく。それがこのイベントの趣旨です。ぜひこれらのコードラボを活用して、皆さん自身に何ができるかを試してみてください。それでは、実際に作っていきましょう。楽しんでいきましょう。今日はご参加いただき、そして最後まで涼しく過ごしていただき、ありがとうございました。