今回の重要キーワードの1つが Agentic Data Cloud です。

これは一言でいうと、データ基盤を「分析のためのもの」から「AIが行動するための基盤（System of Action）」へ進化させるアーキテクチャです。

従来は、人間がデータを分析し意思決定していましたが、AIエージェントが業務を自律的に行うようになると、データをもとに判断し、そのまま業務を実行します。

そのためGoogle Cloudは、

• データの意味を統合するメタデータ管理
• クラウドを横断したデータ連携
• AIが直接アクションできる仕組み

といった要素を組み合わせ、
AIが安全かつ正しく動けるデータ基盤の構築を打ち出しました。

こうした全体方針の中で、BigQueryの役割も明確に変化してきていると感じました。

現地セッションや発表を踏まえ、特に重要だと感じたポイントを3つに整理します。

①『DWH』から『AIネイティブなデータ基盤』へ

今回のBigQuery関連発表で印象的だったのは、単体機能の強化というよりも、データ基盤全体をAIエージェント前提で再構成している点です。

具体的には、

• メタデータ統合（Catalog / Dataplex）
• クロスクラウド対応（Cross-cloud Lakehouse）
• 非構造化データの統合

といった要素が組み合わされています。

特に重要なのは、AIエージェントが扱うデータの範囲です。

従来のような構造化データだけでなく、

• 商談メモ
• PDF資料
• 他クラウドのデータ

などを横断して「文脈」として理解する必要があります。

▶データ基盤としての変化

・従来：分析のためのデータ集約

・今後：AIが意思決定に使うためのデータ供給基盤

②『SQL基盤』から『意味定義済みデータ基盤』へ

個人的に最も重要だと感じたのがこの点です。

AIエージェント活用において本質的な課題は、SQLが書けることではなく、「意味を正しく理解できるか」です。

例えば「売上」という指標でも、

• 税込 or 税抜
• 出荷基準 or 受注基準

など、企業ごとに定義が異なります。

人間であれば会話で補正できますが、AIはそうはいきません。

そのため今後は、

• 指標定義（Semantic Layer）
• メタデータ管理
• 定義済みクエリ

といった仕組みが不可欠になります。

Google Cloudも今回、メタデータ管理を強化し、AIが“誤解しないデータ基盤”の重要性を明確に打ち出しているように感じました。

▶データエンジニアの役割の変化

・従来：テーブル設計、ETL構築

・今後：業務意味の設計、AIが誤解しないデータモデリング

このように、データエンジニアに求められるスキルが、ETLやスキーマ設計といった実装力に加え、業務定義や意味設計まで担う方向へと広がっていく可能性があります。

③『分析結果保存先』から『AIエージェント運用ログ基盤』へ

AIエージェントが本番運用されると、新たに必要になるのが、Agent Observability（エージェントの可視化）です。

具体的には、

• どんな問い合わせが来たか
• どのツールを呼んだか
• どのデータを参照したか
• どんな判断をしたか
• 成功 / 失敗

といったログの蓄積と分析が重要になります。

ここで非常に相性が良いのがBigQueryです。

• 推論ログ
• トークン使用量
• ツール呼び出し履歴
• 会話データ

などを集約し、継続的に分析する基盤として活用できます。

実際に、Agent Development Kit（ADK）では、

エージェントのインタラクションデータをBigQueryにエクスポートし、パフォーマンス・コスト・利用状況を分析できる仕組み

「BigQuery Agent Analytics」プラグインが提供されています。

▶BigQueryが担う役割

・従来：業務データ基盤

・今後：業務データ基盤＋AIエージェントそのものを監視・改善するための基盤

今回の発表を踏まえると、BigQuery活用は単なる分析基盤設計から一歩進み、AIが正しく理解し、安全に利用できる前提でのデータ設計が求められるようになります。

特に重要だと感じた論点は以下の3つです。

①業務意味まで含めたメタデータ整備

AIにとって重要なのは「データがあること」ではなく、そのデータが何を意味するかを一貫して理解できることです。

そのためには、以下のような整備が重要になります。

• KPI・指標の定義（例：売上の定義を明文化）
• カラム・テーブルのビジネス意味の記述
• 同義語や用語ゆれの統一（例：売上 / revenue / sales）
• 定義済みクエリやビューによる利用の標準化

特にAIエージェントは曖昧さに弱いため、「人にとって暗黙知だった業務ルールを明文化する」ことが重要になります。

②構造化・非構造化を横断したデータ設計

AIエージェントは、構造化データだけでなく、

• PDF・ドキュメント
• チャットログ
• 画像・音声

といった非構造化データも含めて判断します。

そのためBigQuery設計でも、

• Cloud Storage上のデータとの連携
• ドキュメントと構造化データの紐付け
• 同一IDでの横断参照設計（例：顧客ID）

といった、データ種別をまたいだ設計が重要になります。

従来のように「DWHは構造化だけ」という前提は崩れつつあります。

③AI利用を前提とした監視・ガバナンス設計

AIエージェントの利用が進むと、「何をしたか」を後から追えることが監視や改善のために非常に重要になります。

具体的には、

• AIが生成したクエリのログ
• 参照したデータセット
• ツール呼び出し履歴
• 推論結果とその成功/失敗

といった情報をBigQueryに蓄積し、分析できる状態が求められます。

また、

• アクセス制御（AIが触ってよいデータの範囲）
• マスキング・権限制御
• 誤利用の検知

といったガバナンス設計も不可欠になります。

Google Cloud Next’26を通して見えてきたのは、データ基盤の役割が確実に変わり始めているという点です。

これまでのBigQueryはデータを蓄積し、分析し、人が意思決定するための基盤でした。

これからはAIがデータを理解し、判断し、業務を実行することを前提とした「AIを動かすための基盤」へと進化していきます。

その中で重要になるのは、

• データの“意味”を定義すること
• AIが誤解しない構造で設計すること
• AIの挙動を継続的に監視・改善できること

といった観点です。

日本においては、AIエージェントの本格活用はまだこれからという印象もあります。
一方で、Google Cloud はこの領域への投資を加速しており、データ基盤の前提はすでに変わり始めています。

現地では「AIエージェント前提」の設計が当たり前のように語られていたことも踏まえると、このギャップをどう埋めていくかが今後の重要なテーマになりそうです。

まずは、AIが活用しやすいデータ設計へのシフトを意識することが、現実的な第一歩になるのではないかと考えています。

参加したセッション：

・Beyond the warehouse: Architecting BigQuery for the future of analytics

・Agent development and AgentOps with BigQuery, ADK, and MCP

・ What’s new in BigQuery: The data platform for agentic AI