こんにちは、小林です!
株式会社リンクアンドモチベーションでデータアナリスト兼データスチュワードをしています。普段はデータ分析業務をやりつつ、データ基盤の品質管理も推進しています。最近は AI エージェントを前提としたデータ基盤の設計アップデートを追いかけていて、毎日ワクワクしています!
それでは記事に入ります。
はじめに
2026年4月22日、Google Cloud が「Agentic Data Cloud」という構想を打ち出しました。Google Cloud Next '26 の流れで、関連する発表群が一斉に公開されたタイミングです。
データ基盤や BigQuery と聞いても、普段あまり触れていない方にとっては、正直ピンとこないかもしれません。
アプリケーション開発やデザインに関わっていると、「どこかにデータが溜まっていて、分析チームが使うもの」くらいの認識でも、これまでは特に困らなかったと思います。
この記事は、そんな方に向けて書いています。
専門用語を細かく解説するというよりは、「データ基盤がこれからどう変わっていくのか」 をイメージできるように、なるべくシンプルに整理していきます。
細かい構成や機能については後半に Appendix としてまとめているので、気になる方だけ読んでもらえれば大丈夫です。
ちなみに自分は、データ基盤の構築に関わるデータスチュワードとして働いています。
「エージェントがデータから自然に示唆を引き出してくれる基盤」 を作りたい、と考えていたのですが、今回の発表はそのイメージが一気に現実に近づいたような内容でした。
かなりワクワクしながら見ていたので、その温度感も含めて共有できればと思います。
そもそもデータ基盤って？
ざっくり言うと、会社のデータが集まっている場所 です。
ユーザーの行動ログ、売上、在庫、問い合わせ履歴など、さまざまなデータが 1 箇所に集められていて、必要に応じて取り出して分析します。
Google でいう BigQuery、他社でいう Snowflake や Redshift がこの役割を担っています。
この「データが集まる場所」が、いま静かに、でも確実に作り替えられています。
これまでのデータ基盤 = "倉庫"
これまでのデータ基盤は、本質的には 倉庫 のようなものでした。
- データを集めて整理する
- 人が SQL を書いて取り出す
- ダッシュボードで可視化する
- 人が見て判断する
この流れが基本です。
整然と管理された倉庫があって、必要なときに担当者が取り出してくれるようなイメージ。
優秀なデータエンジニアが棚を整え、依頼に応じてデータを取り出す。そして最終的な判断は人が行う。
つまり、データはあくまで「人が使うためのもの」 でした。
これからのデータ基盤 = "AI の相棒"
ここで前提が大きく変わります。
Agentic Data Cloud が取っている立場はシンプルで、
「データ基盤は人のためではなく、AI エージェントのためにある」 という考え方です。
AI エージェントが自分でデータを探し、解釈し、そのまま次のアクションまでつなげる。
人はそれを監督する側に回る、という構図です。
少し極端に言うと、「倉庫番そのものが AI になる」 イメージです。
デモで見えた世界
基調講演のデモでは、こんなシーンが紹介されていました。
- 新商品のフローズンヨーグルトの市場投入判断
- AI が社内の PDF レシピとサプライヤーの仕様書 PDF を自動で突合し、隠れた大豆アレルゲンを発見
- 続けて AWS 上にある顧客データと Google 上のアレルゲン情報を結合して市場規模を算出
- 最後に ROI 予測まで生成し、1,500 万ドル規模のビジネス判断を数分で提示
このプロセスの中で、分析者が SQL を書いたり、データエンジニアがパイプラインを組んだりする場面は出てきません。
エージェントがすべてを横断して処理しています。
初めて見たとき、正直ゾクッとしました。
1 年前、自分が「こういうデータ基盤を作りたい」と描いていた絵が、すでに別の会社のプロダクトデモとして動いていたからです。
未来像として語っていたものが、もう製品として並んでいる。
その距離感を実感したのが、今回の発表でいちばん衝撃だったところです。
構造をざっくり図にすると、こんな対比になります。
左側が「人間のためのデータ基盤」、右側が「AI エージェントのためのデータ基盤」。
やっていることは似ていますが、誰のために最適化するか が根本から違います。
何が一番重要なのか
今回の発表で一番重要だと感じたのは、この一言です。
Reasoning without context is just a guess.
（文脈なき推論は、ただの当てずっぽう）
AI にテーブルをそのまま渡しても、賢く動いてくれるわけではありません。
カラム名が u_id だけでは意味が分かりませんし、「売上」の定義がチームごとに違えば、簡単に誤解します。
つまり、
AI の性能よりも、「どんな文脈を渡せるか」の方が重要になる
ということです。
そしてその「文脈」を準備する装置が、これからのデータ基盤の中核になります。
ここが今回の発表の根っこにある認識で、ここを押さえると他の機能の意味が全部つながります。
変わる 3 つのポイント
今回の発表をシンプルにまとめると、変化は大きく 3 つです。
1. データに「意味」を持たせる
データをそのまま置いておくだけではなく、
- このテーブルは何を表しているのか
- この指標はどう定義されているのか
- テーブル同士はどう関係しているのか
といった「意味」を基盤側で管理します。
Google ではこれを Knowledge Catalog として提供しています。
人間の頭の中にあった業務知識を、データ基盤側に持たせるイメージです。
さらに PDF や画像のような、従来「ダークデータ」と呼ばれていた非構造化データにも自動でタグ付けしてくれます。
AI がファイルの中身まで含めて、横断的に参照できるようになります。
2. AI との接続を標準化する
AI がデータにアクセスする方法も整理されました。
MCP（Model Context Protocol） という共通の仕組みに乗り、BigQuery や Cloud SQL、AlloyDB、Spanner といった主要な DB 製品すべてに、MCP 経由の接続口が正式に用意されました。
イメージとしては データベースの USB-C 化 です。
AI ツール側は「MCP に対応してさえいれば、どの DB にもそのまま繋がる」世界に近づいています。
Claude Code や VS Code、Gemini CLI からそのまま BigQuery を叩ける、という話は基調講演でもそのまま名指しで出ていました。
3. データを閉じ込めない
これまでのデータ基盤は、クラウドごとに分断されがちでした。
Google のデータは Google に、AWS のデータは AWS に、という状態です。
今回のアプローチでは、
「データはどこにあってもいい。取りに行く側を賢くする」
という考え方に変わっています。
具体的には Apache Iceberg というオープンなテーブル形式をベースに置き、どこのクラウドにあるデータでも横断して読める設計に切り替えました。
AWS の S3 にある Iceberg テーブルを、BigQuery から直接クエリできます。しかも転送料金（エグレス）もかかりません。
「データを Google に引っ越してくれ」ではなく、「データは好きな場所に置いたままでいい。こっちから見に行くから」というスタンスへの転換、と言えます。
すでに起きている変化
これらはまだ未来の話、というわけではありません。
基調講演と関連ブログで紹介された、すでに本番環境で使われ始めている事例をいくつか拾っておきます。
- Virgin Voyages（クルーズ会社）: 大規模な旅程再予約処理が 6 時間 → 11 分 に短縮。1,000 を超える特化型エージェントが協調している
- Macquarie Bank（オーストラリアの銀行）: BigQuery + Spanner を基盤に AI アシスタント "Q" を全社展開し、詐欺被害が半減
- Vodafone（通信大手）: 数百のエージェントをデプロイ。年間数百万ユーロのコスト削減 見込み
- Citadel Securities（金融）: 既存ワークロードを 2〜4 倍高速化、コスト 30% 削減。処理サイクルが週/日単位から時間/分単位へ
- Seven-Eleven Japan: Spanner + BigQuery ベースのデータ基盤で 21,000 店舗のデータを統合運用
共通しているのは、人が分析していた部分を、エージェントが担い始めている という点です。
試験運用ではなく、もう基幹業務の中で効き始めています。
おわりに
1 年前、自分はデータスチュワードとして 「エージェントが自然にデータから示唆を引き出してくれる基盤」 を作ろう、と決めました。
ただ、その時点ではまだピースが揃っていませんでした。
- セマンティクスをどう扱うか
- 安全にデータへ接続する方法
- クラウドをまたいだデータの扱い
どれも課題としては見えていたものの、実装レベルではバラバラで、絵に描いた餅感が拭えませんでした。
それがこの 1 年で、MCP が標準として据わり、Knowledge Catalog が GA になり、エージェントが大手企業の本番業務に入り始めました。
自分が描いていた地図の白い部分が、一枚ずつ埋まっていっている感覚があります。
追いかけていた未来像が、毎週のように現実側から近づいてくる。
データ基盤を作る側の立場として、これほどやりがいを感じる時期はそうありません。
AI-native なデータ基盤は、もう「いつか来るもの」ではなく、少しずつ当たり前になり始めています。
詳しく知りたい方向け（Appendix）
本文では「3 つの変化」としてざっくり整理しましたが、もう少し解像度を上げたい方向けに、以下 3 つを置いておきます。
A. 4 層モデルで整理する Agentic Data Cloud
Google の公式ブログ群の表現を統合すると、Agentic Data Cloud は以下の 4 層で構成されます。
| 層 | 役割 | 代表コンポーネント |
|---|---|---|
| Layer 1: Agentic Workforce | エージェント群 | Data Engineering Agent / Data Science Agent / Conversational Analytics / Deep Research Agent |
| Layer 2: Context & Memory | 文脈と記憶（ハルシネーション防止） | Knowledge Catalog / Agent Memory Bank / AgentOps |
| Layer 3: Unified Orchestration & Action Plane | 統合実行面 | BigQuery / Spanner / AlloyDB / Cloud SQL / Bigtable / Looker（各 DB に Managed MCP Server） |
| Layer 4: Active Multimodal Engines | 能動的データエンジン | Graph / Vector / Full-text Search / ObjectRef（非構造化）/ Lightning Engine for Spark |
上位層（エージェント）が MCP や A2A（Agent-to-Agent）プロトコルで下位層にアクセスする構造です。
Layer 2 の Knowledge Catalog が「エージェントが嘘をつかないための構造的保証」を担う のが、従来アーキテクチャとの最大の違いです。
B. 主要機能の GA / Preview 一覧（抜粋）
GA（General Availability）は正式リリース・一般提供、誰でも本番利用 OK の状態です。Preview は試験提供段階で、使えるものの仕様変更や提供停止の可能性があります。
Next '26 時点で、多くの機能は段階的に GA しています。
| カテゴリ | 機能 | ステータス |
|---|---|---|
| BigQuery コア | Fluid Scaling（秒課金、平均 34% コスト削減） | GA |
| Managed Iceberg Tables | GA | |
| Cross-Cloud Interconnect for Lakehouse | GA | |
| BigQuery Graph | Preview | |
| BigQuery Measures | Preview | |
| AI.PARSE_DOCUMENT | Preview | |
| ガバナンス | Knowledge Catalog（旧 Dataplex） | GA |
| Business Glossary | GA | |
| エンドツーエンドデータリネージ | GA | |
| Automated Context Curation（Gemini 自動エンリッチ） | Preview | |
| LookML Agent | Preview | |
| Smart Storage（GCS 自動タグ付け） | Preview | |
| エージェント | Data Engineering Agent | GA |
| Data Science Agent | GA | |
| Conversational Analytics（BigQuery / Looker） | GA | |
| Database Observability Agent | Preview | |
| Data Agent Kit（VS Code / Claude Code / Gemini CLI 統合） | Preview | |
| MCP | BigQuery / Cloud SQL | GA |
| AlloyDB / Spanner / Looker | Preview | |
| DB ゼロ ETL | Spanner Columnar Engine（200x 高速化） | GA |
| BigQuery ↔ AlloyDB Query Federation | GA | |
| AlloyDB Lakehouse Federation | Preview | |
| Reverse ETL | Preview |
Gemini 系のアシスティブ機能が、BigQuery や Looker の 既存料金に含まれる（追加課金なし） のも見逃せないポイントです。
C. 他社戦略との比較
| 観点 | Snowflake | Databricks | AWS | |
|---|---|---|---|---|
| エージェント基盤 | MCP ネイティブ、GA 最速 | Cortex Agents（2025-11 GA） | Mosaic AI Agent Framework | Bedrock AgentCore |
| セマンティック層 | Knowledge Catalog で自動化 | Cortex Analyst（手動寄り） | Unity Catalog + Genie | Glue（弱い） |
| Lakehouse | BigQuery + Iceberg、Cross-Cloud | Iceberg + Polaris（自社完結寄り） | Delta 中心、Iceberg 互換 | S3 + Lake Formation |
| OLTP 統合 | AlloyDB / Spanner と zero-ETL | OLTP 非保有 | OLTP 非保有 | Aurora Zero-ETL |
| 垂直統合 | TPU → Gemini → BigQuery → Looker まで自社 | IaaS 依存 | IaaS 依存 | 分散（Redshift / Athena / EMR） |
Google の差別化ポイントは、Knowledge Catalog によるセマンティクス自動付与 と、ハードウェア（TPU）から UI（Looker）まで一気通貫の垂直統合 です。
一方、データシェアリングや Marketplace のエコシステムでは Snowflake に分がある、という構図になります。
情報源
- Agentic Data Cloud の新機能（日本語公式）
- Architecting the Agentic Data Cloud / System of Action
- The Future of Data Lakehouse for the Agentic Era
- Introducing the Google Cloud Knowledge Catalog
- Unveiling New BigQuery Capabilities for the Agentic Era
- Google Cloud Next '26 Keynote (YouTube) — Agentic Data Cloud セクションは 0:49:44〜