Developer Keynote、ラスベガスのマラソンをエージェントに計画させる1時間20分

こんにちは、ちゅらデータのエンジニア 倉富です。

2日目朝、目が覚めると鼻血が出ていました。乾燥しているからでしょうか。

そんな2日目、私はエンジニアなのでDeveloper Keynoteを聴いてきました。参加登録はしていたんですが、会場に到着したタイミングで開場されたので、流れで時間前に入っちゃいました。

なかなか良い場所に座れたのですが、空調が寒くて半袖Tシャツで参戦したことを、地味に後悔しました。時間を確認してなかったため、1時間半待ち。

テーマは、昨日のKeynoteで発表された Gemini Enterprise Agent Platform についてです。今日はそれを使って、プロダクションレディなエージェントをどう作るか、が主題です。
題材が振り切っていて、「ラスベガスのマラソンを計画するエージェントを作る」。ランナー1万人分のコース設計、給水所、医療テント、そして仮設トイレ500か所の配置までをエージェントに決めさせる、という設定でした。

オープニング

寒い中待っていた開演前の時間に、すでにショーが始まっていました。女性がなんか手をずっと動かしている。 どうやらAIを楽器として使い、手のジェスチャーで画面裏のビジュアルをリアルタイム生成という演出みたいです。 左側にあるシェーダーっぽいコードはそういうことかと理解。

デモの説明の中で強調されていたのが、Agent Platform のモデルは Gemini Proと Gemini Flash がデフォルトだが、Model GardenからClaudeなど、他社モデルも選べるという点です。後半のWizデモでClaude Codeを使っていました。
全体像は、下記のような感じでした。

・ADK（Agent Development Kit）: エージェント構築のフレームワーク。スキルとツールを持たせる
・Google Cloud MCP: 全ての Google Cloud サービスが、デフォルトでMCPに対応。エージェントからCloud全体を叩ける。ここで登壇者が「Yeah!」と叫んで、会場拍手
・Agent Runtime: サーバーレスな実行基盤。SessionsとMemoryがついてくる
・Agent Identity: エージェント固有のID。サービスアカウントではない新しい主体
・Agent Gateway: IAMポリシーを強制するプロキシ
・Agent Registry: エージェントの中央ディレクトリ。”DNS of your internet of agents”
・A2A プロトコル: Google Cloud がLinux Foundationに寄贈したエージェント間通信規格
・Agent Observability: トレース・メトリクス・評価。本番での挙動ベースでevalを統合
・A2UI（Agent-to-User Interface）: エージェントがUIを動的に生成するオープン標準

Part 1: Plannerエージェントをゼロから組む

最初のデモは、Plannerエージェントの構築です。

使う技術スタック

・ADK: モジュラーなエージェント構築フレームワーク
・Google Cloud Remote MCP: モデルコンテキストプロトコルサーバー
・Agent Runtime: エージェントのランタイム

Plannerに必要な3要素

登壇者が冒頭で整理したエージェント設計の骨格です。

1．Instructions: マラソンプランナーとしての役割を理解させる指示文
2．Skills: 地図の使い方、地理空間データ、レース計画の専門性
3．Tools: マッピングと実走可能ルート計算のツール

Agent Designer で素のエージェントを作る

まずは Agent Designer（ローコード / ノーコードのGUI）でベースのPlannerを設計。指示文は Gemini に助けてもらいながら書きます。

プレビューで走らせると、数秒でマラソン計画が返ってきて、 Gemini の素の知識だけでも一定の詳細さを持ったプランが返ってきていました。

Agent Designer からPythonコードをダウンロード

Agent Designer で組んだ内容を、指示文も反映された状態でPythonコードとしてダウンロードできる。これが以降のADKコードのベースになります。

Google Maps MCP を接続

次に、地図データへのアクセスを足します。Google Cloud MCP server for Google Maps を数行のコードでアタッチするだけ。自分で作ったMCPサーバーも、 Google Cloud が提供する1st-partyのMCPサーバーも同じ流儀で使え、1st-party MCPはセキュリティがデフォルトで組み込まれている、ということでした。

繋いだあと、「ラスベガスのランドマーク一覧を教えて」とエージェントに聞くと、Google Mapsから引いてきたランドマークのリストが返ってきます。

スキルを3つ追加

スキルはYAMLメタデータ + Markdown本体で構成。メタデータのdescriptionを読んでエージェントが「今、このスキルをロードすべきか」を判断する仕組みになっています。

1．Mappingスキル: Google Maps MCPの呼び出しを選択的に行う。地図に関するクエリを解釈する
2．GISスキル: GeoJSONを扱うPythonスクリプトを同梱。エージェントがこれを実行して、実走可能なルート計算（スタート・ゴール地点の選定含む）を行う
3．Race Directorスキル: レース委員会が実際にルート確認のために使っている Google ドキュメントを、Gemini を使ってスキル形式に変換したもの

GISスキルには、実行可能なPythonが付属する設計になっていて、決定論的な計算はコードに委譲。LLMは非決定論的な判断だけ、という分業をスキル単位で設計できる構造になっています。

完成したPlannerを動かす

スキルを段階的にロードしながらツールを呼び、実走可能ルートを出力。 結果としてラスベガス・ストリップを一望できる夜のマラソンルートが表示されて、Part 1が終了。

Agent Designerで作ったものをPythonコードとしてダウンロードして、そこからADKで拡張していく、という流れが紹介されていましたが、ADKを素で書ける人は最初からADKで書いたほうが早いんじゃないか、という気もしました。GUIで動作確認してからコードに落とす、という入り方は、どういったユーザーの利用を想定しているのでしょうか。

Part 2: マルチエージェント化、A2A と Agent Registry、そして A2UI

エージェントを2体追加

・Evaluatorサブエージェント: ルートを特定基準で判定する審査員
・Simulatorエージェント: 承認されたルートを実際に走らせて結果を返す
登壇者が「1万人ランナーのマラソンを計画して」とプロンプトを投げて、その処理中に設計解説が挟まる、というデモ構成。

Evaluator の設計: 別モデル + 限定コンテキスト

強調されていたのが、Evaluatorは別モデル・限定コンテキストで動くという点です。Plannerが計画を作るたびに、Evaluatorをツールとして呼び出す形。評価対象は、ルートプランのみにフォーカスさせる、と限定していました。

評価基準: 非決定論 + 決定論

評価のcriteriaは2種類。

・非決定論的: コミュニティへの影響、プロンプトとの整合性
・決定論的: ルート距離が正確に 26マイル385ヤード（= 42.195km） か

A2UI : エージェントがUIを自分で描く

A2UI は Google Cloud が作ったオープン標準で、エージェントが自分でUIを動的に生成する仕組み。デモの流れは、

1．プロンプト中に A2UI のワンショット例を1つ埋め込む
2．Gemini がそれに倣って、評価結果を表示するUIコンポーネント（カード、チャート、マップのインタラクティブ要素）を生成する
3．ルートが地図上にレンダリングされ、スコアが動的なカードで表示される共通のデザイン言語を使って、エージェントが必要なインターフェースをその場で設計・構築する、という仕組みです。

A2A プロトコルと Agent Registry

PlannerとSimulatorを接続するために、A2A（Agent-to-Agent）プロトコルと Agent Registry が登場します。
A2A の説明は、各エージェントがAgentCard（能力のマニフェスト）を公開する。他のエージェントはこれを読んで、「何を頼めるかを知る」という仕組みです。

Agent Registry は Agent Runtime にデプロイすれば自動で登録されて、エージェントのアドレスとcapabilityを中央で解決する中央ディレクトリです。

これで、PlannerとSimulatorがゼロコード・ゼロAPIコントラクトで繋がって、新しいシミュレーションを動かせるようになる、という流れ。

Simulatorが1万人分のランナーをspawnする

「Run Simulation」を押すと、Simulatorが環境パラメータを設定し、ランナー一人ひとりを独立したagent sessionとしてspawn、交通問題まで監視しながら結果をPlannerに返してきます。

ランナーの行動モデルは Gemini Deep Researchで調査した現実のランナー行動を取り込んでいて、「マラソン参加者の78%が、後半でペースを落とす」みたいな統計的傾向が実装されているとのこと。

評価基準の中に「26マイル385ヤード（= 42.195km）ぴったりか」というチェックが入っていたのですが、これはエージェントにやらせなくとも、ルールベースの処理で十分な気がします。単純な数値比較に毎回LLMを呼ぶのは、少しもったいない気がしますがデモですしね。 ランナー1万人を一人ずつ独立したagent sessionとしてspawnする、というのも、インフラを自前で潤沢に持っている Google Cloud だからこそのデモだと思いました。

Part 3: メモリとコンテキスト、Antigravity と Data Engineering Agent

Sessions と Memory Bank

「ステートレスからステートフルへ、全履歴をリクエストに詰め込む時代は終わった」というテーマから、具体が出ます。

・Agent Platform Sessions: エージェントをステートフルにする短期の状態管理
・Memory Bank: 過去のイベントから学びを引っ張ってくる長期記憶

さらにSpark + AlloyDB で、RAG経由で差別化されたデータをエージェントに渡す経路も用意されています。

Antigravity + Gemini 3 で20行未満

AntigravityというIDEでデモ。裏で Gemini 3 が動いているとのこと。
ADKクラスを足すだけで、20行未満でSessionとMemory Bankを組み込んでいくところを見せる。

Memory Bankは以下を自動でやってくれます:

・Plannerエージェントの使われ方を分析
・完了したシミュレーションを解析
・学びを長期メモリに自動保存
・次のプランで過去の学びを引ける

エンタープライズ向けフルマネージド、と強調されていました。

Data Engineering Agent の登場

続いて、Data Engineering Agentのデモです。ラスベガス市とネバダ州のローカルルールは、ドキュメントが大量に、色んな構造とファイル形式で存在する、という前提です。

Data Engineering Agentにプロンプトで「SQLアーティファクトを管理するデータパイプラインを作って、ドキュメント処理を一気通貫でオーケストレートして」と指示します。

Lightning Engine + Document AI + AlloyDB の組み合わせ

生成されたパイプラインの中身は、以下のとおりです。

・Lightning Engine for Apache Spark : 高速化されたSparkエンジン
・Document AI : ドキュメントをセマンティックにチャンク分割
・AlloyDB : チャンクを格納

そして、 AlloyDB のAuto Embeddings機能で、指定したモデルを使ってエンベディングを自動生成してくれる、と。

セマンティック検索デモと、ラクダ条例

「ラスベガス・ストリップでマラソンするときの制限事項」でセマンティック検索をかけると、ラスベガス市条例のチャンクが返ってきます。その中の1つが「公道にラクダを連れ出してはいけない」です。

次は、この知識をPlannerに組み込みます。

AlloyDB MCP で Planner に知識を注入

Google Cloud の公式リポジトリからスキルを拡張して、エージェントを AlloyDB とベクトル関数の専門家にした、と説明。さらに、Plannerにツールを追加してコードベースにコミットします。 Google Cloud Remote MCP server 経由で AlloyDB を呼び出す経路が開通します。

シミュレーションを開くと、以前と同じルートで再実行されます。今度は、メモリとコンテキストが効いていて、Plannerが現在のルート上のランドマークを把握していて、条例も取得しながら計画を調整します。メッセージの履歴を見ると、過去のシミュレーションの詳細が長期メモリから引かれている様子が確認できました。

そもそも、マラソン計画というシステムにメモリ機能が必要なのかなと思いましたが、Memory Bankという製品は、ユーザーごとの過去のやり取りや嗜好を覚えておきたい用途においては便利なはずです。

Part 4: 大規模運用でのデバッグ、Cloud Assist が根本原因を特定する

Part 4はデバッグとObservabilityについてです。使うツールは、

・Agent Observability : オープン標準ベースの運用メトリクス
・Gemini Cloud Assist : デザイン・デプロイ・トラブルシュート・最適化を手伝うエージェント的クラウドオペレータ

仕込み: Event Compaction

事前に仕込んでおいたのがEvent Compactionです。ADK標準機能で、エージェントが定期的に自身のワークフローを Gemini で要約して、モデルに送るコンテキストを圧縮する、という機構です。

これを入れておいたにもかかわらず、エラーで落ちた、というのがデモのシナリオです。

アラートからトレースビューへ

Gmail を見せると、Simulatorエージェントで異常に高いレイテンシのアラートが来ています。「View Incident」をクリックして、Cloud Monitoring consoleへ。

さらに、 Agent Runtime のトレースビューを開きます。ツール呼び出しに加えてエージェントの推論フロー（reasoning flow）が、時系列で見える作りになっています。

トレースを見ると、エージェントが複数ツールを成功裏に呼んだあとで、突然クラッシュしています。エラーログから1クリックで Cloud Assist investigation を起動。

Cloud Assist が調査する

Cloud Assist がやったのは、

1．エージェントのログを収集
2．Agent Runtime のインフラを精査
3．結論: Gemini Model APIへのリクエストエラーで落ちている、ペイロードに問題がある
4．具体的なコード行まで指摘

次は、Antigravityに画面切り替え。

Antigravity の中で調査を継続

Antigravityは、内部MCP経由でCloud Assistと繋がっているので、コンソールで開始した調査をIDE内でそのまま引き継げます。

Antigravityで「Simulator Agentについての Gemini Cloud Assist調査を再開して。agent.pyで何が間違ってる？」と聞きます。Cloud Assistエージェントが、

・Cloud Assistの findings を使う
・ソースコードを精査
・GitHub issuesまで検索
・全情報を統合して明確な説明を生成

返ってきた診断は「 Gemini API の100万トークンコンテキスト上限を超えている。追加したEvent Compactionが、巨大なツール呼び出し群の間で十分な頻度で動いていない」でした。

コード修正提案と再デプロイ

エージェントが提案してきたのは、「Event Compaction config に token_threshold パラメータを追加し、各invocation内でより頻繁にコンテキスト圧縮をかける」 変更を承認、コード差分を確認、ソースコントロールにコミット。CI/CDがSimulator Agentを Agent Runtime に再デプロイ。数分かかるので事前デプロイ版に切り替え。 再デプロイ後、同じクエリを投げると1Mトークン上限を超えてもエラーなく、Event Compactionが正常に動作しながら、処理を完了。

表向きはエージェントのデバッグデモなんですが、見ていて、「これはむしろ、バイブコーディングで実装させるときのガードレールとして効くんじゃないかな」という気がしました。

AIに書かせたコードが本番で詰まったとき、別のAI（Cloud Assist）が原因を特定してパッチまで提案する、という構図は、人間が書いていないコードを人間が書いていないツールで運用を監視する流れに近いです。 Event Compactionの頻度不足を直す一連のデモも、デバッグ機能そのものの宣伝というより、生成AI時代の運用パイプラインの話と考えたほうが分かりやすいかな、と思います。

ただ、AIが書いて、AIが直して、人間は承認ボタンを押すだけ、という流れがどんどん加速していくと、何かあったときに「なぜ、そうしたのか？」を説明できる人がいなくなるのでは、という点は、皆さんも懸念されているところでしょう。

Part 5: Vibe Clouding、Cloud Run から GKE への移行、Managed Lustre

シナリオ: Cloud Run → GKE + Gemma 4

ランナーコンポーネントを、2つの観点でアップグレードします。

・Control（制御性）: Cloud Run service を GKE deployment に変換
・Customization（カスタマイズ性）: Gemma 4 ベースのファインチューンモデルを同じクラスタにデプロイ

AntigravityでCloud Runサービスのマニフェストを開き、1つのプロンプトで全部やらせます。

Cloud Assist の翻訳者としての機能

IDEはMCP経由で Gemini Cloud Assist に繋がっている。Cloud Assistは「 Google Cloud のリソースとアドバイスへのアクセス」を提供する翻訳者として動く。

生成されるマニフェストの質

Cloud Assist は、単に構文的に正しいYAMLを出すだけでなく、以下が埋め込まれると紹介されていました。

・GKE上での推論のベストプラクティス
・vLLMの適切なサーバー設定
・スケーリングポリシー

デプロイと失敗

マニフェストが出来たので、 yes を押して適用。100ランナーでは問題なく動いたが、内部で数千ランナー規模にロールアウトしたら問題発生。

Cloud Assist による自動調査

操作する前に、Cloud Assist が自主的に調査を走らせて問題を特定していた。

診断結果:ストレージがモデルを十分速くロードできていない。GCS Fuseは良いが、このスケールにはManaged Lustreのほうが適している。

そして提案: Managed Lustreに切り替えてください、と。 事前にLustreで再デプロイしたバージョンに切り替えるとランナーがちゃんと動くようになりました。

さらに、Gemma 4が入ったおかげで、ランナーの思考と感情がUIに出るようになっていました。

3つの学び

このパートで強調されていた3点:

1．ブラウンフィールドのシステムでも、意図がアクションに即座に変換される
2．特定の規定違反について、能動的に通知される
3．プロダクトや機能の細部ではなく、アウトカムに集中できる

気になった点

インフラを潤沢に持っている企業ならではのデモですね。同じ方針で動こうとすると、コストとオペレーションの重さが課題になりそうです。

Vibe Codingのインフラ版というネタとしては分かりますが、今回の Google Cloud Next 全体を見ていると、 Cloud Run を大幅に強化して、エージェントや周辺アプリのサービングがやりやすくなりました、という趣旨のセッションが多数あったため、このパートで Cloud Run → GKE への移行をデモにするのか、という感想を持ったことも事実です。

100ランナーから数千ランナーに増やして詰まったので、 Cloud Run + GCS Fuse から GKE + Managed Lustre に切り替える、というシナリオは富豪だなぁ、と思いました。

Part 6: Gemini Enterprise と非開発者のエージェント、Agent Designer で1プロンプトでチームを作る

Part 6は毛色が変わって、「デベロッパーじゃない人でも、開発者のエージェントを使える・作れる」という話。

自動登録と発見可能性

Agent Runtime にデプロイした高コードエージェントは、自動的に Agent Registry に登録され、 Gemini Enterprise からも発見可能。Part 1-5で作ってきたPlanner Agentが Gemini Enterprise 上にそのまま出てくる、ということになります。

Gemini Enterprise から Planner を使う

Gemini Enterprise の画面を開くと、Marathon Planner Agentが使用可能です。そこに「ラスベガスで1万人ランナーのマラソンを計画して」とチャットで投げると、A2UIの動的UIで結果が返ってきます。

作ったエージェントの機能が、カスタムアプリでも標準的なGemini Enterprise画面でも同じように動く、とのこと。

次は1プロンプトでエージェントチームを生成

題材は「レースの発注管理（水、食料、音楽）」。

普段は長い Google Doc で手順管理しているところを、その Google Doc をコンテキストとしてエージェントに渡し、 Gemini Enterprise Agent Designer を開く。

プロンプト1発:

レース計画と発注の専門家のエージェントを作って

これで Gemini が、

・メインエージェント: 全体の計画・発注を調整
・複数の専門サブエージェント: それぞれの専門領域（水、食料、音楽等）を担当

を、まるごとチームとして生成。メインエージェントをクリックすると、 Gemini が生成した詳細なinstructionsが確認でき、ユーザーは更にカスタマイズできるようです。

ドキュメントをコンテキストとして与える

Google Drive のリンクを渡すだけで、ドキュメントがエージェントのコンテキストとして組み込まれます。「ドキュメントをコード化する必要なく、文書がそのままエージェントの知識源になる」。ユーザーが Google Doc を更新すれば、エージェントの動作も自動的に最新になるとのこと。

サプライチェーンエージェントの稼働

チャット画面に戻り、会話のフォーカスを「supply chain agent」に切り替え、包括的な発注計画を依頼すると、

・水と食料の配置
・配置するマイル位置
・エンターテイメント
・Port-A-Potties（仮設トイレ、キーノート通してのテーマ）

が揃った計画が出てきます。

エージェント作成の敷居を下げるという意味では、このパートはありだと思いました。

プロンプト1発でメインエージェント + サブエージェントが組めるのは、開発者ではない人が「自分の業務を自動化したい」と思ったときの入口になりそうです。ただ、バンバンマルチエージェントを増やすと、運用者の方が大変になりそうです。でも、それもエージェントがやればいいのか。

Part 7: Agent Identity、Agent Gateway、そして Wiz

セキュリティの責任を開発者に寄せる”Shift Left”ではなく、プラットフォーム側に賢さを持たせるShift Down、という枕からスタート。

「マルチエージェントシステムでのセキュリティのshift downは、深夜のラスベガスストリップを目隠しで歩くようなもの」。続けて、

「攻撃者が1万人のランナーを、カジノのど真ん中にルーティングしてくる可能性もある」という例も入れつつ、ポリシーとIdentityの話に入ります。

Agent Gateway と IAM

現状のシステムには、すでにAgent Gatewayがデプロイ済み、という前提です。Agent Gatewayは、

・エージェント間のプロキシとして立つ
・IAMポリシーを強制
・承認されたソースからのみ、エージェントにアクセスできるようにする

Agent Registryには、既にPlannerとSimulatorが登録されていて、各エージェントインスタンスには、固有のアイデンティティがデプロイ時に自動生成される。

Agent Identity の「生体認証スキャナー」比喩

サービスアカウントは、全スタッフで共有する全室マスターキー、Agent Identityは各扉の生体認証スキャナー。一度生成されたIDはimmutable（変更不可）で、エージェントインスタンスに紐づきます。

Egress Policy のデモ

画面には、すでに設定済みのポリシーが見える状態。Egressポリシーは、エージェントが外に出る通信を制御する。すでに設定済みのポリシーとして、Plannerがオープンインターネットにアクセスするのをブロックしていました。理由付けは、「1万人分のランナープロファイルと本番APIキーを扱うのであれば、Plannerの中で起きたことはPlannerの中で止めないと」。

予算いじりデモと Read-Only 制約

Plannerが予算を変更しようとする行動を、ポリシーでブロックする、というデモ。

新しいポリシーを作成

・対象: Planner Agent
・MCP サーバー: Finance MCP server
・条件: read-only-finance、ReadOnly = True

同じプロンプトを投げると、Agent Gatewayで書き込み系ツール呼び出しがブロックされて予算変更が通らなくなりました。

Wiz 登壇: Red Agent / Green Agent

Wiz, Inc.は、2025年に Google が買収したクラウドセキュリティプラットフォームを開発・提供する企業です。

Security Graph

Security Graphは、クラウドとAIアプリのリビングマップ。脆弱性とリスクをAIモデルで解釈する。その上に、2種類のセキュリティエージェントが乗っています。

Red Agent（攻撃側）

Opening Keynoteでも紹介済みのRed Agent。

・ペネトレーションテスター役の friendly AI attacker
・外部から実際に脆弱性を突けるか検証
・コード解析だけじゃなくデプロイ済みのアプリとAPIに対するリアルなリスクにフォーカス

デモでは、Marathon Planner Agentのアーキテクチャを映し出して、Red Agentが

1．エクスポージャ（公開された経路）を見つける
2．マシンを辿って機密データへのAttack Pathを構築
3．認証バイパス脆弱性を発見
4．そのバイパスに辿り着くまでの全ステップを可視化

「exploit可能か」まで検証するのが強調されていたポイントで、静的解析の「潜在的脆弱性」ではなく、実際に外部から突けるかを証明する、と。

Green Agent（修正側）とCode-to-Cloud

続いての説明、code-to-cloudで、ランタイムで検出したリスクをソースコードのリポジトリ位置まで追跡して修正に繋げる。

Green Agentは、Red Agentが見つけた問題に対してルートコーズの修正案を提示し、開発ワークフローに流し込む（コーディングエージェントにも流せる）。

Wiz Remediate Skill の実行

事前実行版でWiz Remediateスキルを動かし、リポジトリから検出されたリスクを引き出す。Claude Codeに流し込むと

・Toxic combination（危険な組み合わせ） として1つのクリティカルリスクが特定される
・そのAttack Pathを構成する7つの独立したセキュリティリスクが列挙される
・Green Agentが優先度付きの3つの修正を提案

修正の3点:

1．IAM特権のダウングレード（過剰権限の剥奪）
2．認証バイパス脆弱性のパッチ（アプリケーションコード修正）
3．AI guardrailの強制

「human in the loopとして、この順序は理にかなってる」と適用指示。Claude Codeが順次修正を当て、事前実行版で結果を表示

・過剰アクセスを削除するフォームが見つけられた
・認証バイパスのアプリケーションコードがパッチされた
・AI guardrailが強制された

コミットして再スキャン → パス、開発スピードとセキュリティは両立できる、と宣言してPart 7終了。

このパートもガードレールの話で、Part 4のバイブコーディング監視と地続きだなという印象でした。AIが書いて、AIが運用して、AIが脆弱性を突いて、AIが直す、という流れの中で、人間の代わりにレールを敷くピースがAgent Identity / Agent Gateway、そしてWiz, Inc. との連携、という整理で見ると分かりやすい構成です。

エージェント時代に必要なガバナンスとセキュリティの形を、ちゃんと製品レイヤーで提示してきた点は評価できるところで、Agent Identityでサービスアカウントとは別の単位でエージェントのIDを管理する発想や、Egressポリシーでエージェント単位の挙動を縛る仕組みは、使いたいと思いました。

そして、印象的だったのが、 Google のデモにClaude Codeが用いられていたことです。今回、他のセッションでもClaudeが用いられる場面があったので、 Google のエンジニア自身も普段からClaudeをガンガン使っているんだろうな、という雰囲気が伝わってきました。「Model Gardenで選べます」という建前以上に、現場では当たり前にマルチモデル運用をしているんだろうな、と感じる場面でした。

まとめ

1時間20分のキーノートでした。全体を並べ直すと、Agent Platformは単一製品ではなく、エージェントのライフサイクル全体を覆うレイヤー群として、各層にピースが揃った紹介になっていました。

・開発: ADK / Agent Designer / Antigravity
・実行: Agent Runtime / Sessions / Memory Bank
・接続: A2A / Agent Registry / MCP
・UI: A2UI
・運用: Agent Observability / Cloud Assist
・統制: Agent Identity / Agent Gateway / Wiz連携

気になったポイントは色々あるんですが、2つを挙げます。

1．A2UI、UI実装の前提が崩れるかもしれない

ダッシュボードを先に書かず、エージェントに動的に生成させる、という発想は、UX設計の手順そのものを変えます。全てがA2UIで済むとは思わないですが、定型的なレポート画面や設定画面はかなり食われてしまう可能性が見えます。

仕事で「このダッシュボードを作って」と言われるうちの何割かは、「エージェントにその場で作ってもらう」未来がありそうです。

2．Shift Down

「開発者にもっとやらせる」ではなく「プラットフォームを賢くする」という方向転換は、エージェント運用の現実解だと思います。Agent Identity / Agent Gatewayがその具体化で、サービスアカウント運用の雑さから抜け出る道が見えた気がします。

2日目の夜は、Next at Nightが隣のスタジアムでありました。飲み会のためにスタジアムを貸し切るなんて、さすがです。

参考リンク
Developer Keynote｜Google Cloud Next 2026（YouTube） — 本セッションのアーカイブ動画

※Google Cloud および Google Cloud 製品・サービス名称は Google LLC の商標です。

（本記事の内容は、2026年4月時点の情報に基づいています）