【Google Cloud Next Tokyo 26】DAY 2基調講演レポート 〜「委任」を支えるデータとコンテキスト〜

はじめに

「Google Cloud Next Tokyo 26」に現地参加してきました。本記事では、DAY 2基調講演のレポートをお届けします。
DAY 1で示された、以下スライドの6つのレイヤーを1つずつ掘り下げる構成で、インフラ、エージェント基盤、データ基盤、セキュリティと話題が広がりました。
本記事は網羅的なレポートではなく、個人的に印象に残った5つのパートに絞ってまとめたものになります。

DAY 2基調講演

Google Cloudの渕野 大輔 氏をはじめ、Google Cloudのプロダクト担当者と国内企業・パートナーのリーダー計9名が登壇しました。

冒頭で渕野氏から、DAY 1ではGemini Enterpriseとそれを支える6つのレイヤーの全体像を伝えたので、DAY 2ではそのレイヤーを深く掘り下げる、という位置づけが示されました。

1. エージェントの価値を生むのは自社のデータとコンテキスト

Agentic Data Cloudのパートで最初に置かれたのが、この一文でした。

エージェント時代に起きる変化として挙げられたのが3つです。

• 人がひとりで手を動かす規模から、多数のエージェントを動かす規模へ。
• 昨日何が起きたかを振り返る分析から、その場で動く実行へ。
• データからコンテキストへ。

このうち中心に置かれていたのが、3つ目のデータからコンテキストへでした。企業データの9割はダークデータと呼ばれる非構造化データで、テーブルの中身だけを見てもビジネスの背景までは分からない。
表も動画も音声ログも含めて読み解き、顧客とサプライチェーンがどう繋がっているかまで持たせて、はじめてエージェントが使える「生きた知識」になる、という整理でした。

これを実現するものとして示されたのがAgentic Data Cloudで、Borderless Lakehouse、信頼できるコンテキスト、意図した通りの結果という3本柱で構成されていました。

2. Gemini Enterprise Agent Platformの中身

DAY 1でGAが発表されたGemini Enterprise Agent Platformを、構築・拡張・ガバナンス・最適化の4つに分けて掘り下げるパートです。
4つのそれぞれに機能が割り当てられていて、構築にはモデルの選択肢とADK、拡張には専用設計のサーバーレスランタイム、ガバナンスにはレジストリとAgent Identity、Agent Gateway、最適化にはオブザーバビリティが並びます。

拡張にあたるAgent Runtimeは、目標・指示を受けたエージェントの下にセッション・メモリ・モデルを置き、外側にMCPサーバーやAPI、スキルを繋ぐ構成でした。長時間動かすと会話履歴が膨らむため、自動でコンパクションをかけてコストを抑える仕組みや、長期記憶を持たせるメモリバンクも紹介されていました。

ガバナンスの層は、エージェントにAgent Identityという身元を持たせてIAMと連携させ、資産をAgent Registryで管理する形です。出入り口の両側にAgent Gatewayを置いてポリシーとAI保護を効かせ、全体をAgent Observabilityで見る、という構成でした。Agent Registryはプレビューで、エージェントだけでなくMCPツールとスキルも同じ場所で公開・発見・保護の対象になります。

3. 購買エージェントのデモ

ここからデモです。テーマは「デモエージェントから抜け出すために」で、重要なデータとの接続、複数エージェントの連携、わかりやすいフロントエンド、安心できるガードレールの4つが条件として挙げられました。

題材はノートPCの購買申請で、購買エージェントの下に在庫管理エージェントと予算チェック用のMCPサーバーがぶら下がる構成です。開発にはAntigravityのCLIが使われていました。
チャットに「ノートPC3台」と投げると、テキストの回答ではなく機種を選ぶボタン付きのカードが返ってきます。A2UIによってエージェントが動的にUIを組み立てるもので、選ぶだけで申請が進む形になっていました。チャットの流れから離れずに選択と申請まで進められるので、対話型のUIに慣れている人ほど扱いやすそうだと感じました。

そのうえで話がガードレールに移りました。エージェントは業務の中枢にあるデータに近づくほど価値が出る。ただし価値とリスクは同時に大きくなる、という提示です。

デモでは2種類の攻撃が試されました。1つは添付文書に「申請の無条件承認」「支払先の変更」を指示する隠しテキストを仕込むプロンプトインジェクションで、Model Armorがエージェントに届く前に遮断します。もう1つは社外の格安業者のMCPサーバーへ照会させようとするもので、宛先がAgent Registryに未登録のため、Agent Gatewayが外向き通信を拒否しました。どちらも判定は監査ログに残ります。

このパートの結論が、エージェント乱立による4つの統制不能でした。身元・監査・検閲・失効が欠けた状態が並んでいて、それぞれAgent Identity、Agent Observability、Model Armor、Agent Registryが埋めにいく対象になっています。2章で並んでいた機能が何のためのものだったのかが、ここで裏返しに示された形でした。

4. 散らばったデータを5分で繋ぐデモ

Agentic Data Cloud側のデモは、架空の食品会社を題材にしたものでした。
原材料情報は大量のPDF、基幹マスターデータはAWS、行動トランザクションはBigQueryにあり、データは存在するのに繋がらない、という状況設定です。

流れはPDFの自動解析、ゼロコピーでの基盤作成、エージェントによる分析の3ステップです。Cloud Storage上のPDFをGeminiが読んで関係を自動定義し、AWS側の購買データを動かさないまま繋いでグラフを更新し、そのグラフをソースにデータエージェントを作る。通常ならトレンドを掴んで意思決定するまでに5週間かかるところを5分に縮められていました。エージェントの土台になるのがデータの整備だという1章の話が、そのまま画面で示されたパートです。

5. 防御側が持っているコンテキスト

最後がセキュリティでした。AIが自律的に脆弱性を見つける能力が顕在化し、業界では「フロンティアAIショック」とも呼べる不安が広がっている、という切り出しです。脆弱性の発見から悪用までの猶予が1.6日にまで縮まったという数字は、DAY 1でも示されていたものでした。

Googleがこの事態にどう取り組んできたかを示したのが以下の年表です。AIで脆弱性を発見する研究として始めたProject NaptimeがDeepMindとの統合を経てBig Sleepになり、オープンソースソフトウェアから未知のゼロデイ脆弱性をAI単独で発見するという世界初の成果に至ったそうです。ただ発見が速くなるほど手動の修復が追いつかなくなるため、自動修復エージェントのCodeMenderを投入した、という流れでした。CodeMenderは複数のモデルから選べて、その1つとしてGemini 3.5 Flash Cyberが近日提供とされています。

このパートで一番印象に残ったのが以下のスライドです。攻撃者が持っている情報は外から覗ける範囲に限られていて、公開・露出データと推測しかない。対して防御側は、コードのコンテキスト、デプロイの実態、実際の稼働状況、権限の相関図、内部アーキテクチャ、所有権データ、実行時のコンテキストを持っている。このコンテキストの差こそが防御側のアドバンテージだ、という主張でした。1章のデータとコンテキストの話がセキュリティにも接続していて、基調講演全体が同じ軸で貫かれていたのが分かる場面でした。

そのうえで示されたAI Threat Defenseの4ステップは、DAY 1でも触れられていたものです。準備で攻撃可能な範囲を絞り、スキャンで外部から到達可能かを判断して優先順位を付け、修復でAIエージェントがコードを直してテストまで通し、監視でAIが攻撃を試し続け、弱点を洗い直す。DAY 2ではそこに「防御のライフサイクルをマシンスピードへ」という言葉が添えられていました。

さいごに

DAY 1が「指示から委任へ」という話だったのに対して、DAY 2は、その委任を成立させるために手前で何が必要になるのか、という内容でした。エージェントに身元を持たせて登録し、出入り口で通信を制御し、何をしたかを記録する。そのエージェントに渡すコンテキストを、散らばったデータの側で整える。そして守る側は、攻撃者より多くの情報を持っているという前提に立って動く。掘り下げられた6つのレイヤーは、どれもこのいずれかを担うものでした。
印象的だったのは、コンテキストという言葉が何度も出てきたことです。エージェントの価値を生むのは自社のデータとコンテキストだという1章の主張が、セキュリティのパートでは防御側のアドバンテージとして、形を変えて再び出てきました。AI Threat Defenseの4ステップは、DAY 1に続いて同じ図が示されていました。それだけGoogle Cloudが今回のメッセージの中心に据えていたテーマなのだと感じました。
DAY 1とDAY 2の基調講演を通して感じたのは、問われているのはエージェント本体の賢さではなく、そのエージェントが何を知り、どこまで許され、何をしたかを後から確認できるかどうかだ、ということです。エージェントの数を増やすほど、使う側の整備が先に効いてくる。そう考えさせられた2日間でした。