重複した顧客データを統合するための改善手順

「この顧客、CRMに3件登録されてますね」——問い合わせ対応中に営業から相談を受けて調べると、同じ会社が表記違いで何件も登録されている。請求書は片方のレコードにしか紐づいておらず、CS側は別のレコードで対応履歴を追っている。こういう状態は珍しくありません。

原因は単純です。フォーム経由・営業の手入力・他システムからのインポートなど、顧客データの入り口が複数あり、それぞれが自由入力で会社名や担当者名を受け取っている。統合的なチェックをかけずに運用してきた結果、「同一人物・同一企業なのに別レコード」が積み重なります。この記事では、これを止血しつつ安全に統合する手順を整理します。

重複が引き起こしている実害を具体化する

「データがきれいじゃない」で終わらせず、実害を言語化すると優先度が上がります。よくあるパターンは次の通りです。

• 営業がダブルアプローチする: 別の担当者が同じ企業に別々に連絡し、顧客側に「御社は情報共有できていないのか」と不信感を持たれる
• 請求が漏れる・二重になる: 契約情報が片方のレコードにしか紐づかず、請求書の送付先を誤る、あるいは同じ契約を二重計上する
• CSの対応履歴が分断される: 過去のクレームや問い合わせ履歴が別レコードに残り、対応時に「この顧客は初めて問い合わせてきた」と誤認する
• 分析・LTV計算が狂う: 同一顧客が複数IDにまたがるせいで、顧客単位の売上・解約率などの指標が実態より低く出る

これらが月に数件レベルで発生しているなら、名寄せの優先度は高いと判断してよいラインです。判断に迷う場合は既存プロダクト改善の最初の確認観点も参考にしてください。

なぜ名寄せは難しいのか

「同じ会社かどうか、人間なら一目で分かるのに、なぜシステム的に難しいのか」という疑問はもっともです。難しさの正体は次の3つです。

表記ゆれの幅が広い

会社名だけでも「株式会社トーチーズ」「(株)トーチーズ」「Torcheees株式会社」「トーチーズ」が同一企業を指します。住所も「東京都渋谷区」と「東京都渋谷区〇〇1-2-3」では粒度が違い、電話番号もハイフンの有無・市外局番の書き方で揺れます。単純な完全一致では大半の重複を取りこぼします。

「一致」の基準そのものが業務判断

会社名が完全一致していても、実は別法人(フランチャイズの別店舗、グループ会社の別部門)というケースもあります。逆に会社名が違っても、担当者のメールアドレスのドメインが同じで実質同一の窓口ということもある。「何をもって同一顧客とみなすか」はシステムではなく業務側の判断であり、これを最初にすり合わせずに進めると、統合ルールがぶれます。

誤統合はデータ損失を引き起こす

重複を残すリスクより、別々の顧客を誤って1つに統合してしまうリスクの方が深刻です。一度マージすると、片方の履歴・契約・請求情報が失われたり上書きされたりする可能性があり、元に戻すのが困難になります。名寄せの設計は「取りこぼしを減らす」より「誤統合を避ける」ことを優先すべきです。

統合の進め方

いきなり自動統合をかけるのではなく、次の順序で進めます。

1. 候補抽出(スコアリングで機械的に絞る)

まず「重複している可能性が高いレコードの組」を機械的に抽出します。完全一致ではなく、複数の項目を組み合わせたスコアリングで候補を出すのが実務的です。

• 会社名の正規化(全角/半角統一、法人格の除去、空白除去)後の類似度
• 電話番号・郵便番号の完全一致(表記ゆれが少なく信頼度が高い)
• メールアドレスのドメイン一致
• 住所の部分一致(番地レベルまで一致すれば信頼度が高い)

これらを重み付けしてスコア化し、閾値を超えたペアだけを「統合候補」としてリストアップします。閾値は最初は厳しめに設定し、誤検出(実は別会社なのに候補に出てくる)を許容しつつ、見逃し(本当は重複なのに候補に出てこない)を減らす方向で調整します。

2. 人の確認を必ず挟む

抽出した候補を、営業やCSなど実際に顧客を知っている人が目視で確認するステップを必ず入れます。ここを飛ばして自動マージすると、前述の誤統合リスクが現実化します。

• 候補ペアを一覧で見せ、「統合する」「統合しない(別会社)」「保留」を選ばせるレビュー画面を用意する
• 契約中・請求中のレコードが絡む候補は優先度を上げて確認する(実害が大きいため)
• レビュー結果を記録し、後から「なぜこの2件を統合したか」を追跡できるようにする

社内の運用に組み込みやすいのは、CRMやスプレッドシート上でレビューできる簡易ツールを用意する形です。全件を一度に処理しようとせず、まずは実害の大きい顧客(契約金額が大きい、対応中の案件がある)から着手します。

3. マージの実行と関連データの付け替え

統合が確定したら、どちらを「正」のレコードとして残すかを決め、関連データを付け替えます。

• 主レコードの選定基準を先に決める: 「作成日が古い方」「契約が紐づいている方」「情報が充実している方」など、優先順位をルール化しておく
• 関連テーブルの付け替えを漏れなく洗い出す: 契約・請求・対応履歴・タグ・添付ファイルなど、顧客IDを外部キーとして持つテーブルを事前に棚卸しし、付け替え漏れがないようにする
• 削除ではなく無効化(論理削除)にする: 統合後の副レコードは物理削除せず、「統合先ID」を持たせた状態で無効化する。誤統合が後から発覚した場合に復元できるようにするため
• 統合ログを残す: いつ・誰が・どの2件を・どちらを主として統合したかを記録する。後から問い合わせ履歴の不整合に気づいたときの調査に必須

4. 再発防止(入口を締める)

統合しても、データの入口が複数のまま自由入力を許していれば、また重複が積み上がります。再発防止まで含めて初めて「統合」が完了したと言えます。

• 新規登録時にリアルタイムで類似候補を提示する: フォーム入力や営業の手動登録時に、候補抽出と同じロジックで「似た顧客が既に存在します」と警告する
• インポート経路にも同じチェックをかける: 他システムからの一括インポート時に、既存データとの突合を自動で行う
• 入力ルールを軽く統一する: 会社名の法人格表記や電話番号のフォーマットなど、最低限のバリデーションをフォーム側にかけておくと表記ゆれの発生源自体が減る

いきなり自動統合をしてはいけない理由

「候補抽出のスコアが高いものは自動でマージしてしまえば早い」という誘惑がありますが、これは避けるべきです。理由は次の通りです。

• 契約中の顧客を誤って統合すると、請求先の取り違えなど金銭が絡む実害に直結する
• 一度自動マージしたデータの復元は、ログを丁寧に残していても業務的にコストが高い
• 業務側が「この2社は実は別法人」と気づくのは、多くの場合システムのスコアリングでは拾えない文脈情報(担当者の口頭確認など)による

自動化してよいのは「候補抽出まで」で、「確定・実行」は人の判断を経由させる設計を基本線にしてください。関連する既存データの整合性チェック全般についてはデータ不整合の洗い出しと修復でも扱っています。

外注する場合に確認すべきこと

名寄せ・データ統合を外部に依頼する際は、次の点を発注前に確認しておくと安心です。

• 候補抽出と実行を分離した設計を提案してくるか: 「AIで自動統合します」だけの提案は、誤統合リスクへの理解が浅い可能性がある
• 関連テーブルの棚卸しを工程に含めているか: 契約・請求・対応履歴などの付け替え漏れは統合作業で最も事故が起きやすいポイント
• ロールバック(復元)手段を用意しているか: 論理削除・統合ログなど、誤統合が発覚した際に戻せる設計になっているか
• 再発防止(入口対策)まで含めた提案か: 一度統合して終わりではなく、新規登録時のチェックまで設計に含まれているか

私たちが対応する技術スタックの詳細は技術ページに、進め方全体はモダナイゼーション支援サービスにまとめています。

まとめ

• 重複した顧客データは営業のダブルアプローチ・請求ミス・CS対応の分断という具体的な実害を生む。まず実害を数える
• 名寄せは「候補抽出(スコアリング)→人の確認→マージと関連データの付け替え→再発防止」の順で、誤統合リスクを避けながら段階的に進める
• スコアが高くても自動マージは避け、契約・請求が絡む候補は特に人の判断を必須にする

顧客データの重複に心当たりがある、あるいは営業・CS・請求のどこかで「同じ顧客なのに情報がバラバラ」という声が出ているなら、まず現状の診断から始めることをおすすめします。torcheeesでは既存プロダクト改善の診断と、継続的な改善支援を提供しています。まずはお問い合わせフォームから現状を聞かせてください。