リアルタイムCDPとは、発生したイベントをその場で取り込み、統合された顧客プロファイルを即座に更新し、そのプロファイルをミリ秒単位でアクティベーションとAI意思決定に提供するカスタマーデータプラットフォーム（CDP）である。 バッチのスケジュールに従って数時間後や翌日に反映されるのではなく、イベントの発生と同時にプロファイルが現在の状態へ書き換わる。
リアルタイムCDPを他のCDPと分けているのは、機能の多寡ではなくレイテンシーである。パッケージ型CDPは、1時間ごと、夜間、週次といった決められた間隔でソースシステムから変更を集め、負荷の低い時間帯にまとめてプロファイルを更新する。リアルタイムCDPは、流れ込んでくるイベントをその都度処理する。顧客が14時14分に商品ページを閲覧すれば、14時14分00秒台のうちにプロファイルが更新され、そのプロファイルを参照する下流のAIモデルや配信チャネルは、更新後の状態をミリ秒のうちに読み取れる。
この差が「あると望ましい機能」から前提条件へと変わったのは、AIマーケティングとエージェントによる自動化が広がったためである。AIエージェントや意思決定エンジンは、参照したプロファイルの内容をそのまま判断の根拠にする。バッチ更新のプロファイルは、顧客の現在の状態とシステムの認識のあいだにずれを生む。そのずれは、予測の精度、パーソナライズの妥当性、施策の効果にそのまま跳ね返る。
リアルタイムCDPの仕組み
リアルタイムCDPは、バッチETLとは前提の異なるストリーミング型のアーキテクチャの上に構築されている。データは次の4つの段階を、止まることなく通過していく。
イベントの取り込み：Webページの閲覧、アプリ内の操作、購買、問い合わせ、メールの開封、広告のクリックといった顧客の行動は、発生した瞬間にイベントとして生成される。リアルタイムCDPは、これらをストリーミングAPI、WebサイトやアプリのSDK、基幹システムとの直接連携を通じて受け取る。イベントは後続のバッチ処理を待つ中間領域に溜め込まれるのではなく、継続的にプラットフォームへ流れ込む。
名寄せ：イベントが到着するたびに名寄せが実行され、既存の顧客プロファイルへの紐づけ、または新規プロファイルの作成が行われる。メールアドレス、電話番号、デバイスID、会員番号といった識別子を確定的マッチングと確率的マッチングで突き合わせる処理を、ミリ秒単位で完了させる。
プロファイルの更新：IDが定まると、CDPは統合プロファイルをただちに書き換える。行動履歴への追記、エンゲージメント指標の加算、属性値の更新、そして生涯価値やプロペンシティスコアのような派生指標の再計算である。更新後のプロファイルは、CDPに問い合わせるすべての下流システムからその時点で参照できる。
アクティベーション：リアルタイムCDPは、統合プロファイルを低レイテンシーのAPIとして公開する。AIの意思決定エンジンがある商品レコメンデーションを出すべきかを判断するとき、APIから返るのは数秒前の行動まで織り込まれた現在のプロファイルである。
バッチ型CDPとリアルタイムCDPの違い
| 比較軸 | バッチ型CDP | リアルタイムCDP |
|---|---|---|
| データ同期 | 決められた間隔（1時間ごと、夜間、週次） | 継続的なストリーミング取り込み |
| プロファイル更新 | 負荷の低い時間帯にまとめて処理 | イベントの発生と同時に更新 |
| レイテンシー | イベントからアクティベーションまで数時間〜数日 | ミリ秒〜数秒 |
| 適した活用事例 | キャンペーンの計画、過去データの分析 | パーソナライズ、AI意思決定、その場でのオファー |
| アーキテクチャ | ETLパイプラインとデータウェアハウス | ストリーミング基盤とイベント駆動の処理系 |
| AIとの関係 | 過去データで学習した予測モデル | リアルタイム推論とクローズドフィードバックループ |
| インフラ | バッチ実行の計算資源とジョブスケジューラ | 常時稼働のストリーム処理 |
ここでのバッチ型CDPとは、同期が定期実行にとどまるCDP全般を指し、第1世代のパッケージ型CDPはその典型である。選択を決めるのは製品の優劣ではなく、活用事例が許容できるレイテンシーの大きさである。週次のメールマガジンや月次のセグメント分析であれば、数時間の鮮度の差は成果に影響しないため、バッチ型CDPで足りる。現在のセッションの行動に応じてWebサイトの表示を変える、カート放棄から数分以内にメッセージを送る、直前の行動を踏まえてAIエージェントに判断させる。こうした時間に縛られた活用事例に踏み込んだ時点で、リアルタイムCDPが要件になる。
AIがリアルタイムのデータを必要とする理由
AIによるマーケティングは、Customer Intelligence Loop（顧客データの収集・統合・活用を継続的に回す仕組み）、すなわち収集→統合→理解→意思決定→エンゲージメントという5段階のサイクルの上で動く。エンゲージメントの成果は収集へ戻り、次の判断の材料になる。このループが一周する速さが、AIの学習が現実に追いつけるかどうかを決める。
バッチ処理は、このループを一箇所で止める。顧客が14時14分にカートを放棄しても、CDPが更新されるのが深夜0時の夜間バッチであれば、15時にAIが下す判断は放棄の事実を知らないまま行われる。回復のオファーを出す判断そのものが選択肢に入らない。バッチが回るころには、顧客は他店で購入しているか、関心を失っている。
リアルタイムCDPは、この間隔を埋める。顧客の文脈と意図がまだ生きているうちにAIが反応できるようになり、成果が数秒でプロファイルへ戻ることでモデルの再学習も継続的に行える。CDPの評価軸に取り込みのレイテンシーが並ぶようになったのは、この差が施策の成否に直結するためである。AIがCDPの要件そのものを書き換えている流れは、AIはCDPをどう再定義しているかで詳しく扱っている。
リアルタイムCDPとコンポーザブル構成
コンポーザブルCDPは、顧客データの保管場所をデータウェアハウスに置き、その上に軽量なCDPレイヤーを重ねる構成を採る。データの主導権とポータビリティという観点では筋の通った設計であり、エンジニアリング体制の整った組織には合理的な選択でもある。
ただしリアルタイム性については、構成そのものが制約になる。ウェアハウスは分析クエリのために最適化されており、サブセカンドでのプロファイル参照は本来の用途ではない。データの保管、意思決定、実行が別々のベンダーに分かれている構成では、境界を越えるたびにレイテンシーが積み上がる。Tomasz TunguzがAIのバンドリングの瞬間で論じているように、AIが統合されたプラットフォームを有利にするのはこの構造による。ストリーミング基盤と配信チャネルを内部に持つエージェンティックCDPは、この受け渡しの回数を減らすことで、エージェントが必要とするサブセカンドの応答を維持する。
コンポーザブル構成でリアルタイム性を実現することもできる。ただしそのためには、ストリーミングの取り込み層、参照用のキャッシュ、ウェアハウスとの同期ロジックを自前で組み立てて運用し続ける必要があり、その工数と基盤コストは、活用事例が増えレイテンシーの要件が厳しくなるほど膨らんでいく。
リアルタイムCDP導入時の検討事項
リアルタイムCDPの採用を検討する組織が、事前に確かめておくとよい点が4つある。
ソースシステムの対応状況：既存のシステムはストリーミング連携に対応しているか、それともバッチ出力しかできないか。WebサイトとモバイルアプリはSDKで容易にイベントを送出できるが、古いCRMやPOSでは、バッチ抽出をイベントストリームへ変換するミドルウェアが必要になることが多い。
活用事例の要件：どの活用事例が本当にリアルタイムのデータを必要とし、どれがバッチ更新のレイテンシーを許容できるか。Webサイトのパーソナライズ、カート放棄からの回復、AIによる意思決定のように効果の大きい領域からリアルタイム化し、優先度の低いレポートや分析はバッチ更新のままにしておく方が、投資に見合う。
基盤の常時稼働：リアルタイムCDPは、決められた時間帯にまとめて動くのではなく、常時稼働してデータを処理し続ける基盤を前提とする。定常的なコストは高くなる一方で、バッチ処理に付きものの計算資源の急激な変動や、夜間ジョブの失敗による翌朝の対応は起こらなくなる。
組織と運用の変化：リアルタイム化は、キャンペーン単位の運用（計画し、作り、配信し、振り返る）から、AIが継続的に調整し続ける運用への移行を伴う。必要になるスキル、業務プロセス、ガバナンスの設計は、導入前に見積もられているより大きいことが多い。
FAQ
リアルタイムCDPと通常のCDPは何が違うのか
違いはプロファイルが更新されるまでの時間にある。 パッケージ型CDPは時間単位や夜間のバッチでデータをまとめて処理し、その処理が終わるまでプロファイルは古いままである。リアルタイムCDPはイベントを発生順に取り込み、ミリ秒単位でプロファイルを更新して、現在の顧客の状態をパーソナライズとAI意思決定にただちに供給する。実務上の差は反応の可否として現れる。カート放棄に対して、リアルタイムCDPは数分以内に回復のメッセージを出せるが、バッチ型CDPは次の同期まで放棄の事実を認識できない。
「リアルタイム」とはどの程度の速さを指すのか
セッション中のパーソナライズやAIエージェントの判断では、プロファイル参照が一貫して100ミリ秒未満で返ることが実質的な基準になる。 イベントの取り込みからプロファイルへの反映までは数秒以内、参照は100ミリ秒未満、という二段構えで見るとよい。「準リアルタイム」を名乗るプラットフォームでも、実態が5分間隔のマイクロバッチであることは珍しくない。評価の際は、取り込みのレイテンシーと参照の応答時間を分けて確認し、平均値ではなく上位パーセンタイルの値を求めるとよい。
AIマーケティングに取り組んでいない場合もリアルタイムCDPは必要か
必要かどうかは、応答の速さが成果を左右する活用事例を持っているかで決まる。 現在のセッション行動に応じたWebサイトのパーソナライズ、カート放棄からの回復、不正利用の検知、店舗でのその場のオファーは、AIを使っていなくてもリアルタイムのデータから価値を得られる。一方、月次のメール施策や四半期ごとのセグメント分析が中心であれば、バッチ型CDPの機能で足りる。ただしAIを導入した時点で投資対効果は大きく変わる。AIは、判断から実行、成果の計測までが数秒で一巡することを前提に学習するためである。
データウェアハウス上にリアルタイムCDPを構築できるのか
技術的には可能だが、相応のエンジニアリング工数とコストがかかる。 データウェアハウスはバッチ分析のために最適化されており、運用系のリアルタイムクエリを想定した設計ではない。リアルタイムの性能を得るには、ストリーミングの取り込み層、参照用のキャッシュ、ウェアハウスとの同期ロジックを追加することになる。この構成は、専任のデータエンジニアリング体制があり、投資を正当化できる活用事例を持つ組織では機能する。そうでない場合、保守の負担が専用プラットフォームの費用を上回りやすい。
Related Terms
- リアルタイムデータ処理：リアルタイムCDPを支えるストリーミング基盤
- データ取り込み：イベントデータがCDPに入り、即座に処理されるまでの経路
- 顧客データの統合：リアルタイムCDPが即時に実行するプロファイル統合の処理
- データパイプライン：リアルタイム構成でバッチETLに取って代わるストリーミング型のパイプライン
- エージェンティックCDP：リアルタイムのプロファイルを前提に動く、AIエージェント向けのCDP
- コンポーザブルCDP：モジュール性と引き換えにリアルタイム性が制約されるウェアハウス基盤の構成
さらに詳しく： CDPとは何か：カスタマーデータプラットフォームの完全ガイド