GoogleはAIが企業で失敗し続ける問題を解決するために、データアーキテクチャを再設計した
長年にわたり、大企業におけるデータチームとAIチームは、まるで別々の国の部門のように機能してきた。前者はデータウェアハウス、カタログ、パイプラインを構築し、後者はモデル、API、エージェントをデプロイしていた。両者の世界は、手動エクスポート、断続的なプロセス、そして「もう一方のチームが何とかしてくれる」という根拠のない信頼によって辛うじてつながっていた。その結果は予測可能なものだった。AIエージェントが本番環境に投入されると、自律的な機械が読み取り、解釈し、行動できるよう誰も準備していなかったデータの前で、あっけなく機能不全に陥ったのである。
Google Cloud Next 2026において、Googleはその機能不全を明確な言葉で言い表した。データプラットフォームとAIプラットフォームの分断こそが、自律型エージェントの企業展開における最大の障壁であると。Googleの回答が「エージェンティック・データクラウド（Agentic Data Cloud）」だ。これは既存の仕組みの上にAIの層を追加するのではなく、エージェントが企業データの第一級ユーザーとなれるよう、アーキテクチャの根幹そのものを再設計するという、データ基盤の抜本的な再構成である。
その野心の違いは決して小さくない。新しいコネクターや、自然言語で操作できるダッシュボードの話ではない。AWS、Azure、Google Cloudにデータを分散させているFortune 500企業が、すでに保有する情報をどのように管理・提供・収益化するかを根本から問い直す、構造的な再設計の話なのだ。
経営幹部が目を背けたがる診断
不都合なデータがある。本ローンチに伴う調査研究によれば、企業の約70%がデータインフラの欠陥を発見するのはエージェントをデプロイした後であり、前ではない。これは技術的な問題ではない。技術的な装いをまとったリーダーシップの問題だ。
断片化され、ガバナンスも整わず、複数のクラウドのサイロに閉じ込められたデータは、一夜にして生まれたわけではない。それは、拙速な意思決定、統合が不十分だった企業買収、そして「ビジネスはまだ動いている」という理由でデータの実際のアーキテクチャについての困難な議論を先送りし続けてきた、ごく人間的な組織的傾向の積み重ねによって、長年かけて蓄積されてきたものだ。機能しなくなるまで、それは続く。
Googleが発表したアーキテクチャは、互いに独立してはいない六つのコンポーネントで構成されており、順序的な論理を持つシステムを形成している。その基盤となるのがマルチクラウド・データレイクハウスだ。オープンフォーマットであるApache Icebergの上に構築されており、BigQueryがAWS S3やAzure ADLSに保存されたデータを、移動や複製なしに直接クエリできる。これにより、エグレスコストやコピー間の不整合リスクが排除される。その基盤の上で動作するのがApache Spark向けLightningエンジンだ。C++で実装されたベクトル化実行レイヤーであり、従来のSparkの最大4.9倍のパフォーマンスを発揮する。データが単にアクセス可能なだけでなく、エージェントがSparkコードを継続的なサイクルで生成・実行・修正してもコストが急騰しない速度で処理できるようになる。
その実行インフラの上に、文脈的インテリジェンスの層として位置づけられるのがナレッジカタログだ。2026年4月10日に発表されたDataplex Universal Catalogの進化版である。このコンポーネントこそが、企業アーキテクトが最も注目すべきものだろう。このカタログは、データチームが手動でアセットをカタログ化することを必要としない。クエリログを調べ、テーブルをプロファイリングし、Lookerのようなツールのセマンティックモデルを分析し、非構造化ファイルからエンティティ間の関係を抽出する。その結果として生まれるのが、自動的に維持される動的なナレッジグラフだ。これはエージェントが行動する前に必ず解決しなければならない問いに答える。どんなデータが存在し、それが正確に何を意味し、信頼できるものかどうか、という問いに。
ストレージが受動的であることをやめるとき
データの運用上の構造を最も根本的に変えるのが、現在プレビュー中のインテリジェント・ストレージだ。これまでは、Google Cloud Storageのバケットにファイルが入ると、誰かが処理を決定するまでそのファイルは不活性なままだった。この機能によって、ファイルがバケットに到着した瞬間に、システムが自動的にそれにタグを付け、エンベディングを生成し、関連するエンティティを抽出し、ナレッジカタログにリンクさせる。PDF、契約書、サポートチケット、音声録音——エンジニアが何も手を加えることなく、すべてが検索可能なアセットへと変わる。
非構造化データの準備プロジェクト——「6ヶ月かかる」と言われてきた、抽出・OCR・インデックス化・カタログ化を要するプロジェクト——を先送りしてきた経営幹部にとって、これは時間とコストの方程式を、もはや快適に先延ばしできない形で再構成する。かつてはエグゼクティブスポンサー、専用予算、不確かな納期を伴うプロジェクトだったものが、ストレージポリシーの自動的な帰結となるのだ。
Gemini 3.1 Proをベースとしたディープ・リサーチ・エージェントは、このインフラ全体のターミナルなユースケースを示している。ナレッジカタログとレイクハウスの内部ソースとインターネット上のオープンソースを組み合わせて動作し、構造化されたリサーチプランを生成し、検証可能な引用付きのレポートを数分で提供する。競合インテリジェンス、ライフサイエンス、金融サービスといった分野でアナリストが1〜3週間かけていた作業が、終着点ではなく出発点になるのだ。
データ・エージェント・キットは、開発者側からこの全体像を補完する。事前設定済みのMCPツールと三つの専門エージェントを提供する。一つ目は自然言語の指示をマネージドパイプラインに変換し、BigQuery、dbt、Spark、Airflowの中から適切なものを選択するエージェント。二つ目はデータサイエンスモデルの完全なサイクルを自動化するエージェント。三つ目はインフラの可観測性に特化したエージェントだ。モデル・コンテキスト・プロトコル（MCP）は相互運用性のレイヤーとして機能し、Gemini、Claude、独自モデルなど、どのプロバイダーのエージェントも、カスタムコネクターなしにデータアセットにアクセスできるようにする。
マルチクラウドは不満の源から、アーキテクチャの決断へと変わる
Fortune 500の企業の中で、Google Cloudだけで運用しているところは一社もない。SAP、Salesforce、Workday、OracleのシステムはAWSとAzureに分散している。それはCTOのメモ一枚で解決できない、歴史的・契約的・運用的な理由によるものだ。長年にわたり、マルチクラウドはあらゆるスケールのAIイニシアチブを前進させない口実として繰り返し使われてきた。「まずデータを統合する必要がある」と。
マルチクラウド・データレイクハウスは、この議論を技術的な具体性をもって解体する。IcebergのREST Catalog、マルチクラウド・インターコネクト、インテリジェントキャッシュレイヤーを使用することで、BigQueryはAWS S3やAzure ADLSのデータを、Google Cloudのネイティブデータと同等のレイテンシとコストでクエリできる。調達担当のエージェントは、S3に保存された契約データ、Azureの在庫データ、BigQueryのトランザクション記録を、統一されたIcebergカタログ配下で単一のクエリに組み合わせることができる。エンジニアリングチームがクラウド間のETLプロセスを管理する必要は一切ない。
インテグレーションアーキテクトにとって、この含意は戦略的なオーダーのものだ。議論は「すべてを一つのクラウドに移行するにはどうするか」ではなく、「すでに持っているデータ分散の上で、単一のカタログをどのようにガバナンスするか」へと変わる。それは同じ議論ではない。前者は、成熟した組織の大多数において政治的・財政的に法外なコストを伴う。後者は、既存の他プロバイダーとの契約を破壊することなく実行可能だ。
Googleが全体として提案していることは、技術的なアーキテクチャを超えた組織的影響を伴うパラダイムシフトだ。エージェントのガバナンスレイヤーとしてのMCPは、今日APIゲートウェイに適用されるのと同じ規律で管理される必要がある。バージョニング、認証、モニタリング、使用量制限だ。ナレッジカタログはドキュメンテーションのプロジェクトであることをやめ、リアルタイムの運用上の依存関係となる。それはサービスレベル契約、継続的なメンテナンス、そしてデータチームがいまだ設計していない運用モデルを意味する。
組織の文化とは、会議室に飾られたポスターでもなく、年次大会でのCEOのスピーチでもない。それは、決断するより先延ばしする方が楽だったとき、責任を取るより委任する方が安全だったとき、技術的負債のせいにする方が、データのアーキテクチャが権力・恐怖・経営陣が持つ勇気のなさゆえに持ちえなかった議論のアーキテクチャを外科的な精度で映し出していると認めるより簡単だったときに、リーダーたちが下したすべての決断の積み重ねなのだ。
