はじめに
Google Cloudでデータ基盤を作ろうとしてサービス一覧を見ると、
- BigQuery
- Cloud Storage
- Pub/Sub
- Dataflow
- Datastream
- Looker
- Vertex AI
- Knowledge Catalog
と、多くのサービスが登場します。結局どれを、どこで使えばいいの？
となりやすい領域なので、Google Cloudでデータ利活用基盤を構築する場合の主要サービスを、
収集 → 蓄積 → 加工 → 分析 → 可視化 → AI活用
というデータの流れに沿って整理してみます。
細かな仕様をすべて説明するというより、Google Cloudのデータ系サービスの全体像をざっくり掴むこと、体系的に理解することを目的にします。
全体像
Google Cloudでデータ利活用基盤を作る場合、以下のような構成を考えられます。
実際には要件によって構成は大きく変わりますが、
データを集める
↓
保存する
↓
使いやすい形に加工する
↓
BigQueryで分析する
↓
Lookerで可視化する
↓
AI / MLでも利用する
という流れがスタンダードであると理解すると分かりやすいと思います。
1. データを集める
まず必要になるのが、各システムからデータを集める仕組みです。データソースとしては例えば、
- 業務Database
- Web Application
- SaaS
- IoT Device
- Application Log
- CSV / JSON
- 外部API
などがあります。データの種類によって、収集方法も変わります。
Pub/Sub：リアルタイムのEventを集める
ApplicationやIoTなどから発生するEventをリアルタイムで扱う場合に使うのがPub/Subです。
Pub/SubはPublisherとSubscriberを疎結合にするMessaging Serviceで、例えばECサイトで、
- 商品閲覧
- 商品購入
- カート追加
- ログイン
といったEventが発生するとします。
アプリ側は、このEventを誰がどう分析するかを意識せず、Pub/SubへMessageを送り、後続のDataflowなどがMessageを受信して処理します。リアルタイム分析の入口として覚えておくと分かりやすいサービスです。
Datastream：Databaseの変更を取り込む
既存Databaseからデータを取り込みたい場合には、Datastreamも選択肢になります。DatastreamはCDC（Change Data Capture）を利用したServerless Replication Serviceです。
例えば、
Application
↓
PostgreSQL
で動いているシステムがあったとします。Analyticsのために毎回Database全体をコピーするのではなく、
INSERT
UPDATE
DELETE
などの変更を継続的に取得してBigQueryへ反映できます。
つまり、業務Databaseはそのまま使いながら、分析用DataをBigQueryへ持っていくという構成を作れるわけです。
2. データを蓄積する
データを集めたら、次は保存します。Google Cloudでよく登場するのが、
- Cloud Storage
- BigQuery
です。
Cloud Storage：生データ保存
Cloud StorageはObject Storageで、例えば、
- CSV
- JSON
- Parquet
- 画像
- 動画
- Log
- Backup
などをオブジェクトとして保存できます。データ基盤では、Rawデータをまず置いておく場所として使われることがあります。
加工前のデータを残しておけることがメリットで、加工処理に問題があったとしても、Rawデータが残っていれば再処理することが可能で、主にこれらの管理に使われます。
BigQuery：分析の根幹
Google Cloudのデータ基盤で中心になりやすいのがBigQueryです。現在GoogleはBigQueryを単なるData Warehouseではなく、AI-ready Data Platformとして位置付けています。
BigQueryはServerless Architectureで、Infrastructureを自分で管理せず、大規模DataをSQLやPythonなどから分析できます。
例えば、
SELECT
region,
SUM(sales) AS total_sales
FROM
sales
GROUP BY
region
ORDER BY
total_sales DESC;
のようなSQLで、大量のデータを分析できます。
3. データを加工する
収集したデータは、そのまま分析できるとは限りません。
例えば、
{
"id": "1001",
"price": "1000",
"timestamp": "2026/10/09 10:00:00"
}
というデータを、
型を変換する
不要Columnを削除する
MasterデータとJoinする
Aggregateする
異常データを除外する
といった処理が必要になることがあります。そこで登場するのがDataflowです。
Dataflow：BatchとStreamingのData Processing
Dataflowは、BatchとStreamingの両方を扱えるManaged Data Processing Serviceです。
Apache Beamをベースとしており、
というPipelineを作れます。例えば、
Pub/Sub
↓
Dataflow
↓
BigQuery
で、リアルタイムに流れてくるEventを加工してBigQueryへ保存できます。
Dataflow
Data Processingには大きく、1日分のデータを夜間にまとめて処理するバッチ処理と、データが来たらほぼリアルタイムで処理するストリーミング処理があります。Dataflowは、この両方をApache Beamという共通のモデルで扱えるのが特徴です。
ちなみにDataflowの作成にコーディング知識は必須ではなく、Dataflowは、現在はJob Builderも提供されており、Google Cloud Consoleから視覚的にパイプラインを構築することができ、
Pub/Sub
↓
Filter
↓
SQL Transform
↓
BigQuery
といった処理をUIから構成できます。簡単なものであればテンプレートも利用できます。
4. データを分析する
蓄積・加工したデータはBigQueryで分析します。ここまでは従来のData Warehouseと近い世界です。ただ、現在のBigQueryはかなり機能が増えています。
- SQL Analytics
- BigQuery ML
- AI Functions
- Vector Search
- BigQuery Graph
- Geospatial
- Search
などがあります。Dataを保存してSQLを実行する場所というより、Enterpriseデータを中心にAnalytics / ML / AIを実行するPlatformという立ち位置にへ広がっているように見えます。
5. データを可視化する
分析結果をBusiness Userへ提供するためには、可視化も重要です。Google CloudではLookerがあります。
Lookerは、
- Business Intelligence
- Dashboard
- Data Application
- Embedded Analytics
などを提供するPlatformです。
例えば営業データなら、
- 売上
- 利益
- 案件数
- 受注率
- 地域別実績
などをDashboardとして表示するようなものを非エンジニアでもサクッと作ることが出来ます。
6. Machine Learning
BigQueryにDataが集まると、このDataから予測したいという需要が出てきます。Google Cloudでは、
- BigQuery ML
- Vertex AI
などを利用できます。
BigQuery ML
BigQuery MLではSQLを使ってMachine Learning Modelを作れます。
考え方としては、
BigQuery Data
+
SQL
↓
Machine Learning
です。Data Analystなど、普段SQLを利用している人がMachine Learningを始める際に利用しやすい選択肢です。
Vertex AI
より本格的なAI / ML Platformとして使われるのがVertex AIです。
Vertex AIでは、
- Model Development
- Training
- Model Registry
- Deployment
- MLOps
- Generative AI
- Gemini
- AI Application
などを扱えます。
現在はTraditional MLだけでなく、Geminiを利用したGenerative AI Applicationの構築もVertex AIの大きな領域になっています。
7. Governance
データ基盤で意外と後回しになりやすいのがGovernanceです。データが増えてくると、
- このTableは何？
- 誰がOwner？
- どのSystemから来た？
- このColumnには個人情報が入っている？
- どのDashboardで使われている？
- このDataは信頼できる？
という問題が出てきます。
そこで登場するのが、現在のKnowledge Catalogです。
Knowledge Catalogとは？
Knowledge Catalogは、以前Dataplex Universal Catalogと呼ばれていたサービスです。
2026年5月にKnowledge Catalogへ名称が変更されています。
現在は単なるData Catalogではなく、Enterprise DataにBusiness ContextとGovernanceを与えるプラットフォームとして位置付けられています。
例えば、
- Metadata
- Data Lineage
- Data Quality
- Business Glossary
- Data Discovery
- Access
などを扱います。
例えばAI Agentへ、「今月売上が減少した理由を調べて」と聞くとします。
Agentは、
- どのTableを見る？
- 売上とは何？
- Customerとは何？
- どのDataが正しい？
- 誰がOwner？
を理解しなければなりません。そこでKnowledge Catalogが持つ、
Technical Metadata
+
Business Context
+
Data Lineage
+
Semantic Information
が重要になります。
GoogleはKnowledge Catalogを、AI AgentをEnterprise TruthにGroundingするためのContext Engineという方向でも展開しています。
全体整理
ここまでのサービスを、役割ごとに整理すると以下になります。
| Layer | 主なService | 役割 |
|---|---|---|
| Data Source | Application / DB / SaaS | 元データ |
| Ingestion | Pub/Sub | Event / Streaming |
| Replication | Datastream | CDC |
| Raw Storage | Cloud Storage | Object / Raw Data |
| Processing | Dataflow | ETL / Batch / Streaming |
| Analytics | BigQuery | DWH / Analytics |
| BI | Looker | Visualization / Semantic Model |
| ML / AI | BigQuery ML / Vertex AI | Prediction / AI |
| Governance | Knowledge Catalog | Metadata / Context / Governance |
最初から全部入れる必要はない
データ利活用基盤というと、以下が大体開発の候補として挙がるのですが、実際には目的に応じて始めればよいと思います。
- Data Lake
- ETL
- Streaming
- DWH
- Data Catalog
- ML
- BI
- AI
を全部作りたくなります。
まず分析したい
CSV
↓
Cloud Storage
↓
BigQuery
↓
Looker
Databaseのデータを分析したい
Operational DB
↓
Datastream
↓
BigQuery
↓
Looker
リアルタイム分析したい
Application
↓
Pub/Sub
↓
Dataflow
↓
BigQuery
↓
Looker
AIまで利用したい
Enterprise Data
↓
BigQuery
↓
Vertex AI / Gemini
↓
Application / Agent
というように段階的に拡張できます。
「データを集める」がゴールではない
データ基盤を考えると、とにかくData Lakeへ集めることが目的になってしまうことがあります。
しかし、本来重要なのはその先です。
Businessの達成したい目的があり、そのために必要なDataを集めるのがData Platformだと思います。
少し前は、Dataを人間が分析するための基盤だったものが、人間とAI Agentの両方がDataを利用する基盤としての機能に変わりつつあります。お金もかかるので、開発する際には目的感を持ってスモールスタートで始めるのが良いのではないでしょうか。