2026/07/23

CRMの重複データ対策：検出・確認・統合を安全に進める手順

同一対象で関連情報を1件に集約したい場合はマージを検討します。削除する場合も、復元可否、関連情報、監査要件を確認してから実行します。

いいえ。会社名だけで決めず、ドメイン、電話番号、住所、法人番号などを組み合わせ、曖昧な候補は人が確認します。

CRMの重複データを安全に減らすための実務ガイド。クレンジング・名寄せ・マージの役割を分け、照合条件、主レコードの選び方、統合前の確認、再発防止の設計を整理します。

CRMに同じ会社や担当者が複数ある状態では、誰に連絡したか、どの商談が進んでいるか、どの数値を正とするかが揃いません。重複対策はレコードを減らす作業ではなく、営業・マーケティング・CSが同じ顧客を同じ前提で見られるようにする運用設計です。

急いで一括統合すると、支店と本社、旧社名と別法人、同姓同名の担当者まで1件にしてしまいます。候補を見つける工程と、統合を実行する工程を分けてください。

まず決めること：重複の定義はオブジェクトごとに違う

会社、担当者、商談を同じ条件で判定してはいけません。会社では法人番号やドメイン、担当者ではメールアドレス、商談では案件の文脈が判断材料になります。

対象	強い照合条件の例	人が確認する条件の例	そのまま統合しない条件
会社	自社で一意に管理している法人番号の完全一致	ドメイン、電話番号、住所、正規化した会社名が複数一致	会社名の部分一致だけ
担当者	個人のメールアドレス完全一致	氏名、所属、会社ドメインの組み合わせ	氏名だけの一致
商談	同じ会社・同じ商談目的・同じ期間であることを確認済み	件名、担当者、金額、作成時期	件名が同じだけ

法人番号やメールアドレスも、入力ミスや共通アドレスは例外になります。強い条件で候補を絞っても、統合確定の条件は別に持つ方が安全です。

重複対策は、次の3つを混ぜないところから始めます。

たとえば「株式会社Mer」「（株）Mer」「Mer Inc.」は、最初に比較しやすい表記へ整えます。その後、ドメイン・住所・電話番号などを見て同一企業かを判断し、最後に残すレコードと項目を決めてから統合します。

候補が見つかってから主レコードを選ぶと、担当者ごとに判断が変わります。先に優先順位を決め、候補ごとに同じ順序で確認します。

確認項目	判断ルールの例
顧客ID・契約情報	顧客IDまたは契約情報を持つレコードを優先する
活動履歴	最新の商談・問い合わせ・メール履歴を持つレコードを確認する
担当者・所有者	現在の担当・権限・可視性が適切な方を確認する
項目の競合	電話番号、住所、役職などは、どちらを残すかを明示してから統合する
関連レコード	商談、活動、問い合わせ、添付、連携先IDがどう扱われるかを確認する

Pipedriveは主レコードと保存する情報をプレビューしてから統合し、統合後は元に戻せないと案内しています。確信のない候補は、削除せず保留キューに置いてください。

統合の実行者が変わっても同じ判断になるよう、少なくとも次を確認します。

HubSpotの重複管理でも、候補ペアを比較して残すレコードとプロパティを選択し、統合または除外を判断します。候補の検出と統合の実行を同じ自動処理にしないことが、誤統合を防ぐ最低条件です。

全件を一度に処理しません。照合条件が明確な候補だけを選び、統合前後で次を見ます。

観点	確認する内容
判定精度	同一ではない会社・人物が候補に混ざっていないか
情報の継承	必要な活動、商談、問い合わせ、項目値が残っているか
レポート	パイプライン、顧客数、担当別集計に意図しない変化がないか
連携	フォーム、CSV、外部ツールとの同期後に重複が再発していないか

誤った候補が出たら、マージの操作を増やす前に照合条件を見直します。候補を多く出すことより、保留と確定を分けて運用できることが優先です。

一度統合しても、フォーム、CSVインポート、外部ツール同期、手入力から重複は再び増えます。入口ごとに、誰が何を確認するかを決めます。

入口	実装するルール	定期確認
フォーム	メールアドレス・会社名・ドメインの扱いを統一する	送信後に既存レコードとの重複を確認する
CSVインポート	照合項目、更新元、例外の扱いをインポート前に確認する	取込後に候補件数と例外を確認する
外部ツール同期	どちらを正とするか、更新方向と競合時の優先順位を決める	同期エラーと新規重複候補を確認する
手入力	必須項目、表記ルール、既存検索の手順を用意する	入力者ごとの例外を見直す