Googleが2026年11月4日に発表したAgentic Data Cloudの更新は、企業内のデータを一つのクラウドに集約せず、複数の環境に置いたままAIエージェントが使えるようにすることを目指しています。中核となるのは、Apache Icebergを基盤とする「Borderless Lakehouse」と、データに業務上の意味や定義を与える「Knowledge Catalog」です。410

ただし、機能によって提供状況は異なります。また、クロスクラウドでデータにアクセスできることは、あらゆる追加料金がなくなることや、エージェントが業務を安全に遂行できることを意味しません。

データを集約せずに照会する「Borderless Lakehouse」

GoogleはBorderless Lakehouseを、オープンなApache Iceberg形式を使った、ガバナンス付きのデータ基盤として説明しています。Lakehouseのドキュメントでは、Icebergを分析やAIに向けた統一インターフェースの基盤として位置づけています。41 Googleの製品情報は、データを移動させずにクラウドをまたいで照会・活用する構想を掲げ、発表を取り上げた報道はAWSやAzure上のデータをクエリできると伝えています。153

これは、分析の前にデータを中央のウェアハウスへコピーする方式とは異なります。データをその場所で照会できれば、システム間のコピーだけを目的としたデータ連携処理を減らせる可能性があります。ただし、実際の利用には接続、権限、データ形式、関連サービスなどの設定が必要です。

「一般提供」は全機能の提供状況を示すものではない

Googleの製品ページでは、Borderless Lakehouseは一般提供（GA）とされています。11 一方で、すべての連携機能が同じ段階にあるわけではありません。Lakehouseの概要ページによると、AWS Glue、Databricks Unity Catalog、Snowflake Horizonとのカタログフェデレーションはプレビュー段階です。10 また、Google CloudからDatabricks Unity Catalogのデータを照会するためのクロスクラウド接続について、Googleのドキュメントが案内しています。

そのため、製品全体がGAであることを根拠に、すべてのクラウド連携やフェデレーション機能が一般提供済みと解釈するのは適切ではありません。AWS・Azureのプライベート接続やキャッシュの詳細、SAP、Workday、Salesforceとのゼロコピー連携については、今回確認できる資料だけでは裏付けられません。

Knowledge Catalogがデータに「業務上の意味」を与える

テーブルにアクセスできるだけでは、その指標が何を意味するのか、どの定義を組織として採用しているのか、データ同士がどう関係するのかまでは分かりません。GoogleはKnowledge Catalogを、エージェントがデータを解釈するための業務コンテキストを整える仕組みとして位置づけています。11月の発表では、Borderless Lakehouseと連携し、クラウド上に分散したデータや非構造化データを索引化して、エージェントにコンテキストを提供するとしています。4

Googleは、利用者やエージェントとのやり取りからコンテキストの不足を見つける「自己学習型コンテキスト拡充」と、データ管理者がその内容を確認・探索する「Knowledge Studio」もプレビューとして紹介しています。19 これらはコンテキストを管理する機能であり、それだけでエージェントが業務プロセスを安全に実行できることを示すものではありません。

Gemini Enterpriseのリリースノートでは、Data CloudコネクタのフェデレーションクエリーモードとKnowledge Catalog連携がプレビューとして案内されています。対象のコネクタを接続すると、AssistantでKnowledge Catalogが有効になり、利用者がアクセス権を持つデータを検索する読み取り専用ツールや、技術的・業務的なコンテキストを取得する機能が使えます。17 これは範囲が明示された連携であり、Geminiに関するより広い機能のすべてを確認するものではありません。

転送料金の主張と、実際の総コストは分けて考える

Googleのクロスクラウド構想は、データを移動せずにアクセスすることを前面に出しています。発表を扱った報道では、AWSやAzure上のデータを変動型のデータ転送料金なしで照会できると説明されています。153 ただし、今回確認できる発表やドキュメントの抜粋からは、あらゆるリモートクラウドの料金がなくなるとは判断できず、個別の処理にかかる総費用を算定する材料も十分ではありません。

また、talabatでデータ移動コストが約40％下がったという報告や、その数字の根拠となるAmazon S3のIcebergデータとBigQueryの具体的な構成も、ここで確認できる資料では裏付けられていません。仮にデータ移動費の削減が確認できたとしても、それだけでクエリー全体や、エージェントがタスクを完了するまでの総コストも同じ割合で下がるとは言えません。

AlloyDBなどの更新と、Spanner Omniの位置づけ

発表を取り上げた報道は、Knowledge Catalogに加えてAlloyDBやBigQueryにも更新があるとしています。3 ただし、AlloyDBがIcebergの過去データと稼働中のPostgreSQL運用データを直接結合できるという具体的な機能は、今回の資料からは確認できません。

Spanner Omniは、Googleのデータ戦略に関連する別の更新です。Googleは2026年9月30日に一般提供を発表し、オンプレミスや他のクラウドにも展開できる分散型のマルチモデルデータベースとして説明しました。そのため、11月4日に初めてGAになった機能ではありません。20

今回の発表が示すこと、まだ示していないこと

確認できる範囲で言えるのは、Googleがクロスクラウドのデータアクセス基盤と、AIアシスタントやエージェント向けの共有コンテキストを組み合わせようとしていることです。これにより、エージェントが関連情報を探し、組織内で一貫した定義を使うことを支援できます。41719

一方、データへのアクセスと業務上のコンテキストだけでは、エージェントが業務プロセスを安全に実行できるとは限りません。権限管理、結果の検証、トランザクション処理、監査、失敗時の復旧、そしてタスク完了までの総コストについては、別の根拠が必要です。今回の資料には、アナリストの評価やMicrosoft、Databricks、Snowflake、AWSとの比較を確認するのに十分な情報もありません。

つまり、今回の発表はGoogleのプラットフォーム戦略を示すものです。自律的な業務実行の安全性や費用対効果については、データアクセスとコンテキスト機能の説明だけで結論づけず、追加の検証が必要です。

Googleが2026年11月4日に発表したAgentic Data Cloudの更新は、企業内のデータを一つのクラウドに集約せず、複数の環境に置いたままAIエージェントが使えるようにすることを目指しています。中核となるのは、Apache Icebergを基盤とする「Borderless Lakehouse」と、データに業務上の意味や定義を与える「Knowledge Catalog」です。410

ただし、機能によって提供状況は異なります。また、クロスクラウドでデータにアクセスできることは、あらゆる追加料金がなくなることや、エージェントが業務を安全に遂行できることを意味しません。

データを集約せずに照会する「Borderless Lakehouse」

GoogleはBorderless Lakehouseを、オープンなApache Iceberg形式を使った、ガバナンス付きのデータ基盤として説明しています。Lakehouseのドキュメントでは、Icebergを分析やAIに向けた統一インターフェースの基盤として位置づけています。41 Googleの製品情報は、データを移動させずにクラウドをまたいで照会・活用する構想を掲げ、発表を取り上げた報道はAWSやAzure上のデータをクエリできると伝えています。153

これは、分析の前にデータを中央のウェアハウスへコピーする方式とは異なります。データをその場所で照会できれば、システム間のコピーだけを目的としたデータ連携処理を減らせる可能性があります。ただし、実際の利用には接続、権限、データ形式、関連サービスなどの設定が必要です。

「一般提供」は全機能の提供状況を示すものではない

Googleの製品ページでは、Borderless Lakehouseは一般提供（GA）とされています。11 一方で、すべての連携機能が同じ段階にあるわけではありません。Lakehouseの概要ページによると、AWS Glue、Databricks Unity Catalog、Snowflake Horizonとのカタログフェデレーションはプレビュー段階です。10 また、Google CloudからDatabricks Unity Catalogのデータを照会するためのクロスクラウド接続について、Googleのドキュメントが案内しています。

そのため、製品全体がGAであることを根拠に、すべてのクラウド連携やフェデレーション機能が一般提供済みと解釈するのは適切ではありません。AWS・Azureのプライベート接続やキャッシュの詳細、SAP、Workday、Salesforceとのゼロコピー連携については、今回確認できる資料だけでは裏付けられません。

Knowledge Catalogがデータに「業務上の意味」を与える

テーブルにアクセスできるだけでは、その指標が何を意味するのか、どの定義を組織として採用しているのか、データ同士がどう関係するのかまでは分かりません。GoogleはKnowledge Catalogを、エージェントがデータを解釈するための業務コンテキストを整える仕組みとして位置づけています。11月の発表では、Borderless Lakehouseと連携し、クラウド上に分散したデータや非構造化データを索引化して、エージェントにコンテキストを提供するとしています。4

Googleは、利用者やエージェントとのやり取りからコンテキストの不足を見つける「自己学習型コンテキスト拡充」と、データ管理者がその内容を確認・探索する「Knowledge Studio」もプレビューとして紹介しています。19 これらはコンテキストを管理する機能であり、それだけでエージェントが業務プロセスを安全に実行できることを示すものではありません。

Gemini Enterpriseのリリースノートでは、Data CloudコネクタのフェデレーションクエリーモードとKnowledge Catalog連携がプレビューとして案内されています。対象のコネクタを接続すると、AssistantでKnowledge Catalogが有効になり、利用者がアクセス権を持つデータを検索する読み取り専用ツールや、技術的・業務的なコンテキストを取得する機能が使えます。17 これは範囲が明示された連携であり、Geminiに関するより広い機能のすべてを確認するものではありません。

転送料金の主張と、実際の総コストは分けて考える

Googleのクロスクラウド構想は、データを移動せずにアクセスすることを前面に出しています。発表を扱った報道では、AWSやAzure上のデータを変動型のデータ転送料金なしで照会できると説明されています。153 ただし、今回確認できる発表やドキュメントの抜粋からは、あらゆるリモートクラウドの料金がなくなるとは判断できず、個別の処理にかかる総費用を算定する材料も十分ではありません。

また、talabatでデータ移動コストが約40％下がったという報告や、その数字の根拠となるAmazon S3のIcebergデータとBigQueryの具体的な構成も、ここで確認できる資料では裏付けられていません。仮にデータ移動費の削減が確認できたとしても、それだけでクエリー全体や、エージェントがタスクを完了するまでの総コストも同じ割合で下がるとは言えません。

AlloyDBなどの更新と、Spanner Omniの位置づけ

発表を取り上げた報道は、Knowledge Catalogに加えてAlloyDBやBigQueryにも更新があるとしています。3 ただし、AlloyDBがIcebergの過去データと稼働中のPostgreSQL運用データを直接結合できるという具体的な機能は、今回の資料からは確認できません。

Spanner Omniは、Googleのデータ戦略に関連する別の更新です。Googleは2026年9月30日に一般提供を発表し、オンプレミスや他のクラウドにも展開できる分散型のマルチモデルデータベースとして説明しました。そのため、11月4日に初めてGAになった機能ではありません。20

今回の発表が示すこと、まだ示していないこと

確認できる範囲で言えるのは、Googleがクロスクラウドのデータアクセス基盤と、AIアシスタントやエージェント向けの共有コンテキストを組み合わせようとしていることです。これにより、エージェントが関連情報を探し、組織内で一貫した定義を使うことを支援できます。41719

一方、データへのアクセスと業務上のコンテキストだけでは、エージェントが業務プロセスを安全に実行できるとは限りません。権限管理、結果の検証、トランザクション処理、監査、失敗時の復旧、そしてタスク完了までの総コストについては、別の根拠が必要です。今回の資料には、アナリストの評価やMicrosoft、Databricks、Snowflake、AWSとの比較を確認するのに十分な情報もありません。

つまり、今回の発表はGoogleのプラットフォーム戦略を示すものです。自律的な業務実行の安全性や費用対効果については、データアクセスとコンテキスト機能の説明だけで結論づけず、追加の検証が必要です。