CRM移行のためのデータクレンジング：重複排除・正規化・エンリッチメント

CRM移行は、データ品質を改善する絶好の機会です。多くのチームがこの機会を逃すのは、クレンジングを移行後のタスクとして扱うからです。本番稼働が落ち着いたら対処しようという発想です。しかし、落ち着く暇はありません。移行後のバックログは解消されず、6ヶ月後には旧システムと同じ品質の悪いデータに加えて、インポート時に生じた新たなエラーを抱えた新システムが稼働しているという状況になります。

あるRevOpsリードは、HubSpotから新CRMへ8,000件のコンタクトを移行した際に、インポート後に2,400件の重複を発見しました。エクスポート前に3時間の重複排除を行えば防げた問題です。代わりに、クリーンアップに3週間かかり、部分的な再インポートが必要になりました。（HubSpotから移行する場合は、HubSpotからReworkへの移行でこのクレンジング手順がさらに重要になるデータモデルの違いについて解説しています。）

このガイドでは、上記のような事態を防ぐためのクレンジング手順を説明します。ソースシステムでこれらの手順を順番に実行してください。完了するまで1件もエクスポートしないでください。

ステップ1：重複排除の戦略

重複排除には2つのフェーズがあります。重複の特定と、それをどう処理するかの決定です。マッチタイプごとに明確な判断ルールを決めてから、マージを始めてください。

マッチルールの優先順位：

  1. メールアドレスの完全一致：同じメールアドレスを持つ2つのレコードはほぼ同一人物です。自動マージが安全です。フィールド入力数（空でないフィールドが多い方）が多いレコードを残します。
  2. 名前＋会社名のファジーマッチ：名前が似ていて（例：田中太郎と田中T.）会社名が同じか近い2つのレコード。手動確認のキューに入れてください。自動マージは禁止です。
  3. 電話番号の一致：2つの異なるレコードで同じ電話番号を共有。メールよりも信頼性が低いです（会社の代表番号が多くのコンタクトに紐づく場合がある）。手動確認のみです。
  4. 同一コンタクトでのメールドメイン一致：「田中花子」と「T.田中」が同じメールドメインを持つ場合。中程度の信頼性。手動確認が必要です。

重複排除の判断ロジック表

マッチタイプ 信頼度 アクション
メールアドレスの完全一致 高 自動マージ（データが多い方を残す）
名前＋会社名のファジーマッチ（85%以上の類似度） 中 手動確認キューへ
電話番号の完全一致（同一会社） 中 手動確認キューへ
名前のみ（会社名・メールなし） 低 フラグを立てる。自動マージ禁止
メールドメイン一致のみ 低 スキップ（誤検知が多すぎる）

自動マージの閾値：メールアドレスの完全一致のみ自動マージを設定してください。それ以下は人間の目による確認が必要です。同じ会社に所属する別の2人を誤って統合してしまうような過剰な自動マージは、取引履歴と関係性データを破壊し、後から解消するのが非常に難しくなります。

ステップ2：重複排除ツールの選択

ツールの選択は、ソースシステムとデータセットのサイズによって異なります。

HubSpot（標準機能）：コンタクト > アクション > 重複を管理。HubSpotはペアを並べて比較表示し、レビューを促します。マージはネイティブに処理され、残したいレコードを選択するとすべての関連付け履歴が保持されます。制限：1ペアずつ処理するため、約5,000件までは許容範囲ですが、それ以上になると遅くなります。

Salesforce（標準機能）：設定 > 重複管理。重複ルールを定義し（マッチフィールド：メール、マッチタイプ：完全一致）、レポートとして実行します。個別マージには「コンタクトのマージ」ツールを使用します。Salesforceでの一括重複排除は標準ツールに限界があります。10,000件以上のコンタクトには、サードパーティツールの方が高速です。一括操作の前にSalesforce Data Loaderガイドを読んで、競合解決の方法を理解してください。

Pipedrive（標準サポートが限定的）：Pipedriveはコンタクトビューで潜在的な重複にフラグを立てますが、一括重複排除ツールはありません。CSVにエクスポートし、スプレッドシートまたはサードパーティツールで重複排除を行い、クリーンなファイルを再インポートします。

大規模データセット向けサードパーティツール：

  • Dedupely（dedupely.com）：HubSpotとSalesforce専用。ルールベースの自動化による一括マージが可能。10,000件以上に適しています。
  • Dedupe.io：任意のCRMからのCSVエクスポートに対応。ファイルをアップロードしてマッチルールを設定し、重複排除済みのファイルをダウンロード。大規模バッチは1件あたり0.01〜0.02ドルです。
  • Cloudingo（cloudingo.com）：Salesforce専用。複雑なマージルールには標準ツールよりUIが優れています。

重複排除ツールを実行する前に：必ずフルバックアップを取ってください。 すべてのオブジェクトをCSVでダウンロードし、アクセスできる場所に保存します。一括マージはほとんどのシステムで取り消すことができません。問題が発生した場合に備えて、マージ前の状態が必要です。

ステップ3：電話番号の正規化

電話フィールドは、どのCRMでも最も乱れたデータです。+1 (555) 234-5678、555-234-5678、5552345678、+15552345678、555.234.5678 x102、(555) 234-5678 など様々な形式が混在しています。同じ番号で7つの異なる形式です。

目標標準：E.164形式。これは国際標準です：+に続いて国番号、そして加入者番号。スペースや書式文字なし。米国の番号のE.164形式：+15552345678。

正規化手順：

  1. 数字以外の文字をすべて除去：(、)、-、.、スペースを削除
  2. 番号が10桁で米国ベースの場合、+1を先頭に追加
  3. 番号が1で始まり11桁の場合、+を先頭に追加
  4. メイン電話フィールドの内線番号を確認（「x」「ext」「内線」の後の文字）。別の内線フィールドに抽出します。

基本的な電話番号クレンジング用の正規表現（Google Sheetsの REGEXREPLACEで使用可能）：

数字以外を除去：=REGEXREPLACE(A2,"[^0-9+]","")

米国10桁番号の確認：=IF(LEN(REGEXREPLACE(A2,"[^0-9]",""))=10, "+1"&REGEXREPLACE(A2,"[^0-9]",""), A2)

大規模データセットの場合、phonenumbersライブラリを使ったPythonスクリプトの方が国際番号をより確実に処理できます。しかし、スプレッドシートで作業するほとんどのSales Opsチームには、正規表現のアプローチで90%のケースに対応できます。

電話フィールドに役職メールアドレスがある場合： 「info@company.comを参照」などのエントリがある場合があります。これらはプログラムで正規化できないため、手動確認フラグを立ててください。

ステップ4：メールアドレスの検証

移行前に一括メール検証を行うことで、新システムでの最初のアウトリーチキャンペーンでハードバウンスするコンタクトを除去できます。無効なメールレコードを移行する価値はありません。

一括検証ツール：

  • ZeroBounce：CSVをアップロードすると、メールごとのステータス（有効、無効、キャッチオール、スパムトラップ、乱用）が返されます。大規模バッチは1件あたり約0.008ドル。テスト用の無料プランあり。
  • NeverBounce：価格と機能が似ています。スクリプトに組み込みたい場合に適したAPIあり。
  • Hunter.io Email Verifier：遅めですが、特定ドメインのスポットチェックに便利です。

Experianのグローバルデータ品質調査によると、データ品質の低さが組織の平均15〜25%の収益損失をもたらすことが一貫して示されており、移行前検証のビジネスケースを具体的な数字で示しています。

各検証結果への対応：

ステータス アクション
有効 移行する
無効（ハードバウンス履歴あり） 移行から除外、アーカイブ
キャッチオール（ドメインがすべて受け入れる） 「未検証」タグをつけて移行
スパムトラップ 削除、移行禁止
乱用（苦情報告履歴が多い） 移行から除外
役職メールアドレス（info@、sales@、admin@） フラグを立てる。個人メールがない場合のみ移行

関連する取引がある場合を確認せずに無効なコンタクトを削除しないでください。無効なメールを持つコンタクトでも、オープンな商談が紐づいている場合があります。レコードを移行し（悪いメールは除いて）、メールを手動でクリーンアップして、次に進みましょう。

ステップ5：ライフサイクルステージの正規化

このフィールドは移行後の混乱の原因として、ほぼ他のどのフィールドより多くの問題を引き起こします。ソースシステムはプロセス定義が変化するにつれてライフサイクルステージを蓄積します。移行する頃には、移行先の4つのステージにマッピングする必要がある9つの異なるステージ値が存在する可能性があります。

まずソースからすべての異なるライフサイクルステージ値をエクスポートします。 Salesforceの場合：SELECT Status, COUNT(Id) FROM Lead GROUP BY Status。HubSpotの場合：コンタクトをエクスポートしてExcelでライフサイクルステージ列をピボット。Pipedriveの場合：コンタクト/リードをエクスポートしてCOUNTIFを使用。値マッピングを確定する前に、移行先のリードライフサイクルステージの定義を確認してください。ここでの判断がルーティング、自動化、レポートを左右します。

次にマッピングを作成します：

ライフサイクルステージマッピングテンプレート

ソースの値 件数 移行先の値 備考
New Lead 1,240 Lead 直接マッピング
Open Lead 890 Lead 上と統合
Marketing Qualified Lead 430 MQL 直接マッピング
Product Qualified Lead 180 MQL 移行先にPQLがなければMQLへ
Sales Accepted Lead 220 SQL 直接マッピング
Sales Qualified Lead 310 SQL 上と統合
Demo Scheduled 145 SQL SQLのまま、活動メモを追加
Negotiation 88 SQL 後期SQL として扱う
Customer 2,100 Customer 直接マッピング
Churned 340 Customer (非アクティブ) 非アクティブタグをつける
Evangelist 45 Customer Customerにマッピング、タグ追加
Disqualified 670 Disqualified 直接マッピング

このマッピングを文書化し、インポート前に営業リーダーシップの承認を得てください。ライフサイクルステージの定義はルーティング、レポート、クォータに影響します。これは一方的なOpsの判断ではありません。

ステップ6：日付フィールドの正規化

日付フィールドはサイレントに失敗します。エラーなしにインポートされますが、値が間違っていて、日付ベースのレポートや自動化ルールが壊れてしまいます。担当者が日付の間違いに気づくまで気づかないことが多いです。

目標標準：ISO 8601、YYYY-MM-DD形式（例：2025-06-15）。この形式はロケールをまたいで明確で、あらゆるCRMインポートツールで受け入れられます。

よくある問題：

  • MM/DD/YYYY対DD/MM/YYYY：クローズ日「06/07/2024」は米国形式では6月7日、英国/EU形式では7月6日です。国際的な担当者がいるチームでは、同じ列に両方の形式が混在します。
  • テキスト文字列：日付フィールドに「Q3 2024」「年末」「TBD」などのエントリ。プログラムで正規化できません。手動確認か空白インポートが必要です。
  • タイムゾーンオフセット：一部のシステムはタイムゾーン付きのISO 8601（2025-06-15T00:00:00-05:00）で日付をエクスポートします。移行先が自動的にタイムゾーン変換を処理しない限り、インポート前にタイムゾーンオフセットを除去してUTCに変換してください。
  • Unixタイムスタンプ：一部のエクスポートツールはエポックからのミリ秒でタイムスタンプを出力します。次の数式で変換：Excelで=TEXT(A2/86400000+"1/1/1970","YYYY-MM-DD")。

「不明」な日付について：クローズ日が空の場合は空のままにしてください。デフォルト日付で埋めないこと。空白は誠実です。間違った日付は誤解を招きます。

ステップ7：エンリッチメントの判断

移行は、エンリッチメントが最も意味をなす瞬間です。すべてのレコードに触れている段階で、データはクリーンな状態（重複排除・正規化後）にあり、移行先CRMは新鮮なスタートを切っています。

移行前にエンリッチメントを行う場合：

  • 会社名の入力率が70%未満の場合（フィールドタイプ別の完全性ベンチマークはリードデータ管理を参照）
  • 役職も会社への関連付けもないコンタクトがある場合
  • Salesforce AccountsやHubSpot Companiesなど、会社レベルのデータオブジェクトを持つCRMに移行し、関連付けの設定に正確なファームグラフィックスが必要な場合

無料のエンリッチメントオプション：

  • Clearbit Reveal（現在HubSpotのBreeze Intelligence）：メールドメインから会社データを自動エンリッチ。無料プランは限定的ですが、主要ドメインの一括エンリッチに便利です。
  • Apollo.io：月50件の無料プラン。特定のレコードのスポットチェックに適しています。
  • LinkedInの手動検索：遅いですが、データが本当に重要なキーアカウントには信頼性があります。

移行前にエンリッチメントをスキップする場合：

  • フィールドマッピングにエンリッチメント対象フィールドが含まれていない場合（移行しないフィールドをエンリッチするのは無駄）
  • タイムラインが厳しい場合（エンリッチメントには2〜5日かかる）
  • 移行先CRMにインポート後に自動実行されるネイティブエンリッチメント統合がある場合

重要な確認事項：エンリッチされたフィールドが移行のフィールドマッピングで保持されるかを確認してください。「従業員数」をエンリッチしても、そのフィールドが新システムのマッピング先として存在しなければ意味がありません。

ステップ8：クリーンなデータセットのQA

重複排除、正規化、検証、（オプションの）エンリッチメントを行った後、クレンジングプロセス自体がエラーを導入していないことを確認する必要があります。

クレンジング後のQAチェックリスト

チェック項目 クレンジング前 クレンジング後 ステータス
合計コンタクト数 [ベースライン] より少なくなるはず（重複排除）
重複推定（メール） [ベースライン%] 1%未満
メールフィールド：有効なアドレス [ベースライン%] 90%超
電話フィールド：E.164形式 [ベースライン%] 85%超
ライフサイクルステージ：NULL値 [ベースライン件数] 2%未満
日付フィールド：ISO 8601形式 [ベースライン%] 95%超
国フィールド：標準化済み [ベースライン%] 95%超
会社名の入力率 [ベースライン%] [目標%]

まず500行のサンプルでこのチェックリストを実行してください。ランダムに500件のレコードをエクスポートし、プロセスを適用して、チェックリストに対してアウトプットを検証します。サンプルが通過したら、同じプロセスをデータセット全体に適用します。これにより、クレンジングスクリプトにバグがある場合の影響範囲が限定されます。

レコード数の健全性チェック：クレンジング後のコンタクト数はクレンジング前より少なくなるはずです（重複排除でレコードが削除されました）が、大幅に少なくなるべきではありません。10,000件から始まって4,000件になった場合、極端な重複問題があったか、クレンジングスクリプトが削除すべきでないレコードを削除しています。処理を進める前に調査してください。

よくある落とし穴

バックアップなしで重複排除を実行する。 一括マージはほとんどのシステムで取り消せません。CSVバックアップのエクスポートに10分かける価値は毎回あります。

過剰な自動マージの閾値が正当な別コンタクトを破壊する。 同じ会社に2人の「田中健一」がいても、同一人物ではありません。メールや電話番号を先にチェックせずに名前＋会社でオートマージすると、後から解くのが厄介な壊れたレコードが生じます。

フィールドマッピングで保持されないデータをエンリッチメントする。 フィールドマッピング文書に「LinkedInのURL」が移行先フィールドとして含まれていなければ、LinkedInのURLをエンリッチするのは無駄です。何を移行するか確認してからエンリッチメントを決めましょう。カスタムフィールドガイドはどのカスタムフィールドが移行先として価値があるかの判断に役立ちます。

内線番号を確認せずに電話番号を正規化する。 数字以外の文字をすべて除去する正規化スクリプトは、「+1 (555) 234-5678 x102」を「+15552345678102」に変換してしまいます。見た目は有効でも実際には無効な13桁の番号です。正規化前に内線番号を処理してください。

サンプルでテストせずにデータセット全体をクレンジングする。 すべてのクレンジングスクリプトにはエッジケースがあります。500件でテストし、アウトプットをQAしてから、50,000件で実行してください。

次のステップ

一度にすべてをクレンジングしようとしないでください。今週、500行のサンプルをエクスポートし、このガイドのクレンジング手順を適用して、QAチェックリストを実行してください。アウトプットが正しいことを確認してから、全データセットに同じプロセスを適用してください。Reworkに移行する場合に、受け側のデータモデルの構造を理解したいなら、SalesforceからReworkへの移行でオブジェクトとフィールドの違いが解説されています。

順序が重要です：

  1. まず重複排除（マージ予定のレコードを正規化しないように）
  2. 次にメール検証（エンリッチメント前に無効なレコードを除去）
  3. 次に正規化（電話、国、日付、ライフサイクルステージ）
  4. 最後にエンリッチメント（任意、クリーンなレコードにのみ追加）
  5. エクスポート前にクリーンなデータセット全体をチェックリストでQA

クリーンなデータセットがQAを通過したら、フィールドマッピング文書を作成する準備が整います。そのプロセスは次のガイドで説明します。

関連ガイド