CDPとデータウェアハウスの違いは、どの処理に最適化されているかにある。データウェアハウスは全社の構造化データを分析とレポーティングのために保存・照会する基盤であり、CDP（カスタマーデータプラットフォーム）はあらゆる接点の顧客データを一人の顧客像に統合し、マーケティング、営業、サービスの各チャネルへリアルタイムに送り出す基盤である。 どちらもデータを集約する点は同じだが、答えられる問いが違う。ウェアハウスが答えるのは過去を問う質問（前四半期に解約した顧客は何人か、返品率が高い商品はどれか）である。CDPが答えるのは現在を問う質問（いま解約の兆候を見せている顧客は誰か、この訪問者に次に何を出すべきか）であり、その答えをチャネルへ送り出すところまで担う。
両者の混同が生じたのは、クラウドデータウェアハウス（Snowflake、BigQuery、Redshiftなど）を顧客データの保管先に使う構成が広まったためである。保管先が重なっても、両者が最適化している処理は重ならない。CDPそのものの定義と機能範囲はCDPの定義と全体像で扱っている。
分析のための基盤と、実行のための基盤
データウェアハウスは分析系の処理のために設計されている。大量のデータを走査する複雑なSQL、指標の集計、レポートの生成である。列単位で圧縮するカラムナ形式のストレージを採るため、特定の列に対する集計を高速に返せる（2025年の全顧客の平均注文金額を算出する、など）。設計上の優先順位は、クエリ性能、データガバナンス、過去データの分析にある。
CDPは運用系の処理のために設計されている。個々の顧客プロファイルの高速な参照、常時動く名寄せ、低レイテンシーのアクティベーションである。プロファイルは新しいイベントが届くたびに更新され続け、APIを通じて外部へ公開される。パーソナライゼーションエンジンやAI意思決定の仕組みは、このAPIを毎秒数千回の規模で照会する。設計上の優先順位は、プロファイルへのアクセス速度、即時の更新、アクティベーションの実行にある。
アーキテクチャの違い
データの持ち方
データウェアハウスは分析用のスキーマでデータを持つ。ファクトテーブル、ディメンションテーブル、スタースキーマ、スノーフレークスキーマといった構造で、レポーティングと集計に効く形に整える。一人の顧客のデータは複数のテーブルに分散し、購買は購買テーブル、問い合わせはサポートテーブル、Webのセッションはログテーブルに入る。顧客の全体像は、照会のたびに顧客IDでテーブルを結合して組み立てる。
CDPは統合プロファイルを単位にデータを持つ。一人ひとりについて分かっていることを1件のレコードにまとめた形である。プロファイルには属性データ、行動の履歴（購買、ページ閲覧、メールの開封）、エンゲージメントの指標、算出した属性（顧客生涯価値、プロペンシティスコア）、識別子の対応関係（メールアドレス、デバイスID、ロイヤルティ番号）が入る。テーブルの結合を組まなくても、顧客の文脈全体にその場でアクセスできる。
更新の頻度とレイテンシー
データウェアハウスの更新は、多くの場合バッチのスケジュールに従う。夜間のETLジョブがソースシステムからデータを抽出し、ウェアハウスのスキーマへ変換して読み込む。クラウドのウェアハウスならストリーミング取り込みも可能だが、比較的静的なデータセットに対する分析クエリを前提とした設計であることは変わらない。
リアルタイムCDPはイベントを継続的に取り込み、プロファイルを即座に更新する。顧客が行動を起こしてから数ミリ秒後には、統合プロファイルがその変化を反映し、アクティベーションに使える状態になる。Webサイトのパーソナライズ、カート放棄からの回復、その場でのAIの判断のように時間に縛られた活用事例では、この即時性が要件になる。
名寄せを誰が担うか
ウェアハウスでの名寄せは、分析担当者やデータエンジニアがクエリの中で組み立てる処理になる。どの識別子を突き合わせるか、どの一致を同一人物と見なすかをSQLや変換フレームワークのモデルで定義し、ソースが増えるたびにその定義を維持し続けることになる。
CDPでは名寄せが常時動く機能として組み込まれており、確定的マッチングと確率的マッチングを組み合わせて、新しい識別子が現れた時点でプロファイルを統合する。同じ人物が複数の別人として残り続けるかどうかが、この差として現れる。
アクティベーションの有無
データウェアハウスにアクティベーションの機能はない。分析の結果を施策で使うには、リバースETLのような外部ツールでデータを配信先へ書き戻す必要がある。CDPはデータアクティベーションを自らの機能として持ち、メール、アプリ、Web、広告へセグメントとプロファイルを送り出し、その結果を同じプラットフォームへ戻す。結果が戻るまでの時間が、AIが次の判断を改善できるまでの時間になる。
機能の比較
| 比較軸 | データウェアハウス | CDP |
|---|---|---|
| 主な目的 | 分析、レポーティング、BIによる可視化 | リアルタイムの顧客データ統合とアクティベーション |
| 主な利用者 | 分析担当者、データエンジニア | マーケティング、顧客体験の担当者、AIの仕組み |
| データの持ち方 | スタースキーマやスノーフレークスキーマ、ファクトテーブルとディメンションテーブル | 統合プロファイル（一人につき1件のレコード） |
| 更新の頻度 | バッチ（1時間ごと、夜間、週次） | ストリーミング取り込みによる継続的な更新 |
| クエリの特性 | 複雑なSQL、数百万件を横断する集計 | プロファイルの高速参照、低レイテンシーのAPIクエリ |
| 名寄せ | 手動（分析担当者が顧客IDでテーブルを結合する） | 自動かつ継続的なマッチングと統合 |
| アクティベーション | なし（実行には外部ツールが必要） | 標準機能または密接に連携（メール、アプリ、Web、広告） |
| 活用事例 | 過去データの分析、ダッシュボード、機械学習の学習 | パーソナライズ、施策のオーケストレーション、AI意思決定 |
| レイテンシー | 数分〜数時間 | ミリ秒〜数秒 |
| AIと機械学習 | モデルを学習させる環境（特徴量ストア、SQLベースの機械学習） | 予測スコアの付与、次の最適なアクションの判断、AIエージェント |
| マーケターの自走 | SQLの知識かBIツールの層が必要 | セグメント、ジャーニー、施策管理の画面を標準で持つ |
| ストレージの最適化 | クエリ性能のためのカラムナ圧縮 | 個別参照を速くするためのプロファイル索引 |
端的に言えば、データウェアハウスは何が起きたかを理解するための基盤であり、CDPはいま起きていることに対して動くための基盤である。
ウェアハウスを基盤にCDPの機能を組む場合
クラウドデータウェアハウスを顧客データの中心に据え、その上に名寄せ、セグメント、アクティベーションのツールを重ねる構成はコンポーザブルCDPと呼ばれる。ウェアハウスネイティブなこの構成が向く条件、レイテンシーと個人を特定できる情報（PII）の複製という代償、総保有コストの比較は、コンポーザブルCDPの解説で扱っている。
構成の選択がどちらであっても、名寄せ、プロファイル参照のAPI、アクティベーションという機能そのものは、どこかで用意しなければならない。ウェアハウスを基盤に選んだ場合、それを用意するのは自社のデータエンジニアリング体制になる。ハイブリッドCDPは、ウェアハウスへの接続を備えたうえで低レイテンシーのプロファイルストアを自前で持つことで、分析側と運用側の要件を同時に満たそうとする展開モデルである。
どちらを使うか、いつ併用するか
データウェアハウスで足りるのは、次のような場合である。
- 必要なのは過去データのレポーティングとダッシュボードである
- 主な利用者がSQLを扱う分析担当者である
- 個別のプロファイルを引くのではなく、大きなデータセットを集計するクエリが中心である
- 数時間から数日の更新間隔を許容できる
CDPが要るのは、次のような場合である。
- リアルタイムのパーソナライズとアクティベーションが目的である
- 主な利用者がマーケティングや顧客体験の担当者である
- Webサイトの表示やその場の判断のために、プロファイルを即座に引く必要がある
- 名寄せを継続的に動かし続ける必要がある
- ベンダーの境界をまたぐPIIの複製を抑えることが、セキュリティや法令対応の要件になっている
エンタープライズの構成では、両方を併用する形が多い。ウェアハウスが分析層を担い、長期のデータ保持、部門横断のレポーティング、機械学習モデルの学習、分析担当者によるアドホックな探索を引き受ける。CDPが運用層を担い、プロファイルの統合、ミリ秒単位の参照、名寄せ、オーディエンスセグメンテーション、下流チャネルへのアクティベーションを引き受ける。両者の間ではデータが双方向に流れ、CDPのイベントはウェアハウスへ蓄積されて過去分析の材料になり、ウェアハウスで算出したスコア（プロペンシティモデル、顧客生涯価値の予測）はCDPのプロファイルへ戻ってリアルタイムの判断を厚くする。
AIが両方を必要とする理由
AIの活用が広がったことで、この使い分けは後回しにできない論点になった。AIは性質の異なる二つのデータアクセスを同時に必要とするからである。
- 即時の判断に使うリアルタイムのデータアクセス（この顧客にいま何を出すか）
- 予測モデルの学習に使う過去データの厚み（どのパターンが解約を予測するか）
データウェアハウスは学習の段階に強いが、低レイテンシーの推論には向かない。CDPはリアルタイムの判断に強いが、大規模なモデルを学習させるためのデータ保持と計算能力は従来持っていなかった。Tomasz Tunguzが「AIのバンドリングの瞬間」で論じるように、AIは端から端までデータの流れを押さえたプラットフォームに有利に働く。学習データ（ウェアハウス）、判断のためのデータ（CDP）、アクティベーション先を別々のベンダーに分けた構成では、境界をまたぐたびにレイテンシーと運用の複雑さが積み上がるためである。
多くの企業にとっての問いは「CDPかデータウェアハウスか」ではなく、両者をどこまで密に連携させるかである。週次のオーディエンス同期や月次のセグメント分析で足りるなら、ウェアハウス上に構成を組む選択でも足りる。リアルタイムのパーソナライズ、カスタマージャーニーオーケストレーション、エージェンティックマーケティングに踏み込むなら、専用のCDP層が要る。
FAQ
データウェアハウスだけでCDPの役割を果たせるのか
技術的には近いものを作れるが、CDPの機能をゼロから組み上げることになる。 ストリーミング取り込み、名寄せ、プロファイル参照のAPI、アクティベーション先への連携を自前で用意する必要があり、専用のCDPを導入するより工数と運用費が膨らみやすい。ウェアハウスは分析クエリに最適化されており、個別プロファイルの高速参照とアクティベーションはその最適化の対象外である。この選択が成立するのは、専任のデータエンジニアリング体制と、投資に見合う活用事例の両方がある場合に限られる。
CDPのデータをデータウェアハウスへ送るべきか
多くの場合、送るべきである。 CDPを顧客データの中心に据えている企業でも、イベントとプロファイルをウェアハウスへ流しておく価値がある。長期のデータ保持、部門横断のレポーティング、機械学習モデルの学習は、ウェアハウス側が得意とする処理だからである。結果としてCDPが運用層、ウェアハウスが分析層という役割分担になり、リアルタイムのアクティベーションと深い分析の両方が手に入る。
CDPとデータウェアハウスはどちらを先に導入すべきか
先に必要になるのはウェアハウス側であることが多い。 経営指標のレポーティングと部門横断の分析は、マーケティングの成熟度に関係なく必要になるからである。CDPが効いてくるのは、扱うチャネルが増え、匿名の行動データを含む統合プロファイルをリアルタイムに保持しなければ施策が回らなくなった段階である。すでにウェアハウスを運用しているなら、そのデータをCDPの取り込み元の一つとして扱い、算出済みのスコアをプロファイルへ戻す構成にできる。
データレイクやデータレイクハウスはこの比較のどこに入るのか
どちらも分析側に位置し、CDPの代わりにはならない。 データレイクは構造化されていないデータを加工前の形で保管し、データレイクハウスはレイクの柔軟性にウェアハウスの分析性能を組み合わせた構成である。いずれもストレージと分析の層であり、名寄せとアクティベーションは備えていない。CDPと比べるときの軸は保管形式ではなく、統合プロファイルをどの速さで参照でき、どこへ送り出せるかにある。
関連用語
- データウェアハウス：分析とレポーティングのための保存・照会の基盤
- データレイクハウス：ウェアハウスの分析性能とデータレイクの柔軟性を併せた構成
- データパイプライン：ウェアハウス、CDP、アクティベーション先の間でデータを運ぶ仕組み
- CDPとCRMの違い：業務システムとの対比という、もう一つの使い分けの軸
- シングルカスタマービュー（SCV）：CDPが保持する統合プロファイルの到達点
この記事は他の言語でも読めます： CDP vs Data Warehouse