「CRMのレポート機能だけでは、経営が求めるクロスチャネルの分析ができない」「マーケ・営業・CSのデータを横串で見たいが、CRM単体では限界がある」「BigQueryやSnowflakeを導入したが、CRMデータとの連携設計がわからない」——こうした課題を抱える企業が増えています。
CRMに蓄積されたデータは、営業パイプラインや顧客情報の管理には最適です。しかし事業規模が拡大し、複数のSaaSやチャネルからのデータを横断的に分析したいフェーズでは、CRM単体のレポーティングでは限界が生じます。そこで必要になるのが、CRMとデータウェアハウス（DWH）を連携させた統合データ基盤の設計です。
本記事では、CRM × DWH連携の設計思想からBigQuery・Snowflakeとの具体的な統合アーキテクチャ、ETL/ELTの設計パターンまでを解説します。
CRM × DWH連携とは、CRMに蓄積された顧客データ・商談データ・活動ログを、BigQueryやSnowflakeなどのデータウェアハウスに集約し、他のデータソースと組み合わせて横断的な分析を可能にするデータアーキテクチャです。CRMのデータを「外に出す」のではなく、CRMを含む全社データを「一箇所に集めて分析する」という発想がポイントになってきます。
CRMのレポート機能は、CRM内のデータに閉じた分析には優れています。例えばパイプラインの進捗や、コンタクトのライフサイクル遷移、営業活動のKPIなどはCRM標準のレポートで十分対応できます。
しかし以下のようなケースでは、CRM単体では対応が難しくなります。
こうした分析ニーズが出てきたタイミングが、DWH連携を検討するトリガーになります。
DWH連携により、CRMデータは「営業の管理ツール」から「全社の意思決定基盤の一部」に昇格します。例えば、マーケティングのチャネル別ROI分析にCRMの商談データを組み合わせることで、「どのチャネルから来たリードが最も収益に貢献しているか」を正確に可視化できます。これは経営判断の精度を大きく高めるポイントです。
CRM × DWH連携のアーキテクチャは、大きく3つのレイヤーで構成されます。
| レイヤー | 役割 | 具体例 |
|---|---|---|
| データソース層 | 各SaaSからのデータ取得 | HubSpot、freee、Google Ads、プロダクトDB |
| ETL/ELTパイプライン層 | データの抽出・変換・ロード | Fivetran、Airbyte、Stitch、trocco |
| DWH + BIレイヤー | データの蓄積・変換・可視化 | BigQuery / Snowflake + Looker / Tableau / Metabase |
この3層構造の設計が結構ミソになってくるところで、「どこで何をやるか」の責務分担を明確にすることが、運用フェーズでの混乱を防ぐ鍵となります。
データパイプラインの設計では、ETL（Extract-Transform-Load）とELT（Extract-Load-Transform）の選択が重要です。
| 比較項目 | ETL | ELT |
|---|---|---|
| 変換タイミング | ロード前に変換 | ロード後にDWH上で変換 |
| 適するケース | データ量が限定的、変換ロジックが複雑 | 大量データ、DWHの計算能力を活用 |
| 代表ツール | Informatica、Talend | Fivetran + dbt、Airbyte + dbt |
| CRM連携の推奨 | — | ELTが現在の主流 |
CRMデータの連携においては、ELTアプローチが現在の主流です。CRMからデータをそのまま抽出してDWHにロードし、dbtなどの変換ツールでDWH上で加工する。この方式であれば、CRM側のAPIレート制限を最小限に抑えつつ、DWHの計算能力を最大限に活用できます。
BigQueryはGoogle Cloudのフルマネージドなデータウェアハウスで、サーバーレスで運用負荷が低いのが特徴です。
HubSpotとBigQueryの連携では、以下の方法が一般的です。
BigQueryの課金体系はストレージとクエリ実行量に基づくため、CRMデータのように構造化されたデータであればコスト効率が高いです。月間1TBまでのクエリは無料枠が適用されるため、中小企業のCRMデータ量であれば実質的なクエリコストはかなり抑えられるかなと思います。
Snowflakeはマルチクラウド対応のDWHで、コンピュートとストレージが分離されたアーキテクチャが特徴です。
HubSpotとSnowflakeの連携では、以下の方法があります。
Snowflakeのウェアハウス（コンピュートリソース）はスケールアップ/ダウンが柔軟なため、月末のレポーティング期間だけリソースを増やすといった運用が可能です。ただし、従量課金のコスト管理には注意が必要で、クエリの最適化やウェアハウスの自動サスペンド設定を適切に行うことがポイントになってきます。
| 比較項目 | BigQuery | Snowflake |
|---|---|---|
| クラウド基盤 | Google Cloud限定 | AWS / Azure / GCP対応 |
| 課金モデル | クエリ量 + ストレージ | コンピュート時間 + ストレージ |
| 小規模利用のコスト | 無料枠が大きい（月1TB） | 無料トライアル後は従量課金 |
| リアルタイム性 | ストリーミング挿入対応 | Snowpipe対応 |
| データシェアリング | BigQuery Data Exchange | Snowflake Marketplace（より成熟） |
| 推奨ケース | Google Cloud中心の企業、コスト重視 | マルチクラウド、大規模データ分析 |
自社のクラウド基盤がGoogle Cloudであれば BigQuery、AWS / Azureであれば Snowflakeが自然な選択です。ただし、企業様によって最適な選択は異なりますので、データ量・分析頻度・チームのスキルセットを総合的に判断いただくのがよいかなと思います。
まず、CRMからDWHに連携すべきデータを明確に定義します。全データを無条件に連携するのではなく、分析目的に基づいて必要なオブジェクトとプロパティを選定するのが結構重要です。
| HubSpotオブジェクト | 連携優先度 | 主な分析用途 |
|---|---|---|
| コンタクト | 高 | リードの属性分析、セグメンテーション |
| 会社 | 高 | アカウント単位の分析、業種別分析 |
| 取引 | 高 | パイプライン分析、売上予測、CAC/LTV |
| アクティビティ | 中 | エンゲージメント分析、営業活動の生産性 |
| マーケティングイベント | 中 | チャネル別ROI、キャンペーン効果測定 |
| チケット | 中〜低 | CS分析、チャーン予測の入力データ |
| ツール | 特徴 | HubSpot対応 | 価格帯 |
|---|---|---|---|
| Fivetran | フルマネージド、自動スキーマ管理 | ネイティブ対応 | 月$500〜 |
| Airbyte | OSS版あり、カスタムコネクタ作成可能 | ネイティブ対応 | OSS: 無料、Cloud: 月$300〜 |
| trocco | 日本製、日本語UI、サポート充実 | API経由で対応 | 月5万円〜 |
| Stitch | Talend傘下、シンプルなUI | ネイティブ対応 | 月$100〜 |
スモールスタートであれば、Airbyte（OSS版）+ dbt + BigQueryの構成がコスト面で優れています。組織が拡大してデータエンジニアリングの運用負荷を下げたい段階では、Fivetranのフルマネージドサービスに移行するという段階的なアプローチがおすすめです。
DWH上でのデータモデリングは、Star SchemaまたはSnowflake Schemaが一般的です。CRMデータの場合、以下のような構造が推奨されます。
dbtを使う場合は、staging → intermediate → mart のレイヤー構成で段階的にデータを変換します。stagingレイヤーでCRMの生データを正規化し、intermediateレイヤーでビジネスロジックを適用し、martレイヤーで最終的なレポーティング用テーブルを作成します。
DWHに集約したデータは、BIツールで可視化します。
| BIツール | 特徴 | DWH連携 | 価格帯 |
|---|---|---|---|
| Looker | Google Cloud統合、データモデリング機能 | BigQuery最適 | 要問い合わせ |
| Tableau | 可視化の自由度が高い | BigQuery / Snowflake対応 | 月$75〜/ユーザー |
| Metabase | OSS、軽量、導入が簡単 | BigQuery / Snowflake対応 | OSS: 無料、Cloud: 月$85〜 |
| Redash | OSS、SQLベースの分析に強い | BigQuery / Snowflake対応 | OSS: 無料 |
ここで1個ポイントになるのが、CRMのダッシュボード機能とBIツールの使い分けです。日常的な営業管理やパイプライン管理にはCRM標準のダッシュボードを使い、クロスチャネル分析や経営レポートにはBIツールを使うという棲み分けが合理的です。二重管理にならないよう、「どの指標をどこで見るか」を明確にルール化しておくことをおすすめします。
CRMの全オブジェクト・全プロパティをDWHに連携しようとすると、APIレート制限に抵触したり、DWHのストレージコストが膨らんだりします。分析目的に基づいて必要なデータだけを選定するのが鉄則です。
「リアルタイムでCRMの最新データが見たい」というリクエストは多いですが、多くのETL/ELTツールの同期間隔は最短でも5〜15分です。リアルタイム性が必要な用途（例：営業の即時アクション）にはCRM標準のダッシュボードを使い、DWHは分析・レポーティング用途に割り切るという判断が重要です。
DWH連携はCRMのデータ品質問題を増幅します。CRM上で名寄せや重複排除が不十分なままDWHに連携すると、分析結果の信頼性が損なわれます。CRM側のデータクレンジングが前提条件であることを忘れないでください。
DWH連携は「構築して終わり」ではありません。データモデルの変更、新しいデータソースの追加、BIダッシュボードのメンテナンスなど、継続的な運用が必要です。社内にデータエンジニアがいない場合は、運用負荷の低い構成（フルマネージドのETLツール + シンプルなBIツール）を選択するのが現実的です。
CRM × DWH連携は、すべての企業に必要なソリューションではありません。CRMの標準レポート機能で分析ニーズが満たされている段階であれば、DWH連携のコスト（ツール費用 + 構築工数 + 運用工数）は過剰投資になります。目安として、複数のデータソースを横断した分析が経営会議で定常的に求められるようになったタイミングが、DWH連携を検討する適切な段階かなと思います。
CRM × DWH連携の設計は、以下の流れで進めます。
まずはスモールスタートとして、CRMの取引データとマーケティングデータをBigQueryに連携し、チャネル別のROI分析ダッシュボードを1つ作るところから始めてみてください。CRMデータが社外の分析基盤にも流れることで、データの価値が飛躍的に高まります。
明確な基準はありませんが、目安としてCRMのコンタクト数が1万件を超え、かつ広告・会計・プロダクトなど複数のデータソースを横断した分析が必要になった段階が検討タイミングです。従業員100名以下でCRM単体のレポートで十分な場合は、DWH連携は時期尚早かもしれません。
構成にもよりますが、Airbyte（OSS）+ BigQuery（無料枠内）+ Metabase（OSS）であれば、クラウドインフラ費用のみ（月数千円〜）で始められます。Fivetranを使う場合はETLツール費用が月$500〜加算されます。
HubSpotのWebhookとCloud Functions / Lambda を組み合わせれば、ニアリアルタイム（数秒〜数分遅延）の連携は技術的に可能です。ただし、多くの分析ユースケースでは15分〜1時間間隔のバッチ同期で十分です。
基本的なアーキテクチャは同じです。Salesforceの場合はFivetranやStitchがネイティブ対応しており、またSalesforce Data Cloudという独自のデータプラットフォームもあります。Salesforceからの移行を検討されている場合は、DWHを共通基盤として両CRMのデータを並行管理する設計も可能です。
いいえ。日常的な営業管理（パイプライン進捗、タスク管理、個別アカウントの状況確認）にはCRM標準のダッシュボードが引き続き最適です。DWHのBIダッシュボードは、クロスチャネルの分析や経営レポートなど、CRM単体ではカバーできない分析に活用するという棲み分けが合理的です。