エンタープライズのデータスタックは、決まった時間に実行されるクエリを行う人間のために作られてきました。AIエージェントが、24時間体制で企業を代わりに自律的に動くようになってくるにつれ、そのアーキテクチャは崩れ始めており、ベンダーはそれを作り直すために急いでいます。Googleが水曜日のCloud Nextで発表した答えが、Agentic Data Cloudです。
このアーキテクチャには3つの柱があります：
Knowledge Catalog。 意味論的メタデータのキュレーションを自動化し、データスチュワードによる手作業の介入なしに、クエリログからビジネスロジックを推定します
クロス クラウド・レイクハウス。 AWS S3上のIcebergテーブルを、プライベートネットワーク経由でBigQueryからクエリ可能にし、イグレス料金（アウトバウンド課金）を発生させません
Data Agent Kit。MCPツールをVS Code、Claude Code、Gemini CLIに投入し、データエンジニアがパイプラインを書くのではなく、アウトカムを記述できるようにします
「データのアーキテクチャは今変える必要があります」と、Google CloudのData Cloud担当VP兼GMであるAndi GutmansはVentureBeatに語りました。「私たちは、人間規模からエージェント規模へ移行しています。」
知能のシステムからアクションのシステムへ
Agentic Data Cloudの中核となる前提は、企業が人間規模の運用からエージェント規模の運用へ移っている、ということです。
これまでのところ、データプラットフォームは、レポーティング、ダッシュボード、そして一部の予測のために最適化されてきました。Googleが「reactive intelligence（反応型の知能）」と呼ぶモデルです。このモデルでは、人間がデータを解釈し、何をすべきかを判断します。
しかし今、AIエージェントがますますビジネスのために直接アクションを実行することが期待される中で、Gutmansは、データプラットフォームはアクションのシステムへ進化する必要があると主張しました。
「企業のデータをすべてAIで有効化できるようにしなければなりません。構造化データも非構造化データも含みます」とGutmansは述べました。「適切なレベルの信頼があることを確認する必要があります。つまり、それは単にデータへのアクセスを得ることだけではなく、データを本当に理解することでもあるのです。」
Knowledge Catalogは、その課題に対するGoogleの答えです。これはGoogleの既存のデータガバナンス製品であるDataplexの進化版ですが、その土台となるアーキテクチャは大きく異なります。従来のデータカタログでは、データスチュワードがテーブルに手作業でラベル付けし、ビジネス用語を定義し、グロッサリーを作り込む必要がありました。Knowledge Catalogは、それをエージェントを使って自動化します。
データエンジニアリングチームにとっての実務的な意味合いは、Knowledge Catalogが、少人数のデータスチュワードが手作業で維持できる「キュレーション済みの一部」だけでなく、データ資産全体にスケールすることです。このカタログはBigQuery、Spanner、AlloyDB、Cloud SQLをネイティブにカバーし、Collibra、Atlan、Datahubといったサードパーティのカタログともフェデレーションします。ゼロコピー・フェデレーションにより、SAP、Salesforce Data360、ServiceNow、WorkdayといったSaaSアプリケーションから、データの移動を必要とせずに意味的なコンテキストを拡張できます。
Googleのレイクハウスがクロス クラウド対応に
Googleは、2022年から、 BigLakeというデータレイクハウスを提供してきました。最初はGoogleのデータに限定されていましたが、近年では他の場所にあるデータに対して企業がクエリできるようにするため、限定的なフェデレーション機能が追加されてきました。
Gutmansは、従来のフェデレーションはクエリAPIを通じて行われていたため、BigQueryが外部データに対して発揮できる機能や最適化が制限されていたと説明しました。新しいアプローチは、オープンなApache Iceberg形式による、ストレージベースの共有です。つまり、データがAmazon S3にあるのか、Google Cloudにあるのかは、彼は「違いはない」と主張しています。
「これによって、第三者のデータセットに対して、あらゆる良さとAIの能力を持ち込めるということになります」と彼は述べました。
実務上の結果として、BigQueryは、GoogleのCross-Cloud Interconnect（専用のプライベート・ネットワーキング層）経由で、Amazon S3上に置かれたIcebergテーブルをクエリできます。イグレス料金はかからず、Googleが言うところでは、価格と性能の面でネイティブのAWSウェアハウスと同等です。すべてのBigQuery AI機能は、そのクロス クラウドのデータに対して、修正なしで実行されます。プレビュー段階の双方向フェデレーションは、S3上のDatabricks Unity Catalog、Snowflake Polaris、そしてAWS Glue Data Catalogにまで拡張されます。いずれもオープンなIceberg REST Catalog標準を用います。
パイプラインを書くことからアウトカムを記述することへ
Knowledge Catalogとクロス クラウドのレイクハウスは、データアクセスとコンテキストの課題を解決します。3つ目の柱は、データエンジニアが実際に、それらをすべて使って何かを作ろうと座ったときに起こることを扱います。
Data Agent Kitは、スキルのポータブルセット、MCPツール、IDE拡張として提供され、VS Code、Claude Code、Gemini CLI、Codexにそのまま投入できます。新しいインターフェースを導入するわけではありません。
それが可能にするアーキテクチャ上の転換は、Gutmansが「prescriptive copilot experience（指示型のコパイロット体験）」と呼んだものから、意図に基づくエンジニアリングへの移行です。ソースAからデスティネーションBへデータを移すためにSparkパイプラインを書くのではなく、データエンジニアはアウトカムを記述します。たとえば、モデル学習の準備ができたクリーンなデータセットや、ガバナンスルールを強制する変換です。するとエージェントが、それを実行するためにBigQuery、Apache Spark向けのLightning Engine、Spannerのどれを使うかを選び、その後、生産環境で使えるコードを生成します。
「顧客は、自分たちでパイプラインを作ることにうんざりしています」とGutmansは述べました。「コードを書くモードというより、レビューするようなモードのほうに本当にいます。」
Googleと競合が分かれるポイント
エージェントにはデータアクセスだけでなく意味的コンテキストが必要である、という前提は、市場全体で共有されています。
DatabricksにはUnity Catalogがあり、レイクハウス全体に対してガバナンスと意味的レイヤーを提供します。SnowflakeにはCortexがあり、AIと意味的レイヤーを提供します。 Microsoft Fabricには、ビジネスインテリジェンス向けに作られた意味モデル層が含まれており、さらにエージェントのグラウンディング（根拠付け）に向けてますます拡張されています。
論点は、セマンティクスが重要かどうかではありません。誰もが重要だと認めています。論点は、それを誰が構築し、誰が維持管理するのかです。
「私たちの目標は、可能な限り得られるセマンティクスをすべて集めることです」と彼は説明し、Googleは顧客に最初から作り直させるのではなく、サードパーティの意味モデルとフェデレートすると述べました。
またGoogleは、Databricks Unity CatalogやSnowflake Polarisへの双方向フェデレーションを、オープンなIceberg REST Catalog標準を通じて実現できることを、オープン性を差別化要因として位置付けています。
これが企業にとって意味すること
Googleの主張――そしてデータインフラ市場全体に広がっている主張――は、企業が3つの面で遅れを取っている、というものです：
意味的コンテキストがインフラになりつつある。 データカタログがまだ手作業でキュレーションされているなら、エージェントのワークロードにはスケールしません。そしてGutmansは、エージェントのクエリ量が増えるにつれて、そのギャップはさらに広がるだけだと主張しています。
クロス クラウドのイグレスコストは、エージェント型AIにとって見えにくい負担だ。オープンなIceberg標準によるストレージベースのフェデレーションが、Google、Databricks、Snowflakeにまたがるアーキテクチャ上の答えとして姿を現しつつあります。独自のフェデレーション手法にロックインされている企業は、それらのコストをエージェント規模のクエリ量でストレステストすべきです。
Gutmansは、パイプラインを書く時代が終わると主張する。 アウトカムベースのオーケストレーションに移行するデータエンジニアは、今すでに大きな先行優位を得られます。
