クラウドDWH入門｜BigQuery/Snowflakeで営業データ基盤を構築する

クラウドデータウェアハウス（DWH）は、営業データ基盤の中核を担うインフラである。CRM、MA、CSツールに散在するデータを一箇所に集約し、SQLで横断的に分析できる状態を作る——これがクラウドDWHの役割だ。営業データ基盤構築の記事でアーキテクチャ全体像を解説したが、本記事ではそのストレージレイヤーにあたるクラウドDWHにフォーカスし、BigQueryとSnowflakeを中心に選定基準・スキーマ設計・CRM連携・運用のポイントをGTMエンジニア向けに体系的に解説する。

クラウドDWHとは何か——CRMとの違い

クラウドDWHは「分析に特化したデータの集約基盤」であり、CRMとは設計思想が根本的に異なる。

CRMはSalesforceやHubSpotに代表される業務システムだ。営業担当者が日々の商談を記録し、パイプラインを管理するために使う。データの書き込み（INSERT/UPDATE）に最適化されており、「今この商談はどのステージにあるか」をリアルタイムに把握するのが得意である。一方で、「過去1年間のリードソース別×業界別の受注率推移」のような大量データの横断分析にはCRM単体では限界がある。

クラウドDWHはこの分析ニーズに応える。複数のデータソースから抽出したデータを格納し、カラム指向ストレージと分散処理エンジンにより、数億行規模のデータでも数秒〜数十秒でクエリ結果を返す。CRMデータ設計で定義したデータ構造をそのまま分析基盤に引き継ぎつつ、マーケティングデータやプロダクト利用データと統合できるのがDWHの強みだ。

つまり、CRMは「業務を回す」ためのシステム、DWHは「意思決定する」ためのシステムである。この2つを組み合わせることで、営業組織のデータ活用は完成形に近づく。

BigQueryとSnowflake——2大クラウドDWHの特性比較

営業データ基盤で採用されるクラウドDWHの中で、現時点で最も有力な選択肢はGoogleのBigQueryとSnowflakeの2つだ。それぞれの特性を比較する。

BigQuery

BigQueryはGoogle Cloudが提供するサーバーレスDWHである。最大の特徴は「インフラ管理が不要」という点だ。クラスターのサイジングやチューニングを一切意識することなく、SQLを書くだけで分析が始められる。

• 課金モデル: クエリの処理データ量に対する従量課金（オンデマンド）。月1TBまでの無料枠あり
• ストレージ: 月10GBまで無料。以降は$0.02/GB/月（アクティブストレージ）
• 強み: Google Cloud内の他サービス（Looker Studio、Cloud Functions、Vertex AI）とのネイティブ統合。学習コストが低い標準SQL
• 適する組織: Google Workspace利用企業、50名以下の営業チーム、最小構成から段階的にスケールしたい組織

営業データの規模が月間数百万行以下であれば、BigQueryの無料枠の範囲内で運用できるケースも多い。「まずは無料で始めてみる」が可能な点が、小規模組織にとっての最大のメリットだ。

Snowflake

Snowflakeはマルチクラウド（AWS・GCP・Azure）で動作するDWHである。最大の特徴はコンピュート（処理能力）とストレージ（データ保管）の完全分離アーキテクチャだ。

• 課金モデル: コンピュート（クレジット課金）とストレージ（容量課金）が独立。コンピュートは自動停止・自動スケールに対応
• 強み: データシェアリング（社外とのデータ共有）、Time Travel（過去データの復元）、マルチクラウド対応
• 適する組織: 100名以上の営業組織、マルチクラウド環境、パートナー企業とのデータ共有が必要な場合

Snowflakeのウェアハウス（コンピュートリソース）は使わない時間は自動で停止し、課金も止まる。夜間や週末にクエリを実行しない営業データ基盤では、この仕組みが大きなコスト削減につながる。

どちらを選ぶか——判断基準

選定の判断基準はシンプルだ。

1. クラウド環境: Google Cloud中心ならBigQuery、AWS/Azure中心ならSnowflake
2. 組織規模: 50名以下の営業チームはBigQueryの無料枠から開始が合理的
3. データ共有: 社外パートナーとのデータ共有が必要ならSnowflake
4. コスト予見性: 固定費を抑えたいならBigQueryのオンデマンド、予算を確定したいならSnowflakeのクレジット購入

迷ったらBigQueryから始めてよい。営業データの規模であれば、移行の判断は後からでも遅くない。

スキーマ設計——営業データをDWHにどう格納するか

DWHを選定したら、次はスキーマ設計だ。CRMのデータ構造をそのままDWHにコピーするのではなく、分析に最適化した構造に変換する必要がある。

レイヤード・アーキテクチャの採用

営業データ基盤のDWHでは、3層のスキーマ構造を推奨する。

Raw層（生データ）: CRMやMAツールから抽出したデータをそのまま格納するレイヤー。カラム名もデータ型もソースシステムのまま保持する。ELTの「Load」にあたる部分だ。

-- BigQueryの例: rawスキーマ
CREATE SCHEMA raw_hubspot;
CREATE SCHEMA raw_salesforce;
CREATE SCHEMA raw_marketo;

Staging層（加工・統合）: Raw層のデータをクレンジング・名寄せ・型変換して格納するレイヤー。ここで複数ソースのデータを共通スキーマに統一する。

-- Staging層: 商談テーブルの統合例
CREATE TABLE staging.deals AS
SELECT
  deal_id,
  CAST(amount AS NUMERIC) AS amount,
  LOWER(TRIM(stage_name)) AS stage_name,
  DATE(created_at) AS created_date,
  DATE(closed_at) AS close_date,
  owner_email,
  'hubspot' AS source_system
FROM raw_hubspot.deals;

Mart層（分析用）: ビジネスロジックを適用した最終的な分析テーブル。BIツールやSQLクエリから参照されるのはこのレイヤーだ。SQLで営業企画を変えるで紹介したクエリは、このMart層のテーブルに対して実行する想定になっている。

-- Mart層: パイプラインサマリービュー
CREATE VIEW mart.pipeline_summary AS
SELECT
  DATE_TRUNC(created_date, MONTH) AS month,
  stage_name,
  COUNT(*) AS deal_count,
  SUM(amount) AS total_amount,
  AVG(DATE_DIFF(CURRENT_DATE(), created_date, DAY)) AS avg_age_days
FROM staging.deals
WHERE close_date IS NULL
GROUP BY 1, 2;

この3層構造を採用する理由は、変更の影響範囲を局所化するためだ。CRMのスキーマ変更はRaw層だけに影響し、Staging層の変換ロジックを修正すればMart層とBIツールには影響しない。

ディメンション設計のポイント

営業データ分析で頻出するディメンション（分析軸）は以下の通りである。

• 時間: 日次・週次・月次・四半期ごとの集計
• 営業担当者: パフォーマンス分析、活動量分析
• リードソース: チャネル別ROI分析
• 業界・企業規模: セグメント別の受注傾向
• 商品・プラン: 商材別の売上構成分析

これらのディメンションテーブルをMart層に事前定義しておくと、新しい分析要件が出ても既存のディメンションとファクト（商談・活動量等）をJOINするだけで対応できる。営業KPI設計で定義した指標体系を、そのままMart層のテーブル設計に落とし込むのが理想形だ。

CRM・MAツールからDWHへのデータ連携

スキーマ設計が固まったら、データソースからDWHへのデータ連携パイプラインを構築する。

ELTツールによるノーコード連携

現在のデータ連携はELT（Extract → Load → Transform）が主流だ。まずデータソースからDWHのRaw層に生データをロードし、DWH上でSQLによる変換を行う。

主要なELTツールは以下の3つである。

• Fivetran: 500以上のコネクタ。HubSpot、Salesforceとの連携は公式サポート。設定は画面操作のみで完結するが、料金はMAR（Monthly Active Rows）課金で規模が大きくなるとコストが上がる
• Airbyte: オープンソース版あり。セルフホストすればコストを抑えられる。コネクタ数は300以上で、カスタムコネクタの作成も可能
• Stitch Data: Talend傘下のELTサービス。シンプルな設定とリーズナブルな価格が特徴

50名以下の営業組織であれば、Airbyteのオープンソース版をDocker環境で動かすのがコスト最適解だ。HubSpotやSalesforceのコネクタは標準で用意されており、15分のクイックスタートガイドに従うだけでデータ連携が始められる。

Webhook連携との組み合わせ

ELTツールによるバッチ連携に加え、リアルタイム性が求められるデータにはWebhookを活用する。たとえば「商談ステージが変更された瞬間にDWHに反映したい」場合は、CRMのWebhookイベントをCloud Functions（BigQuery）やSnowpipe（Snowflake）で受信し、Raw層に即座に書き込む構成が有効だ。

ただし、営業データ基盤の大半のユースケースでは日次バッチ連携で十分である。リアルタイム連携は要件を見極めたうえで段階的に追加するのがよい。

dbtによる変換レイヤーの管理

Raw層からStaging層・Mart層への変換ロジックは、dbt（data build tool）で管理することを推奨する。dbtはSQLベースの変換ツールで、以下のメリットがある。

• SQLファイルでモデル（テーブル/ビュー）を定義し、Gitでバージョン管理できる
• テストを定義してデータ品質を自動チェックできる（NULL検知、ユニーク制約、参照整合性）
• ドキュメントが自動生成され、テーブル間の依存関係が可視化される

BigQueryでもSnowflakeでもdbtはネイティブに対応しており、営業データ基盤の変換レイヤーのデファクトスタンダードとなっている。

コスト管理と運用設計

クラウドDWHは従量課金が基本であり、設計を誤ると予想外のコストが発生する。運用段階で押さえるべきポイントを整理する。

BigQueryのコスト最適化

BigQueryのコストは「クエリ処理量」と「ストレージ量」の2軸で決まる。

• パーティショニング: 日付カラムでテーブルをパーティション分割する。WHERE created_date >= '2026-01-01' のようなフィルタ条件で読み取りデータ量を大幅に削減できる
• クラスタリング: 頻出フィルタカラム（stage_name、owner_email等）でクラスタリングを設定する。I/Oが最小化され、クエリコストが下がる
• 定額料金プラン: 月間クエリ量が予測可能な場合は、Editions（定額）プランへの切り替えでコストを平準化できる

Snowflakeのコスト最適化

Snowflakeのコストはコンピュートの「ウェアハウスサイズ×稼働時間」で決まる。

• 自動サスペンド: ウェアハウスの自動停止を5分に設定する。営業レポートのクエリは通常数秒で完了するため、5分のアイドル後に自動停止すれば無駄なコストを防げる
• ウェアハウスの分離: BIツール用（小規模・常時稼働）とアドホック分析用（中規模・必要時のみ起動）でウェアハウスを分ける。負荷の干渉を防ぎつつコストを最適化できる
• リソースモニター: 月間クレジット上限を設定し、超過時にアラート通知またはウェアハウスの自動停止を行う

アクセス制御

営業データには個人情報や商談金額など機密性の高い情報が含まれる。DWHのアクセス制御は以下の原則で設計する。

• ロールベースアクセス制御（RBAC）: 「営業マネージャー」「営業企画」「データアナリスト」などのロールを定義し、ロール単位でテーブル・ビューへのアクセス権を付与する
• カラムレベルマスキング: 顧客のメールアドレスや電話番号など、分析には不要だがRaw層には存在するPII（個人識別情報）は、Staging層以降でマスキングまたは除外する
• クエリログの監査: 誰がいつどのテーブルにアクセスしたかを記録し、定期的にレビューする

導入ロードマップ——4週間で営業DWHを立ち上げる

最後に、50名以下の営業組織がクラウドDWHを4週間で導入するロードマップを示す。

Week 1: 設計

• 分析要件の洗い出し（営業レポーティング自動化で定義したKPIが出発点）
• DWH選定（本記事の判断基準に基づく）
• スキーマ設計（Raw → Staging → Mart の3層）

Week 2: データ連携

• ELTツール（Airbyte推奨）のセットアップ
• CRMからRaw層への初回データロード
• 日次バッチスケジュールの設定

Week 3: 変換・分析

• dbtプロジェクトの構築（Staging層・Mart層のモデル定義）
• 営業データ分析で必要な指標テーブルの作成
• BIツール（Looker Studio / Metabase）との接続

Week 4: 運用整備

• アクセス制御の設定
• コストモニタリングのアラート設定
• データ品質テスト（dbt test）の実装
• 運用ドキュメントの整備

4週間はあくまで最小構成の目安だ。重要なのは「完璧な基盤を最初から作ろうとしない」ことである。まずCRMの商談データだけをDWHに連携し、1つのダッシュボードを動かす。その小さな成功体験が、データ基盤への組織的な投資を正当化する最大の武器になる。

---

クラウドDWHは営業組織のデータ活用を根本的に変えるインフラだ。CRMだけでは見えなかった横断的なインサイトが、SQLを書くだけで手に入るようになる。BigQueryの無料枠から始めれば初期投資はゼロに近い。まずはCRMのデータをDWHに流し込み、SQLで1本クエリを書くところから始めてほしい。その一歩が、データドリブンな営業組織への転換点になる。