重複排除と名寄せを仕組みで回す。CRMデータクレンジングは、監査と再発防止まで含めて設計することが核心です。
「同じ会社が複数の表記で登録されている」「既存顧客か新規顧客かをすぐに判断できない」「CRMを信用できず、営業担当者がExcelで別の顧客リストを作っている」——このような状態では、CRMに情報を集めても業務や判断に生かしにくくなります。
CRMデータクレンジングとは、CRMに蓄積された顧客データの重複排除、名寄せ、表記揺れの修正、欠損データの整理を行い、データの信頼性を保つ運用プロセスです。単発の修正作業ではなく、入力、統合、利用、監査までを一つの流れとして設計します。
本記事は「RevOps(レベニューオペレーションズ)入門|営業・マーケ・CSを統合して収益を最大化する方法」シリーズの一部です。
この記事でわかること
CRMのデータが増えるにつれて重複や表記揺れが目立ってきた導入担当者、営業企画、RevOps担当者が、クレンジングの設計から継続運用までを整理できる内容です。
- CRMデータの品質が低下する原因 — 入力経路の分散、ルールの不統一、経年変化、責任者不在がどのように重複や欠損を生むかを整理します。
- 名寄せ手法の使い分け — 完全一致、あいまい一致、正規化マッチングの特徴と、対象データに応じた選び方を解説します。
- 重複判定とマージの設計方法 — 判定キー、信頼度、残す値の優先ルールを決め、人が判断する範囲と自動化する範囲を分けます。
- クレンジングの実施手順 — 現状分析、ルール策定、テスト、実行、再発防止を順番に進める方法を示します。
- データ品質を保つ監査と運用体制 — 点検項目、役割分担、プロパティ管理を仕組みとして継続する考え方を解説します。
最後まで読むと、自社のデータ品質課題を数値で把握し、優先順位をつけてクレンジングを進められるようになります。
CRMデータの品質が低下する構造的な原因
データ品質の問題は、担当者の入力ミスだけで起きるわけではありません。複数の入力経路、異なる管理ルール、更新されない情報が重なり、時間とともに構造的な問題になります。原因を分けて捉えると、修正後の再発も防ぎやすくなります。
入力経路ごとにルールが分かれている
CRMには、Webフォーム、営業担当者による手動入力、CSVインポート、API連携、名刺管理ツールなどからデータが入ります。入力経路ごとに項目名や形式が異なると、同じ人物や会社でも別レコードとして登録されやすくなります。
| 入力経路 |
重複・品質低下の典型パターン |
| Webフォーム |
フリーメール(gmail等)での登録、会社名の省略・誤入力 |
| 営業の手動入力 |
入力基準のばらつき、必須項目の空欄 |
| CSVインポート |
旧データの一括投入による大量重複の発生 |
| API連携(MA等) |
連携元システムとの項目マッピングのずれ |
| 名刺管理ツール |
OCR読取の誤変換、姓名の逆転 |
特に、顧客リスト、担当者マスタ、商談一覧を別々のExcelやスプレッドシートで管理していると、それぞれに異なる情報が残ります。CRMへ移行する際に単純結合すると、重複だけでなく、どの値を正とするか決められない状態も生まれます。
情報が変化しても更新のきっかけがない
部署、役職、電話番号、所在地などの顧客情報は変化します。CRMに登録した時点では正しくても、更新のきっかけが設計されていなければ、古い値と新しい値が並存します。
例えば、担当者が転職後に別のメールアドレスで登録された場合、氏名だけでは同一人物か判断できません。会社の名称変更や移転があった場合も、旧会社レコードと新会社レコードを別企業として扱うと、活動履歴や取引が分断されます。
責任者と判断基準が決まっていない
クレンジングを「気づいた人が直す作業」にすると、担当者ごとに判断が変わります。片方の担当者は会社名が似ていれば統合し、別の担当者は電話番号まで一致しない限り残す、といった差が生まれます。
品質を安定させるには、データ領域ごとに判断者を決め、重複候補の抽出条件、統合条件、残す値の優先ルールを共有します。担当者が交代しても同じ判断ができる状態にすることが、データ品質管理の出発点です。
データ品質の低下が業務全体へ波及する
| 影響する業務 |
データ品質が低い場合 |
整理後の状態 |
| レポート |
顧客数や取引数を重複して集計する |
集計対象と関連付けが揃う |
| マーケティング |
同じ相手へ重複して連絡する |
コンタクト単位で履歴を確認できる |
| 営業 |
既存顧客か新規顧客か判断しにくい |
会社と取引の関係をたどれる |
| 顧客支援 |
問い合わせ履歴が複数レコードへ分かれる |
顧客単位で経緯を確認できる |
| CRM運用 |
Excelによる個別管理が増える |
CRMを共通の判断基盤として使える |
CRMは顧客情報を保管する場所だけではなく、営業プロセスの標準化、部門間の連携、経営判断を支える基盤です。データクレンジングは見た目を整える作業ではなく、CRMを事業運営に使える状態へ戻す取り組みと捉える必要があります。
名寄せは関連データをつなぎ直す作業
名寄せとは、同一人物または同一企業に該当する複数のレコードを見つけ、一つのレコードへ統合するプロセスです。候補を抽出し、同一性を判断し、関連する履歴を保ちながらマージするところまでが名寄せに含まれます。
コンタクトと会社では影響範囲が異なる
| 対象 |
主な判定材料 |
統合時に確認する関連情報 |
| コンタクト |
メールアドレス、氏名、電話番号、会社 |
メール配信、活動履歴、会社との関連 |
| 会社 |
会社名、ドメイン、電話番号、住所 |
コンタクト、取引、契約に関する情報 |
| 取引 |
取引名、会社、金額、進行状況 |
パイプライン、活動、担当者 |
次の表は、名寄せの単位ごとの判定難易度と影響範囲を整理したものです。
| 名寄せの単位 |
判定の難易度 |
影響範囲 |
| コンタクト(個人)の名寄せ |
中 |
メール配信、活動履歴の統合 |
| 会社レコードの名寄せ |
高 |
コンタクト・商談・契約の紐付けに影響 |
| 商談の名寄せ |
低(発生頻度が低い) |
パイプラインレポートの精度 |
会社レコードが分かれると、関連するコンタクトや取引も別々に見えるようになります。そのため、会社の名寄せでは会社名の一致だけでなく、統合後にどのコンタクトと取引が紐づくかまで確認します。
リレーションを保つことが名寄せの目的になる
HubSpotのようにコンタクト、会社、取引が関連付けられるCRMでは、個々のレコードをきれいにするだけでは不十分です。コンタクトから会社、会社から取引、取引から顧客対応や請求に関する情報へたどれる状態を保つ必要があります。
例えば、同一企業の会社レコードが分かれていると、一方には担当者、もう一方には取引が紐づいていることがあります。この場合、会社名だけを統一しても関連付けを直さなければ、営業担当者は企業全体の状況を把握できません。
以下の画面は、HubSpotの取引一覧をテーブルビューで表示した例です。

一覧で使用する列や絞り込み条件も、クレンジング後の確認に使えます。会社、担当者、取引ステージなど、業務上の判断に必要な項目が同じ基準で入力されているかを見ると、単体の重複だけでなく関連付けの不整合も見つけやすくなります。
統合前に残す情報を決める
マージでは、どちらを主レコードにするかを先に決めます。作成日が古いレコードを残す方法だけでなく、活動履歴が揃っているレコード、営業担当者が確認したレコード、関連する取引が正しく紐づいているレコードを主にする方法があります。
ただし、空欄を埋めるために値を無条件で混ぜると、古い住所や別人の電話番号を残すおそれがあります。更新日時、入力経路、活動履歴を並べ、矛盾しない値は統合し、矛盾する値はデータオーナーの判断へ回すルールに分けます。
名寄せアルゴリズムの選び方
重複候補の抽出には、完全一致、あいまい一致、正規化マッチングを使い分けます。どれか一つに統一するのではなく、誤って統合する影響と、重複を見逃す影響を比べて選ぶことがポイントになってきます。
| 比較軸 |
完全一致 |
あいまい一致 |
正規化マッチング |
| 精度(誤判定の少なさ) |
★★★ |
★★☆ |
★★★ |
| 検出率(見逃しの少なさ) |
★☆☆ |
★★★ |
★★★ |
| 日本語対応 |
★☆☆ |
★★☆ |
★★★ |
| 実装の容易さ |
★★★ |
★★☆ |
★★☆ |
| 処理速度 |
★★★ |
★☆☆ |
★★☆ |
| 推奨用途 |
メールアドレスの重複検出 |
氏名の表記揺れ検出 |
会社名・住所の名寄せ |
| レコードA(原文) |
レコードB(原文) |
正規化後A |
正規化後B |
結果 |
| 株式会社ABC |
(株)ABC |
abc |
abc |
重複 |
| ABC株式会社 |
ABC(株) |
abc |
abc |
重複 |
| 株式会社エー・ビー・シー |
(株)ABC |
エービーシー |
abc |
要確認(手動判断) |
| 項目 |
内容 |
| 判定ロジック |
データの正規化(前処理)→ 一致判定 |
| 正規化の内容 |
法人格の統一、全角/半角変換、カタカナ/英字統一、不要文字の除去 |
| 精度 |
高い(正規化ルールの設計次第) |
| 検出率 |
高い |
| 適する場面 |
日本語の会社名・住所の名寄せに最適 |
| レコードA |
レコードB |
類似度(目安) |
判定(閾値80%の場合) |
| 株式会社ABC |
(株)ABC |
約65% |
非重複(閾値未満) |
| 株式会社エービーシー |
株式会社ABC |
約40% |
非重複(閾値未満) |
| 田中太郎 |
田中太朗 |
約85% |
重複候補 |
| ABCホールディングス |
ABCグループ |
約70% |
非重複(閾値未満) |
| レコードA |
レコードB |
判定キー |
結果 |
| tanaka@example.co.jp |
tanaka@example.co.jp |
メール |
重複 |
| tanaka@example.co.jp |
t.tanaka@example.co.jp |
メール |
非重複(別メール) |
| 03-1234-5678 |
03-1234-5678 |
電話番号 |
重複 |
| 03-1234-5678 |
0312345678 |
電話番号 |
非重複(ハイフン有無) |
完全一致は識別性の高い項目に使う
完全一致は、指定した値が同じレコードを重複候補として抽出する方法です。メールアドレス、法人番号、正規化済みの電話番号など、同一性を判断しやすい項目に向いています。
| 比較例 |
判定 |
| 同じメールアドレス |
重複候補として扱う |
| ハイフンの有無が異なる電話番号 |
正規化前は一致しない |
| 同じ氏名で会社が異なる |
氏名だけでは統合しない |
| 同じドメインで会社名が異なる |
グループ会社や組織構造を確認する |
以下の表は、完全一致による判定の特徴をまとめたものです。
| 項目 |
内容 |
| 判定ロジック |
指定フィールドの文字列が100%一致 |
| 典型的な判定キー |
メールアドレス、法人番号、電話番号 |
| 精度 |
非常に高い(誤判定が少ない) |
| 検出率 |
低い(表記揺れのある重複を検出できない) |
| 適する場面 |
メールアドレスベースの個人重複検出 |
完全一致は判断を自動化しやすい一方、表記が少しでも違えば候補に出ません。そのため、完全一致で拾えなかったレコードを次の方法で段階的に確認します。
あいまい一致は候補抽出に使う
あいまい一致は、文字列の類似性から重複の可能性があるレコードを探す方法です。会社名、氏名、住所のように表記揺れが起こりやすい項目で利用できます。
次の表は、あいまい一致による判定の特徴をまとめたものです。
| 項目 |
内容 |
| 判定ロジック |
文字列の類似度(Levenshtein距離、Jaro-Winkler距離等)を計算 |
| 典型的な判定キー |
会社名、氏名、住所 |
| 精度 |
中(閾値の設定次第で誤判定が発生) |
| 検出率 |
高い(表記揺れのある重複も検出可能) |
| 適する場面 |
会社名ベースの企業重複検出 |
ただし、似た会社名や同姓同名を誤って同一と判断する可能性があります。あいまい一致の結果は自動マージの条件にせず、電話番号、住所、ドメイン、関連する取引を追加で比較し、一致する情報が揃った候補だけを統合対象にします。
正規化してから一致判定する
正規化とは、比較前に表記を共通の形式へ変換することです。会社名の法人格、英数字の全角と半角、空白、記号、電話番号のハイフンなどを揃えることで、見た目が異なる同一データを比較しやすくします。
| 対象 |
正規化前の違い |
正規化の考え方 |
| 会社名 |
法人格の位置や略記 |
比較用の値から法人格を分ける |
| 英数字 |
全角と半角、大文字と小文字 |
比較用の形式を統一する |
| 電話番号 |
ハイフンや空白の有無 |
数字を比較できる形に整える |
| 住所 |
空白や区切り記号の違い |
区切り方を揃える |
| 氏名 |
姓名間の空白 |
比較用の空白を整理する |
以下の表は、正規化の代表的なカテゴリと変換の考え方を示したものです。
| 正規化カテゴリ |
変換前 |
変換後 |
ルール |
| 法人格の統一 |
株式会社ABC |
ABC |
「株式会社」「(株)」「有限会社」等を除去 |
| 法人格の統一 |
(株)ABC |
ABC |
同上 |
| 全角→半角 |
ABC |
ABC |
英数字を半角に統一 |
| カタカナ→半角 |
エービーシー |
エービーシー |
または英字に統一 |
| スペースの統一 |
A B C |
ABC |
スペースを除去 |
| 旧字体→新字体 |
髙橋 |
高橋 |
旧字体を新字体に変換 |
| 大文字→小文字 |
ABC Corp. |
abc corp |
英字を小文字に統一 |
| 記号の除去 |
ABC・ジャパン |
ABCジャパン |
中黒・ハイフン等を除去 |
表示用の正式名称と、照合に使う正規化済みの値は分けて持つと運用しやすくなります。表示名まで機械的に書き換えると、正式表記に必要な文字を失う場合があるためです。
段階的なマッチングで範囲を広げる
| 段階 |
抽出方法 |
処理方法 |
| 高い信頼度 |
識別性の高い項目の完全一致 |
関連情報を確認して統合 |
| 中程度の信頼度 |
正規化後の複数項目一致 |
条件を満たす候補をレビュー |
| 低い信頼度 |
会社名や氏名のあいまい一致 |
人が周辺情報を確認して判断 |
初めから広い条件で候補を出すと、レビュー対象が増え、本当に確認したい候補が埋もれます。まず完全一致を整理し、次に正規化後の一致、最後にあいまい一致へ進むスモールスタートが適しています。
重複判定基準とマージルールを設計する
マッチング方法を選んだ後は、どの項目が一致したら統合するかを定義します。判定基準はデータの種類や入力経路によって変わるため、すべてのレコードへ同じ条件を当てはめないことが重要です。(出典:Deduplicate records in HubSpot)
コンタクトの判定キーを組み合わせる
| 判定条件 |
信頼度 |
処理方針 |
| メールアドレスが完全一致 |
高い |
活動履歴と会社を確認して統合 |
| 氏名と会社名が正規化後に一致 |
中程度 |
メールや電話番号を追加確認 |
| 氏名と電話番号が一致 |
中程度 |
所属会社と活動履歴を追加確認 |
| 氏名だけが類似 |
低い |
自動統合せず人が判断 |
| 判定パターン |
判定キーの組み合わせ |
信頼度 |
自動マージ可否 |
| パターン1 |
法人番号(完全一致) |
非常に高い |
可 |
| パターン2 |
会社名(正規化一致)+ 電話番号 |
高い |
条件付き可 |
| パターン3 |
会社名(正規化一致)+ 住所(正規化一致) |
高い |
条件付き可 |
| パターン4 |
会社名(正規化一致)のみ |
中 |
不可(手動判断必須) |
| パターン5 |
ドメイン名(完全一致) |
高い |
条件付き可 |
| 判定パターン |
判定キーの組み合わせ |
信頼度 |
自動マージ可否 |
| パターン1 |
メールアドレス(完全一致) |
非常に高い |
可 |
| パターン2 |
氏名 + 会社名(正規化一致) |
高い |
条件付き可 |
| パターン3 |
氏名 + 電話番号(完全一致) |
高い |
条件付き可 |
| パターン4 |
氏名のみ(あいまい一致) |
低い |
不可(手動判断必須) |
メールアドレスが同じ場合でも、共有アドレスが使われていることがあります。メールアドレスだけで判断する前に、氏名、所属、活動履歴が一人分として整合しているかを見ると、誤った統合を避けやすくなります。
会社の判定キーは関連情報まで見る
| 判定条件 |
信頼度 |
処理方針 |
| 法人番号が一致 |
高い |
名称変更や関連レコードを確認 |
| 正規化した会社名と電話番号が一致 |
高い |
住所とドメインを確認 |
| 正規化した会社名と住所が一致 |
高い |
移転履歴の有無を確認 |
| ドメインが一致 |
中程度 |
グループ会社や部門利用を確認 |
| 正規化した会社名だけが一致 |
中程度 |
自動統合せず周辺情報を比較 |
BtoBの会社データでは、同一ドメインを複数の組織が使う場合や、会社ごとに複数ドメインを持つ場合があります。会社名、電話番号、住所、ドメインのうち複数の情報が整合するかで判断し、関連するコンタクトと取引も合わせて確認します。
残す値の優先順位を項目別に決める
| 優先ルール |
考え方 |
適する項目 |
| 最新値優先 |
更新日時が新しいほうの値を採用 |
電話番号、住所、役職、部署 |
| 空でない値優先 |
値が入っているほうを採用 |
メールアドレス、業種、従業員数 |
| 手動入力優先 |
APIやフォームより営業の手動入力を優先 |
決裁者情報、商談メモ |
| マスターレコード優先 |
古い(先に作成された)レコードを基準とする |
CRM ID、作成日 |
| 活動量が多いほうを優先 |
紐付く活動ログが多いレコードを基準にする |
コンタクトの主レコード選定 |
すべての項目を「新しい値優先」にすると、誤入力で正しい値を上書きする可能性があります。項目ごとに優先ルールを分け、判断できない値は保持したままレビュー対象へ送る設計が適しています。
CRMデータクレンジングの実施手順
クレンジングは、現状を把握してから対象とルールを決め、限定した範囲で試し、結果を確認しながら広げます。いきなり削除や一括更新をすると、活動履歴や関連付けを失うおそれがあります。各段階の完了条件を決めてから次へ進みます。
| KPI |
計算式 |
目標値 |
計測頻度 |
| 重複率 |
重複レコード数 ÷ 総レコード数 × 100 |
5%以下 |
月次 |
| 必須項目入力率 |
入力済み件数 ÷ 該当レコード総数 × 100 |
90%以上 |
月次 |
| データ鮮度 |
更新日6ヶ月以上前のレコード ÷ 総レコード × 100 |
30%以下 |
四半期 |
| 表記揺れ率 |
正規化で検出された不統一件数 ÷ 総件数 × 100 |
5%以下 |
四半期 |
| バウンス率 |
ハードバウンス件数 ÷ メール配信数 × 100 |
2%以下 |
月次 |
| # |
監査項目 |
確認方法 |
判定基準 |
対処 |
| 1 |
全体の重複率の推移 |
重複率の前四半期比を計測 |
前四半期より悪化していれば要因分析 |
重複発生源の特定と対策 |
| 2 |
データの鮮度チェック |
最終更新日が6ヶ月以上前のレコード割合 |
30%を超えたら要対応 |
アーカイブまたはデータ更新施策 |
| 3 |
セグメント精度の確認 |
主要セグメント(業種、企業規模等)の内訳が妥当か |
「不明」「その他」が20%以上は要改善 |
データ補完施策の実施 |
| 4 |
プロパティの棚卸し |
全カスタムプロパティの利用率を確認 |
過去3ヶ月間使用されていないプロパティ |
廃止または統合を検討 |
| 5 |
連携データの整合性 |
CRMと連携先システムのレコード件数を突合 |
件数に5%以上の乖離があれば要確認 |
連携エラーの調査・修正 |
| 6 |
ライフサイクルステージの正確性 |
各ステージのレコード数と実態の整合 |
明らかに不整合がある場合は要修正 |
ステージ更新漏れの一括修正 |
| 7 |
データガバナンスルールの見直し |
入力ルール・命名規則の有効性を評価 |
現場の運用実態とルールの乖離がないか |
ルールの改訂・現場への再周知 |
| # |
監査項目 |
確認方法 |
判定基準 |
対処 |
| 1 |
新規重複レコードの検出 |
CRMの重複管理ツールを実行 |
新規重複が10件以上で要対応 |
手動レビュー+マージ |
| 2 |
必須項目の欠損率 |
プロパティ別の入力率レポートを確認 |
欠損率が10%を超える項目は要改善 |
入力促進の施策を検討 |
| 3 |
バウンスメールの処理 |
ハードバウンスのレコードを抽出 |
ハードバウンスは即時対応 |
メールアドレスの無効化/削除 |
| 4 |
入力ルールの遵守状況 |
命名規則違反のレコード数を確認 |
違反率5%以上で要対応 |
入力者への周知・ルール再徹底 |
| 5 |
新規プロパティの確認 |
当月に追加されたカスタムプロパティを確認 |
不要なプロパティが増えていないか |
不要プロパティの整理・削除 |
現状分析で問題の発生場所を絞る
最初に、重複、欠損、表記揺れ、古い情報、使われていないプロパティを分けて確認します。件数だけでなく、どの入力経路から問題が生じているかを見ます。
| 分析項目 |
確認方法 |
目安基準 |
| 総レコード数 |
CRMのレコード件数を確認 |
ー |
| 推定重複率 |
メールアドレスの重複件数 ÷ 総件数 |
10%以下が目標 |
| 必須項目の欠損率 |
主要項目の空欄率を確認 |
各項目90%以上入力が目標 |
| 表記揺れの状況 |
会社名の法人格表記パターンを集計 |
パターンが3種類以下が理想 |
| 古いデータの割合 |
最終更新日が1年以上前のレコード割合 |
30%以下が目標 |
| 不要プロパティ数 |
使用されていないカスタムプロパティ数 |
全プロパティの20%以下 |
| 確認対象 |
確認方法 |
次へ進む条件 |
| 重複候補 |
メール、会社名、電話番号などで抽出 |
対象と判定キーを説明できる |
| 欠損項目 |
業務で使う主要項目の空欄を抽出 |
補完する項目と残す項目を分けられる |
| 表記揺れ |
会社名や電話番号の値を一覧化 |
正規化ルールを定義できる |
| 古い情報 |
更新履歴と活動履歴を比較 |
更新、保留、アーカイブを分けられる |
| 不要プロパティ |
利用場面と入力状況を確認 |
維持、統合、廃止候補を分けられる |
この段階では削除せず、問題の全体像と影響範囲を把握します。レポートやワークフローで利用しているプロパティも洗い出し、変更すると影響する処理を確認します。
ルールと対象範囲を決める
次に、対象オブジェクト、判定キー、マージ後に残す値、レビュー担当者を決めます。会社レコードを整理する場合は、関連するコンタクトと取引の扱いも同じルールへ含めます。
優先順位は、判断しやすく影響を確認しやすい範囲から付けます。メールアドレスの完全一致、正規化後の電話番号一致、会社レコードの複数項目一致というように対象を分けると、各処理の結果を比較できます。
次の表は、クレンジングに着手する際の優先順位の考え方を示したものです。
| 優先順位 |
対象 |
理由 |
| 1 |
完全一致の重複排除(メールアドレス) |
自動化可能、即効性が高い |
| 2 |
会社レコードの名寄せ |
影響範囲が広い(関連コンタクト・商談) |
| 3 |
表記揺れの修正(法人格、全角/半角) |
正規化ルールで一括処理可能 |
| 4 |
不完全データの補完 |
段階的に対応可能 |
| 5 |
古いデータのアーカイブ |
影響が限定的、後回しでも問題ない |
バックアップと限定テストを行う
実行前に対象データをエクスポートし、変更前の値とレコード識別子を保存します。復元時に必要な項目、関連付け、担当者、更新前の値が含まれているかを確認します。
その後、限定した候補でマージ結果を確認します。主レコード、残ったプロパティ値、活動履歴、会社とコンタクトと取引の関連付けが想定どおりなら対象を広げ、どれかが欠ける場合はルールを修正して再度限定テストを行います。
実行結果を再計測して防止策へつなげる
| 実行前 |
実行後に確認すること |
| 重複候補が複数ある |
同じ条件の候補が残っていないか |
| 必要項目に空欄がある |
補完元と更新経路が記録されているか |
| 表記が統一されていない |
新規入力にも同じ正規化が働くか |
| 関連付けが分断されている |
コンタクト、会社、取引をたどれるか |
| 不要項目が多い |
現場が使う項目に絞られているか |
クレンジング後は、減った候補だけを見て終了しません。レポート、リスト、ワークフロー、担当者の画面で使われるデータまで確認し、業務の流れが維持されていることを完了条件にします。
再発を防ぐ入力設計と自動化
クレンジングで現在のデータを直しても、同じ入力経路と運用を残せば重複は再発します。入力時の制御、正規化、重複候補の通知を組み合わせ、問題を早い段階で止める設計へ移します。人の注意力ではなく、引き継げる仕組みで品質を保つことが重要です。
| 影響領域 |
具体的なインパクト |
| レポートの信頼性 |
重複レコードにより顧客数・商談数が過大計上される。経営判断の精度が低下 |
| マーケティング施策 |
同一人物に重複メールが配信され、顧客体験が悪化。配信数課金の無駄 |
| 営業活動 |
担当者が「この会社は既存顧客か新規か」の判別に時間を浪費。属人的な記憶に依存 |
| カスタマーサクセス |
顧客の全体像が把握できず、適切なフォローが遅れる |
| CRM定着率 |
「データが信用できない」→「自分でExcel管理」→CRM離れの悪循環 |
以下の表は、再発防止のために組み合わせる代表的な施策です。
| 防止策 |
具体的な施策 |
| 入力時のバリデーション |
フォーム・CRM入力画面で必須項目・形式チェックを設定 |
| 重複チェックの自動化 |
新規レコード作成時に既存レコードとの重複チェックを自動実行 |
| 正規化の自動処理 |
ワークフローやData Hub等で入力値を自動正規化 |
| 入力ガイドラインの整備 |
命名規則・入力ルールをドキュメント化し、CRM画面にヘルプテキストを設置 |
| 定期的なデータ監査 |
月次・四半期の定期監査スケジュールを策定 |
入力項目を業務上必要な範囲に絞る
使われていないプロパティが増えると、入力者はどの項目が重要か判断しにくくなります。営業活動、セグメント、レポート、自動化のいずれにも使わない項目は、追加前に用途を確認します。
| 設計項目 |
決める内容 |
| 必須項目 |
次の業務へ進むために必要な情報 |
| 選択肢 |
集計や自動化で使う共通の分類 |
| ヘルプテキスト |
入力形式と判断例 |
| 編集権限 |
値や項目を変更できる担当者 |
| 利用先 |
レポート、リスト、ワークフローとの関係 |
項目を最小限にすると、新人や異動後の担当者も入力の優先順位を理解しやすくなります。新しいプロパティは、利用目的と管理者を決めてから追加する運用にします。
次の表は、入力ルールを具体的な規定として整理した例です。
| ルール項目 |
具体的な規定 |
設定方法 |
| 会社名 |
正式名称(登記名)で入力。「株式会社」は前後を統一 |
CRM上にヘルプテキストを設置 |
| 電話番号 |
ハイフン付き(03-1234-5678形式)で統一 |
入力形式のバリデーションを設定 |
| メールアドレス |
小文字で統一。共有アドレス(info@等)は備考に記載 |
自動小文字変換の設定 |
| 住所 |
都道府県から記載。丁目・番地はハイフン区切り |
プルダウン+フリーテキスト |
| 業種 |
CRMのマスタ定義に従いプルダウン選択 |
プルダウン項目として設定 |
| 部署名 |
正式名称。略称不可 |
ヘルプテキストで例示 |
正規化と候補抽出を自動化する
HubSpotでは、ワークフローやData Hubのデータ品質管理に関する機能を組み合わせ、入力値の整形や重複候補の確認を進められます。例えば、新規レコードの作成後に比較用の値を整え、候補を抽出し、担当者へレビューを依頼する流れを設計できます。
ただし、あいまい一致の候補を自動で統合すると、似た名称の別企業や同姓同名のコンタクトをまとめる可能性があります。完全一致など判断根拠が明確な処理は自動化し、企業の関係性や活動履歴を読む必要がある候補は人が最終判断します。
コンタクトから請求までの全体フローで見る
データ品質は、コンタクトの登録だけで完結しません。コンタクトが会社へ関連付けられ、取引が作成され、顧客として対応され、請求に関する情報へつながる流れの中で、同じ識別情報と更新ルールを使う必要があります。
| フロー |
品質管理のポイント |
| コンタクト登録 |
メール、氏名、会社との関連を整える |
| 会社管理 |
正式名称、ドメイン、住所を共通化する |
| 取引管理 |
会社、担当者、取引ステージを関連付ける |
| 顧客対応 |
問い合わせや活動履歴を顧客単位で残す |
| 請求に関する管理 |
取引先と取引の識別情報を揃える |
一元管理、自動化、可視化は別々の取り組みではありません。正しい関連付けで一元管理し、入力と更新を自動化し、その結果をレポートで可視化する一連の設計として扱います。
定期監査と組織体制で品質を維持する
データ品質は、クレンジング実施後も入力や連携のたびに変化します。監査では重複の件数だけでなく、発生源、関連付け、使われていない項目を確認し、入力設計へ改善を戻します。担当者と判断ルールを固定すると、監査を継続しやすくなります。
日常的に確認する項目を決める
| 監査項目 |
確認内容 |
分岐する対応 |
| 新しい重複候補 |
入力経路と判定キー |
同じ経路に偏れば入力設定を修正 |
| 必須項目の欠損 |
欠けている項目と担当部門 |
業務で必要なら必須化、不要なら項目を整理 |
| メールの配信エラー |
無効な宛先と関連レコード |
修正元があれば更新、なければ配信対象から分離 |
| 表記ルール違反 |
会社名、電話番号、住所 |
共通パターンなら正規化へ追加 |
| 新しいプロパティ |
用途、管理者、利用先 |
用途が明確なら維持、重複するなら既存項目へ統合 |
監査で同じ問題が繰り返される場合、担当者への再周知だけで終わらせません。入力画面、インポート手順、連携元のマッピングのどこで発生したかを特定し、その経路へ防止策を入れます。
以下の表は、年次で見直すレビュー項目です。
| レビュー項目 |
内容 |
| データ品質KPIの年間推移 |
重複率、欠損率、表記揺れ率の12ヶ月推移を確認 |
| クレンジングの費用対効果 |
クレンジングに投じた工数とデータ品質の改善度合いを評価 |
| ルールの有効性評価 |
入力ルール・正規化ルール・監査プロセスの有効性を評価 |
| 組織体制の見直し |
データオーナー・監査担当者のアサインが適切か確認 |
| ツール・仕組みの見直し |
クレンジング・監査に使用しているツールの有効性を評価 |
データ領域ごとにオーナーを置く
| データ領域 |
オーナー |
責任範囲 |
| 顧客マスタ(会社) |
営業企画またはRevOps |
正式名称マスタの管理、重複排除の実行 |
| コンタクト情報 |
マーケ+営業の共同管理 |
入力ルールの遵守、バウンス対応 |
| 商談データ |
営業マネージャー |
パイプラインの正確性、ステージ定義の遵守 |
| マーケティングデータ |
マーケ部門 |
リード定義、セグメント定義の管理 |
| 全体のデータガバナンス |
情シスまたは導入担当 |
監査の実施、ツール管理、ルール策定 |
データオーナーはすべての修正を一人で行う役割ではありません。判断基準を管理し、例外が出たときにどのルールを採用するかを決め、次回の監査へ反映する役割です。
監査結果を運用改善へ戻す
監査は、問題の一覧を作って終えるものではありません。重複の発生源がフォームなら入力項目を見直し、CSVインポートなら照合キーとマッピングを修正し、手動入力なら必須項目とヘルプテキストを調整します。
改善後は同じ条件で候補を抽出し、再発が減ったかを確認します。結果が変わらなければ、発生源の仮説を見直し、別の入力経路や更新処理を調べます。この循環を続けることで、クレンジングを単発作業から品質管理の運用へ変えられます。
BtoBマーケティングの全体像はBtoBマーケティング完全ガイドで体系的にまとめています。また、このテーマのカテゴリ全体はCRM基礎・導入で網羅しています。
よくある質問
CRMデータクレンジングはどこから始めればよいですか?
最初は、識別しやすいメールアドレスや電話番号の完全一致から重複候補を抽出します。候補をすぐに削除せず、関連する会社、取引、活動履歴を比較し、どの入力経路で重複したかまで整理してください。判断ルールが固まってから会社名の正規化やあいまい一致へ範囲を広げます。
あいまい一致の誤判定を減らすにはどうすればよいですか?
会社名や氏名だけで統合を決めず、電話番号、住所、ドメイン、所属会社など複数の項目を組み合わせます。追加情報が整合する候補は統合し、名称だけが似ている候補は人のレビューへ回します。誤判定が出た条件は除外ルールとして残し、次回の候補抽出へ反映します。
必要なデータを誤って変更した場合はどう戻しますか?
実行前に、レコード識別子、変更対象のプロパティ、関連付けを含むデータをエクスポートしておきます。限定テストの段階で復元手順も確認し、戻せる項目と手作業が必要な関連付けを分けておきます。変更後に問題が見つかった場合は、保存した識別子を基準に対象を絞って復元します。
クレンジングはどこまで自動化できますか?
入力形式の統一、正規化、完全一致による候補抽出、担当者への通知は自動化しやすい領域です。一方、会社同士の関係、同姓同名、活動履歴の意味を踏まえる判断は人が担当します。自動化の目的は人の判断をなくすことではなく、人が確認すべき候補を絞ることです。
データクレンジングの責任者は誰が適していますか?
仕組みや権限はCRM導入担当や情報システム担当が管理し、会社、コンタクト、取引などの業務判断は各データオーナーが担う形が適しています。営業やマーケティングだけに任せず、判断基準と例外時の決定者を明文化します。これにより、担当者が変わっても同じルールで運用できます。
まとめ
CRMデータクレンジングは、重複レコードを削除するだけの作業ではありません。コンタクト、会社、取引、顧客対応、請求に関する情報を一つの流れとしてつなぎ、営業活動やレポートに使える状態を保つ運用プロセスです。
完全一致、正規化、あいまい一致には、それぞれ向いている対象があります。判断根拠が明確な候補は仕組みで処理し、会社の関係性や活動履歴を読む必要がある候補は人がレビューします。入力項目を必要な範囲に絞り、正規化、候補抽出、監査までを連携させると、担当者の注意力に依存しにくい運用になります。
まずは、影響を確認しやすい完全一致の候補から始めてください。
- メールアドレス、電話番号、会社名の重複候補を入力経路別に抽出する
- 主レコード、残す値、関連付けの確認手順を決め、限定した範囲でテストする
- 結果を確認した後、入力時の正規化と定期監査へルールを反映する
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
CRMのデータ品質管理や運用設計に関連する記事をご紹介します。商談管理やCRM選定・導入の観点をさらに深めたい方は、以下もご覧ください。