See where CDP is headed with AI — Agentic World 2026, Oct 5–7, Miami →
English
グロッサリー

シングルカスタマービュー(SCV)とは?CDPでの作り方

シングルカスタマービュー(SCV)とは、CRM、Web、アプリ、購買などに分散した顧客データを一人分の単一プロファイルへ集約したものである。Customer 360との違い、名寄せによる構築の4段階、AIエージェント時代に求められる鮮度、CDP選定時の確認項目を解説する。

Kazuki Ohta Kazuki Ohta 読了目安 1 分

シングルカスタマービュー(SCV)とは、組織が保有する顧客データを、一人の顧客として一貫して扱え、そのまま施策の宛先にできる単一の顧客像へまとめたものである。 列を増やした1枚の表ではなく、後述する5つのレイヤーが噛み合って初めて機能する。チャネルや媒体をまたいだ行動を一つの記録から追えるため、オムニチャネルマーケティングを成り立たせる前提になる。

シングルカスタマービューは、Customer 360 View(C360)や Unified Customer View(UCV)とも呼ばれる。氏名、電話番号、住所、年齢といった個人を特定できる情報に加えて、購買履歴、ロイヤルティプログラムの利用状況、コミュニケーション履歴までを一つのプロファイルに束ねる。

このプロファイルを継続的に生成し、維持する仕組みがCDP(カスタマーデータプラットフォーム)である。シングルカスタマービューは、CDPが生み出す中心的な成果物にあたる。

シングルカスタマービューが必要になる理由

顧客はWebサイト、モバイルアプリ、電話、SMS、実店舗など多数の接点でブランドと接する。接点ごとに別々のシステムが記録を持ち、それらが同一人物のものとして紐づかないままだと、一人の顧客が複数の別人として数えられる。結果として、同じ人に重複した案内が届き、すでに購入済みの商品を薦めることになる。

例えば、メールを開いてサイトへ遷移し、商品をカートに入れたうえで、実物を確かめるために店舗へ向かう顧客がいる。この一連の行動を結び付ける仕組みがなければ、企業側にはカートを放棄した見込み客としか見えない。店舗で購入が完了した後もカート放棄のリマインドが送られ続け、獲得済みの売上に対して広告費を払い続けることになる。

実際、フォレスター(Forrester, 2023)によれば、統合された顧客プロファイルを導入した組織は、顧客満足度が10~20%向上し、マーケティング効率が15~25%改善しているという。

シングルカスタマービューを構成する5つのレイヤー

シングルカスタマービューは、次の5つのレイヤーからなる。それぞれ答えている問いが違い、どれか一つが欠けるか、互いに食い違っていれば、残りがどれだけ整っていても、そのプロファイルから下した判断は当てにならない。構築作業の大半は、下敷きになるソースシステムが変わり続けるなかで、この5つの整合を保ち続けることに費やされる。

識別子のレイヤー。 同一人物に行き着く識別子を保持する。メールアドレスとそのハッシュ値、電話番号、会員番号、アカウントID、モバイル広告ID、Cookieなどである。これは項目の一覧ではなくグラフであり、どの識別子とどの識別子が、どの根拠で、いつ結ばれたのかまでを記録する。

属性のレイヤー。 氏名、住所、連絡先、年齢や性別、契約の状態といった、その人を説明する項目である。同じ項目の値がソースごとに食い違うのはよくあることであり、属性ごとにどの値を正とするかを決める規則(優先規則)と、採用した値をどのシステムから採ったかの記録があって、はじめてこのレイヤーは用をなす。

イベントのレイヤー。 時系列に並んだ行動の記録である。ページの閲覧、アプリの起動、購買、返品、問い合わせ、メールの開封、来店などが該当する。イベントは追記するだけで書き換えない。人への紐づけは識別子のレイヤーを介して決まるのであって、プロファイル側に書き込んだキーで決まるのではない。

派生属性のレイヤー。 上の3つから計算される値である。顧客生涯価値、直近の購買からの経過期間や購買頻度の区分、購買確度や解約確率、反応の得られやすい配信時刻などがこれにあたる。セグメントの条件として実際に使われるのはこのレイヤーの値であり、項目ごとに更新の間隔を持つ。その間隔が、その項目から作ったセグメントの鮮度をそのまま決める。

権限のレイヤー。 同意の状態、チャネルごとの受信可否、利用目的の制限、項目ごとの保持期間、未処理の削除請求を、他の属性と同じアイデンティティグラフの上で解決する。最初の4つを備えていてこのレイヤーだけがないプロファイルは、完成していながら使えない。そこから作ったセグメントは、人手で法務の確認を通さないかぎり1件も配信できないからだ。

CDPがシングルカスタマービューを構築する仕組み

CDPは、断片化したデータを一人分のプロファイルにまとめる処理を4つの段階に分けて自動化する。

  1. 収集:Webの行動ログ、モバイルアプリ、CRM、POS、ロイヤルティプログラム、コールセンター、広告プラットフォームなど、顧客接点を持つシステムからファーストパーティデータを取り込む。
  2. 名寄せ:メールアドレス、デバイスID、会員番号、Cookie IDといった識別子を、名寄せが照合し、同一人物のレコードを一つに束ねる。確定的マッチングでは確実な一致を、確率的マッチングでは匿名の行動までを対象にする。
  3. 統合プロファイルの生成:束ねられたレコードから、属性、行動履歴、算出された指標(顧客生涯価値、解約確率など)を持つプロファイルが作られる。このプロファイルは取引の区切りをまたいで維持されるが、無期限に残すわけではなく、権限のレイヤーで定めた項目ごとの保持期間に従う。
  4. 更新とアクティベーション:新しいイベントが届くたびにプロファイルが更新され、その内容がメール、広告、アプリ、店舗の端末へ配信される。

プロファイルに載せるべきものは、属性と行動データだけではない。顧客がどのデータの利用に同意し、どのチャネルでの連絡を拒否しているかという同意管理の情報も、同じプロファイルに含まれている必要がある。同意の状態が別システムに残っていると、配信の直前に照合処理を挟むことになり、その場での判断ができなくなる。CDPを比較するとき、同意情報の扱いは見落とされやすい。

Customer 360、ゴールデンレコードとの違い

シングルカスタマービューとCustomer 360は同じ概念を指す。近年のマーケティング領域では後者の呼び方が優勢になっているが、指しているものは変わらない。一方、ゴールデンレコードは同義ではなく、統合の過程で生まれる別の成果物である。

用語指すもの
シングルカスタマービュー(SCV)一人の顧客に関するデータを集約したプロファイル。閲覧と活用の単位
Customer 360(C360)SCVと同じ概念。全方位から顧客を捉えるという含意を強調した呼称
ゴールデンレコード属性ごとにどの値を正とするかを確定させた、唯一の正となるレコード

呼称の違いは評価に影響しないが、ゴールデンレコードとSCVを取り違えると必要な機能を見誤る。ゴールデンレコードは「3つの住所のうちどれが現住所か」という値の選択の問題であり、シングルカスタマービューは「その顧客について何を見られるか」という範囲の問題である。値の正しさを決める機能を備えていても、行動履歴やセグメント所属を参照できなければ、マーケティングの用途は満たせない。

シングルカスタマービューが組み上がるまでの6工程

先に挙げた4段階は、CDPの機能として説明したときの区切りである。実装の単位で分けると工程は6つになり、ベンダーによって説明のしかたは違っても、この並びはどのアーキテクチャでも変わらない。実装ごとに違うのは処理の速さであって、工程の有無ではない。同じ6工程が、ある環境では夜間バッチで一巡し、別の環境では数秒で一巡する。

1. 識別子を伴う収集。 データ取り込みが、CRM、WebとモバイルアプリのSDK、POS、コールセンター、ロイヤルティプログラム、バッチ連携のファイルからレコードを集める。ここで効くのは量ではなく、1件ごとにどの識別子が付いているかである。メールアドレスも電話番号も会員番号も伴わない取引データには、どのプロファイルにも行き着く経路がない。

2. 正規化。 マッチングを走らせる前に、識別子と属性の表記をそろえる。メールアドレスは小文字にしてプラス記号以降の別名を畳み、電話番号はE.164形式に直し、住所は郵便の標準形に分解し、ハッシュ値はソースをまたいで同じアルゴリズムに合わせる。この工程を飛ばすと、同じ値を2通りに書いただけの識別子がグラフ上でつながらない。

3. 名寄せ。 確定的マッチングが完全に一致する識別子を結び、確率的マッチングがデバイス、位置情報、行動のシグナルから一致の確からしさを点数化し、推移的マッチングがそのつながりを連鎖の先へ広げる。既知のメールアドレスと同じ端末で観測された識別子は、この連鎖によってその人の会員番号まで引き継ぐ。出力は識別子のまとまりからなるグラフであり、1つのまとまりが1人に対応する。

4. 統合と値の確定。 1つのまとまりに含まれるレコードを、1件のプロファイルへ畳む。どの値を正とするかは属性ごとの優先規則が決める。配送先住所のように本人が申告する項目では新しい値を採り、請求やCRMが正となる項目ではそのシステムの値を優先する。あわせて統合履歴を残し、どの統合も後から説明でき、取り消せるようにしておく。派生属性と権限の状態は、この統合処理の一部ではなく、統合後のプロファイルに対する別の処理として計算・解決される。両者が統合とは別の更新の間隔を持つのはこのためである。

5. プロファイルの提供。 読み手のいる場所にプロファイルを実体化する。1件を即座に引くための低レイテンシーのキーバリューストアと、オーディエンスの作成や分析のための列指向のテーブルである。前者を読むのは、セッション中のパーソナライズや、会話の途中でプロファイルを参照するAIエージェントだ。1件の即時参照と大量の走査は別の読み方であり、リアルタイムCDPが両方を保持して同期を保つのはこのためである。

6. アクティベーションと結果の書き戻し。 プロファイルは、API、オーディエンスの同期、イベントを起点とした配信を通じてチャネルやアプリケーションへ届く。これがデータアクティベーションの工程であり、その結果は新しいイベントとして戻ってくる。この戻りの経路がないシングルカスタマービューは、顧客が何をしたかをすべて記録しながら、企業側が何をしたかを何も記録していない。

「リアルタイム」が静かに失われる場所として最も多いのが、工程5である。書き込み側の計測は整備され、イベントが数秒で着くことは確認されているのに、キャンペーンツールや対応窓口の画面が実際に照会する読み出し側を誰も測っていない。その読み出し先が、夜間に一度だけ更新される複製ということもある。ただし、工程2から4がバッチで動いていて、そこで時間を失っていることも同じくらいあり得る。工程5が名指ししているのは、速い書き込みが古い提供用の複製を支えているという特定の失敗であって、遅れが常に読み出し側で生じるという主張ではない。

AIエージェントが読み出すシングルカスタマービュー

人間のマーケターが画面で確認するSCVであれば、日次バッチでの更新でも足りていた。プロファイルを見てからキャンペーンを設計し、配信するまでに数時間の猶予があるからだ。AIエージェントが同じプロファイルを読む場合、求められる鮮度は変わる。エージェントは顧客がサイトに滞在している数百ミリ秒のあいだにプロファイルを参照して次の行動を決めるため、数時間前の状態を返すプロファイルでは、直前の問い合わせも直前の購入も反映されない。

エージェンティックCDPは、この要求に合わせてSCVをリアルタイムで維持する。届いたイベントをその場でプロファイルへ反映し、API並みの速度で読み出せる状態に保つ。Customer Intelligence Loop(顧客データの収集・統合・活用を継続的に回す仕組み)のUNIFY(統合)段階が生む出力がシングルカスタマービューであり、後続のUNDERSTAND(理解)、DECIDE(判断)、ENGAGE(実行)はいずれもこの出力を入力として動く。プロファイルが古ければ、その先の判断もすべて古い前提の上で下される。

シングルカスタマービューの設計でつまずく6つのパターン

以下は作業上のミスではなく、設計の判断である。いずれも、レビューを通り、画面上は完成して見え、そのうえで読む側を誤らせるプロファイルを生む。構築の順序に起因する失敗はこれとは別の一覧になり、5つのステップでシングルカスタマービューを構築するで扱っている。投資判断の組み立て方はシングルカスタマービューの効果にある。

ログイン時に捨てられる匿名期間の履歴。 多くの顧客は、名乗る前に閲覧し、比較し、カートを放棄する。ログインの瞬間に匿名の識別子を統合せず破棄すると、プロファイルはアカウント作成の時点から始まり、最も予測に効く数週間、すなわち検討期間の行動が、そのプロファイルで学習するすべてのモデルから消える。対策は、匿名の識別子をグラフ上の正規のノードとして保持し、本人と判明した時点で、それまでのイベント履歴を既知のプロファイルへさかのぼって接続することである。

プロファイルに書き込まれるイベント。 接点ごとの記録を属性として追記していくと、レコードは際限なく膨らみ、その分だけ参照が遅くなる。セグメントの作成画面には似たような項目が数千個並び、マーケターはどれを選べばよいか判断できない。対策は、イベントをイベントのレイヤーに置いたまま、数の決まった名前付きの集計値としてプロファイルへ出すことである。最終購買日、直近30日のセッション数、チャネル別の開封率といった単位になる。

鮮度の取り決めがない項目。 5年前に観測した住所が昨日の購買と同じ重みで並び、取り込みのときに一度だけ計算した解約確率が現在の値として表示される。プロファイルを読む側には、どの値が今もその顧客を説明しているのか判断できず、チームごとに独自の見立てで補うことになる。対策は、属性ごとに観測時刻と取得元を刻み、派生属性には更新の間隔を公開し、そのどちらもプロファイルを読むシステムから参照できるようにすることである。

全読み手への同一プロファイルの提供。 対応窓口の画面も、広告プラットフォームも、AIエージェントも、同じ完全なプロファイルを受け取る。広告プラットフォームは保持する理由のない個人を特定できる情報(PII)まで抱え、エージェントは1つの問いに答えるために数百の項目を読み、権限の適用はその時々の読み手任せになる。対策は、送り先ごとに必要最小限の項目だけを切り出した部分ビューを定義し、同意とアクセスの規則を元のレコードではなくその部分ビューに結び付けることである。

個人単位でしかモデル化しない設計。 個人単位のビューでは、誰が買う主体なのかに答えられない。法人取引の意思決定は複数人で行われ、世帯は動画配信サービスの契約や配送先を共有し、家族向けプランでは4人が1つの支払い手段を共有する。それぞれを無関係な個人として扱うと、本来ひとまとまりの購買履歴が分かれ、重複した案内と、文脈の欠けた対応の両方が生じる。対策は、アカウントと世帯を、独自の名寄せ規則を持つ正規のエンティティとしてモデル化し、個人のグラフとは区別したうえで相互に結び付けることである。

プロファイルを読む側に見えない統合の確信度。 確率的に結んだつながりと、ログインで裏づけた一致は、プロファイルに届いた時点では見分けがつかない。広い対象に案内を送るマーケターと、注文内容を確認する応対担当者が、確信度の異なる根拠に基づいて動くことになる。誤った統合の代償は、後者のほうがはるかに大きい。対策は、マッチングの方法と確信度スコアをプロファイル側に持たせ、応対、金融取引、要配慮個人情報にあたる項目といったリスクの高い用途では、確定的マッチングで結んだつながりだけを使う設定にすることである。

CDP選定時に確認すべきこと

CDPベンダーによって、シングルカスタマービューの作り込みには差がある。含められる情報、その提示のしかた、目的の情報にたどり着くまでの手数が異なる。デモの場では、次の点を確認しておきたい。

  • 自社の事業で必要な項目を追加し、プロファイル画面の構成を変更できるか
  • 一人の顧客の全体像を、複数の画面を行き来せずに把握できるか
  • 任意の項目で検索できるか。あらかじめ用意された項目にしか検索が効かない仕様になっていないか
  • 購買、来店、メール開封といったイベントや行動の履歴を、プロファイル上でそのまま追えるか
  • そのプロファイルがどのセグメントに含まれているかを確認できるか
  • 最適な配信時刻、推奨チャネル、各種スコアといった機械学習の出力を、プロファイル上で参照できるか
  • 同意の状態と、その同意を取得した経路を確認できるか
  • プロファイルをAPI経由で外部システムやAIエージェントから読み出せるか

プロファイル画面の使い勝手だけでなく、CDP全体としての評価観点はエンタープライズCDPに必要な10の機能にまとめている。

FAQ

シングルカスタマービューとCustomer 360の違いは何か

両者は同じ概念を指しており、実務上の違いはない。 どちらも、一人の顧客に関するあらゆるデータを一つのプロファイルに集約したものを指す。Customer 360(C360)という呼び方は、すべての接点を全方位から捉えるという含意を強調したもので、近年のマーケティング技術の文脈ではこちらが多く使われる。Unified Customer View(UCV)も同じものを指す呼称である。

オンラインとオフラインのデータを一つのシングルカスタマービューにまとめられるか

まとめられる。 現代のCDPは、店舗POSでの購買、コールセンターでの応対、Webの行動、アプリの利用、メールへの反応を同一のプロファイルへ統合する。オフライン側は会員番号や電話番号といった確定的な識別子で紐づけ、Web側は認証済みのセッションを起点に、それ以前の匿名の行動を後から接続する。この統合があってはじめて、接触経路によらず同じ顧客として扱えるようになる。

シングルカスタマービューの構築は何から始めるべきか

最初に対象とする活用事例を決め、そこから逆算して統合するデータソースを絞る。 全社のデータを一度に統合しようとすると、名寄せの精度を検証できないまま範囲だけが広がる。まずは一つの施策を回すのに必要な2~3のソース(例えばECの購買、Webの行動、メールへの反応)に限定し、重複や統合漏れの発生率を確認してから対象を広げるほうが早い。

  • Identity Graph:一人の顧客に紐づく識別子の関係を保持するデータ構造
  • Customer Data Unification:複数のデータソースを一つのプロファイルへまとめる処理
  • Data Enrichment:統合プロファイルに外部データや算出属性を付け加える手法
  • CDP vs CRM:CDPとCRMが扱うデータと役割の違い
  • Customer Digital Twin:顧客の行動を再現する動的なモデル

この記事は他の言語でも読めます: Single Customer View (SCV): What It Is & How to Build One · Single Customer View (SCV): o que é e como criar · Référentiel client unique (RCU) : définition · Single Customer View: Aufbau, Abgleich und Nutzen

Kazuki Ohta
執筆者

Kazuki Ohta is Co-Founder & CEO of Treasure AI (formerly Treasure Data), which he co-founded in 2011. A co-developer of Fluentd, a CNCF graduated open-source project, he previously served as CTO of Preferred Infrastructure. Ohta graduated with honors in Computer Science from the University of Tokyo and conducted research in high-performance computing and large-scale data processing as a visiting researcher at Argonne National Laboratory. CDP.com is managed by Treasure AI as an educational resource.