はじめに
当記事は、先日開催された Google Cloud Next Tokyo 2025 の中で行われたセッションのレポートとなります。
タイトル：データ基盤チームに休日を。データ活用を支える BigQuery と Data Product
登壇：Google Cloud 村上 祐磨氏
セッション概要
本セッションでは、生成AIの登場によるデータ分析の敷居が下がったことや中央集権的なデータ管理の体制によるデータ基盤チームが直面する課題を解決し、より全社的なデータ活用を促進するため、Data Mesh、Data Product、Data Contracts という3つの考え方とそれらを実現するための Google Cloud のサービスをご紹介いただきました。この考え方を導入することで、データ基盤チームは本来の創造的業務に集中でき、組織全体のデータ活用もより効率的に推進することが可能です。
データ基盤チームが多忙となる理由
データ基盤チームが多忙になりがちな理由として、大きく2つが挙げられていました。
- 生成AIの登場
- データ分析の敷居が下がり、誰もがデータにアクセスできるようになった。
- データの正確性やリソース管理といったマネジメントやガバナンスの重要性が増加し、データ分析チームの責任は重くなる。
- 中央集権的なデータ管理
- データを生み出す事業部門 (プロデューサー) とデータ利用者 (コンシューマー) の間にデータ基盤チームが位置し、双方からのコミュニケーションの起点となる。
- 利用者からはデータの内容についての問い合わせがあり、事業部門からは追加の連携等の依頼がある。
- データ基盤チームはデータを生成するプロセスには関わっていないため、データに関する問題の根本解決はできない。
- データを生み出す事業部門 (プロデューサー) とデータ利用者 (コンシューマー) の間にデータ基盤チームが位置し、双方からのコミュニケーションの起点となる。
データ基盤チームをボトルネックにしないデータアーキテクチャ
ボトルネック状況を打破するための解決策として、Data Mesh、Data Product、Data Contracts という3つのキーワードが紹介されました。
これらは相互に関連し、データ活用を促進するものです。
Data Mesh
- 概要
- 従来の中央集権的なアプローチから脱却し、データに関するオーナーシップを中央のデータ基盤チームではなく、データを最もよく理解しているドメイン (事業部門) へ移譲する分散型アーキテクチャの考え方。
- データ基盤チームは個別のデータ問い合わせから解放され、全体的な監査・ガバナンスや共通基盤やソリューションの提供といった、より専門性の高い横断的な役割に集中できるようになる。
- Google Cloud での実装例
- 各事業ドメインが自身の BigQuery プロジェクト内でデータを保持し、BigQuery Sharing (旧 Analytics Hub) を通じて他ドメインと共有。
- 組織全体のデータカタログとしては、Dataplexのデータカタログ (Dataplex Universal Catalog) を活用。
- 利用者は SQL や Spark、Notebook、Dashboard、スプレッドシート等目的にあったツールで分析。
- データ基盤チームは BigQuery Monitoring や組織ポリシーでガバナンスを管理。
Data Product
- 概要
- Data Mesh の考え方に基づき、各ドメインが利用者がそれ単体で分析を開始できる価値ある「製品」としてデータを提供するという考え方。
- 単なるデータ本体だけでなく、利用者が迷わずに安心して使えるようにパッケージ化された概念であり、以下の要素を含む必要がある。
- メタデータ・ドキュメント
- スキーマ情報。
- カラムやテーブルの説明。
- 分析例 (具体的なSQLクエリ例、Notebook、分析フロー (Data Canvas 等) 。
- 品質基準
- データ品質とテスト結果 (特定のカラムはNullを許容しない、値の範囲の説明等) 。
- 提供に関する保証 (SLO、RTO) 。
- データへのアクセスの担保
- データへのアクセス権 (from SQLEngine、Spark 等) 。
- エージェント。
- データカタログを通じた検索機能。
- 権限管理方法。
- メタデータ・ドキュメント
- Google Cloud での実装例
- BigQuery へのデータ格納、Data Quality によるデータ品質チェック、メタデータ登録 (Dataplex Universal Catalog)、BigQuery Sharing を介したデータ利用。
- 分析例の共有は、Query Templates や Notebooks、Canvas 等で実施。
- データ基盤チームは上記実装の展開や組織のガバナンスを管理。
- Data Product は Data Contracts を満たしていることが重要。
- 各サービスの紹介
- BigQuery Sharing
- 物理的にデータのコピーを作ることなく組織内外で、安全にデータセットを共有したり検索するための機能。
- Data Exchange と Data Clean Room という2つの方法がある。
- Data Clean Room を使うと、元データを露出させることなく、集計や突合、集計した結果のエクスポートなどに制約をつけた状況でデータを共有することができる。
- Data Exchange では、生データを直接共有することができる。
- Data Canvas
- GUIベースでSQL クエリを生成し、クエリとその結果を樹形図的に整備していくためのツール。
- 分析プロセスの全体をマインドマップ的に整理することができ、データの分析フローの共有に役立つ。
- Canvas Assistant (自然言語で Data Canvas を操作するエージェント) も使用可能。
- Conversational Analytics
- 対話形式でデータ分析ができる機能。
- 特定のデータに特化したエージェントを作成し共有することができ、ドキュメントの代わりとして使用可能。
- Query Templates
- 共有したデータに対して実行できるクエリを事前定義テンプレートに限定することで、分析を制限することができる機能。
- Dataplex Universal Catalog
- データの検索や各種ドメイン情報を管理する機能。
- Metadata Generation の機能によりカラムやテーブルのディスクリプションなどを整備する際に自動生成することも可能になり、人間が整備する時間がない際に利用。
- Data Quality
- NULL の可否や値はの上限や下限等のチェックルールをGUIベースで作成でき、データがその実態に即しているのかを検査できる機能。
- ロードマップとしては、データのアノマリー検知を自動化する機能 (Data Anomaly Detection) があり、売上などの異常な上昇や減少も検知できるようになる予定。
- Data Products
- 組織のデータを Data Product としてコンテナ化し共有することが可能。
- 今後提供予定。
- BigQuery Sharing
Data Contracts
- 概要
- データ仕様を、人間だけでなく機械ないしスクリプトも理解できるよう整備したもの。
- スキーマ情報、データ品質基準、更新頻度などを明記し、API 経由でアクセス可能にすることで、品質チェックや権限管理の自動化・コード化が可能となる。
- 利用パターン
- Data Product 側が Data Contracts に基づき Validation を行い、利用者はその Contracts を信頼してデータを利用。
- Data Product の品質が不十分な場合や、利用者側で極めて高い品質が求められる場合、Contracts を基に利用者側で Validation を生成・実行。
- Google Cloud での実装例
- Contracts の提供は Dataplex Universal Catalog や Data Quality で実装可能。
- Validation は Data Quality のルールを基に実行可能。
アーキテクチャだけでは改善できないこととその対応
これらの仕組みを導入しても、ボトルネックがデータ基盤チームから事業ドメイン内部に移動するだけという可能性もあるとのことです(事業ドメイン内部のデータ担当が事業ドメイン内部のビジネス担当とデータ利用者の板挟みになる)。
これを解決するためには2つの方針があります。
- データ担当者が事業ドメインで最もビジネスを理解するプロフェッショナルになること。
- ビジネス担当者が Data Engineering Agent、Data Preparation、Cloud Data Fusion など、AI や GUI ベースのツールを活用してデータ整備のタスクの一部を担うこと。
このような体制の整備は、全社一斉導入は避け、一部のドメインで小規模に試行し、少しずつ導入を拡大していくのが良いとのことです。
おわりに
本セッションで提唱された Data Mesh、Data Product、Data Contracts という考え方は、データ基盤チームが抱える課題に対する解決策を提示しており、Google Cloud ではそれを実装するための具体的なサービスも提供されているため、実現が可能だと感じました。ただし、アーキテクチャで全てを解決できるわけではなく、事業ドメイン内部の体制整備も重要になるとのことで、技術的な観点と組織体制的な観点の両方からのアプローチが必要という点が学びになりました。
簡単30秒