「CRMのコンタクト数は3万件を超えているのに、実際にアクティブな顧客は半分以下かもしれない」「同じ会社が『株式会社ABC』『(株)ABC』『ABC株式会社』と3つ登録されていて、正確な取引先数すら把握できない」「営業が『CRMのデータは信用できない』と言い出し、結局Excelで独自管理を始めてしまった」
CRMのデータクレンジングは、導入後のあらゆるフェーズで発生する最も身近かつ深刻な課題です。データ品質が低いCRMは、レポートの信頼性を損ない、マーケティング施策の精度を下げ、最終的には現場のCRM離れを引き起こします。
CRM データクレンジングとは、CRMに蓄積された顧客データの重複排除、名寄せ（同一顧客の統合）、表記揺れの修正、不完全データの補完、不要データの削除を行い、データ品質を維持・向上させるプロセスです。本記事では、名寄せアルゴリズムの選定基準（完全一致・あいまい一致・正規化マッチング）、重複判定基準の設計方法、定期的なデータ監査の仕組みまで、CRM導入担当者がすぐに実践できるデータ品質 管理の方法を体系的に解説します。
データクレンジング画面の例：データ品質管理とインポート（出典：HubSpot）
CRMには、Web フォーム、営業の手動入力、CSVインポート、API連携、名刺管理ツールなど、複数の経路からデータが流入します。各経路でのバリデーション（入力チェック）ルールが統一されていないと、同一人物が異なる表記で重複登録されます。
| 入力経路 | 重複・品質低下の典型パターン |
|---|---|
| Webフォーム | フリーメール(gmail等)での登録、会社名の省略・誤入力 |
| 営業の手動入力 | 入力基準のばらつき、必須項目の空欄 |
| CSVインポート | 旧データの一括投入による大量重複の発生 |
| API連携（MA等） | 連携元システムとの項目マッピングのずれ |
| 名刺管理ツール | OCR読取の誤変換、姓名の逆転 |
「会社名はどの表記で入力するか」「電話番号にハイフンを入れるか」「部署名は正式名称か略称か」といった入力ルールが定義されていない、または定義されていても徹底されていないケースが大半です。
顧客データは時間の経過とともに劣化します。人事異動、転職、会社の移転・合併・倒産などにより、CRMに登録された情報は年間約25〜30%が陳腐化するとされています。
CRM導入時に重複チェックの仕組みを設計しなかった場合、時間の経過とともに重複レコードが蓄積されます。特に会社レコードの重複は、関連するコンタクトや商談のデータにも影響を及ぼし、レポートの精度を大きく損ないます。
CRM データクレンジングは「誰かがやるべき作業」として認識されていても、「誰が・いつ・どのように」実行するかが定義されていないケースが多く見られます。責任者の不在はデータ品質の慢性的な低下に直結します。
| 影響領域 | 具体的なインパクト |
|---|---|
| レポートの信頼性 | 重複レコードにより顧客数・商談数が過大計上される。経営判断の精度が低下 |
| マーケティング施策 | 同一人物に重複メールが配信され、顧客体験が悪化。配信数課金の無駄 |
| 営業活動 | 担当者が「この会社は既存顧客か新規か」の判別に時間を浪費。属人的な記憶に依存 |
| カスタマーサクセス | 顧客の全体像が把握できず、適切なフォローが遅れる |
| CRM定着率 | 「データが信用できない」→「自分でExcel管理」→CRM離れの悪循環 |
名寄せとは、CRM上に散在する同一顧客（同一人物・同一企業）のレコードを特定し、一つに統合するプロセスです。名寄せ 方法は、以下の3段階で構成されます。
| 名寄せの単位 | 判定の難易度 | 影響範囲 |
|---|---|---|
| コンタクト（個人）の名寄せ | 中 | メール配信、活動履歴の統合 |
| 会社レコードの名寄せ | 高 | コンタクト・商談・契約の紐付けに影響 |
| 商談の名寄せ | 低（発生頻度が低い） | パイプラインレポートの精度 |
会社レコードの名寄せは、影響範囲が最も広く、かつ判定難易度が高いため、最優先で取り組むべき領域です。
2つのレコードの特定フィールドが完全に一致する場合に重複と判定する、最もシンプルな手法です。
| 項目 | 内容 |
|---|---|
| 判定ロジック | 指定フィールドの文字列が100%一致 |
| 典型的な判定キー | メールアドレス、法人番号、電話番号 |
| 精度 | 非常に高い（誤判定が少ない） |
| 検出率 | 低い（表記揺れのある重複を検出できない） |
| 適する場面 | メールアドレスベースの個人重複検出 |
完全一致マッチングの判定例：
| レコード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 | 電話番号 | 非重複（ハイフン有無） |
文字列の「類似度」を計算し、一定の閾値以上の場合に重複候補と判定する手法です。
| 項目 | 内容 |
|---|---|
| 判定ロジック | 文字列の類似度（Levenshtein距離、Jaro-Winkler距離等）を計算 |
| 典型的な判定キー | 会社名、氏名、住所 |
| 精度 | 中（閾値の設定次第で誤判定が発生） |
| 検出率 | 高い（表記揺れのある重複も検出可能） |
| 適する場面 | 会社名ベースの企業重複検出 |
あいまい一致の類似度計算例：
| レコードA | レコードB | 類似度（目安） | 判定（閾値80%の場合） |
|---|---|---|---|
| 株式会社ABC | (株)ABC | 約65% | 非重複（閾値未満） |
| 株式会社エービーシー | 株式会社ABC | 約40% | 非重複（閾値未満） |
| 田中太郎 | 田中太朗 | 約85% | 重複候補 |
| ABCホールディングス | ABCグループ | 約70% | 非重複（閾値未満） |
上記の例が示すとおり、あいまい一致単独では日本語の会社名の表記揺れ（株式会社/(株)、カタカナ/英字等）に対する検出精度に限界があります。そのため、次に説明する正規化マッチングとの併用が推奨されます。
データを事前に正規化（標準化）したうえで、完全一致またはあいまい一致を行う手法です。日本語特有の表記揺れに対応するために最も有効なアプローチです。
| 項目 | 内容 |
|---|---|
| 判定ロジック | データの正規化（前処理）→ 一致判定 |
| 正規化の内容 | 法人格の統一、全角/半角変換、カタカナ/英字統一、不要文字の除去 |
| 精度 | 高い（正規化ルールの設計次第） |
| 検出率 | 高い |
| 適する場面 | 日本語の会社名・住所の名寄せに最適 |
正規化ルールの設計例：
| 正規化カテゴリ | 変換前 | 変換後 | ルール |
|---|---|---|---|
| 法人格の統一 | 株式会社ABC | ABC | 「株式会社」「(株)」「有限会社」等を除去 |
| 法人格の統一 | (株)ABC | ABC | 同上 |
| 全角→半角 | ＡＢＣ | ABC | 英数字を半角に統一 |
| カタカナ→半角 | エービーシー | ｴｰﾋﾞｰｼｰ | または英字に統一 |
| スペースの統一 | A B C | ABC | スペースを除去 |
| 旧字体→新字体 | 髙橋 | 高橋 | 旧字体を新字体に変換 |
| 大文字→小文字 | ABC Corp. | abc corp | 英字を小文字に統一 |
| 記号の除去 | ABC・ジャパン | ABCジャパン | 中黒・ハイフン等を除去 |
正規化後のマッチング例：
| レコードA（原文） | レコードB（原文） | 正規化後A | 正規化後B | 結果 |
|---|---|---|---|---|
| 株式会社ABC | (株)ABC | abc | abc | 重複 |
| ＡＢＣ株式会社 | ABC(株) | abc | abc | 重複 |
| 株式会社エー・ビー・シー | (株)ABC | ｴｰﾋﾞｰｼｰ | abc | 要確認（手動判断） |
| 比較軸 | 完全一致 | あいまい一致 | 正規化マッチング |
|---|---|---|---|
| 精度（誤判定の少なさ） | ★★★ | ★★☆ | ★★★ |
| 検出率（見逃しの少なさ） | ★☆☆ | ★★★ | ★★★ |
| 日本語対応 | ★☆☆ | ★★☆ | ★★★ |
| 実装の容易さ | ★★★ | ★★☆ | ★★☆ |
| 処理速度 | ★★★ | ★☆☆ | ★★☆ |
| 推奨用途 | メールアドレスの重複検出 | 氏名の表記揺れ検出 | 会社名・住所の名寄せ |
推奨アプローチ：段階的なマッチング
実務では、単一の手法ではなく、以下のように段階的にマッチングを行うのが効果的です。
データクレンジング画面の例：データ品質管理とインポート（出典：HubSpot）
顧客データ 重複排除において、どの項目（フィールド）を判定キーとするかは、名寄せの精度と効率を左右する重要な設計判断です。
コンタクト（個人）の重複判定：
| 判定パターン | 判定キーの組み合わせ | 信頼度 | 自動マージ可否 |
|---|---|---|---|
| パターン1 | メールアドレス（完全一致） | 非常に高い | 可 |
| パターン2 | 氏名 + 会社名（正規化一致） | 高い | 条件付き可 |
| パターン3 | 氏名 + 電話番号（完全一致） | 高い | 条件付き可 |
| パターン4 | 氏名のみ（あいまい一致） | 低い | 不可（手動判断必須） |
会社レコードの重複判定：
| 判定パターン | 判定キーの組み合わせ | 信頼度 | 自動マージ可否 |
|---|---|---|---|
| パターン1 | 法人番号（完全一致） | 非常に高い | 可 |
| パターン2 | 会社名（正規化一致）+ 電話番号 | 高い | 条件付き可 |
| パターン3 | 会社名（正規化一致）+ 住所（正規化一致） | 高い | 条件付き可 |
| パターン4 | 会社名（正規化一致）のみ | 中 | 不可（手動判断必須） |
| パターン5 | ドメイン名（完全一致） | 高い | 条件付き可 |
重複と判定されたレコードをマージ（統合）する際は、どちらのレコードのデータを残すかのルールを事前に定義しておく必要があります。
| 優先ルール | 考え方 | 適する項目 |
|---|---|---|
| 最新値優先 | 更新日時が新しいほうの値を採用 | 電話番号、住所、役職、部署 |
| 空でない値優先 | 値が入っているほうを採用 | メールアドレス、業種、従業員数 |
| 手動入力優先 | APIやフォームより営業の手動入力を優先 | 決裁者情報、商談メモ |
| マスターレコード優先 | 古い（先に作成された）レコードを基準とする | CRM ID、作成日 |
| 活動量が多いほうを優先 | 紐付く活動ログが多いレコードを基準にする | コンタクトの主レコード選定 |
データクレンジングに着手する前に、現在のデータ品質の状態を数値で把握します。
| 分析項目 | 確認方法 | 目安基準 |
|---|---|---|
| 総レコード数 | CRMのレコード件数を確認 | ー |
| 推定重複率 | メールアドレスの重複件数 ÷ 総件数 | 10%以下が目標 |
| 必須項目の欠損率 | 主要項目の空欄率を確認 | 各項目90%以上入力が目標 |
| 表記揺れの状況 | 会社名の法人格表記パターンを集計 | パターンが3種類以下が理想 |
| 古いデータの割合 | 最終更新日が1年以上前のレコード割合 | 30%以下が目標 |
| 不要プロパティ数 | 使用されていないカスタムプロパティ数 | 全プロパティの20%以下 |
分析結果をもとに、どのデータを・どのルールで・どの順序で処理するかを策定します。
優先順位の考え方：
| 優先順位 | 対象 | 理由 |
|---|---|---|
| 1 | 完全一致の重複排除（メールアドレス） | 自動化可能、即効性が高い |
| 2 | 会社レコードの名寄せ | 影響範囲が広い（関連コンタクト・商談） |
| 3 | 表記揺れの修正（法人格、全角/半角） | 正規化ルールで一括処理可能 |
| 4 | 不完全データの補完 | 段階的に対応可能 |
| 5 | 古いデータのアーカイブ | 影響が限定的、後回しでも問題ない |
策定したルールに基づき、データクレンジングを実行します。
実行の手順：
クレンジングは一度きりの作業ではありません。再発を防止するための仕組みを実装します。
| 防止策 | 具体的な施策 |
|---|---|
| 入力時のバリデーション | フォーム・CRM入力画面で必須項目・形式チェックを設定 |
| 重複チェックの自動化 | 新規レコード作成時に既存レコードとの重複チェックを自動実行 |
| 正規化の自動処理 | ワークフローやOperations Hub等で入力値を自動正規化 |
| 入力ガイドラインの整備 | 命名規則・入力ルールをドキュメント化し、CRM画面にヘルプテキストを設置 |
| 定期的なデータ監査 | 月次・四半期の定期監査スケジュールを策定 |
毎月実施する定期監査の項目と手順です。所要時間は2〜4時間が目安です。
| # | 監査項目 | 確認方法 | 判定基準 | 対処 |
|---|---|---|---|---|
| 1 | 新規重複レコードの検出 | CRMの重複管理ツールを実行 | 新規重複が10件以上で要対応 | 手動レビュー＋マージ |
| 2 | 必須項目の欠損率 | プロパティ別の入力率レポートを確認 | 欠損率が10%を超える項目は要改善 | 入力促進の施策を検討 |
| 3 | バウンスメールの処理 | ハードバウンスのレコードを抽出 | ハードバウンスは即時対応 | メールアドレスの無効化/削除 |
| 4 | 入力ルールの遵守状況 | 命名規則違反のレコード数を確認 | 違反率5%以上で要対応 | 入力者への周知・ルール再徹底 |
| 5 | 新規プロパティの確認 | 当月に追加されたカスタムプロパティを確認 | 不要なプロパティが増えていないか | 不要プロパティの整理・削除 |
四半期ごとに実施する詳細監査の項目です。所要時間は半日〜1日が目安です。
| # | 監査項目 | 確認方法 | 判定基準 | 対処 |
|---|---|---|---|---|
| 1 | 全体の重複率の推移 | 重複率の前四半期比を計測 | 前四半期より悪化していれば要因分析 | 重複発生源の特定と対策 |
| 2 | データの鮮度チェック | 最終更新日が6ヶ月以上前のレコード割合 | 30%を超えたら要対応 | アーカイブまたはデータ更新施策 |
| 3 | セグメント精度の確認 | 主要セグメント（業種、企業規模等）の内訳が妥当か | 「不明」「その他」が20%以上は要改善 | データ補完施策の実施 |
| 4 | プロパティの棚卸し | 全カスタムプロパティの利用率を確認 | 過去3ヶ月間使用されていないプロパティ | 廃止または統合を検討 |
| 5 | 連携データの整合性 | CRMと連携先システムのレコード件数を突合 | 件数に5%以上の乖離があれば要確認 | 連携エラーの調査・修正 |
| 6 | ライフサイクルステージの正確性 | 各ステージのレコード数と実態の整合 | 明らかに不整合がある場合は要修正 | ステージ更新漏れの一括修正 |
| 7 | データガバナンスルールの見直し | 入力ルール・命名規則の有効性を評価 | 現場の運用実態とルールの乖離がないか | ルールの改訂・現場への再周知 |
年に1回、データ品質の包括的なレビューを実施します。
| レビュー項目 | 内容 |
|---|---|
| データ品質KPIの年間推移 | 重複率、欠損率、表記揺れ率の12ヶ月推移を確認 |
| クレンジングの費用対効果 | クレンジングに投じた工数とデータ品質の改善度合いを評価 |
| ルールの有効性評価 | 入力ルール・正規化ルール・監査プロセスの有効性を評価 |
| 組織体制の見直し | データオーナー・監査担当者のアサインが適切か確認 |
| ツール・仕組みの見直し | クレンジング・監査に使用しているツールの有効性を評価 |
データ品質 管理を持続可能にするために、データ領域ごとのオーナーを明確に定義します。
| データ領域 | オーナー | 責任範囲 |
|---|---|---|
| 顧客マスタ（会社） | 営業企画またはRevOps | 正式名称マスタの管理、重複排除の実行 |
| コンタクト情報 | マーケ＋営業の共同管理 | 入力ルールの遵守、バウンス対応 |
| 商談データ | 営業マネージャー | パイプラインの正確性、ステージ定義の遵守 |
| マーケティングデータ | マーケ部門 | リード定義、セグメント定義の管理 |
| 全体のデータガバナンス | 情シスまたは導入担当 | 監査の実施、ツール管理、ルール策定 |
| ルール項目 | 具体的な規定 | 設定方法 |
|---|---|---|
| 会社名 | 正式名称（登記名）で入力。「株式会社」は前後を統一 | CRM上にヘルプテキストを設置 |
| 電話番号 | ハイフン付き（03-1234-5678形式）で統一 | 入力形式のバリデーションを設定 |
| メールアドレス | 小文字で統一。共有アドレス（info@等）は備考に記載 | 自動小文字変換の設定 |
| 住所 | 都道府県から記載。丁目・番地はハイフン区切り | プルダウン+フリーテキスト |
| 業種 | CRMのマスタ定義に従いプルダウン選択 | プルダウン項目として設定 |
| 部署名 | 正式名称。略称不可 | ヘルプテキストで例示 |
データ品質を定量的に管理するために、以下のKPIを設定し、定期的に計測します。
| KPI | 計算式 | 目標値 | 計測頻度 |
|---|---|---|---|
| 重複率 | 重複レコード数 ÷ 総レコード数 × 100 | 5%以下 | 月次 |
| 必須項目入力率 | 入力済み件数 ÷ 該当レコード総数 × 100 | 90%以上 | 月次 |
| データ鮮度 | 更新日6ヶ月以上前のレコード ÷ 総レコード × 100 | 30%以下 | 四半期 |
| 表記揺れ率 | 正規化で検出された不統一件数 ÷ 総件数 × 100 | 5%以下 | 四半期 |
| バウンス率 | ハードバウンス件数 ÷ メール配信数 × 100 | 2%以下 | 月次 |
CRM データクレンジングは、CRMの投資対効果を最大化するための最も基本的かつ重要な運用プロセスです。データ品質が低いCRMは「高価な住所録」にしかならず、レポート、マーケティング施策、営業活動のすべてに悪影響を及ぼします。
本記事の要点を振り返ります。
CRM データクレンジングは一度実施すれば終わりではなく、継続的な運用プロセスとして組織に組み込む必要があります。まずは現状のデータ品質を数値で把握し、最も影響の大きい領域（メールアドレスの重複、会社名の名寄せ）から着手してください。
なお、HubSpot Operations Hubには、データ品質管理ツール（重複検出・マージ、データフォーマットの自動修正など）が標準搭載されており、クレンジングの自動化と定期的なデータ監査を効率的に実現することが可能です。
A. 初回のクレンジング（フルクレンジング）は、データ量と品質の状態によりますが、レコード数1万件で2〜3週間、5万件で4〜6週間が目安です。ただし、これは分析・ルール策定・実行・防止策の全フェーズを含む期間です。初回クレンジング後の定期監査は、月次で2〜4時間、四半期で半日〜1日程度で実施可能です。
A. 単一のフィールドだけでなく、複数のフィールドを組み合わせた判定基準を設計してください。例えば、「会社名（正規化一致）AND 電話番号（完全一致）」のように、2つ以上の条件を組み合わせることで誤判定を大幅に減らせます。また、あいまい一致の閾値を高めに設定し（90%以上）、閾値未満の候補は手動レビューに回す運用が推奨されます。
A. クレンジング実施前に必ずCRMデータのフルバックアップ（CSVエクスポート）を取得しておくことが最重要です。多くのCRMにはゴミ箱機能（一定期間内であれば削除レコードの復元が可能）が備わっています。HubSpotの場合、削除後90日以内であればゴミ箱からの復元が可能です。大規模なクレンジングの前には、サンドボックス環境での事前テストも推奨します。
A. 完全一致の重複検出・マージ、表記揺れの正規化（法人格の統一、全角/半角変換等）、必須項目の欠損アラートなどは自動化が可能です。一方、あいまい一致による重複候補の最終判定（同一企業かどうかの判断）は、ビジネス文脈の理解が必要なため、完全な自動化は困難です。「自動化できる部分は自動化し、判断が必要な部分は人がレビューする」というハイブリッド運用が現実的です。
A. データクレンジングの「仕組みの構築と運用」は情シスまたはCRM導入担当、「日常的なデータ品質の維持」は各データオーナー（営業企画、マーケ等）が担うのが理想的な役割分担です。重要なのは、経営層がデータ品質を経営課題として認識し、予算と工数を確保することです。データクレンジングを「情シスの片手間作業」として位置づけると、必ず優先度が下がり、品質が劣化します。