Agentic Data Cloudとは？AIエージェント時代のデータ基盤をGoogle Cloud発表から整理
Agentic Data Cloudは、Google CloudがCloud Next '26で打ち出した、AIエージェント時代のデータ基盤アーキテクチャです。従来のデータ基盤が「人が分析するためにデータを集める場所」だったのに対し、Agentic Data Cloudは「AIエージェントが業務文脈を理解し、必要なデータを探し、判断し、業務システムに働きかけるための基盤」として位置づけられています。
Agentic Data Cloudは単体の新製品名というより、Google CloudのBigQuery、Knowledge Catalog、Looker、Spanner、AlloyDB、Cloud SQL、Managed Service for Apache Spark、MCP、Gemini Enterpriseを、AIエージェントが安全に使える形へ束ねる構想です。導入を考えるときは、AI機能そのものより、業務定義、データ権限、データ鮮度、監査ログ、マルチクラウド接続がエージェントに渡せる状態かを先に見る必要があります。
本記事のポイント
- Agentic Data Cloudは単体ツールではなく、AIエージェントが業務文脈つきでデータを扱うための基盤設計である。
- 中核はKnowledge Catalogによる業務定義、Data Agent Kitによる開発者体験、Cross-cloud Lakehouseによる分散データ接続である。
- 導入前に見るべきなのはAI機能の多さではなく、権限、データ品質、指標定義、監査ログをエージェントに渡せる状態かである。
この記事で扱うテーマ
このページで答える質問
- Agentic Data Cloudとは何か？
- Google CloudのAgentic Data Cloudは何を発表したのか？
- AIエージェント時代のデータ基盤では何を整えるべきか？
- SnowflakeやMicrosoft Fabricなどのデータ基盤と何が違うのか？
Agentic Data Cloudとは何か
Google Cloudは2026年4月23日の公式発表で、Agentic Data Cloudを「静的なリポジトリから動的な reasoning engine へ進化するAI-native architecture」と説明しています。背景にあるのは、生成AIが質問に答える段階から、AIエージェントがデータを読んで業務を実行する段階へ移っていることです。
たとえば、営業担当者が「今週優先すべき既存顧客を出して」と聞くだけなら、従来のBIや自然言語検索でも近いことはできます。しかしAIエージェントが、売上履歴、問い合わせ履歴、契約更新日、担当者の活動ログ、過去提案書、Slackやメールのやり取りを見て、優先順位を決め、CRMにタスクを作るところまで進むと、単なる分析基盤では足りません。AIエージェントによる業務自動化では、データの意味、権限、鮮度、実行先が同時に問われます。
Google Cloudが言うAgentic Data Cloudの中心は、次の3つです。
| 構成要素 | 役割 | 導入時に見るポイント |
|---|---|---|
| Knowledge Catalog | 業務定義、メタデータ、意味関係、検索権限をエージェントに渡す | 指標定義、データ所有者、権限、リネージが整理されているか |
| Data Agent Kit | 開発者やデータ担当者がエージェント経由でパイプラインや分析を作る | dbt、Spark、Airflowなどの既存ワークフローと衝突しないか |
| Cross-cloud Lakehouse | AWS、Azure、Snowflake、Databricksなどに分散したデータを扱う | データ移動、egress cost、権限継承、監査ログが破綻しないか |
つまり、Agentic Data Cloudは「BigQueryの新機能」だけではありません。Google Cloudのデータ、アプリケーション、AI、ネットワーク、ガバナンスを、エージェント実行を前提に再配置する考え方です。
なぜ従来のデータ基盤では足りないのか
従来のデータ基盤は、多くの場合、人間がダッシュボードやSQLを見て判断することを前提に作られてきました。更新頻度が日次でも、定義が部署ごとに違っていても、人間が最後に確認するなら運用で吸収できることがあります。
しかしAIエージェントは、同じ曖昧さを高速に拡大します。売上、粗利、商談、既存顧客、解約リスク、優先リードといった言葉の定義が揃っていないと、エージェントは正しい列を選べず、間違った結論を自信ありげに返します。AIエージェントのガバナンスでは、この「それらしいが根拠が弱い判断」を止める仕組みが重要になります。
Google Cloudはこの課題を、System of IntelligenceからSystem of Actionへの転換として説明しています。System of Intelligenceは、過去のデータを集め、可視化し、人が意思決定するための仕組みです。一方でSystem of Actionは、エージェントが業務データを理解し、判断し、実行まで進めることを前提にします。
この違いは、次のように整理できます。
| 観点 | 従来のデータ基盤 | Agentic Data Cloud型の基盤 |
|---|---|---|
| 主な利用者 | 人間の分析者、経営者、現場マネージャー | 人間とAIエージェントの両方 |
| 中心機能 | 集計、可視化、レポート、予測 | 業務文脈の検索、権限付き取得、実行、監査 |
| 前提データ | 構造化データが中心 | 構造化データ、非構造化文書、業務ログ、リアルタイムデータ |
| 失敗時のリスク | 人が見て違和感に気づけることがある | 誤った判断が自動実行まで進む可能性がある |
| 重要な統制 | BI権限、データ品質、レポート管理 | エージェント権限、文脈評価、操作ログ、実行境界 |
AIエージェントが社内データにアクセスするなら、プロンプトの工夫だけでは不十分です。どのデータにアクセスできるか、どの指標定義を使うか、どの操作を許可するかを、データ基盤側で制御する必要があります。
中核になるKnowledge Catalogの役割
Google Cloudの発表で特に重要なのが、Dataplexを発展させたKnowledge Catalogです。Google CloudはKnowledge Catalogを、エンタープライズ全体の「universal context engine」と位置づけています。従来のデータカタログがテーブル名やスキーマを管理するものだったのに対し、Knowledge Catalogは業務意味、関係性、利用実態、検索権限まで含めてエージェントに文脈を渡すことを狙っています。
実務では、ここが一番重要です。AIエージェントに「売上が落ちそうな顧客を出して」と依頼したとき、エージェントは売上テーブルだけを見ればよいわけではありません。契約更新日、問い合わせ増加、担当者変更、未対応タスク、直近の提案内容、サポート履歴などをつなぎ、さらに「売上」「解約リスク」「重要顧客」の社内定義を理解する必要があります。
Knowledge Catalogが担う論点は、次の3つに分けると理解しやすくなります。
- 集約: BigQuery、AlloyDB、Spanner、Cloud SQL、Looker、SAP、Salesforce Data360、ServiceNow、Workdayなどのメタデータや業務文脈を集める
- 意味づけ: スキーマ、利用ログ、BI定義、非構造化ファイルから、データが業務上何を意味するかを補う
- 検索と権限: エージェントが必要な文脈を探すとき、アクセス権限に沿って信頼できる情報だけを返す
この発想は、AIエージェントの権限設計と直結します。AIエージェントに「全部見せる」のではなく、役割、業務、データ分類、実行権限に応じて、探せる情報と実行できる操作を分ける必要があります。
Data Agent KitとCross-cloud Lakehouseで何が変わるか
Agentic Data Cloudのもう1つのポイントは、データ担当者の働き方を変えようとしている点です。Google CloudはData Agent Kitを、VS Code、Gemini CLI、Codex、Claude Codeなど、開発者が普段使う環境に入るスキルやツール群として説明しています。狙いは、新しい画面を増やすことではなく、既存の開発環境からデータパイプライン、分析、検証をエージェントに依頼できる状態を作ることです。
たとえば「この顧客データを商談化率分析に使える形へ整えて」と依頼したとき、エージェントがdbt、Spark、Airflow、BigQuery Dataframesなどの候補から適切な道具を選び、ガバナンスルールに沿ってコードや変換処理を作る、という方向です。これはデータエンジニアの仕事がなくなるというより、手作業のSQLやパイプライン作成から、エージェントの成果物をレビューし、運用ルールを設計する役割へ寄ることを意味します。
Cross-cloud Lakehouseは、データがGoogle Cloud内だけにない企業向けの構成です。Google Cloudの発表では、Apache Icebergを軸に、AWSやAzure上のデータ、Snowflake Polaris、Databricks Unity Catalog、AWS Glue Data Catalogなどとの連携が示されています。現実の企業では、CRMはSalesforce、分析はBigQuery、部門別のデータはSnowflake、機械学習はDatabricks、日々の業務はGoogle Workspaceというように、データが分散していることが普通です。
Google WorkspaceとCRMをつなぐ運用でも同じですが、エージェント活用で重要なのは、データを無理に一か所へ移すことではありません。どのデータをどこで管理し、どの文脈だけをエージェントに渡し、どの実行先へ戻すかを設計することです。
競合データ基盤との違いをどう見るか
Agentic Data Cloudを理解するときは、Snowflake、Databricks、Microsoft Fabric、Salesforce Data 360などの動きと並べると分かりやすくなります。どのベンダーも、データ基盤をAIエージェントの実行基盤へ広げようとしています。
| 基盤 | 強み | 注意点 |
|---|---|---|
| Google Cloud Agentic Data Cloud | BigQuery、Looker、Gemini、MCP、Knowledge Catalog、cross-cloud lakehouseを一体で設計しやすい | Preview機能も多く、既存データ統制が弱いと価値が出にくい |
| Snowflake AI Data Cloud | Snowflake IntelligenceやCortex系の機能で、Snowflake内のデータ活用とエージェント体験を強化しやすい | Snowflake外の operational data と実行系をどうつなぐかを設計する必要がある |
| Databricks Data Intelligence Platform | Unity Catalog、Lakehouse、Mosaic AI、Agent BricksなどでデータサイエンスとAI開発に強い | 業務ユーザーの自然言語体験やCRM実行系は別途設計が必要になりやすい |
| Microsoft Fabric | OneLake、Power BI semantic model、Fabric Data Agent、Microsoft 365連携で業務利用に近い | Microsoft 365中心でない企業では、既存SaaSや他クラウドとの接続設計が重要になる |
| Salesforce Data 360 | CRM、顧客データ、Agentforceを同じ業務文脈で扱いやすい | 営業・CS以外の全社データや分析基盤との役割分担を明確にする必要がある |
比較で大切なのは、どれが最も新しいかではありません。自社のデータがどこにあり、AIエージェントに何をさせたいかで、評価軸が変わります。営業や顧客接点の実行が中心ならCRM側の基盤が重要になり、全社横断の分析とマルチクラウド接続が中心ならGoogle CloudやSnowflake、Databricksの設計が重要になります。
導入前に点検すべき5つの論点
Agentic Data Cloudのような構想を検討するとき、最初に製品比較表を作ると失敗しやすくなります。AIエージェントが本当に業務で動くかどうかは、既存データの整い方に左右されるためです。
| 点検項目 | 確認すること | 不十分な場合のリスク |
|---|---|---|
| 業務定義 | 売上、商談、既存顧客、休眠、解約リスクなどの定義が部署間で揃っているか | エージェントが似た列を誤って使い、判断がぶれる |
| 権限 | 人間の権限をエージェントにも継承できるか | 見てはいけないデータを検索したり、操作してはいけない業務に進む |
| データ鮮度 | 日次、時間単位、リアルタイムのどれが必要か | 古いデータで優先順位や次アクションを決めてしまう |
| 監査ログ | エージェントが何を見て、何を判断し、何を実行したか追えるか | 誤操作や誤判断の原因を説明できない |
| 例外処理 | 人が確認すべき判断境界が決まっているか | 自動化しすぎて、現場が信用しなくなる |
特にBtoB営業やマーケティングでは、顧客データ、商談履歴、メール、会議メモ、広告、Web行動、サポート履歴が分散しがちです。Agentic Data Cloudの導入価値は、エージェントに「全部のデータを触らせる」ことではなく、信頼できる文脈だけを安全に渡すことにあります。
いま取り組むなら小さく始める
2026年5月時点では、Agentic Data Cloud関連の機能にはGAとPreviewが混在しています。そのため、いきなり全社データ基盤を置き換えるより、1つの業務シナリオに絞って検証するのが現実的です。
たとえば、次のようなユースケースから始めると、データ基盤側の不足が見えやすくなります。
- 営業マネージャー向けに、更新リスクの高い既存顧客を毎週抽出する
- マーケティング施策ごとの商談化率を、広告、Web、CRMのデータから説明する
- 問い合わせ履歴と契約情報をもとに、サポート優先度を提案する
- 会議メモ、提案書、CRM活動ログから、次回商談の準備メモを作る
この段階で見るべき成果は、AIがきれいな文章を返すかではありません。必要なデータにアクセスできたか、根拠を示せたか、権限を守れたか、人が確認すべき行を分けられたか、実行ログが残ったかです。
参照した公式情報
本記事は、2026年5月11日時点で公開されている以下の一次情報をもとに整理しています。
- Google Cloud: What's new in the Agentic Data Cloud
- Google Cloud: Architecting the Agentic Data Cloud
- Google Cloud: Introducing the Google Cloud Knowledge Catalog
- Google Cloud: The future of data lakehouse for the agentic era
- Microsoft Learn: Fabric data agent
- Snowflake: Snowflake Intelligence and Cortex Code
よくある質問
Agentic Data CloudはGoogle Cloudの新製品ですか？
単体製品というより、Google Cloudのデータ、AI、ガバナンス、マルチクラウド接続をAIエージェント向けにまとめるアーキテクチャ構想です。個別にはKnowledge Catalog、Data Agent Kit、BigQuery、Looker、Spanner、AlloyDB、MCPなどが関わります。
従来のデータウェアハウスやBIとは何が違いますか？
従来の基盤は、人が分析して判断する前提が中心でした。Agentic Data Cloud型の基盤は、AIエージェントが業務文脈を探し、判断し、実行先へつなぐことを前提にします。そのため、権限、業務定義、監査ログ、リアルタイム性の重要度が上がります。
中小企業でも検討すべきですか？
大規模なマルチクラウド基盤をすぐ導入する必要はありません。ただし、AIエージェントに顧客データや営業データを扱わせたいなら、指標定義、データ権限、CRMとの接続、ログ管理は早めに整える価値があります。
まず何から始めるべきですか？
最初は1つの業務シナリオを選び、必要なデータ、権限、判断ルール、人の確認境界を棚卸しします。たとえば既存顧客の更新リスク検知や、商談準備メモの作成など、成果とリスクが見えやすい業務から始めるのが現実的です。
SnowflakeやDatabricksを使っている場合は乗り換えが必要ですか？
必ずしも乗り換えではありません。重要なのは、既存のSnowflake、Databricks、Microsoft Fabric、Salesforceなどのデータ基盤を、AIエージェントの文脈、権限、実行、監査にどう接続するかです。Agentic Data Cloudは、その設計を考えるための比較軸としても使えます。
AIエージェント導入の前提を整理したい場合
AIエージェントを業務に入れるには、プロンプトやモデル選定だけでなく、データの置き場、権限、業務定義、実行ログの設計が必要です。ファネルAiでは、既存の営業・マーケティング業務を起点に、エージェントが使えるデータ基盤と運用フローの整理を支援します。
