はじめに
2026年7月30日〜31日、Google Cloud Next Tokyo ’26 が開催されました。
データエンジニアの視点から、主に Day2（7月31日）の基調講演とデータ／エージェント関連セッションを聞いた参加レポートです。
場全体を通して繰り返し聞こえてきたのは、次の一点です。
エージェントを本番で活かすには、データと意味を「使える状態」にしておくことが前提になる。
以下では、まずイベントで語られた問題設定（3つの大きな変化）から、この「使える状態」の中身、Google Cloud の答えと優位性までを整理し、そのあと参加した公式セッションを紹介します。
1. エージェント時代の3つの大きな変化
Day2 基調では、AI 時代のデータ戦略を覆す変化として、次の3つが示されました。この整理は Google Cloud の Agentic Data Cloud 公式ページ でも「3つの大きな変化」として同じ形で掲げられています。
1. 人間スケールからエージェントスケールへ
実務担当者は作業者からエージェントのオーケストレーターへ役割を変え、エージェントは 24 時間体制でビジネスを監視し実行します。システムには、人間の直感を増幅しつつ、エージェントの速度と規模に耐えることが求められます。
2. 受動的なインテリジェンスからプロアクティブな行動へ
過去を分析して予測するだけでは足りず、エージェントはその瞬間に行動します。基調ではこれを、人間の質問を待つ「System of Intelligence」から、代わりに動く System of Action への転換、と表現していました。
3. データからコンテキストへ
エージェントがビジネスについて真に推論するには、ダークデータとして非構造化形式に閉じ込められている 90% を含む、全てのデータを活用できる必要がある、と語られました。重要なのはデータへのアクセスだけでなく、関係性・意味・ビジネスとの関連性まで深く理解することです（公式ページでは「データからセマンティック情報への移行」と表現されています）。
2. AIエージェントを使えるようにするための3つの前提
3つ目の変化「データからコンテキストへ」を、もう一歩実務側に引き寄せます。イベントで語られた「使える状態」は、きれいなテーブルを揃えることだけではありませんでした。少なくとも次の3つがセットです。
| 前提 | イベントで聞こえてきた中身 |
|---|---|
| 意味 | 関係性・意味・ビジネスとの関連性まで理解できること。指標の定義や用語が整い、エージェントが推論の根拠にできる状態 |
| ガバナンス | エージェントの身元・監査・失効を持てること。あわせて、許可された情報だけにアクセスさせ、最小必要コンテキストでトークンを抑えること |
| セキュリティ | 重要データに近づくほど価値とリスクが同時に増える。プロンプトインジェクションや未登録ツールへの外向き通信を遮断できる |
「意味だけ整える」「守りだけ足す」ではなく、エージェントが触る前提として三者が同時に語られていた点が印象的でした。
3. Google Cloud が提唱する3つのコンセプト
この3つの前提に対する Google Cloud の答えとして、Day2 基調では3つのコンセプトが軸になっていました。前提と1対1に対応させて読むと整理しやすいと思います（対応づけは私の読み方で、公式の分類ではありません）。
| 前提 | コンセプト | 概要 |
|---|---|---|
| 意味 | Agentic Data Cloud | データ、AI モデル、運用データベースを単一の「行動するシステム」に統合する、世界初のデータクラウド。Borderless Lakehouse（データがどこにあってもつなぐ）／信頼できるコンテキスト（Knowledge Catalog など）／意図した通りの結果（Data Agent Kit や会話型分析）の3領域で提供 |
| ガバナンス | Gemini Enterprise Agent Platform（以下、Agent Platform） | 本番エージェントのライフサイクル（構築・拡張・ガバナンス・最適化）をまとめて扱うプラットフォーム。構築には Agent Development Kit（以下、ADK）などが使われ、身元（Identity）、台帳（Registry）、通信制御（Gateway）、コンテンツ防御（Model Armor）で「本番で乱立させない」 |
| セキュリティ | AI Threat Defense | 防御のライフサイクル全体（準備→スキャン→修復→監視）を AI で回す枠組み。System of Action は絶対的なセキュリティとコントロールがあって成立する、という位置づけ |
なお、データの許可制御や最小コンテキストの付与は Knowledge Catalog（Agentic Data Cloud 側）も担います。上表のガバナンスは、主にエージェント運用の統制（Agent Platform）に寄せて対応づけています。
エージェント／データ／セキュリティが同じ場で語られていたことが、今年の Next の特徴だと思いました。
4. Googleの優位性
基調では、エージェント体験を最上層に置き、その下にエンジン群、中央に Knowledge Catalog、下層にクロスクラウドのレイクハウスを置くスタックとして示されました。意味を中央に置いて「使える状態」を作る、という先の話が、図では層になって見えます。
出典： Agentic Data Cloud - Google Cloud
では、なぜ Google がこれを提供できると言うのか。基調では、まず継ぎはぎ（断片化）のアーキテクチャがエージェント規模で破綻する、という対比が置かれました。
| 構造的リスク | 内容 |
|---|---|
| コストスパイラル | 断片化されたスタック上で自律エージェントを拡張するとコストが爆発しやすい |
| ウォールドガーデン | データを孤立環境へ移すことを強いられ、セキュリティが分断され、リアルタイムの行動が妨げられる |
| トラストギャップ | 技術カタログがあれば高品質な結果が出る、という誤解。実際には豊かなコンテキストが必要 |
GoogleCloudが唯一、AIのスタック全てを所有
他のハイパースケーラーはインフラを所有していても AI モデルは他所から借り、主要な AI 企業はモデルを所有していてもインフラは借り、その間をデータプラットフォームが借り物の部品でつなぐ。この断片化では単独のプロバイダーが結果に責任を持てない、という流れです。
これに対して基調は、次のように言い切っていました。
- 本日これを提供できるのは我々だけである
- 他のプロバイダーのパーツの寄せ集めではない
- Google だけがスタック全体を所有している
公式ページでも「AI サプライチェーン全体を独自に構築した唯一のプロバイダ」と表現されており、2日間の基調の締めも、ハードウェアからモデル、データ、セキュリティ、プラットフォーム、アプリケーションまでの一気通貫でした。
データエンジニアとしては、この優位性の話が製品の推しで終わらず、なぜ意味（コンテキスト）とガバナンス・セキュリティが前面に出るのかの説明になっていた点が重要でした。
セッション詳細
セッションのアーカイブ動画とスライドをご覧いただけます。気になればぜひセットでご覧になってください。（無料の登録が必要）
https://www.googlecloudevents.com/next-tokyo/
1. DAY 1 基調講演
ビジョン中心。産業革命のたとえ（中央の大きな動力を替えるだけでは足りず、現場に小さなモーターを埋め込み工程を再設計したときに伸びた）で、エージェントを業務に埋め込むイメージが語られました。データの信頼性とセキュリティ、フルスタックの予告があり、技術の本線は Day2 へ橋渡し、という位置づけでした。
2. DAY 2 基調講演
Day1 がビジョンと全体像なら、Day2 はエージェントを本番で回す技術スタックの掘り下げでした。ここでは会場で見た3つのデモを紹介します。データ・エージェント運用・セキュリティが、それぞれ実演で示されました。
Agentic Data Cloud デモ
会場で手触りが分かりやすかったのが、Google Cloud の山田氏によるデモです。スライドでは「1 PDF 自動解析 → 2 ゼロコピー基盤作成 → 3 エージェントによる分析」の流れが示され、架空の食品メーカーを題材に次が一気に見えました。
- Cloud Storage 上のレシピ／サプライヤー PDF からエンティティと関係を抽出してテーブル化
- AWS 上の購買データを、データを大きく動かさずに（ゼロコピー／フェデレーション）BigQuery から見える化
- グラフを拡張し、制約付きの複合質問（アレルゲン影響・会員セグメント・予測など）までエージェントで分析
会話型のデータアクセスについては、標準の生成 AI だけではビジネス文脈がなく、セキュリティ管理のバイパスやハルシネーションが起きうるため、Knowledge Catalog で回答を根拠付ける（grounding）、と本編で明示されていました。
デモとしては簡単そうに見えます。だからこそ、意味の抽出・クロスクラウド接続・エージェントへの根拠付けが短時間に圧縮されていること自体が学びだと受け取りました。後から手順をなぞるだけでも価値がある、と感じる密度でした。
Agent Platform デモ
購買エージェントのデモでは、単体で動くデモ用エージェントと、本番で成果を出すエージェントは別物だ、と切り分けられていました。重要データに接続し、複数エージェントを協調させ、画面やガードレールをプラットフォーム側で持つ、という話です。
構成として効いていたのは、構築（ADK）の話の直後に Identity / Registry / Gateway / Model Armor が続き、「権限はどうするのか？」が同じ流れで回収された点です。未登録ツールへの外向き遮断や、プロンプトインジェクションの検出ブロックもその場で示されました。
スライドにあった「統制不能の型」も実務の共通言語になりそうです。
| 欠如 | 帰結 |
|---|---|
| 身元なし | 誰が動かしたか証明できない |
| 監査なし | どのデータに触れたか追えない |
| 検閲なし | PII・悪意プロンプトが素通り |
| 失効なし | 問題時に一括停止できない |
締めのトーンは、「スケールや画面や通信制御はプラットフォームに任せ、人が集中するのは業務知識側」でした。
AI Threat Defense デモ
最終ブロックは、自律エージェント時代の攻撃速度への備えです。脆弱性の発見から悪用までの時間が 1.6 日にまで短縮された、という数字とともに、攻撃側は外側から覗くことしかできない一方、防御側はコード／クラウド／ビジネス／実行時のコンテキストを持てる、という対比が示されました。
デモでは Wiz と CodeMender の連携が実演されました。Wiz が AI エージェント・モデル・MCP サーバーを含む環境を可視化し、「インターネット公開 × VM 上のエージェント × 機密 DB」のような組み合わせをセキュリティグラフで特定して優先度を付ける。CodeMender が未知を含む脆弱性を検出し、攻撃コードを生成・実行して検証したうえで、修正パッチの作成まで進める、という流れです。防御ライフサイクルを人間のスピードからマシンスピードへ引き上げる、が締めのトーンでした。
4. 非構造化データのメダリオンアーキテクチャ
徹底入門！非構造化データのメダリオンアーキテクチャ Google Cloud 森田 想平氏 D2-DA-16
非構造化データ（センサー、画像・動画、VoC など）を、伝統的なデータエンジニアリングの型で整理し、後続の AI／エージェント利用につなげる入門セッションでした。
いちばん持ち帰ったのは、メダリオンの本質は「3層であること」ではない、という一文です。
N 個の供給と M 個の利用を N×M で直接つなぐとパイプラインが爆発する。全体コストを抑えるには N+M にする。
Bronze（原材料・追記中心）→ Silver（Single Source of Truth）→ Gold（利用側の要求）という役割分担は、構造化データと同じ型で非構造にも載ります。取り込みの TODO も具体的でした。
- 非構造を Cloud Storage へ置く（Bronze）
- BigQuery から扱えるようにする（オブジェクトテーブル等）
- 非構造から構造化を生成する（
AI.GENERATE等）（Silver）
もう一つの軸が、個人利用と組織／システムワイドの対比です。個人はプロンプト中心で準備は軽い一方、トークンが多く結果がばらつきやすい。組織ワイドは大事な点を形式知化するので安定しますが、準備負荷が大きい。エージェント向けに非構造をパイプラインへ入れるかどうかの設計判断そのものだと思いました。
基調の「エージェントスケール」「データ→コンテキスト」を、パイプライン設計の言葉に落とす内容でした。
5. AIエージェントのフィードバックループ（Bigqueryの会話分析）
BigQuery で始める AI エージェントのフィードバックループ ソフトバンク 小川 潤氏 D2-DEV-17
Conversational Analytics を題材にした 10 分 LT で、エンジニアリングの手触りが強い内容でした。
作成自体は「名前 → テーブル接続 → 指示」で始められます。しかし本編の核心は、「なんでも答えられる」と「信頼できる」は別、でした。
具体例として、「全期間の売上相当はいくら？」への失敗が示されます。キャンセルや返品の扱いが曖昧なのに、エージェントは聞き返さず解釈して合計してしまう。思考ログを覗くと曖昧さには気づいているのに、確認せず進む、という点が生々しいです。
正しく動かし続けるための処方箋は、次の二つでした。
| 軸 | 内容 |
|---|---|
| 根拠 | 何に答えて、何を確認させるか（手順・検証済みクエリ・用語集） |
| 台帳 | やり取りをログとして残し、レビューとカイゼンのベースラインにする |
手順の例としては、「売上の status が未指定なら数値も SQL も出さず確認する」「予測は受けない」「個人レベル集計は拒否する」など。用語集は Knowledge Catalog から少しずつ、という現実的な進め方も示されていました。
最後のメッセージは、「まずはじめてみること。そうでないと失敗や課題に気づくことすらできない」です。基調が「使える状態を作る」なら、DEV-17 は「使い始めてから信頼を育てる」側の話だと思います。
6. メタデータ自動付与パイプライン
Knowledge Catalog を活用したメタデータ自動付与パイプライン Supership 今村 豊氏 D2-DA-14
人手でスケールしないメタデータ付与を、Knowledge Catalog とスケジューラ／ワークフロー／BigQuery を組み合わせたデータパイプラインとして自動化する事例です。抽象度の高いガバナンス枠組み（CDMC）を、データエンジニアリングで馴染みのある手法に当てはめた点が参考になりました。「ガバナンス実行も、もう一つのデータパイプラインになりうる」という発想を持ち帰っています。
Knowledge Catalog に載せる知識そのものの形については、Google が公開した Open Knowledge Format（OKF）も整理しています。別記事にまとめたので、あわせてどうぞ。
Googleが公開した【AIと人間の両方が読めるWiki】の書き方 - Open Knowledge Format（OKF）とは
7. 企業のAIエージェント利用で差をつけるには
AI エージェントはなぜ実務で「定着しない」のか G-gen 杉村 勇馬氏 D2-DEV-14
実装デモというより考え方の LT。残ったのは、待っていれば進むこと（基盤側の進化）と、待っても進まないこと（自社のコンテキスト整備・データ化）の切り分けです。「指をくわえて待っているだけでは、勘所を押さえている企業と差がついていく」という一文が、基調のダークデータ論と同じ向きに聞こえました。
8. ADKとSlackによる社内タスクのエージェント化
現場で使える！ADK と Slack Bot で社内タスクをエージェント化 KDDIアイレット 西田 駿史氏 D2-DEV-18
ADK と Slack Bot で社内問い合わせや SFA／CRM 補助などを載せる事例。事例記事と GitHub リポジトリが公開されており、手を動かす入口があります。持ち帰りの型としては、「普段使う UI を入り口にする」「やり取りが溜まる場所を意識する」が残ります。
事例: cloudpack.jp / OSS: slack-bot-adk-python-cloudrun
9. AIエージェントを個人利用止まりにしないために
AI エージェントが個人利用止まりの“症状”に効く AX の処方箋 クラウドエース 杉山 裕亮氏 D2-DIA-03
個人利用止まりを、ユースケース／推進体制／定着設計の不全として整理する内容です。組織変革・評価寄りの話が中心でした。
10. AIエージェントのメモリ実装
AI エージェントの記憶を支えるメモリ実装のベストプラクティス PingCAP 関口 匡稔氏 D2-SIL-08
長期記憶（セッション横断）というテーマ自体は関心がありますが、製品デモ色が強く、実装像までは持ち帰りきれませんでした。Agent Platform 側の Memory Bank（長期記憶）など、公式の具体例を別途追うテーマとして残しています。
まとめと感想
Next Tokyo ’26 で主催側が示していた中心は、エージェントそのものの話題であると同時に、エージェントが前提とするデータと意味の状態でした。
- エージェント時代の3つの変化（エージェントスケール／プロアクティブ／データ→コンテキスト）が問題設定として置かれ、90% のダークデータを使える状態にすることが課題の中心だった
- 使える状態には、意味・ガバナンス・セキュリティという3つの前提が含まれる
- その答えとして Google Cloud からは Agentic Data Cloud / Agent Platform / AI Threat Defense が提示され、スタック全体を所有する一気通貫が Google の優位性として語られた
イベントを通して印象に残ったのは、エージェントの話が増えるほど、データの担う役割がより大きくなっているという感触です。意味付けや現場知を溜め、エージェントが使える状態にする側の仕事が、以前よりはっきり前面に出ていたように見えました。
データエンジニアとしては、まさにここが本業です。
次は狭い題材で一度通し、失敗を残しながら意味とルールを蓄積していく実践から始めていきたいと思いました。
ぜひイベントに参加できなかった方も、基調講演のアーカイブをご確認してみてください。