--- title: "顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件" url: "https://www.issoh.co.jp/column/details/18983/" published: 2026-10-27 updated: 2026-10-27 categories: ["DX"] publisher: "株式会社一創" --- # 顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件 顧客データ統合とは、CRM・EC・基幹システム・MAなどに別々に登録された顧客情報を、1人（1社）につき1件の顧客として扱える状態にそろえる取り組みです。この記事では、BtoBとBtoCで変わる名寄せキーの決め方、棚卸しから運用までの6段階の手順、どの値を残すかのルール、個人情報保護法で事前に確認する利用目的と共同利用を順に整理します。最後に、CRM・DWH・CDPのどこを統合先にするかを分岐条件で示し、CDPを入れずに済む会社の条件まで言い切ります。 ## まとめ：顧客データ統合はキーの決定と正の置き場所選びで工期が決まる 顧客データ統合で時間がかかるのは、ツールの導入ではありません。同じ顧客を同じと判定する名寄せキーを決める作業と、統合後の「正しい値」をどのシステムに置くかを決める作業の2つです。BtoBなら国税庁の法人番号を主キーにし、BtoCならメールアドレス・電話番号・会員番号に優先順位を付けて突き合わせる。この順序を先に決めておけば、統合方式の選択で迷う時間は短くなります。 統合先は、顧客データの源がCRMとEC程度で、使い道が営業と問い合わせ対応ならCRMを正にすれば足ります。源が5つを超え、分析と配信の両方に使うならDWHで組み、施策担当者が自分でセグメントを切って毎週配信する体制があって初めてCDPが候補に入ります。グループ会社をまたぐ統合や、Cookie・閲覧履歴を会員情報に結びつける統合では、着手前に個人情報保護法の確認を済ませてください。 ## 顧客データ統合とは何かと散らばる顧客情報を1人1件にそろえる目的 部門ごとにシステムを入れてきた会社では、同じ顧客が営業のSFAでは会社名、ECでは個人名、会計では請求先名で登録されています。顧客データ統合は、この状態を解いて、顧客単位で取引・問い合わせ・購買の履歴を並べられるようにする作業です。 ### 顧客データ統合の定義とシングルカスタマービューやゴールデンレコードの関係 海外の解説では、顧客データ統合はCDI（Customer Data Integration）と呼ばれ、到達点は「シングルカスタマービュー（顧客の単一の全体像）」と表現されます。複数のシステムにある同一顧客のレコードを束ね、項目ごとに最も信頼できる値を選んで作った1件をゴールデンレコードと呼びます。 データ統合一般との違いは対象の絞り方にあります。売上や在庫も含めたデータ統合の方式（ETL・データ仮想化・CDCなど）の選び方は[データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説](https://www.issoh.co.jp/column/details/18977/)で整理しました。顧客データ統合はそのうち「顧客」という1種類のデータに絞り、同一人物・同一企業の判定に重心を置きます。方式より判定の設計で成否が分かれる点が特徴です。 ### 統合対象になる7つのデータ源とシステムごとに違う顧客の持ち方 最初に、顧客情報を持っているシステムを洗い出します。多くの会社で対象になるのは次の7種類です。 - CRM・SFA：取引先企業と担当者、商談履歴 - ECサイト・会員システム：会員番号、メールアドレス、購買履歴 - POS・店舗システム：ポイントカード番号、来店履歴 - 基幹システム・会計：請求先、取引先コード、入金履歴 - MAツール：メールアドレス、開封・クリック履歴 - 問い合わせ管理・コールセンター：電話番号、応対履歴 - Web解析・広告：Cookie等の識別子、閲覧履歴 同じ「顧客」でも、基幹は請求先の法人を、ECは個人を、MAはメールアドレスを1件と数えます。数え方の単位がそろっていないまま結合すると、1社に担当者が5人いる企業が5社として集計される事故になりがちです。店舗とECの両方を持つ小売では、在庫と顧客IDの統合を同時に進める必要があり、その要件は[オムニチャネルとは？在庫・顧客データの統合要件と導入手順・見送る判断基準](https://www.issoh.co.jp/column/details/16554/)で扱っています。 ## 名寄せキーの設計｜BtoBは法人番号・BtoCはメールと電話番号で決める基準 名寄せキーとは、2つのレコードが同じ顧客かを判定するときに見る項目です。BtoBとBtoCでは使えるキーが違うため、先に自社の顧客がどちらかを決めてから設計します。 ### BtoBの顧客は国税庁の13桁の法人番号を主キーにして社名の揺れを吸収する 法人顧客の名寄せで最も強いキーは、国税庁が指定する13桁の法人番号です。「株式会社サンプル商事」「（株）サンプル商事」「サンプル商事」は文字列としては一致しません。法人番号に置き換えれば同じ1社として結合できます。 既存の取引先マスタに法人番号が入っていない場合は、国税庁の[法人番号システム Web-API](https://www.houjin-bangou.nta.go.jp/webapi/)で付与します。2026年10月時点でVer.4.0が提供されており、法人番号の指定・法人名の指定（Ver.2.0以降）・取得期間を指定した差分取得の3つが提供される機能です。利用には事前にアプリケーションIDの届出が必要で、発行まで2週間から1か月程度かかると案内されています。統合の計画を立てた時点で申請しておくと、名寄せ作業の開始を待たずに済みます。 法人名で照会すると同名の別法人が複数返ることがあります。所在地の都道府県と市区町村で絞り、それでも1件に決まらないものだけを人が確認する、という二段構えにします。 ### BtoCの顧客はメール・電話番号・会員番号の優先順位と正規化で突き合わせる 個人顧客には法人番号のような共通の番号がありません。そのため、複数の項目に優先順位を付けて判定します。実務で多い順序は、会員番号が両方にあれば会員番号、無ければメールアドレス、次に電話番号、最後に氏名と住所の組み合わせです。 突き合わせの前に、表記をそろえる正規化を必ず行います。 - メールアドレス：前後の空白を除き、すべて小文字にする - 電話番号：ハイフン・括弧・空白を除き、「+81」を先頭の「0」に戻す - 氏名：全角と半角、旧字体、姓と名の間の空白をそろえる - カナ：半角カナを全角にし、小書き文字の扱いを決める 家族で1つのメールアドレスを共有している、固定電話を世帯で使っている、といった理由で、1つのキーだけで結合すると別人を同一人物にしてしまいます。メール一致でも氏名が大きく違えば結合しない、という否定条件を1つ入れておくことが、誤結合の大半を防ぐ方法です。キーの無い顧客を確率的に突き合わせる手法やOSSの選び方は[データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方](https://www.issoh.co.jp/column/details/2377/)に詳しくまとめています。 ### 住所の表記揺れをアドレス・ベース・レジストリで正規化する方法と限界 住所は「1丁目2番3号」「1-2-3」「一丁目二番地三」のように揺れ方が多く、名寄せの補助キーに使うには正規化が要ります。デジタル庁は住所の公的な基準データとして[アドレス・ベース・レジストリ](https://www.digital.go.jp/policies/base%5Fregistry%5Faddress)を公開しており、町字（都道府県・市区町村・町字の階層）のデータは2025年6月1日に自治体の確認を経た正式版になりました。 同庁は住所を正規化するOSSとして[ABRジオコーダー](https://github.com/digital-go-jp/abr-geocoder)もGitHubで公開しています。ただし、住居表示と地番のデータは未整備で、町字より下の番地・号は試験公開の段階です。2026年10月時点では、町字までを正規化して比較し、番地以下は数字だけを抜き出して照合する運用が現実的です。 ## 顧客データ統合の手順｜棚卸しから名寄せ・正の値の決定・運用までの6段階 統合は一度作って終わりではなく、新しい顧客が増え続けるかぎり続く作業です。手順を初回の統合と日々の運用に分けて設計します。 ### 顧客データ統合を進める6段階の手順と各段階で決めておく成果物 初回の統合は次の順で進めます。各段階の終わりに成果物を残しておくと、後から担当者が替わっても判定の根拠を追えます。 1. 目的の確定：営業の重複訪問を減らす、配信の重複を止める、LTVを測る、のどれかに絞り、使う画面と指標を決める 2. データ源の棚卸し：前章の7種類について、件数・更新頻度・顧客の単位・持っているキーを一覧にする 3. 正規化ルールの定義：会社名・氏名・電話番号・メール・住所の表記をそろえる規則を文書にする 4. 名寄せの試行：2つのシステムだけで突き合わせ、一致率と誤結合を人の目でサンプル確認する 5. 値の優先順位の決定：項目ごとにどのシステムの値を残すかを決め、ゴールデンレコードを作る 6. 運用への移行：新規登録と変更を差分で取り込み、名寄せを定期的にやり直す仕組みを作る 4段階目で一度に全システムを対象にしないことが、工期を延ばさないコツです。CRMとECのように件数が多い2つから始め、ルールが固まってから残りを足していきます。 ### どの値を残すかを決めるサバイバーシップルールと項目別の優先順位 同じ顧客の住所がCRMとECで違うとき、どちらを残すかを決める規則をサバイバーシップルールと呼びます。項目ごとに「どのシステムを正とするか」を決めた表を作り、関係部門の合意を取ってから実装します。 | 項目 | 正とするシステムの例 | 決め方の理由 | | ------- | ---------- | ----------- | | 会社名・所在地 | 法人番号の公表情報 | 公的な登記に基づく | | 請求先 | 基幹・会計 | 入金の照合に使う | | 担当者の役職 | CRM・SFA | 営業が最後に会った情報 | | メール・配送先 | EC・会員システム | 本人が自分で更新する | | 配信の許諾 | MAの最新の操作 | 配信停止を優先する | 迷ったときの原則は「本人が最後に自分で入力した値を優先する」です。配信の許諾だけは例外で、どこか1つのシステムで配信停止が押されていれば停止を優先します。統合のたびにこの表を作り直す組織では、顧客・商品・取引先の正を1か所で管理するマスタデータ管理（MDM）を検討する段階に来ています。考え方は[マスタ（マスターデータ）とは？トランザクションデータとの違いと管理・MDMの進め方](https://www.issoh.co.jp/column/details/11085/)を参照してください。 ### 統合後に増える新規顧客と変更を日次で取り込む差分更新の運用設計 初回の統合が終わった翌日から、ECでは新規会員が登録され、営業は新しい名刺を入力します。統合済みの顧客台帳を保つには、変更があったレコードだけを日次で取り込み、名寄せをかけ直す差分更新の仕組みが必要です。BtoBであれば、法人番号Web-APIの差分取得で商号変更や本店移転を拾い、取引先の会社名を自動で更新できます。 差分の取り込みでは、システム間のAPI連携の設計がそのまま品質を決める要因です。どのシステムから先に書き込むか、書き戻しをどこまで許すかの判断は[CRM連携とは？MA・SFA・基幹をつなぐAPI連携の設計と選定基準を解説](https://www.issoh.co.jp/column/details/15591/)で解説しています。統合後に重複が再発する原因の多くは、ECの会員登録画面がCRMの既存顧客を検索せずに新規作成している、といった入口側の作りにあります。 ## 顧客データを統合する前に確認する個人情報保護法の利用目的と共同利用 顧客データ統合は、別々の目的で集めた個人情報を1か所に集める作業です。社内の作業であっても、個人情報保護法の確認を飛ばすと、統合したデータを使えない事態になります。以下は個人情報保護委員会の[個人情報の保護に関する法律についてのガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)（2026年10月時点で掲載の令和8年6月一部改正版）に基づく整理です。保存期間や削除まで含めた顧客台帳の要件は[顧客情報管理システムの要件｜個人情報保護法の安全管理措置・保存期間・削除を設計に落とす](https://www.issoh.co.jp/column/details/18264/)で扱っています。 ### 社内のシステム間で統合するときに法17条と18条の利用目的を確認する手順 [個人情報の保護に関する法律](https://laws.e-gov.go.jp/law/415AC0000000057)の第17条第1項は利用目的をできる限り特定することを求め、第18条第1項は、本人の同意を得ずに利用目的の達成に必要な範囲を超えて扱うことを禁じています。問い合わせ対応のために集めた電話番号を、統合後に販促の電話に使う場合は、この範囲を超えないかの確認が必要です。 確認の手順は単純です。統合する各システムの取得画面やプライバシーポリシーに書いた利用目的を並べ、統合後の使い道がその範囲に収まるかを見ます。収まらない場合、利用目的の変更は第17条第2項により変更前と関連性を有すると合理的に認められる範囲に限られ、変更したときは本人への通知か公表が必要になります。範囲を超えるなら本人の同意を取り直すしかありません。 ### グループ会社間の顧客データ統合では共同利用の5項目を事前に通知・公表する グループ会社どうしで顧客データを統合すると、別法人への個人データの提供になり、原則として第三者提供の規制を受けます。本人の同意を取らずに進める方法の1つが、第27条第5項第3号の共同利用です。ガイドライン3-6-3(3)では、提供の前に次の事項を本人に通知するか、容易に知り得る状態に置くことを求めています。 - 共同利用をする旨 - 共同して利用される個人データの項目 - 共同して利用する者の範囲 - 利用する者の利用目的 - 管理責任者の氏名または名称、住所、法人の場合は代表者の氏名 システム側では、どの顧客がどの時点の共同利用の公表に基づいて統合されたかを記録できるようにしておきます。公表の内容を後から変えたとき、対象を切り分けられなくなるからです。 ### Cookieや閲覧履歴を会員情報に結びつけるときの個人関連情報の同意確認 Webの閲覧履歴や購入履歴は、それ単体では氏名と結びつかない「個人関連情報」にあたる場合があります。ガイドライン3-7（法第31条関係）は、提供先がそれを個人データとして取得することが想定されるときは、原則として本人の同意が得られていることを確認せずに提供してはならないとしています。ID等を介して提供先が持つ個人データに付加する場合が典型です。 顧客データ統合で問題になるのは、広告や解析の外部事業者から受け取ったデータを、自社の会員IDに結びつける場面です。この統合を計画しているなら、会員登録や同意取得の画面で、閲覧履歴を会員情報に結びつけることへの同意を取る文言を先に用意してください。 ## 統合先の選び方｜CRMを正にするかDWHで組むかCDPを入れるかの分岐 統合した顧客データをどこに置くかは、データ源の数と使い道で決まります。製品の機能比較から入ると、使わない機能に費用を払う結果になりがちです。 ### CRM・DWH・CDPの3つの統合先を向く会社と運用体制で比べた一覧 | 統合先 | 向く会社 | 必要な運用体制 | | -------- | ----------- | ------------ | | CRMを正にする | 源が2〜3個のBtoB | 営業事務が重複を直す | | DWHで組む | 源が5個超で分析が主 | SQLを書ける担当がいる | | CDPを入れる | 配信の施策が週次で回る | 施策担当が自分で抽出する | CRMを正にする構成は、他のシステムからCRMへ顧客を寄せ、CRMの顧客IDを全社の共通IDにします。DWHで組む構成は、各システムのデータを集めてSQLで名寄せし、BIや配信ツールへ渡す仕組みです。BigQueryの上でIDグラフとセグメントを組み、パッケージ型CDPの役割を自前で担う構成と費用の分岐は[BigQueryでCDPを構築する構成：ID統合・セグメント生成・広告連携と権限設計](https://www.issoh.co.jp/tech/details/16666/)で具体的に示しています。 ### CDPを導入せずにCRMやDWHで顧客データ統合が済む会社の4条件 次の4つのうち1つでも当てはまるなら、CDPは導入しません。CRMかDWHで顧客データ統合は済みます。 - 顧客の大半が法人で、法人番号で名寄せが終わる - 統合したデータの使い道が、営業の訪問計画と月次の分析だけ - メールや広告の配信を週に1回以上の頻度で回す担当者がいない - Web行動データを会員IDに結びつける同意を取る予定が無い CDPが強みを出すのは、匿名のWeb行動と会員情報を結びつけ、施策担当がその場でセグメントを切って配信する場面です。BtoB中心でこの使い方をしない会社が契約すると、CRMと同じ顧客リストを高い費用で二重に持つだけになります。 ### 名寄せキーを決めないままCDPを先に契約して失敗する典型パターン 最も多い失敗は、名寄せキーとサバイバーシップルールを決めないままCDPを契約し、データ源を接続し始めるパターンです。CDPの名寄せ機能は、与えられたキーで結合する仕組みであり、どのキーを信じるかまでは決めてくれません。結果として、重複したままの顧客がCDPに入り、配信の重複は止まらず、契約の更新時に効果を説明できなくなります。 統合の設計と基盤の構築を外部に頼むなら、ツール選定より前の「棚卸し・正規化ルール・キーの決定」から一緒に進める支援先を選んでください。一創の[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)では、顧客データの棚卸しからDWHの設計、名寄せの実装、BIや配信ツールへの連携までを受託しています。CDPを入れるべきか、DWHで足りるかの判断から相談できます。 ## 顧客データ統合の進め方と名寄せ・費用に関するよくある質問と回答 顧客データ統合を検討する担当者から寄せられやすい質問に、本文の内容を踏まえて答えます。 ### 顧客データ統合とCDPの違いは何ですか？ 顧客データ統合は「顧客を1人1件にそろえる」という取り組みそのもので、CDPはその取り組みを実行する製品の種類の1つです。顧客データ統合はCRMやDWHでも実現できます。CDPは、統合した顧客データを施策担当がセグメントに分け、広告やメールの配信へ届けるところまでを1つの製品で担う点が特徴です。ETL・DWH・BIとの役割分担は[ETL・BI・DWH・CDPの違い｜4つの役割分担とどこから作るかの導入順序](https://www.issoh.co.jp/column/details/18981/)で比較しています。 ### 顧客データの名寄せはExcelでもできますか？ データ源が2つで、件数が数万件以内なら、Excelでも可能です。メールアドレスや電話番号を正規化した列を作り、XLOOKUPやPower Queryの結合で突き合わせます。限界が来るのは、データ源が3つを超えたときと、毎月の更新を担当者が手で繰り返すようになったときです。判定のルールが担当者の手元のファイルに埋もれ、異動とともに失われるため、その段階でDWHやCRM側に名寄せを移します。 ### 顧客データ統合にかかる期間と費用は何で決まりますか？ 期間を最も左右するのは、データ源の数と名寄せの難しさです。法人番号で結合できるBtoBの取引先データであれば、初回の統合は数週間で終わることもあります。共通キーの無いBtoCの顧客を複数システムから統合する場合は、正規化ルールの合意とサンプル確認に時間がかかり、数か月かかるのが普通です。費用は、ツールのライセンスより、棚卸しとルール決めに参加する社内外の人の工数が大半を占めます。 ### 統合したはずの顧客データで重複が再発するのはなぜですか？ 原因の多くは、顧客を登録する入口が統合後も変わっていないことにあります。ECの会員登録、営業の名刺入力、問い合わせフォームがそれぞれ既存顧客を検索せずに新規作成していれば、重複は毎日増えます。対策は2つです。入口の画面で既存顧客を照会してから登録する作りに直すこと、そして差分更新のたびに名寄せをかけ直す運用を組むことです。 ### 顧客データを統合すると何ができるようになりますか？ 最も効果が出やすいのは、同じ顧客への重複対応の削減です。営業と問い合わせ窓口が同じ顧客に別々に連絡する、同じ人に同じメールが2通届く、といった事態が減ります。次に、顧客単位の売上や購買回数を正しく数えられるため、LTVや解約の分析を実態に合わせることが可能です。BtoBでは、法人番号で統合することで、支店や営業所ごとに別の取引先として登録されていた取引を、1社単位の総額で把握できるようになります。法人番号は法人ごとに付くため、グループ会社をまとめて見るには、親会社との対応表を別に持つ必要があります。 ## 関連記事 - [データ統合とは？種類・方式の違いと名寄せの壁から導入判断まで解説](https://www.issoh.co.jp/column/details/18977/)：顧客以外のデータも含めた統合方式の選び方を、物理統合・仮想統合・同期連携の3系統で整理しています。 - [顧客管理システムとは？機能・Excelとの違い・脱Excelの判断基準を解説](https://www.issoh.co.jp/column/details/12809/)：CRMを顧客データの正にする構成を選ぶときの、顧客管理システムの機能と選び方を解説しています。 - [BigQueryでCDPを構築する構成：ID統合・セグメント生成・広告連携と権限設計](https://www.issoh.co.jp/tech/details/16666/)：DWHで顧客データ統合を組む場合の、IDグラフのテーブル設計と費用の目安を示しています。 - [データマッチング技術とは？名寄せ・類似検索の3系統とツールの選び方](https://www.issoh.co.jp/column/details/2377/)：共通キーの無い顧客を突き合わせる確率的マッチングの考え方とツールを扱っています。 --- 出典: [顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件]()（株式会社一創）