速報！｜Google Cloud Next’26｜Day2｜Developers Keynote

みなさん、こんにちは！ ラリオスです。

Google Cloud Next の Day2 で行われた Developers Keynote（開発者向け基調講演）の内容を、速報としてお届けします。

今年の Developers Keynote は「AI エージェント プラットフォームと、その本番運用に向けた開発者体験の刷新」が大きなテーマでした。非常に面白かったのは、今回のデモがすべて「ラスベガスで 1 万人規模のマラソン大会を企画し、シミュレーションするシステムを構築する」という一貫したシナリオに沿って進められた点です。

この記事では、プランナーやシミュレーターといったエージェントが実際にどのように構築・連携され、デバッグやセキュリティ管理が行われていくのか、Day2 で発表された開発者向けアップデートの詳細を順を追ってまとめていきます。

なお、Day2 なので、Day1 で発表された新サービスも含まれています。先に Day1 速報を読んでおくと、より理解が深まります。

AI エージェントの構築｜Agent Development Kit と MCP

まずはじめに、ブラッド・カルダーさんが、本番環境ですぐに使用できるエージェントを構築・実行するための「Gemini Enterprise Agent Platform」を紹介しました。

これまではゼロからコードを書く必要があったエージェント開発ですが、Agent Development Kit（ADK）と Agent Designer を使うことで、ローコードで簡単に構築できるようになりそうです。

「2026 年の働き方」を支えるエージェント・シミュレーション

ブラッド・カルダーさんの熱いオープニングの後、ステージにはリチャード・シュローダーさんとエマ・トゥワースキーさんが登場しました。

リチャードさんは、「ソフトウェア開発者の役割は大きく変化しており、私たちは 2026 年に向けて新しい働き方を考えなければならない」と語り始めます。

かつては数週間、数ヶ月かかっていたアプリケーションが、今や数日で開発される時代。そのスピード感を象徴するデモとして選ばれたのが、「ラスベガスでの夜間マラソン大会の開催」です。

なぜマラソンなのか？ エマさんはその理由をこう説明します。 「マラソンは、エージェントがいかに計画・シミュレーションを行い、大規模な課題を解決できるかを示す絶好の例です。交通への影響、緊急車両の経路変更、地域経済の活性化、ランドマークの活用など、考慮すべき要素が山ほどあるからです」。

これを実現するために、彼らは役割の異なる 3 つのエージェントによるチームを編成しました。

1. プランナー（計画エージェント）
   あらゆるルートを決定し、給水所や医療テントなどの設置を計画する。
   

2. エバリュエーター（評価エージェント）
   企業や地域のニーズ、さらには「正確に 42.195 キロであるか」といった基準に基づき、ルートを評価する。
   

3. シミュレーター（シミュレーション エージェント）
   実際にランナーや車のアクターを走らせ、都市への最終的な影響を確認する。

そして、ここから、このシミュレーション システムを完成させ、本番運用に乗せるまでを 7 つのステップで繋ぐ「リレー形式」 で、最新技術のデモが次々と披露されます。

• Step 1｜構築（プランナーを作る）

• Step 2｜連携（3つのエージェントを繋ぐ）

• Step 3｜記憶（過去の知見を学ばせる）

• Step 4｜デバッグ（エラーを自動で直す）

• Step 5｜インフラ（実行基盤を強化する）

• Step 6｜拡張（ノーコードでチームを増やす）

• Step 7｜セキュリティ（全体を安全に守る）

ここからは、この「マラソン・シミュレーション」がどのように形作られていくのか、技術的な詳細を見ていきましょう。

【Step 1｜構築】Agent Development Kit と MCP でエージェントを作る

まず、中核となる「プランナーエージェント」の構築を担当したのがモフィ・ラーマンさんです。

彼は、Agent Development Kit（ADK）と Agent Designer を使い、アイデアを PoC（概念実証）へと進める流れを実演しました。

特に興味深かったのは、エージェントを「地図とレースのエキスパート」にするための拡張方法です。

モフィさんは、Google Cloud が提供するフルマネージドな MCP（Model Context Protocol）サーバー を活用し、わずか数行のコードでエージェントを Google マップに接続しました。

これにより、エージェントは自らラスベガスの観光名所を検索し、それらを取り込んだ最適なルート案を作成できるようになります。

さらに、エージェントに特定の「スキル」を学習させる仕組みも紹介されました。

• GIS スキル
  GeoJSON データに基づき、適切な開始・終了地点を持つ実行可能なルートを算出する。

• レースディレクター・スキル
  過去のレース要件が書かれた Google ドキュメントを、Gemini を使ってエージェントが理解できる形式（Markdown と YAML）に変換して取り込む。

このように、既存のドキュメントや外部ツールをセキュアに「スキル」として統合することで、やり取りのターン数やトークン消費を抑えつつ、精度の高いアウトプットが得られるようになっています。

【Step 2｜連携】マルチエージェント連携と動的 UI

プランナーエージェントがルートを作ったら、次はそれが本当に実現可能かを評価し、テストする必要があります。

ここで登壇したイヴォンヌ・ナルディーニさんとケイシー・ウェストさんは、システムに「評価エージェント（エバリュエーター）」と「シミュレーター エージェント」を追加しました。

評価エージェントは、ルートの長さ（正確に 42.195 キロメートルあるかなど）や地域社会への影響といった基準をチェックします。ここで注目したいのが、A2UI（Agent to User Interface） というオープン スタンダードの導入です。

これにより、エージェントは単なるテキストを返すのではなく、生成 UI を使って評価結果やルートマップといった動的なインターフェースを自ら構築し、ユーザーに提示できるようになります。

そして、これら 3 つのエージェント（プランナー、評価、シミュレーター）をシームレスに繋ぐのが、A2A（Agent to Agent）プロトコル と Agent Registry です。

A2A は Google が Linux Foundation に寄贈したプロトコルで、各エージェントが自身の能力を「エージェント カード」として公開するためのものです。これによって、エージェント同士が会話できるようになります。

一方の Agent Registry は、ランタイムにデプロイされた各エージェントの ID とスキルセットが自動でマッピングされる、いわば「エージェント版の DNS」のような役割を果たします。（他のエージェントが連携先を見つけるための中央ディレクトリとして機能する）

今回のデモでは、シミュレーター エージェントがこのエージェント カードを提供し、他のエージェント（プランナーなど）がレジストリを通じてそれを読み取ることで、エージェント同士を接続していました。

これにより、開発者が従来のように API の仕様を細かく定義して、手作業でエージェント同士をつなぎ合わせるようなコードを書くことなく、プランナーとシミュレーターが直接相談し合い、新しいシミュレーションを計画・実行する連携を実現しています。

コードの記述量や、システム同士がガチガチに依存し合う状態（密結合）を避けつつ、柔軟なマルチエージェント システムを作れる非常によいアプローチだと感じました。

【Step 3｜記憶】過去の知見と外部データをエージェントに組み込む

エージェントがより賢く振る舞うためには、過去のやり取りを覚える「記憶」と、外部の知識を引き出す「コンテキスト管理」が欠かせません。

ジャック・ウェザースプーンさんとルシアさんのデモでは、プランナー エージェントをステートフル（状態を保持した状態）に進化させる手法が紹介されました。

これまでは毎回のプロンプトにすべてのコンテキストを詰め込む力技が主流でしたが、Agent Platform のセッション管理と、フルマネージドな「メモリバンク」を利用することでアプローチが変わります。

デモでは 20 行未満のコードを追加するだけで、プランナー エージェントが過去のシミュレーションで得た知見を「長期記憶」として保存し、次回のルート計画に呼び出せるようになっていました。

さらに興味深かったのが、AlloyDB を使った RAG（検索拡張生成）による非構造化データの取り込みです。

マラソン開催にあたり、ラスベガス市のローカルルール（公道にラクダを連れて行ってはいけない、など）を読み込ませる必要がありました。

ここでルシアさんは、AlloyDB の自動エンベディング（埋め込み）機能を活用し、データエンジニアリング エージェントを使ってドキュメントをベクトル化する仕組みを構築しました。

プランナー エージェントはベクトル検索の「スキル」を使って AlloyDB にアクセスし、この地域規則を考慮した上で新しいルートを引くようになります。記憶と外部データをシームレスに連携させる、非常によい実践例だと思います。

【Step 4｜デバッグ】Agent Observability と Cloud Assist による自動修復

システムが複雑になり、シミュレーター エージェントが大量のランナーや車のコンテキストを処理し始めると、予期せぬエラーが発生します。

実際のデモでも、シミュレーションが突然クラッシュし、大量のサイレンが鳴り響くトラブル（という演出）がありました。

ここで登壇したメーガン・オキーフさんは、マルチ エージェント システム特有のデバッグ手法を披露しました。

まず活用したのが、オープンスタンダードに基づく Agent Observability（エージェントの可観測性）です。

トレースビューを開くことで、エージェントがどのツールをどのような順序で呼び出し、どこで推論が破綻したのかを視覚的に追うことができます。

そしてさらに強力なのが、AI クラウドオペレーターである Gemini Cloud Assist との連携です。

エラーログからボタンを 1 つクリックするだけで、Cloud Assist が調査を開始します。IDE（Antigravity エディタ）内で MCP を介して Cloud Assist と対話すると、「シミュレーター エージェントが抱えるコンテキストが、Gemini API の 100 万トークン制限を超過したこと」が根本原因であると特定してくれました。

驚くべきことに、Cloud Assist は原因を見つけるだけでなく、「コンテキストを定期的に圧縮するための、しきい値パラメータを追加する」というプロアクティブなコード修正案まで提案してくれました。

開発者はその修正を確認してソースコードにコミットするだけです。エージェントがエージェントのバグを見つけ、自律的に修正を提案する時代になってきていると言えそうです。

【Step 5｜インフラ】Cloud Assist で実行基盤をアップグレードする

シミュレーションのデバッグが完了したところで、今度はシミュレーション内を走る「ランナー」の実行基盤を強化するお話です。

登壇したボビー・アレンさんは、既存のシステムをアップグレードするアプローチを実演しました。

もともと Cloud Run 上で動いていたランナーのアプリケーションを、より高度な制御を行うために GKE（Google Kubernetes Engine）へと移行し、さらにカスタマイズされた Gemma モデルを同じクラスター内に導入するというタスクです。

ここでも、インフラのコード化（IaC）において Gemini Cloud Assist が活躍します。

IDE 上で「この Cloud Run サービスを、同じクラスター内の Gemma を使用する GKE サービスに変換して」と自然言語で指示するだけで、Cloud Assist が意図を汲み取り、ベストプラクティスに沿った GKE マニフェストを自動生成してくれました。

さらにデモの後半では、ランナーを数千人規模に一気に増やしたことでストレージの遅延問題が発生しましたが、これに対しても Cloud Assist が自律的に調査を行い「迅速なスケーリングには Lustre が適している」とプロアクティブに提案し、インフラのアップグレードを支援する様子が示されました。

Gemma モデルを組み込んだ結果、シミュレーション上のランナーが「今日は走って、明日は郵便ポストまで這って行く」といった本音を吹き出しでつぶやくようになり、会場の笑いを誘っていました。

ゼロから作るだけでなく、既存のシステムに対しても AI と伴走しながら安全にインフラを変更していく「自律型クラウド」の方向性がよくわかるセッションでした。

【Step 6｜拡張】ノーコードとハイコードのエージェントを連携させる

シミュレーションの基盤が整ったところで、次はエージェントのチームをさらに拡張します。

アズ・エンヴィッドさんとジェイソン・ダベンポートさんは、Gemini Enterprise を使い、非エンジニアでも作れる「ノーコード エージェント」と、これまで構築してきた「ハイコード エージェント」を連携させるデモを行いました。

マラソン大会には、水や食料、エンターテイメント、そして大量の「仮設トイレ」の発注といったロジスティクスが不可欠です。

ジェイソンさんは Gemini Enterprise の Agent Designer を開き、「レースの計画と発注に精通したエージェントを作成して」と自然言語でプロンプトを入力するだけで、業務に特化したエージェントのチームを瞬時に作成しました。

さらに、備品の要件が書かれた Google ドライブのリンクを渡すだけで、エージェントに最新のコンテキストを共有していました。

ここで素晴らしいのが、Agent Registry の力です。Gemini Enterprise で作成したノーコード エージェントも自動的にレジストリに登録されるため、Step 1 で開発した「プランナー エージェント」から発見できるようになります。

実際にプランナー エージェントの画面（動的 UI）からロジスティクスに関する指示を出すと、新しく作ったサプライチェーン エージェントと自律的に連携し、給水所や仮設トイレの配置を含めた包括的な計画を見事に立ててくれました。

エンジニアだけでなく、あらゆるスキルレベルの人がエージェントを作り、システム全体をシームレスに拡張していける非常によい仕組みだと感じます。

【Step 7｜セキュリティ】エージェントの権限管理と脆弱性の自動修正

エージェントが自律的に動くようになると、意図しないデータへのアクセスや操作を防ぐためのガードレールが必要になります。

実際のデモでも、エマさんがプランナー エージェントを使って、マラソン用の光るスティックやサングラスの予算を勝手に増やそうとする一幕がありました。

ここで登壇したアンクル・コトワルさんは、開発者にセキュリティの負担をすべて押し付けるのではなく、プラットフォーム側で安全を担保するアプローチを紹介しました。

中核となるのは「Agent Gateway」と「Agent Identity」です。

誰でも使えるホテルの鍵のような汎用的なサービス アカウントを使うのではなく、エージェントごとに固有の ID を割り当てます。

デモでは、プランナー エージェントが財務データベース（MCP サーバー）を呼び出す際に、ゲートウェイ上で「読み取り専用」のポリシーを適用し、予算の書き換えを見事にブロックしていました。

エージェントに対するロールベースのアクセス制御（RBAC）が簡単に実装できるのは非常に安心感があります。

さらに、Wiz 社のイノン・コスティカさんが登壇し、コードの脆弱性を自動で発見・修正する強力なエコシステムを披露しました。

Wiz の「レッド エージェント（攻撃者目線でテストする AI）」が外部から認証バイパスなどの脆弱性を発見すると、今度は「グリーン エージェント（修正担当 AI）」が根本原因を分析します。

開発者は普段使っている Cloud Code の画面から離れることなく、過剰な権限を削除する Terraform コードや、脆弱性をふさぐためのアプリケーションのパッチを受け取り、そのまま適用することができます。

開発スピードとセキュリティのどちらかを犠牲にすることなく、安全なシステムを構築できる、まさに 2026 年に向けた開発者体験の完成形を見せてくれたセッションでした。

まとめ｜本番運用を見据えたエージェント開発の幕開け

今回の Developers Keynote 全体を通して見えてきたのは、AI エージェントが単なる「面白い実験」の段階を終え、いよいよ「本番環境で安全かつスケーラブルに運用する」フェーズに入ったということです。（Day1 の基調講演でも強調されています！）

Agent Development Kit（ADK）による構築から始まり、A2A プロトコルによる自律的な連携、過去の文脈を引き継ぐメモリ管理、そして可観測性（オブザーバビリティ）やセキュリティの組み込みに至るまで、開発者がエージェントを本番運用するためのエコシステムが一気に整ってきたと言えそうです。

そして何より嬉しいことに、今回のデモで使われた「マラソン・シミュレーション」のシステムは、コードの隅々までオープンソースとして公開されています。

実際に GitHub のリポジトリをクローンして、ご自身の手でこのアーキテクチャやエージェントの挙動を試すことができるようになっています。（以下のリンクまたは画像の QR にアクセスして、必要な登録を済ませるとリポジトリにアクセスできます）

開発者の毎日のワークフローを大きく変えていく、とてもエキサイティングなアップデートの連続でした。ぜひみなさんも、公開されたコードを触りながら新しいエージェントプラットフォームを体験してみてください！

速報！｜Google Cloud Next’26｜Day1｜Opening Keynote はこちら！

【祝10周年】第30回 酒とゲームとインフラとGCP@Google｜5 月 15 日（金）19:30 〜

Google 渋谷オフィスで、お酒を飲みながら Google Cloud の最新情報についてお話ししませんか？