※本記事は、Google Cloud が公開した「Google Cloud Next '26 Developer Keynote」の内容を基に作成されています。本キーノートでは、創造性という「スーパーパワー」を解き放ち、私たちを取り巻く世界をモデル化する方法をテーマに、「Hello World」を超えて、マルチエージェントのオーケストレーション、永続的なメモリ、ゼロトラストセキュリティといったエージェント型アプリケーションのエンジニアリングにおける難題に、実際にコードを書きながら取り組む様子が、1時間にわたって実演されています。AIを使ってAIエージェントを作り、プラットフォームを自律的に運用し、エージェントを大規模に使って世界をモデル化する過程をご覧いただけます。動画は https://www.youtube.com/watch?v=A01DQ8_xy7Q でご覧いただけます（ASL付きの配信は https://youtube.com/live/6e-lJkYF4Vc ）。本記事では、キーノートの内容を要約しております。なお、本記事の内容は原発表者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。
登壇者は以下のとおりです。冒頭の導入とソートリーダーシップを担当した Brad Calder 氏、司会およびシミュレーションの紹介を務めた Richard Seroter 氏と Emma Twersky 氏、エージェントプラットフォームでのエージェント構築を実演した Mofi Rahman 氏、自律エージェントのオーケストレーションを解説した Casey West 氏と Ivan Nardini 氏、メモリによるエージェントの強化を示した Lucia Subatin 氏と Jack Wotherspoon 氏、大規模なエージェントのデバッグを担当した Megan O'Keefe 氏、Gemini Cloud Assist による意図からインフラへの変換を実演した Bobby Allen 氏、ノーコードエージェントの構築と共有を紹介した Jason Davenport 氏と Ines Envid 氏、そしてエージェントのセキュリティについて解説した Ankur Kotwal 氏と Wiz の Yinon Costica 氏です。
なお、エンタープライズグレードのエージェント構築を学べる Gemini Enterprise Agent Ready（GEAR）プログラム（月35クレジット付与）の詳細は https://developers.google.com/program... を、Google Cloud Next '26 の100以上のセッションは https://www.googlecloudevents.com/nex... をご参照ください。
1. オープニングとキーノートの全体像
1.1 Brad Calder による導入：Gemini Enterprise Agent Platform の全体像
Brad Calder： デベロッパーキーノートへようこそ。今日は皆さんに素晴らしいショーをお見せします。昨日、私たちは Gemini Enterprise Agent Platform を発表しました。これは、ユーザーを能動的に支援し、タスクを独立して完遂する自律型エージェントを構築できるプラットフォームです。そして今日は、このエージェントプラットフォームを使って、本番環境で使えるエージェントをどう構築するかをお見せします。私たちのプラットフォームは最先端の Gemini モデルで動いており、Pro モデルと Flash モデルの両方を含んでいます。それだけでなく、Model Garden を通じて Claude のような他のモデルをエージェントに選ぶこともできます。
Brad Calder： プラットフォームが何を提供するのか、エージェントを構築・スケール・最適化する流れに沿って手短にご説明します。出発点となるのが Agent Development Kit、つまり ADK です。ADK を使えば、必要なスキルやツールでエージェントに力を与えられます。Google Cloud 全体にわたってすぐに使えるスキルを用意していますし、いまやすべての Google Cloud サービスがデフォルトで MCP 対応になっています。これによって、エージェントは Google Cloud と簡単にやり取りできます。次に、スケーラブルでサーバーレスなエージェントランタイムでエージェントを実行・スケールさせます。ランタイムでは、セッションを使ってエージェントをユーザーとつなぎ続け、メモリを使ってエージェントのコンテキストをパーソナライズし、焦点を絞ることができます。
Brad Calder： これらすべてを安全に保つために、私たちはエージェントに固有のエージェントアイデンティティを与えることでガバナンスを可能にします。これによって、エージェントに対するポリシーを設定でき、そのポリシーはエージェントゲートウェイによって厳格に強制されます。たとえばそうしたポリシーの一つが、他のエージェントとの接続です。エージェントレジストリと A2A プロトコルによって、エージェント同士が互いを発見し、協調できるようにしています。そして最後に、エージェントオブザーバビリティによって、エージェントの管理・監視・最適化が可能になります。これは本番環境でのエージェントの挙動に基づいた統合的な eval も提供します。いま申し上げた機能はすべて、Gemini Enterprise Agent Platform が提供するものです。
Brad Calder： Google 自身も、この同じエージェントプラットフォームの上で自分たちのアプリケーションを構築しています。それによって、共通の共有コンテキストですべてのエージェントを接続しガバナンスできるようにしているのです。私たちはこの共有コンテキストを、Gemini Enterprise、Workspace、そしてサードパーティのマーケットプレイスのエージェントにまたがって提供しています。これにより、皆さんのエージェントのエコシステム全体が共有コンテキストを介して協調できるようになります。さて、私は熱心なランナーなので、今日のキーノートデモには本当にわくわくしています。今日は、ラスベガスを舞台にしたマラソンの計画を立てる方法をお見せします。実際に走る必要はありません。いま説明したエージェントプラットフォームのすべてを使って、エージェント型のマラソンプランナーを構築していきます。AI を使えば、ラスベガスのストリップ沿いに 500 個の仮設トイレをどこに配置するかといった、影響の大きい意思決定もできるのです。皆さんを案内してくれる MC として、Richard So Machado と Emma Torski を迎えましょう。
1.2 MCによる導入と開発者コミュニティ事例
Richard： Brad、ありがとう。ショーへようこそ、Emma。
Emma： ここにいられてうれしいです、Richard。
Richard： ところで、君は走るの? Brad はずいぶん走ることばかり話していたけど。
Emma： 一度ハーフマラソンを走ったきりです。あなたは?
Richard： いや、走るなんてひどいよ。追いかけられているのでもなければ、誰がやるんだろうね。でも、ソフトウェア開発者の役割は大きく変わってきています。2026 年に向けて、新しい働き方を考えなければなりません。皆さんは、ほんの数年前なら数週間から数か月かかっていたアプリケーションを、いまや数日で作っています。
Emma： ここ Google でも、私たちはさらに速くやっています。このコミュニティにいる、とんでもなく才能ある開発者たちには圧倒されてきました。DeepMind では、Andy Coenen が Gemini を使って、複雑な地理情報システムのデータを、ニューヨーク市全体のノスタルジックな 90 年代風アイソメトリックマップに変換しました。何千ものピクセルをアートに変えることで、これまで自分には決して理解できないだろうと思っていたデータセットを、学び、可視化し、把握できるようになったのです。
Richard： まさにそうですね。あるいはインドの Google スタートアップアクセラレーターに参加している Cloud Physician のチーム。彼らは Google Cloud 上にマルチモーダルなビデオ AI プラットフォームを構築しました。高精細なビデオと AI 駆動の臨床ツールを組み合わせ、ベッドサイドのチームを 24 時間 365 日の中央ケアチームとつなぎ、専門医がより速く、より質の高い意思決定をできるようにしています。そして驚くべきことに、彼らは Google Cloud と Google AI を使って ICU の死亡率を 47% 削減し、文字通り命を救っているのです。
Emma： その数字が忘れられません。そして Flutter 開発者として個人的に応援してきたのが、フィンランドの Google Developer Expert である Çağatay Ulusoy です。彼は市民権試験の勉強をしながら、生成 UI を活用した言語学習アプリを作りました。このアプリは私のチームの Flutter Gen UI SDK に加えて、Firebase や Gemini など多くの Google 製品を使って、ユーザーの言語学習の仕方を生成しパーソナライズしています。
Richard： 私は個人的に Genie 3 でずいぶん遊んでいます。こうしたワールドモデルは、開発へのアプローチそのものを変えつつあります。Waymo は実際に Genie 3 を使って、まれな交通状況のエッジケースを再現し、それによって世界最高のドライバーを目指すための基盤モデルを訓練しています。これは、私がここに来る前にラスベガスを探索しようとして作ったプロンプトと体験です。よく見ると、偽物のブルーイみたいなのが、ニセモノのスパイダーマンと戦っているんですよ。まるで本物のラスベガスみたいでしょう。さて、私たちは口ではいろいろ言えますが、皆さんに証明しなければなりません。これからの 50 分ほどで、Google がエージェントを構築し、本番品質で実行する最良の方法を提供することを実演します。Emma、これから何をお見せするのか説明してくれる?
Emma： はい。何度も触れてきましたが、私たちはマラソンの計画をシミュレートするシステムを構築します。なぜマラソンかというと、エージェントが計画・シミュレーション・思考を通じて、本当に大きな課題の解決を助けてくれるよい例だからです。ラスベガスでレースを計画するような規模のイベントは、交通に影響を与え、緊急サービスの経路変更を引き起こす可能性があり、同時に地域経済を活性化させ、ラスベガスの象徴的なランドマークを見せたいとも考えます。考慮すべき要素が山ほどあるのです。エージェントを使えば、こうしたシミュレーションを素早く構築して、レースが都市に与える実際の影響をよりよく理解できます。エージェントシステムは、振る舞いをハードコードしたり純粋に確率に頼ったりするのではなく、実際の振る舞いをシミュレートします。
Richard： 私たちのシステムは 3 つの主要なエージェントを使います。皆さんを案内しながら説明しましょう。まず、走るルートをすべて決定するプランナーがあります。次に、それらのルートをビジネス上および地域社会上の要件に基づいて評価するエバリュエーター（評価者）があります。そして、ルートを受け取り、コードを通じてさまざまなアクターを生成し、その振る舞いをランダム化して都市への正味の影響を見るシミュレーターがあります。
2. 完成形デモのプレビューとプランナーエージェントの構築
2.1 完成形シミュレーションアプリのプレビュー
Emma： まずは、これから作り上げるものをお見せしましょう。マジックステージが立ち上がりました。さて、私たちはシミュレーションアプリの中にいます。これを起動すると、ラスベガスのスカイラインが光り始めるのが見えます。よく見ると、ちょうどこのあたりで私たちがキーノートをやっているのが見えるんですよ。
Richard： 本当だ、私が見える。怯えた顔をしているね。
Emma： ここには、ラスベガスでの夜のマラソンの提案ルートがあります。だって正直なところ、ラスベガスのスカイラインは日が暮れてから本領を発揮しますから。私が「シミュレーション実行」をクリックする間に、これをどう作ったかをお話しできます。私は 5 年間 Angular チームにいたのですが、このアプリの土台と、今日ここでお見せしている 3D アニメーションのレンダリングはすべて、その Angular が動かしています。いま私は Flutter チームにいて、このサイドバーはすべて A2UI と、今日後ほど実演する GenUI のアイデアのいくつかによって動いています。
Emma： さあ、できあがりました。シミュレーションが始まっています。「Follow the Leader（リーダーを追う）」をクリックすると、シミュレーションの動作を見られます。サンプルのランナーの 10% がレースをスタートするのが見えます。プランナーエージェントがこのルートを丁寧に計画してくれました。そして「I'm Feeling Lucky」をクリックすると、給水所や医療テントなど、プランナーエージェントが配置を助けてくれたものが見えるかもしれません。一方で、シミュレーターエージェントはリアルなレース環境を作る手助けをしています。ラスベガスの交通を行き交う車も、シミュレーターエージェントが配置したものです。
Richard： 昨夜のタクシーより速いね。今朝の私の Uber よりずっと速い。
Emma： それは本物じゃありません、シミュレートされたものです。それから、もう一つお見せしたいものがあります。「オーガナイザー」タブに移動すると、今日ステージに上がる前に実行しておいたシミュレーションのいくつかが見えます。「レポートを開く」をクリックすると、これまで話してきた非決定論的な条件にさらされたとき、それらのシミュレーションがどうスコアづけされたかを確認できます。
Richard： さて、皆さんはそろそろ本当の舞台裏を見る準備ができたと思います。これから作り上げるものを見たので、いったん巻き戻して、これをどう構築したのかを、あのプランナーエージェントから順にお見せします。この一連のオンステージのデモを通じて、2026 年にエージェントをどう構築するのか、使ったテクニックのすべて、そしてエージェントを複数の面（サーフェス）へデプロイするのに役立つ製品を明かしていきます。しかも、いまお見せしているものはすべて、いまこの瞬間 GitHub リポジトリに置かれていて、このアプリ全体を皆さん自身が再現できるようになっています。このアプリは無料で差し上げます。すべてオープンソースです。では口火を切るために、私の盟友 Rophy Rahman を呼びましょう。
2.2 プランナーエージェントの構築（Rophy Rahman）
Rophy Rahman： ありがとう、Richard。このデモでは、エージェントのアイデアから概念実証（PoC）へと、私たちのエージェントプラットフォームを使ってどう進むのかをお見せします。プラットフォームの中から、エージェントを構築するためのフレームワークとして ADK を、Google Cloud のリモート MCP（Model Context Protocol）サーバーを、そしてエージェントのランタイムであるエージェントランタイムを使います。私たちのシミュレーションアプリにはいくつかのエージェントがありますが、その中核の一つがプランナーエージェントです。プランナーエージェントには次のものが必要です。まず、マラソンプランナーとしての役割を理解させる指示（インストラクション）。次に、地図を使い、地理空間データを扱い、レースを計画する専門性を与えるスキル。そして、地図化や実行可能なルートの計算を助けるツールです。
Rophy Rahman： 私たちはまず、Agent Designer で基本的なプランナーエージェントを設計することから始めました。Agent Designer ではローコード・ノーコードのエージェントを設計でき、その振る舞いをプレビューすることもできます。これによって、さまざまなエージェントのアイデアを試すのが簡単になります。私たちは Gemini の助けを借りて作ったマラソン計画に関する指示をエージェントに与えました。これを実行して、マラソン計画のサンプルプロンプトに対して何が得られるか見てみましょう。エージェントが計画を返してくるまで数秒かかります。皆さんに見守られながらエージェントを作るのは本当に楽しいですね。マラソンを計画するだけでよくて、走らなくていいのがありがたいです。さあ、結果が出ました。よい出発点です。Gemini の知識を使うだけで、マラソンを計画するためのそれなりの詳細が得られています。
Rophy Rahman： では次に、この計画を実データにグラウンディング（接地）させて、エージェントを地図とレースの専門家にしましょう。これはツールとスキルを追加することで実現します。Agent Designer が指示とともに事前に用意してくれた Python コードをダウンロードできます。これが私たちの出発点となるコードで、ここからコード編集ツールを使って機能を追加し続けます。まず、エージェントに地図データへのアクセスを与える必要があります。Google Maps 用の Google Cloud MCP サーバーを使って地図ツールへのアクセスを与えます。エージェントを Google Maps の MCP サーバーに接続するのは、ここにあるほんの数行のコードです。Google Cloud の MCP サーバーを使えば、エージェントは皆さんが登録した任意のツールにアクセスできます。また、Google が設計・構築したファーストパーティのツールも使え、その場合はセキュリティがデフォルトで組み込まれています。これで、地図に関する質問ができるようになり、エージェントは Google Maps の MCP ツールを使って答えられます。たとえば、ラスベガスのランドマークの一覧を尋ねれば、それを使ってルートを計画できます。
Rophy Rahman： 次にスキルについてお話しします。スキルは 2 つの部分から成ります。YAML のメタデータと、Markdown の本文です。メタデータは最初にコンテキストへ読み込まれます。これには説明（description）が含まれていて、エージェントがいつスキルの残りの部分を読み込むべきかを判断できるようにします。私たちのエージェントには 3 つのスキルがあります。マッピングスキルを見て、それがどうやってエージェントを Google Maps の使い手にするのかを確認しましょう。エージェントはスキルを読み込むことで、それに基づいて Maps のツールを選択的に呼び出せます。同じ構造で、地理情報を扱う GIS スキルもあります。このスキルは、エージェントが実行できる Python スクリプトにもアクセスでき、GeoJSON データを処理して、よい開始地点と終了地点を持つ実行可能なルートを見つけられます。最後に、レースディレクタースキルがあります。ここには、私たちのレース計画委員会が、過去の要件に関する知識に基づいてルートを計画・確認するために使う Google Doc があります。Gemini を使って、それをスキルに変換しました。既存のプロセス文書を、そのままエージェントが使える形にできるのは本当に簡単で気に入っています。できあがったものは、先ほど紹介した他のスキルと同じフォーマットに従っています。
Rophy Rahman： これで、このエージェントは出荷準備が整いました。エージェントランタイムへのデプロイには 4〜5 分かかります。皆さんは私の新しい親友なので、お待たせはしません。先ほどデプロイしておいたバージョンに切り替えましょう。これが、Emma が先ほど見せてくれたシミュレーションの中で動いている様子です。プランニングエージェントにプロンプトを与えると、まもなくエージェントが、私たちが提供したスキルを読み込み、組み込んだツールを実行して実行可能なルートを見つける様子が見えます。スキルは、作業を完遂するためにエージェントが何を利用できるかを段階的に理解させ、時間とトークンを削減します。終わったようです。ルートが描画されているのが見えます。シミュレートされたルートは美しいですね。ランナーはラスベガスのストリップ全体の素晴らしい眺めを楽しめそうです。まとめると、Agent Designer で作ったローコードのエージェントから出発して、初期のエージェントを改良し、いまではマラソン参加者のためにルート計画を作成するのに必要なスキルとツールを備えるに至りました。
Richard： 素晴らしいデモだ、Rophy。ありがとう。お気づきかもしれませんが、Rophy はローカルの MCP サーバーを使いませんでした。Google Cloud はデフォルトで、多くの製品についてこうしたフルマネージドの MCP 機能を提供します。だから皆さんは MCP を使う恩恵を得ながら、セキュリティ要件や、必要となる個々のツールの設計といったことは Google が面倒を見てくれます。この例のように、私と同じく Google Maps の専門家でなくても、Google Maps 用の MCP がエージェントに地図ツールをそのまま提供してくれるのです。今日ご覧いただく各デモについて、より詳しく知りたい方のために、スキャンすればコードラボに進めて、いま紹介した概念をすべて学べる QR コードを用意しています。そして最後に、シミュレーターのコードすべてへのリンクを共有します。
3. マルチエージェントによる評価システムの構築（Ivan Nardini と Casey West）
3.1 リアルタイム評価とA2UIによる動的UI
Richard： Rophy が手伝ってくれて作ったプランナーエージェントがありますが、これはよい出発点にすぎません。プランナーはルートを生成し、レース計画に関するいくつかの特性を見てくれますが、もっと堅牢な評価が欲しいところです。さらに、シミュレーションが実際に動いたとき何が起きるのかも見たい。だからこそ、ユースケース、必要なアクセス権、必要な能力に基づいてエージェントのチームを作り、関心事を分離したいのです。チームが協力して働くのと同じように、責任を分散させるには、特定の役割を持つエージェントの集まりを作る方が理にかなっています。エージェント同士が会話できるようにする 2 つのコンポーネントについてお話ししましょう。一つは A2A、エージェントが自分の能力を宣伝し、互いに通信するための普遍的なプロトコルです。もう一つはエージェントレジストリで、ここにエージェントが登録されます。エージェントはレジストリを検索して、目下のタスクを完遂するために必要かもしれないスキルや能力を持つ他のエージェントを、A2A カードを使って発見できます。エージェントが協力して評価システムをどう構築できるかをお見せするために、Ivan Nardini と Casey West を迎えましょう。
Ivan Nardini： さあ、行きましょう。今日は、壊れやすく予測不能なエージェントのループから、厳密に評価された専門家のネットワークへどう移行するかをお見せします。そのネットワークは文字通り自分自身の UI を構築します。Casey、これまでにルートの候補を作るプランナーエージェントの話をしてきました。いまや私たちはさらに 2 つのエージェントを持っています。特定の基準でルートを判定するエバリュエーター（評価者）サブエージェントと、プランナーと協力して承認されたルートを受け取り、それを実行して結果を見せるシミュレーターエージェントです。
Casey West： さあ、楽しもう。私はいま、ラスベガスで 1 万人のランナーのためのマラソンを計画するプロンプトを実行しました。プランナーは新たに 2 つのことをやっています。マラソン計画でエージェントのドリフト（逸脱）を防ぐためのリアルタイム評価と、即座の評価フィードバックのための動的 UI です。
Ivan Nardini： エージェントが動いている間に、ここでリアルタイムのエバリュエーターサブエージェントをどう作るか説明します。これはソブリンモデルと限定されたコンテキストを使ってルートを判定します。プロセス全体ではなく、ルート計画の採点だけに焦点を当てます。新しい計画を作るたび、あるいは既存の計画を修正するたびに、プランナーエージェントはエバリュエーターを一つのツールとして呼び出します。このシステムでは、評価は地域社会への影響やプロンプトとの整合性といった非決定論的な基準と、決定論的な基準の両方をチェックします。ルートはきっかり 26 マイル 385 ヤードでなければなりません。
Casey West： でも、キロメートルを使う Ivan や世界の 95% の人にとっても、別に簡単になるわけじゃありません。42.195 キロですからね。
Ivan Nardini： とても具体的だね。
Casey West： いや、Ivan、私はマイルの方がいい。42 と聞くと、ずっと遠くまで行く気がするだろう。
Ivan Nardini： 認めるよ。さて、これでプランナーが計画を作り、それをパッケージ化してエバリュエーターに送り、採点してもらいます。でも Casey、私たちはまだ評価結果をユーザーに見せたい。かつてはそれは、たくさんのカスタムコードやダッシュボードを書くことを意味しました。正直なところ、私は UI 開発がずっと得意ではありませんでした。
Casey West： わかるよ、Ivan。本当に大変な作業だ。でもありがたいことに、これに対する素晴らしい解決策がある。A2UI、つまり Agent to User Interface だ。Google が作ったオープンスタンダードだよ。この結果を見てみよう。エージェントが各コンポーネントを動的に構築して私たちと共有し、このルートを地図上に描画した。でも、この UI がどうプロンプトされたのか見てみよう。ここではワンショットの A2UI の例を使っていて、Gemini はそれによって自分のインターフェースをどう生成すればよいかを理解する。A2UI は、私たちのエージェントに、延々と続くテキストの壁を超えて、動的で表現力豊かな UI を作る力を与えてくれる。共通のデザイン言語を使って、エージェントが必要とするまさにそのインターフェースを、自分で設計し構築できるんだ。
3.2 A2Aプロトコルとエージェントレジストリによる連携
Ivan Nardini： わかった、Casey。これで評価結果が手に入りました。でも、まだ実際の計画を走らせる必要があります。ここで主役になるのがシミュレーションエージェントです。これは何千人ものランナーが参加するマラソンのタイムラプスを実行します。でもまだ、シミュレーターとプランナーをつないで協力させる必要があります。これを実現するために、さらに 2 つのコンポーネントを導入しなければなりません。エージェント間のプロトコルである A2A と、エージェントレジストリです。まずは A2A から始めましょう。これは Google が作って Linux Foundation に寄贈したプロトコルで、エージェント同士をつなぐための壊れやすい API コードを排除します。各エージェントは、ここに見えるようなエージェントカードを公開します。これはそのエージェントの能力のマニフェストです。シミュレーターエージェントはこのエージェントカードを提供し、他のエージェントがそれを読めるようにします。
Ivan Nardini： そして、このコードを見たくはないけれど、どのエージェントがいまデプロイされていて、それらがどうつながっているかを把握したいという方のために、エージェントレジストリがあります。これを、皆さんのエージェントのインターネットにおける DNS だと考えてください。すべてのエージェントのアイデンティティを解決し、エージェントネットワーク全体にわたって、それぞれの固有のスキルセットをマッピングする中央のディレクトリです。これらのエージェントをエージェントランタイムにデプロイすると、自動的にエージェントレジストリに登録されます。さあ、プランナーとシミュレーターがついにつながったので、Casey、コードや API 契約をいっさい書かずに、新しいシミュレーションを計画して実行する準備ができました。
Casey West： では実際に動くところを見るために、UI に戻ろう。プランナーエージェントがエバリュエーターとシミュレーターに相談して計画を立てたのがわかる。エージェントたちが協力しているんだ。シミュレーションの準備ができたから、始めよう。「シミュレーション実行」をクリックすると、新しいものが走り出す。ランナーが走り始めたら追いかけることもできる。すごいだろう。
Ivan Nardini： これ、本当にすごいですね。どうやって動いているんですか?
Casey West： さっぱりわからないよ。いや、冗談だ。シミュレーターエージェントが環境パラメータを設定する。そして、ランナーを独立したエージェントセッションとして生成する。交通の問題も監視している。
Ivan Nardini： そして結果をプランナーに報告し返します。そしてランナーについては、Gemini Deep Research を使って実世界のランニング行動を学習し、実装しています。Casey、マラソンランナーの 78% が後半で少しペースを落とすって知っていましたか?
Casey West： 知っているよ、Ivan。私自身その一人だったからね。
Ivan Nardini： 私は 10K を一度走ったきりで、それで十分でした。
Casey West： もちろんそうだろうね。さあ、まとめよう。この時点で手に入れたのは、エージェントを軌道に乗せ続けるリアルタイム評価、エージェント自身がレンダリングする動的 UI、そして A2A とエージェントレジストリを使った自動接続だ。エージェントたちが大変な仕事をこなしてくれている。
Ivan Nardini： もう十分だと思います、Casey。コーヒーとか、次のマラソンの話みたいな楽しい話に戻りましょう。
4. コンテキストとメモリによるエージェント強化（Lucia Subatin と Jack Witherspoon）
4.1 セッション・メモリ管理とRAGの導入
Richard： ATUI と Flutter Gen UI SDK でずいぶん遊んできましたが、エージェント同士が協力して、ユーザー体験を本当にレベルアップさせていく様子を見るのは素晴らしいですね。でも次は、各シミュレーションから得た学びを取り出して、次の実行に向けて最適化する必要があります。
Emma： そう、それが重要な次のステップですね。かつて私たちは、過去の実行のすべての履歴を、次に送るリクエストすべてに詰め込むことでこれをやっていました。でも、いまや私たちは、生のテキストをすべてのリクエストに詰め込むというやり方を超えて進んでいます。
Richard： いまではアーキテクチャ的なアプローチや、データベースツールがあって、もっと効率的で思慮深いやり方でこれができます。利用できるものが増えたのです。コンテキストエンジニアリングとは、エージェントがタスクを完遂するために、自身の一般化された知識に加えて、どんな情報を手元に持っているかを管理することです。ステートレスなエージェントから、ステートフルなエージェントとコンテキストウィンドウへの移行がすべてです。エージェントプラットフォームのセッションによって、エージェントを時間をまたいでステートフルにし、必要に応じてそのコンテキストを変更できるようになります。
Emma： そして、ここでメモリバンクの出番です。メモリバンクは、過去のイベントから得た学びのうち、特定のタスクに関連するものをコンテキストウィンドウに引き込み、さらにエージェントが学んだメモリを将来のセッションのために保存する能力をエージェントに与えます。また、Spark や AlloyDB のようなツールを使えば、差別化されたデータアプローチで、検索拡張生成（RAG）を通じてエージェントに追加のコンテキストを提供できます。コンテキストの管理とは、エージェントにスーパーパワーを与えるために、どんなデータを持ち込むかということに尽きます。エージェントのコンテキストとメモリ、そしてそのスーパーパワーについて話してくれる人たちを呼びましょう。Lucia Subatin と Jack Witherspoon を歓迎してください。
Lucia Subatin： さあ、やりましょう。私たちは、コンテキストとメモリがどうエージェントの振る舞いを改善するかをお見せします。例としてプランナーエージェントを使いましょう。セッションを管理し、メモリを追加し、他のデータソースにアクセスする能力を与えることで、そのコンテキストを改善します。Jack、お願い。
Jack Witherspoon： プランナーエージェントをレベルアップさせるところから始めましょう。私たちはいま Antigravity の中にいます。エージェントにセッションとメモリの管理を設定するのがどれほど簡単か見てください。20 行未満のコードです。簡単でしょう。エージェントプラットフォームのセッションを統合する ADK のクラスを追加しているのが見えます。これによって、エージェントを時間をまたいでステートフルにし、必要に応じてコンテキストを変更できます。メモリについても同じことができて、エージェントをエージェントプラットフォームのメモリバンク、つまりエンタープライズ対応のフルマネージドなメモリサービスに接続します。こうすれば、次にルートを計画するとき、プランナーエージェントは以前作った計画の詳細を覚えています。メモリサービスは、私たちがプランナーエージェントをどう、何のために使うかに基づいて、自動的にメモリを作成します。完了したシミュレーションを分析して、その学びを長期メモリに保存し、将来の計画で使えるようにすることさえできます。さて、エージェントにさらに多くのデータを持ち込みましょう。
Jack Witherspoon： ラスベガス市とネバダ州には、山ほどのローカルルールがあります。Lucia、この追加の非構造化データをプランナーエージェントにどう持ち込めるでしょう?
Lucia Subatin： よくぞ聞いてくれました。データサイエンティストやエンジニアが、自分のワークフローの中で IDE をどう使えるかをお見せしたいと思います。これらのファイルは、さまざまな構造とファイル形式で保存されています。これを使えるようにするには、ドキュメントをチャンク（断片）に分割し、それらをエンベディング（埋め込み）、つまりテキストの数値表現に変換する必要があります。プランナーエージェントは、検索拡張生成、つまり RAG を使って、このテキストとエンベディングを検索できます。ここでは、データエンジニアリングエージェントに、SQL のアーティファクトを管理し、ドキュメント処理をオーケストレーションするデータパイプラインをプロンプトから作るよう指示しました。データエンジニアリングエージェントは、プロンプトからデータモデルとパイプラインを書きます。皆さんのコードと統合し、ソフトウェアエンジニアリングのプラクティスをデータエンジニアリングに持ち込みます。
4.2 Spark・AlloyDBによるデータ処理とプランナーへの統合
Lucia Subatin： そして私はいま、Apache Spark 用の Lightning Engine を使っています。これは Spark を電光石火の速さで実行する最適化されたエンジンです。このプロセスは各ドキュメントを読み込み、Document AI を使ってセマンティックに（意味的に）チャンク分割します。これで、チャンクを素早く処理して、AlloyDB のこのテーブルに保存しました。チャンクを見てみましょう。エンベディングが見えますが、ここで本当に、本当にすごいことに注目したいと思います。私たちはエンベディングを手作業で作る必要がありませんでした。AlloyDB の自動エンベディング機能が、指定したモデルに基づいて自動的に生成してくれるのです。これが実際に動くところも見られます。私はいま、ラスベガスのストリップでレースを行うことに関する制約のセマンティック検索を実行し、ラスベガス市というフィルターを加えました。これはエンベディング空間を検索して、上位の結果を返します。Jack、このルールを知っていましたか? 公道にラクダを連れて行ってはいけないんですよ。
Jack Witherspoon： へえ。ラクダの返品ポリシーがどうなっているか、まさか知らないよね?
Lucia Subatin： 少なくともこれで、私たちのエージェントはラクダの制約を認識するようになります。さて、あとはこの知識をプランナーエージェントに組み込むだけで、エージェントは交通ルールをマラソンルートの設計に取り込めます。私は先回りして、公式の Google Cloud リポジトリからスキルを拡張し、エージェントを AlloyDB とベクトル関数の使い手にしておきました。また、コードベースにコミットされたツールをプランナーエージェントに追加しました。エージェントはこれらを使って、Google Cloud のリモート MCP サーバー経由で AlloyDB を呼び出します。Jack、あなたに戻して、変更をテストしてみましょうか?
Jack Witherspoon： やりましょう。シミュレーションを開きます。これは以前計画したルートです。コンテキストをよりよく管理し、メモリを追加したので、いまそれを再実行しました。どう見えるか見てみましょう。いまやプランナーエージェントは、どんなランドマークを通り、現在のルートが何のそばを通るかといった最新のコンテキストを把握し、アクセスできるようになりました。そしていま、ローカルルールが計画プロセスの一部として取得されています。メッセージ履歴を見ると、プランナーエージェントが、過去のシミュレーションの長期メモリから引き出して、以前の詳細を思い出しているのがわかります。Lucia、ここの違いを見てください。灰色の線が私たちが出発した地点ですが、カラフルな線が新しい経路です。コンテキストを効率的に管理し、エージェントにメモリを加えることで、シミュレーションがいま持っているメモリとデータに基づいて、ルートを調整したのがわかります。
Richard： ありがとう、皆さん。Lucia と Jack に拍手を。ずいぶんラクダの話が多かったね。ラクダの話が多すぎる。
Emma： ラクダエンジニアリングです。
Richard： いやいや、それはなしだ。これはコンテキストエンジニアリングだよ。こうしたシステムが連携して、エージェントをより賢くしていく様子を見るのはわくわくしますね。
5. エージェントのデバッグとオブザーバビリティ（Megan O'Keefe）
5.1 オブザーバビリティとCloud Assistによる根本原因調査
Emma： さて、シミュレーター全体を作り上げたので、複数のシミュレーションを実行できます。全体が動くところを見るのは本当にクールですね。
Richard： そうだね。でも君がずっとこれを操作してきたよね。私も一度くらいやらせてもらえる?
Emma： どうぞ。いまや私たちには、すべてのデータコンポーネントと、これらすべてのピースを備えたシミュレーションエンジンがあります。だから一つ実行すると、過去の履歴やそれらのメモリがすべて揃って、すべてがうまく動くんです。
Richard： うわ、いったい何をやったんだ、それ。これは君のせいだ。
Emma： いえ、それは私です。一つだけの仕事だったのに。
Richard： ずいぶんサイレンが鳴っているね。ところで Richard、こういうことなんだ。
Emma： あなたのせいじゃありません。ご存じのとおり、LLM を導入し始めると、物事は予期しない新しい仕方で壊れます。
Richard： そうなんだ。開発中に実際にぶつかった問題の一つが、これらのツールがすべて実行されるときにコンテキストがどう管理されるか、ということに関係していました。いろいろなことが起きているからね。そこで、エージェント的な振る舞いをデバッグし、アプリをこれまでより速く修正する助けになる 2 つのものについて話しましょう。一つは、オープンスタンダードに基づいてエージェントの運用メトリクスを可視化するエージェントオブザーバビリティ。もう一つは Gemini Cloud Assist、設計から実行、修正、最適化までエージェントの管理を助けるエージェント的なクラウドオペレーターです。私を窮地から救い出してくれる、唯一信頼できる人を呼びましょう。Megan O'Keefe を迎えてください。
Megan O'Keefe： おはようございます。エージェントを大規模にデバッグする話をしましょう。こうした自律システムでは、本番環境の課題は単にインフラをスケールさせることではありません。推論、ツール呼び出し、そしてシステム全体で何かがうまくいかなくなりうるあらゆる箇所を管理することです。そしてこうした環境では、予期しないエラーは実際に起きます。今日は、そうした問題をどう修正するかをお見せします。エージェントオブザーバビリティと Cloud Assist の Investigations エージェントを使って、エージェントランタイム上のシミュレーターエージェントのエラーを掘り下げます。エラーの根本原因を見つけて切り分け、そのうえで先回りした修正を、すべて自然言語でデプロイします。
Megan O'Keefe： さて、私たちのシミュレーターエージェントは、ライブのシミュレーションのために大量のコンテキストを管理する必要があります。これに備えて、私はそのエージェントにコンテキストコンパクション（コンテキストの圧縮）を追加しておきました。これは Agent Development Kit ではイベントコンパクションと呼ばれる機能で、エージェントに対して、Gemini を使って自分のワークフローを定期的に要約させ、各ターンでモデルに送るコンテキストの総量を減らすよう指示します。この最適化はデプロイしておいたのですが、先ほど Richard がシミュレーションを壊すのを皆さんが見ましたね。彼のせいにしたいところですが、Google には犯人捜しをしない（blameless）文化があるので、ここでは調査することにしましょう。Gmail を見ると、アラートが発火しているのがわかります。シミュレーターエージェントが異常に高いレイテンシを経験しています。「インシデントを表示」をクリックして、Cloud Monitoring のコンソールを開きましょう。シミュレーターエージェントの実行に本当に長い時間がかかっています。何の応答も返していませんが、このビューではなぜなのか正確には見えにくいですね。
Megan O'Keefe： 内部で何が起きているのかを突き止めるために、エージェントランタイムのトレースビューを開きましょう。トレースを使うと、エージェントの根底にあるツール呼び出しと推論の流れを見られます。ここを見ると、エージェントが複数のツールを正常に呼び出しているのがわかりますが、その後突然クラッシュしています。これは妙ですね。ああ、これらのログは密度が濃い。以前なら私はパニックになって、必死にあちこちをコピー＆ペーストしていたでしょうが、いまはこれを見てください。エラーログから一つボタンをクリックするだけで、Cloud Assist の調査を開始できます。Gemini Cloud Assist は、ワークロードの設計、デプロイ、トラブルシューティング、最適化を助けてくれる AI アシスタントエージェントです。この調査には数分かかったので、ここにあらかじめ読み込んでおきました。Cloud Assist がエージェントからログを集め、エージェントランタイムのインフラを詳しく調べた様子がわかります。どうやら、シミュレーターエージェントがリクエストエラーのために Gemini のモデル API の呼び出しに失敗しているようです。モデルに送っているペイロードに何か問題があります。
Megan O'Keefe： ここでうまくいけば、Cloud Assist が私たちのエージェントシミュレーターのコードの特定の行を指し示してくれるはずなので、それを開いてさらに掘り下げましょう。さて、ここからがかなりクールなところです。私は IDE、この場合は Gemini 3 を搭載した Antigravity を開いて、先ほどコンソールで始めた Cloud Assist の調査を続けられます。これは、私の IDE が MCP を通じて Cloud Assist につながっているからです。Cloud Assist は、あらゆる AI アプリケーションのために組み込みのリモート MCP サーバーを備えた、数多くの Google Cloud 製品の一つなのです。そこで、エージェントに対して「シミュレーターエージェントに関する Gemini Cloud Assist の調査を再開してほしい。agent.py で何がおかしいのか?」とプロンプトしました。このプロンプトには 1 分ほどかかるので、ここに読み込んでおきました。エージェントが Cloud Assist の発見を使い、エージェントのソースコードを詳しく見ている様子がわかります。関連する Issue を求めて GitHub を検索さえしています。そして、エージェントがそのすべての情報を統合して、私たちのコードで何が起きているのかを明快に説明している様子を見てください。この 400 エラーが見えている理由は、私たちが Gemini API の 100 万コンテキストトークンの上限を超えているからのようです。
5.2 プロアクティブな修正と運用の教訓
Megan O'Keefe： 私たちがエージェントに追加したあのイベントコンパクションが、これらの巨大なツール呼び出しの合間にコンテキストを圧縮するのに、十分な頻度で実行されていなかったのです。さて、ここがデバッグのプロセスでエージェントを使うことについて、私が本当に気に入っているところです。エージェントは問題の根本原因を見つけるだけではありません。問題にパッチを当てるための、先回りしたコード修正を提案してくれるのです。ここでエージェントは、イベントコンパクションの設定にトークンの閾値（threshold）パラメータを追加して、各呼び出しの中でより頻繁にコンテキストを圧縮するよう提案しています。ここから、その変更を承認し、コードの差分（diff）を確認し、この変更をソース管理にコミットし返すことができます。それによって CI/CD がトリガーされ、シミュレーターエージェントがエージェントランタイムへ再デプロイされます。このプロセス全体には 5 分ほどかかるので、ここにあらかじめデプロイしておきました。私はエージェントランタイムのコンソールに戻り、パッチを当てたシミュレーターエージェントで同じクエリを再実行しました。すると、あの 100 万コンテキストトークンの上限を超えているにもかかわらず、イベントコンパクションが正常に動作して、シミュレーターがエラーなく実行されているのがわかります。
Megan O'Keefe： このデバッグの一連の体験が示しているのは、シミュレーターのようなエージェントも、やはりただのソフトウェアだということです。それらを安全に運用するには、透明性のあるメトリクス、適切なデバッグツール、そしてスケールへの注意深い配慮が必要です。しかも、それは単にインフラのスケールだけでなく、トークンのスケールのようなものも含みます。Google Cloud は、エージェントのための完全なオブザーバビリティのスイートを独自に提供しています。Cloud Assist とコーディングエージェントは、こうしたシステムの問題を特定するだけでなく、見つけた問題を先回りして修正してくれます。だから、こうした適切なツールを手にしていれば、エージェントの運用はずっと楽になります。
Richard： お見事、Megan。また私を窮地から救ってくれてありがとう。適切なツールがあれば、こうした分散したマルチエージェントシステムにおける障害の根本原因を突き止めるのが、私たちにとってずっと簡単になりますね。今回の場合、Antigravity と Gemini Cloud Assist が、最初のエージェントのクラッシュから、コードの中のバグまで、あの連鎖的な障害をたどってくれました。よく言われることですが、最高のコードとは動くコードだ、と。
Emma： それは美しいですね。シェイクスピアですか?
Richard： いや、Gemini だよ。
6. アーキテクチャの進化とインフラ変更（Bobby Allen）
6.1 Cloud RunからGKEへの変換とGemmaのデプロイ
Richard： さて、ここで大事なことがあります。最初のアーキテクチャは、たいてい最終形ではありません。私の場合、最初のものが最終形になることはめったにありません。アプリケーションや AI システムを構築するとき、私たちは小さく始めたいと思います。そうすることで、AI がどう動くのか、それが何を助け、何を壊すのかという新しいことを学べるからです。そこから、自分たちのニーズに基づいてアーキテクチャを進化させていきます。アプリがエージェント的に変化していくにつれて、ランタイムやデータベース、あるいはプログラミング言語そのものさえ入れ替えるかもしれません。これを示すには、このシミュレーションに新しい機能、たとえばランナーに自分の考えを見せてもらうような機能を追加するのが一番だと思います。これは現在のアーキテクチャでは動きません。これを実現するには、いくつものコンポーネントを追加する必要があります。Google Cloud のエキスパートエージェントをかたわらに置いて、これをどうやってできるかをお見せするために、私のお気に入りの Googler の一人、Bobby Allen を迎えましょう。
Bobby Allen： ありがとう、Richard。会場に GKE ファンはいますか? もっと盛り上がりすぎないように落ち着かなきゃ、デモができなくなる。さて、このシミュレーションはマラソンですが、このたとえはどんなソフトウェアにも使えます。私たちはこれまでになく速く、わくわくするものを作れるようになりました。とはいえ、世界はグリーンフィールドのソフトウェア、つまり毎回ゼロから新しく作るもので動いているわけではありません。グリーンフィールドはスプリント（短距離走）です。システムを長期間にわたって運用するには、厳密さ、集中、そして反復的な改善が必要で、それはむしろマラソンに似ています。私は「Vibe Clouding（バイブ・クラウディング）」の例をお見せしたいと思います。これは、エージェントの力を使って既存のシステムをアップグレードするやり方です。シミュレーションの一つのコンポーネント、つまりランナーのアップグレードに焦点を当てましょう。これを 2 つのやり方で行います。コントロール（制御）とカスタマイズ（カスタム化）です。
Bobby Allen： より高い制御のために、私たちはアプリを Cloud Run のサービスから Google Kubernetes Engine、つまり GKE のデプロイメントへ変換します。より高いカスタマイズのために、同じクラスタで動かす予定の、Gemma 4 をベースにしたファインチューニング済み、つまりカスタマイズされたモデルを導入します。さて、先ほどのデモでは、Megan が Cloud Assist を使ってコードをデバッグするのをご覧いただきました。今度は、Cloud Assist を使って Infrastructure as Code（コードとしてのインフラ）を変更します。私はいま Antigravity のエディタにいて、ランナーを表す Cloud Run サービスのマニフェストを開いています。ランタイムの変換と Gemma のデプロイを、一つのプロンプトで行います。「この Cloud Run サービスを、同じクラスタにホストされた Gemma 4 モデルとともに、GKE 上の同等のものに変換してほしい」。私の IDE は MCP 経由で Gemini Cloud Assist につながっていて、それによって Google Cloud のリソースと、アプリケーションの設計・運用に関する助言にアクセスできます。言い換えれば、Cloud Assist は私の意図をインフラの変更に翻訳してくれる翻訳者の役割を果たします。Cloud Assist は、フルスタックのインフラデプロイを助けてくれて、GKE で推論を実行するためのベストプラクティス、たとえばサービングのための正しい VLAN 構成や、スケーリングのためのポリシーを特定してくれます。
Bobby Allen： さて、Gemma を含む、変換されたアプリのための GKE のマニフェスト、つまり構成が準備できました。あとは「はい」と言って変更を適用するだけです。デプロイされたワークロードは 30 秒ほどでコンソールに現れ始め、完了するまでには 10 分ほどかかります。時間の都合で少し早送りしたので、完成形を見られます。これを、ぜひ受け止めてください。私は自分の声を使って、AI に AI をデプロイさせて、それを Kubernetes に入れたのです。これに興奮する人はいませんか? いま見えている 2 つのコンポーネントは、GKE に移った変換済みのランナーアプリと、同じクラスタで動いている Gemma の推論サーバーです。これはコンソールの中で、AI ワークロードの詳細を見られる部分で、期待どおり Gemma 4 をデプロイしたという確認も見られます。
6.2 スケール問題への対処とまとめ
Bobby Allen： ここで、念のため申し上げると、ランナーは皆さんが先ほどご覧になったマラソンシミュレーションの一コンポーネントにすぎません。さあ、これを試してみましょう。テストでは 100 人のランナーで問題なく動いたのですが、これを社内で何千人ものランナーに展開したところ、いくつか問題が見え始めました。どうやらランナーが実際には走っていないようです。少なくとも今回は、Richard が壊したのではないとわかっています。いいですか、時にはスケールが物事を壊したり、壊れているように見えるほど遅くしたりするのです。だからこそ、問題を素早く浮かび上がらせてくれる Cloud Assist のような先回りの助っ人がいると助かります。私たちはいま Google Cloud のコンソールにいて、Cloud Assist はすでに私たちに代わって調査を実行し、問題を特定しています。ストレージがモデルを十分速く読み込めていないのです。GCS FUSE はいくつかのユースケースには優れていますが、今回の場合は素早くスケールする必要もあるので、Lustre の方がよい選択肢です。そこで、このアップグレードされたストレージをデプロイするという Cloud Assist の推奨を受け入れ、詳細は Cloud Assist に任せることにします。
Bobby Allen： これには数分かかるので、Lustre がすでにデプロイされている別のインスタンスに移ります。シミュレーションに戻って、いま実行を開始しました。これでレイテンシはもう問題にならないはずです。これがアップグレードされたランナーを備えたアップグレード済みのシミュレーションで、Gemma 4 によるアップグレードの証拠として、ランナーがどう感じ、何を考えているかを見られるようになります。確認してみましょう。なるほど、ストームトルーパーを数えているのか、私も同じことをしているだろうな。ラスベガスは音楽を送ってくる。私の思考の吹き出しはきっと「今日は走っているけど、明日は郵便受けまで這っていくことになる」とでも言うでしょうね。それくらい疲れを感じるでしょうから。さて、ご覧いただいたことを少し振り返りましょう。
Bobby Allen： 一つ目は、私たちの意図が、既存のブラウンフィールドのシステムに対してさえ、素早くアクションに変わるということ。二つ目は、私たちが問題について、具体的な解決策とともに先回りで通知を受けられるということ。三つ目は、絶えず変化する製品や機能ではなく、成果に集中できるということです。ここで肝心なのは、これです。私たちは、エージェントが単に皆さんの質問に答えるのではなく、皆さんが設定したガードレールの内側で、皆さんと一緒にアクションを取ってくれる世界を思い描いています。変化について私と「おしゃべり」するのではなく、変化を安全に実装するために私と「パートナーになる」。これが私たちの自律型クラウド（autonomous cloud）のビジョンです。
Richard： Bobby に拍手を。さすがの彼でも「ファイブ・クラウディング」みたいな造語が定着するようにはできないだろうから、その言い回しは使わないでおこう。
Emma： でも彼は、私がレースを走っているときの心の中の考えを読めるみたいですよ。
Richard： いまのフレーズを聞いて、私の方も心の中でいろいろ思うところがあるよ。さて、私たちが本当に使い捨てのアーキテクチャの段階まで来ているかはわからないけれど、開発者としての私たちの価値は、構築する各バージョンから得た学びを取り出して、それをアプリの次のバージョンに適用することにあります。そして Gemini Cloud Assist は、その具体的な部分の多くを、時には自律的にさえ手伝ってくれるので、私たちはユースケースと、優れたアプリを作ることに集中できるのです。
7. ハイコードとノーコードエージェントの協働（Enas Ved と Jason Davenport）
Richard： すべての作り手のためのユースケースといえば、エージェントプラットフォームが開発者やビルダーを、彼らがどこにいても、どう強化するかについて話しましょう。まず Gemini Enterprise を使えば、Google が提供する事前構築済みのエージェント、たとえばデータインサイトエージェントや、私の個人的なお気に入りの一つである Notebook LM などを使って、自分のデータソースからインサイトを生み出せます。次に、皆さんのユーザーと開発者のチームは、ハイコード・ローコード・ノーコードのインターフェースを使って、リッチなエージェント体験を構築し、エージェント的な振る舞いから価値を引き出せます。そして、それらすべてのエージェントを、エージェントプラットフォームの組み込みのガバナンス制御によって、安全に、大規模に共有できます。
Emma： ご存じのとおり Richard、ここにいるのは皆、開発者です。私たちは皆、ハイコードからノーコードへ、そしてまたハイコードへと行き来しますよね。
Richard： それが君のやっていることなのかい? まあ、それは君の力の一つだね。これがエージェントプラットフォームの力です。あらゆる種類のエージェントを構築し共有する、その力を見せてくれる二人を呼びましょう。Enas Ved と Jason Davenport を迎えてください。
Enas Ved： さあ、始めましょう。これまで私たちは、完全に機能するシミュレーションを作り上げてきました。でも、構築したエージェントを使って、もっと多くのことができます。そこで、開発者にとってなぜノーコードのエージェントが、道具箱の中の本当に強力な道具になりうるのかをお見せします。ハイコードとノーコードのエージェントがどう協力して働くかをご紹介しましょう。まず、Enas と Ved（私たち）が、マラソンプランナーエージェントを Gemini Enterprise で共有します。それから、あらゆる種類のユーザーが、仕事を楽にするために自分自身のノーコードエージェントを作れることをお見せします。たとえば私が職場の会議から抜け出すためとか、あるいは水やバナナ、仮設トイレをすべて発注するといったロジスティクスの仕事のような、まじめなことのためにもです。
Enas Ved： さて Jason、Gemini Enterprise に対応したエージェントをすべて呼び出してみましょう。私たちがエージェントランタイムで作ったエージェントはすべて、自動的にエージェントレジストリに登録されます。それらは他のエージェントやアプリから発見可能で、ここ Gemini Enterprise にも含まれています。
Jason Davenport： クールですね。では、実際にどこにあるのか見てみましょう。私たちはいま Gemini Enterprise のアプリの中にいて、プランナーエージェントが使えるようになっているのがわかります。試してみましょう。ここに、ラスベガスで 1 万人のランナーのためのマラソンを計画するテストセッションがあります。Gemini Enterprise で私たちのエージェントを使うときも、A2UI による動的なインターフェースが返ってきます。私たちのハイコードのエージェントの機能は、カスタムアプリでも、ここ Gemini Enterprise のような標準化された面（サーフェス）でも、どちらでも動くのです。
Enas Ved： さて、レースのためにいろいろ発注しているとしましょう。水や食べ物、それに人々を楽しませるための音楽などです。そして私たちはたいてい、すべての手順を追跡するためにとても長い Google Doc を使います。本当に長いんです。マラソンの計画も、チームスポーツです。私たちの委員会は通常、さまざまな手順のすべてについて、多くの人を巻き込む必要があります。そして、それは感謝されることの少ない大変な仕事です。そこで、その計画と発注を扱うエージェントを作りましょう。このドキュメントをエージェントにコンテキストとして与えます。Gemini Enterprise の Agent Designer を開いてください。
Jason Davenport： はい、Gemini Enterprise の Agent Designer に来ました。私たちは Gemini Enterprise に対して、ここにあるこのプロンプトを使って、レースの計画と発注の専門家であるエージェントを作るよう指示しました。Gemini がチームを作るのに 1 分ほどかかるので、あらかじめ作っておいたものを用意しました。Gemini が作成したデザインがこの右側にあります。そして、先ほどお話ししたとおり、Gemini Enterprise で作ったエージェントは自動的にエージェントレジストリに登録し返されるので、必要なら他の場所でも使えます。
Enas Ved： そして、あのたった一つのプロンプトで、Gemini Enterprise はエージェントのチーム全体を作ってくれました。すべての計画と発注を調整するメインのエージェントと、それぞれの特定の領域の専門家であるサブエージェントのチームがあります。では、メインのエージェントをクリックしてみましょう。Gemini がエージェントのために詳細な指示のセットを作ったことに注目してください。さらにカスタマイズすることもできます。Jason、供給品の発注に関する私たちのドキュメントを、エージェントにコンテキストとしてアクセスさせましょう。
Jason Davenport： そのためには、Google Drive のリンクを与えるだけでいいんです。ユーザーは、このドキュメントをコード化する方法を知る必要がありません。ここでは単に、ドキュメントをエージェントにコンテキストとして与えるだけで、エージェントは常に最新の情報にアクセスできます。では更新しましょう。さあ、いよいよ正念場です。マラソンプランナーエージェントとの会話に戻りましょう。ここでできるのは、議論の焦点を変えること、この場合はサプライチェーンエージェントに切り替えて、レースに必要なロジスティクスを含む包括的な計画を作るよう頼むことです。
Enas Ved： そしてクールなのは、いまやエージェント同士が協力して、私たちの計画を実際に作ってくれることです。水と食べ物があり、物を配置すべき距離（マイル数）のようなものがあり、エンターテインメントがあり、そして何より重要なのは、仮設トイレがあることです。
Jason Davenport： とても重要ですね。あの仮設トイレすべて。
Enas Ved： これが、私の言う、コードとノーコードのエージェントが協力して、私たちのためにレースの計画を楽にしてくれるということです。
Richard： 素晴らしい仕事だ、Jason。私と Emma に戻してくれてありがとう。すごかったですね。このキーノートにはラクダも仮設トイレも出てくる。いったい誰がこの台本を書いたんだ。でも、ここで重要なのは、あらゆる規模のチーム、あらゆるスキルレベルの人々が、Gemini Enterprise を通じて実際にエージェントを使えるということです。
8. セキュリティとガバナンス
8.1 シフトダウンとエージェントガバナンス（Ankur Kotwal）
Richard： さて、では次にセキュリティとガバナンスについて話しましょう。話はますますよくなっていきます。
Emma： そうですね。エージェントは、ユーザーや他のエージェントに対して、意図的にであれ意図せずであれ、私たちが望まないような仕方でデータや振る舞いを露出させる新しい手段を与えてしまいます。たとえば、ユーザーは財務データを変更できるべきではありません。Richard、私たちはレースに参加する全員のためにすでに応援タオルを用意しましたが、これは夜のレースなので、もっと何かしたいんです。だから、予算を増やして、グロースティックや、あの本当にクールな夜光の LED サングラスを手に入れられないか試してみましょう。
Richard： いいね。でも、それはどうかな。私だって Thomas Kurian の甘い甘い運用費（OpEx）を使うのは大好きだけど、それはやっていいことじゃない気が……。ほら、やっぱりだ、これは動くべきじゃない。
Emma： でも、できてしまいましたよ。
Richard： よくないね。私たちのプランナーエージェントは予算を変更できるべきではありません。これは明らかに、私たち開発者による何らかのセキュリティ上のバグです。私たちはいつも開発における「シフトレフト」について話しますが、それは難しいことですし、セキュリティは開発者にとって決して楽しいものではありません。正直に言って、シフトレフトはしばしば「開発者がもっと多くのことをやるべきだ」ということの言い換えになっています。開発者がスタックのすべての層に責任を持つというのは、持続可能ではありません。私たちは代わりに「シフトダウン」すべきです。それは、より賢いプラットフォームを意味します。私たちは、エージェントから人間へ、そしてエージェントからエージェントへの条件付きアクセスを与える、よりよい方法を提供する必要があります。
Emma： そうですね。エージェントアイデンティティは、エージェントが必要なものにだけ、本当に必要なときにだけアクセスでき、それ以上は何もアクセスできないようにするための、明確に定義されたポリシーをエージェントに与えます。
Richard： そしてエージェントゲートウェイは、これらすべてのポリシーを一元的に管理する場所をチームに与えます。プラットフォームエンジニアリングはチームスポーツです。私たちは協力しなければなりません。この MCP とエージェントの時代に、エンジニアリングチームがより安全なアプリケーションの構築とガバナンスを助けられるよう、どう力づけるかをお見せするために、私の友人 Ankur Kotwal を迎えましょう。
Ankur Kotwal： 皆さん、こんにちは。開発者として、マルチエージェントシステムでセキュリティをシフトダウンするのは、目隠しをして真夜中のラスベガスのストリップを進もうとするような感覚でした。どの脆弱性が致命的なのか、あるいは攻撃者がどうやってプランナーエージェントを操作して、1 万人のマラソンランナーをまっすぐラスベガスのカジノに通すよう仕向けるのか、いつもわかるとは限りません。私は、わかりやすいポリシーでエージェントをガバナンスする方法をお見せします。また、コードの中で悪用可能なリスクを特定する方法と、それを修正する方法もご覧いただきます。私たちのエージェントはエージェントプラットフォームにデプロイされています。エージェントゲートウェイは、エージェント間のプロキシです。私たちのシミュレーションには、すでにゲートウェイが配置されています。エージェントゲートウェイは、アイデンティティとアクセス管理のポリシー、つまり IAM ポリシーを強制して、エージェントが承認されたソースからのみアクセスされるようにします。
Ankur Kotwal： これがエージェントレジストリです。私たちのプランナーエージェントとシミュレーターエージェントは、すでにここにリストされています。各エージェントのインスタンスはアイデンティティを持っていて、これはエージェントがデプロイされるときに自動的に生成されます。広い目的のサービスアカウントとは異なり、エージェントアイデンティティは、個々のエージェントごとに固有で不変の（immutable）認証情報を提供します。サービスアカウントは、マラソンイベントのスタッフ全員で共有される、一本の全アクセス可能なホテルの鍵のようなものだと考えてください。なんとひどい考えでしょう。それに対してエージェントアイデンティティは、すべてのドアに生体認証スキャナーがあるようなもので、完全に監査可能です。ここに、私たちのポリシーが見えます。これらのエグレス（送信）エージェントポリシーは、エージェントからツール、モデル、他のエージェントといったリソースへの、外向きのトラフィックをガバナンスします。エグレスポリシーは、私たちのエージェントのためのガードレールです。私たちのゲートウェイは、プランナーがオープンなインターネットにアクセスするのをブロックする厳格なポリシーで、すでに構成されています。エージェントに 1 万件のライブのランナープロファイルと、私たちの本番の API キーを与えているとき、プランナーの中で起きたことはプランナーの中にとどまらなければなりません。
Ankur Kotwal： でも、私たちにはまだ問題があります。Emma が、自分が予算を変更できてしまう様子を見せてくれましたね。エージェントの気前のよさはありがたいのですが、予算を高級スイートのように扱われては困ります。そこで、私たちのプランナーエージェントにポリシーを追加します。「作成」を押して、このリストからプランナーエージェントを選びます。プランナーエージェントは、財務データベースの読み書きのためのツールを持つ MCP サーバーを呼び出します。そこで、このリストから財務（Finance）の MCP サーバーを選びましょう。そして、条件を追加します。これに「read-only finance（読み取り専用財務）」という名前をつけて、ここで read-only の値を true に設定します。「保存」を押して「作成」を押します。これが伝播するのに 5 分ほどかかるので、先ほどデプロイしておいたバージョンに切り替えます。では、Emma が入力したのと同じプロンプトを試してみましょう。プランナーエージェントはエージェントゲートウェイを通じて通信していて、私たちの新しいポリシーのおかげで、財務 MCP サーバー上の書き込み可能なツールをもう呼び出せません。これで完了です。すみません、Emma。グロースティックとサングラスを承認したいのは山々ですが、私たちのゼロトラストアーキテクチャには、衝動的な出費に対するゼロ予算ポリシーが付いてくるのです。ほんの数ステップで、エージェントプラットフォームはエージェントアイデンティティとポリシーを使って、私たちのエージェントのためのロールベースアクセス制御（RBAC）を実装することを可能にしました。
8.2 コードセキュリティ（Yinon Costica / Wiz）
Ankur Kotwal： では、話題を変えましょう。こうしたエージェント的な開発ツールのおかげで、私はたくさんのコードを書いています。でも、自分のコードが安全だと、どうやって確信できるでしょうか? すべてを自分の開発ツールの中から、私たちのコードを安全に保つのをどう助けるかをお見せするために、Wiz の創業者でプロダクト担当バイスプレジデントの Yinon Costica を迎えましょう。
Yinon Costica： ありがとう、Ankur。そして、ここ Next の素晴らしい開発者コミュニティの皆さんに発表する機会をいただき、ありがとうございます。Wiz は、組織が構築・運用するすべてのものを保護する、統合されたクラウドセキュリティプラットフォームです。Wiz は皆さんのコードとインフラをスキャンして、セキュリティグラフ、つまり皆さんのクラウドと AI アプリケーションの生きた地図を構築します。私たちはルールベースの手法だけでなく、最新の AI モデルも使って、環境に対するリスクと脆弱性を理解します。グラフの上で、Wiz はコンテキストと、セキュリティの作業を加速させるセキュリティエージェントの層を使います。昨日のオープニングキーノートでは、レッドエージェントをご紹介しました。レッドエージェントは、外側から問題を悪用する、私たちの友好的なペンテスター（侵入テスター）です。次にご紹介したのが Wiz のグリーンエージェントで、これは根本原因の修正を提案し、開発ワークフローを、私たちのコーディングエージェントに直接でさえ開始する修正役です。そして、ご覧ください、私たちのマラソンプランナーエージェントと、それが動いているモデル、そしてアクセスできるツールが見えます。
Ankur Kotwal： そうです、まさに。これが完全なアーキテクチャです。だから、皆さんがアプリを構築している間に、セキュリティ担当者は、皆さんがわざわざ説明しなくても、何を構築したのかを簡単に見て、理解できます。
Yinon Costica： ここに見えるのはエージェントだけでなく、インターネットから、このインターネットへの露出を通じて、その背後にある機密データまでの完全な攻撃経路（アタックパス）も見えます。さて、レッドエージェントはこの攻撃経路を見て、そのリスクが実際に外側から悪用可能であることを検証します。認証バイパスの脆弱性を見つけたのがわかりますし、さらにこの認証バイパスを見つけるためにエージェントが取ったすべてのステップも見られます。一般に、この AI の攻撃者であるレッドエージェントは、皆さんの環境を探る最高の AI 攻撃者であり、コード解析をはるかに超えて、デプロイされたアプリと API への実際のリスクに焦点を当てます。そして、私たちのクラウド・トゥ・コード推論によって、それを修正するためのソースリポジトリを実際に特定できます。さて、開発者として私は、セキュリティポータルに行くことなく、自分が働く場所、つまり自分の開発ツールの中でセキュリティが私を出迎えてくれることを望みます。Google Cloud と Wiz があれば、セキュリティの作業を助けるために、どんな AI ツールでも使えます。
Ankur Kotwal： その通り。ここでは、Opus を使ったクラウド・トゥ・コードがあります。
Yinon Costica： Wiz で私たちは、皆さんがアプリケーションの中の実際のリスクを修正し、防止する限り、ツールとモデルの選択を可能にしたいと考えています。さて、私たちはたったいま、Wiz がすぐに修正すべきだと言う、プランナーエージェントへの致命的なリスクを見ました。Wiz の remediate（修復）を使えます。ここで、私が先ほど実行しておいた Wiz の remediate を見ると、このリポジトリからデプロイされたすべてのリスクを引き出しています。Wiz が、トキシックコンビネーション（毒性のある組み合わせ）、つまり致命的なリスクを見つけたのがわかります。この攻撃経路を実際に生み出した、7 つの別々のセキュリティリスクが見えます。グリーンエージェントはこの攻撃経路を見て、攻撃の連鎖を断ち切るための 3 つの優先的な修正を提案します。一つ目は IAM の権限をダウングレードすること、二つ目は認証バイパスの脆弱性にパッチを当てること、三つ目は AI のガードレールを強制することです。さて、人間がループの中にいる（human in the loop）者として、私はこの制御と現実的な順序付けが気に入っています。では、これらの変更を適用してみましょう。
Yinon Costica： これには数分かかるので、先ほど実行しておいたものに切り替えます。Cloud Code がすでにすべての修正を適用したようです。変更点が見えますし、ここに要約も見えます。Cloud Code は、過剰なアクセスを取り除くための Terraform を実際に見つけ、認証バイパスの脆弱性にパッチを当てるためのアプリケーションコードを見つけ、そして AI のガードレールを強制しました。こうして、コードの発見事項が、ランタイムの露出と実際の攻撃経路のコンテキストに基づいた、実行可能なコードの修正へと変わったのです。そして、再スキャンとともにコードをコミットできます。スキャンが通ったのがわかり、これで準備完了です。これこそが、これまでになく速く、そして安全に構築するということの意味です。
Richard： 素晴らしかった、ありがとう Yinon。このデモでは、エージェントプラットフォームが、プロキシとしてのエージェントゲートウェイ、ロールベースアクセス制御のアイデンティティとポリシーによって、エージェントのきめ細かなガバナンスをどう可能にするかをご覧いただきました。また、Wiz が皆さんのコードを先回りしてスキャンしてリスクを見つけ、それが実際に悪用可能かどうかを特定し、それをすべて皆さん自身の開発ツールの中から、どう修正すればよいか導いてくれる様子もご覧いただきました。これこそが真の安全な開発です。私たちはもはや、開発の速度とセキュリティのどちらかを選ぶ必要はないのです。
9. クロージング
Richard： さあ、魔法をかけよう。Richard と Emma、私たちをフィニッシュラインまで連れて行ってくれ。Ankur と、特別ゲストの Yinon にもう一度拍手を。素晴らしかったですね。Gemini Enterprise Agent Platform が、開発者に本番環境で使えるエージェントを構築する力を与える様子を見るのは、わくわくします。
Emma： Richard、ご存じのとおり私はオープンソースの世界で働いているので、これをお伝えできることに本当にわくわくしています。今日皆さんに共有したコードを、一行残らずオープンソースにしました。
Richard： すごいだろう?
Emma： 100% です。この会場にいるすべての開発者が、私たちが作ったアプリをいますぐ試せます。でも、このプロジェクトのために私たちが用意した開発者向けのソリューションをぜひチェックしてください。これは、アーキテクチャや、Google Cloud を使ってこれらのさまざまなピースをどう構築したのかを案内してくれますし、私たちが作ったすべてのラボへのリンクとクラウドクレジットも提供するので、皆さん自身で試せます。そのリポジトリをクローンして、ショーのすぐあとに試してみてください。
Richard： もし他に何も覚えていないとしても、これだけは覚えておいてください。私たちのエージェントプラットフォームは、こうしたエージェントを構築し実行するプロセスを、どのクラウドよりも最良のものにします。Agent Cloud によるランタイムから、データクラウドによってエージェントにメモリとコンテキストを与えること、ADK によるコードとフレームワーク、そしてエージェントプラットフォームに組み込まれた、トレーシングと eval のための AI サービスまで。エージェントを私たちと一緒に構築するのは、本当にわくわくする、素晴らしい時代です。
Emma： そのとおりです。それでは、ラスベガスの会場にいる皆さん、そしてライブ配信をご覧の皆さん、ご参加いただき本当にありがとうございました。さあ、作りに行きましょう。