メールアドレスの重複を安全に削除・統合する実践ガイド

CRMのエクスポートデータにフォーム送信やイベント参加者リストを統合すると、メールアドレスの重複がいつの間にか入り込んでしまいます。同じ人物が2回登録されていても、それぞれの行が完全に一致するケースはほとんどありません。一方には電話番号があり、もう一方には流入元や重要なメモが残っていることもあります。

そのため、私は重複したメールアドレスをいきなり削除しません。メールアドレスを安全に重複排除するには、Datablist Duplicates FinderでSmart matchingとEmail processorを使用します。表記の異なるメールアドレスをグループ化したうえで、連絡先の行全体を確認し、残したい情報を統合できます。

今回は、プラスエイリアスやGmailの表記ゆれ、ラッパー付きアドレスなど、実際によく見かけるパターンを含む1,000件のテスト用連絡先リストを用意しました。Datablistは200組の重複ペアを検出し、クリーニング後のコレクションは800件になりました。ここからは、使用した設定と、統合前に確認したポイントをご紹介します。

まずメールアドレスで照合し、何を残すかは連絡先の行全体を見て判断してください。 氏名、電話番号、企業ドメインなど、別の識別情報を比較したい場合は、オンラインでリストの重複を削除する方法もご覧ください。

Datablistが同一と判定するメールアドレス

Email processorを使ったSmart matchingでは、セル内の文字列そのものではなく、メールアドレスの同一性を比較します。前後の空白を削除し、小文字に変換して比較するほか、ローカルパートの+suffixを取り除いて照合します。

Gmail固有のルールも適用されます。Gmailアドレスではローカルパートのドットが削除され、googlemail.comはgmail.comとして扱われます。また、表示名で囲まれた文字列や、クエリ文字列を含むmailto:値から有効なアドレスを抽出することもできます。

テストデータに含まれる例をご覧ください。

ドットを無視する処理はGmailにのみ適用されます。 Datablistは、first.last@company.comとfirstlast@company.comを同じアドレスとは見なしません。Gmail以外のドメインでは、ドットに意味がある場合があります。

不正な形式の値も変更されません。このprocessorは、有効な単一メールアドレスを処理するためのもので、任意の文字列から意味を推測するものではありません。保存されている値が完全に一致する場合だけ照合したいときは、SmartではなくExactを選択してください。

🔑 正規化は重複候補のグループを提示します

すべてのフィールドが同一人物のものだと証明する機能ではありません。統合前に、氏名、会社、代表アドレスなどを確認してください。

一般的な連絡先リストのクリーニングでは、Email processorを使ったSmart matchingをおすすめします。エイリアスを別々に残す必要がある場合や、保存文字列自体を識別子として扱う場合に限り、Exactへ切り替えます。

正規化ルールの全内容と利用可能なプランについては、Email processorのリファレンスをご覧ください。

この手順で使用するメールリストの例

テストファイルには、800人分のIDを想定した1,000件の架空の連絡先データが含まれています。どの重複ペアも、元のメール文字列は完全には一致しません。完全一致だけでクリーニングすると、エイリアスを考慮した照合を再現できないためです。

ファイルには、record_id、first_name、last_name、email、company、phone、source、notesの8列があります。照合にはemailを使用しますが、マスターレコードを選び、有用な値を残せるよう、ほかのフィールドも表示したままにします。

2組の重複ペアから、実際の入力行を4件ご紹介します。

Noraのペアを見ると、重複を見つけてすぐ削除すべきでない理由が分かります。元のレコードには望ましいフルネームがあり、プラスエイリアス側の行にだけ電話番号と別の流入元が記録されています。統合すれば、両方を残せます。

データセットには、2行で構成される重複IDが200組あります。プラスエイリアス、ドット付きGmailアドレス、gmail.comとgooglemail.com、表示名ラッパー、mailto:値という5種類に均等に分かれています。残りの600件は1行ずつです。

手順を再現する場合は、1,000行のサンプルCSVをダウンロードできます。ご自身のファイルを使う場合は、1行につき1つのメールアドレスを入力し、統合したい関連フィールドも残してください。

メール列をインポートして準備する

CSVまたはExcelファイルを、新しいDatablistコレクションへインポートします。インポートのプレビューを確認し、メール列をemail propertyとしてマッピングしてください。

氏名、会社、電話番号、流入元、メモ、固定IDは、それぞれ別のpropertyとして残します。これらの列は不要な情報ではありません。メールアドレスは一致していても、ほかの情報が異なる2行を判断するための根拠になります。

このワークフローでは、1セルにつき1つのアドレスにすることもおすすめします。セルにalice@example.com; bob@example.comと入っている場合は、先に分割または正規化してください。このケースについては、複数のメールアドレスを含むフィールドを重複排除する方法で解説しています。

💡 統合の判断材料を残しておきましょう

重複排除の前に、流入元、メモ、電話番号、固定IDの列を削除しないでください。マスター行を選び、固有のデータを失わないために役立ちます。

Clean > Merge duplicatesを開きます。Selected Propertiesを選択し、今回のメール優先の処理ではemailを指定します。

propertyを1つに絞ると、ルールを理解しやすくなります。この段階で氏名や会社のpropertyを追加すると、値が欠けている場合や書式が異なる場合に、本来一致するメールアドレスを検出できない可能性があります。

Duplicates Finderを設定する

email propertyの比較アルゴリズムにSmartを選び、Email processorを指定します。

各設定には、それぞれ役割があります。

• Selected Propertiesでは、比較対象を目的の識別子だけに限定します。
• Smartでは、保存文字列の単純比較ではなく、processorによる正規化を有効にします。
• Emailでは、前述のエイリアス、Gmail、表示名、mailto:に関する検証済みルールを適用します。

アドレスの表記ゆれを検出するには、SmartとEmail processorを併用してください。Exactで検出できるのは、保存値が完全に一致する場合だけです。

重複チェック自体は読み取り専用です。実行すると確認用の候補グループが作成されますが、コレクションの行が削除または統合されることはありません。変更が行われるのは、統合または削除の操作を選び、適用した後です。

この分離は重要です。一括統合でリストを変更する前に、照合ルールが何を同一と判断したのかを確認できます。

チェックを実行して重複グループを確認する

Run duplicates checkをクリックします。今回のテストでは、1,000行のうち400行が、2行ずつの200グループに分類されました。

この時点では、グループ数を削除件数と考えないでください。各グループは確認候補です。グループごとに、次の点を確認します。

• メールアドレスの表記ゆれに妥当性があるか
• 姓名が一致しているか、または違いを合理的に説明できるか
• 会社や電話番号の値が競合していないか
• 流入元やメモに補完的な情報があるか
• 共用アドレスではないか

通常は、最初の数グループと、会社をまたぐ意外な一致を確認してから一括ルールを適用します。統合しすぎたデータを後から修復するより効率的です。

⚠️ 同じアドレスでも、同じ人物とは限りません

sales@company.comのような共用アドレスが、複数の正当な連絡先に登録されていることがあります。すべてを1件にまとめず、役割ベースのアドレスは手動で確認してください。

テストファイルは、正規化された各ペアが同一人物を表すよう設計されています。実際のCRMエクスポートは、より複雑です。氏名や会社から別人と判断できる場合は、そのグループをスキップするか、個別に確認してください。

統合か削除かを選ぶ

私が使っている判断基準はシンプルです。

• 行同士に補完的なデータがある場合は統合する
• 追加の行に有用な値がない場合だけ削除する
• 判断が難しいグループは手動確認に回す

今回の処理では、最も情報が充実している行をマスターとして選択しました。マスターのrecord_idを維持し、姓名には最も長い値を採用し、sourceとnotesはセミコロンで結合しています。

この設定は今回の例に適していますが、競合するすべてのpropertyを無条件に結合することはおすすめしません。流入元の履歴ならWebサイトのフォーム;CRMエクスポートとしても問題ありません。一方、CRMステータス、担当者ID、メインのメールアドレスには、通常1つの正式な値が必要です。

選択内容はプレビューで検証します。ルールを変更したら、統合先の行をもう一度確認してください。

💡 ルールを変更するたびにプレビューしましょう

準備済みの全グループにルールを適用する前に、どの行がマスターになるか、どの値が結合され、どの値が消えるかを確認してください。

重複行に固有の電話番号、流入元、メモがある場合は、削除せずに統合してください。 Noraの例では、一方のレコードからフルネームを、もう一方から電話番号を残せました。

CRM内の複雑な競合を処理する場合は、データを失わずに重複Leadを統合する方法もご活用いただけます。今回のメール中心の処理では、すべてのpropertyを複数値の文字列にすることなく、有用な関連フィールドを残すことが目的です。

1,000行のテストリストで得られた結果

統合の実測結果は次のとおりです。

計算は明快です。開始時の1,000行 - 削除された200行 = 残った800行となります。

人が操作した今回のテストでは、統合は数秒で完了しましたが、正確な時間は計測していません。性能のベンチマークではなく、今回の実行結果としてお考えください。

ダウンロードした変更ログには、削除された200行と更新された200件のマスター行を合わせた400件の記録があります。各統合グループについて、統合前の値と、統合先の行に残された値を確認できます。

以下の表では、実行時の値をそのまま掲載しています。

残される値が、見た目上最もシンプルなメールアドレスとは限りません。どの保存済みメールアドレスが残るかは、選択されたマスターレコードによって決まります。正規化は照合に使用されますが、残す値が自動的に標準形式へ書き換えられるわけではありません。

今回のテストでは、確認済みの重複行200件をマスターレコードへ統合したため、1,000行が800行になりました。 これは設計されたテストリストでの結果であり、あらゆるメール形式に共通する検出率ではありません。

失敗しやすいケースと検証チェックリスト

Smart Email matchingは、テストした5種類の表記ゆれに対応しますが、人による確認の代わりにはなりません。

Gmail以外のドット

Gmail以外のドメインでは、ドットは区別されます。first.last@company.comとfirstlast@company.comが同じメールボックスだと決めつけないでください。両者を結び付ける外部の根拠がある場合は、そのペアを手動で処理します。

不正な形式の値

不正な文字列や、有効な単一メールアドレスの形式ではない値は変更されません。該当セルをクリーニングするか、別の確認キューへ移してください。processorが任意のテキストからアドレスを推測することはありません。

Exact matching

Exact comparisonでは、保存文字列が異なるプラスエイリアス、Gmailのドット表記、ドメインエイリアス、ラッパーを検出できません。エイリアスを別々に残したい場合には適切ですが、このワークフローで使用する設定ではありません。

1セルに複数のアドレス

この方法は、1セルにつき1つのアドレスを前提としています。区切り文字で複数のアドレスが入ったセルには、行単位で照合する前に、別の複数値用ワークフローが必要です。

共用メールアドレス

sales@company.comを持つ2行が、別々の人物を表している場合があります。氏名、役職、会社、メモを基に判断してください。役割ベースのアドレスは、確認せずに一括統合しないことをおすすめします。

補完フィールドの削除

余分に見える行を削除すると、唯一の電話番号、流入元、メモまで失う可能性があります。統合プレビューで、どの情報が残るかを確認してください。

今回のテストでは、意図した200件のIDをすべて検出し、異なるID同士が誤ってグループ化されることはありませんでした。ただし、実在するあらゆるメール形式、不正な値、共用アドレスのパターンをテストしたわけではありません。

ご自身のリストをエクスポートする前に、次の項目を確認してください。

• 承認した各グループが1人のIDを表している
• 共用・役割ベースのアドレスを手動で確認している
• マスター行に望ましい氏名、ID、メールアドレスが入っている
• 固有の電話番号、会社、流入元、メモが統合後も残っている
• 開始行数から削除行数を引いた値が最終行数と一致する
• リストに含まれる各正規化パターンを抜き取り確認している
• 残りの重複グループ数が想定と一致する

📌 件数を照合しましょう

統合後の完全性を素早く確認するには、開始行数 - 削除行数 = 最終行数をチェックしてください。

メールリストのクリーニングを続ける

重複排除で解決できるのは、同じIDの重複です。メールボックスの実在性、使い捨てメールのprovider、配信停止状況、到達可能性までは確認できません。

私は、まず重複するIDを解消するようにしています。そうすれば、後続のチェックは同じ人物の複数バージョンではなく、残した連絡先だけを対象に実行できます。統合結果がチェックリストを満たしたら、メールリストの残りをクリーニングし、Exportを開いてCSVまたはExcelを選択してください。

Datablistでメールの重複を解消する

連絡先ファイルをDatablistへインポートし、メールアドレスに対応した重複チェックを実行します。候補グループを確認し、有用な値を統合してから、クリーニング済みのリストをエクスポートしてください。

FAQ

メール照合で大文字・小文字は区別されますか？

Smart Email comparisonでは、小文字に変換した値を照合に使用します。そのため、正規化後のほかの部分が一致すれば、NAME@example.comとname@example.comを同じグループにできます。

Gmailのドットとプラスエイリアスは同じアドレスですか？

Smart Email matchingでは、ローカルパートのプラス接尾辞を削除し、Gmailのローカルパートにあるドットを無視します。ドットのルールはGmail限定で、Gmail以外のドメインでは引き続き区別されます。

重複した連絡先は統合と削除のどちらが適切ですか？

別の行に電話番号、流入元、メモ、会社情報などの有用なフィールドがある場合は統合します。必要な情報が何も追加されない場合に限り、余分な行を削除してください。

1つのセルに複数のメールアドレスがある場合は？

行単位のワークフローを実行する前に、複数値のセルを分割または正規化してください。複数のメールアドレスを含むフィールドを重複排除する方法をご覧ください。

sales@company.comのような共用アドレスも統合すべきですか？

自動的には統合しないでください。1つの共用アドレスが複数の連絡先を表す場合があります。氏名やほかのフィールドを比較し、該当グループを手動で確認してください。