営業リストの収集や採点を自動化すると、候補数は増えても「以前に送った会社がもう一度出てくる」問題が起きます。送信直前に人が気づければ止められますが、下書き作成やタスク登録まで進むと、確認コストが増え、誤送信の危険も高まります。
結論は、新規候補を作った後ではなく、候補化する前に接触履歴を照合することです。会社名だけに頼らず、正規化したドメイン、問い合わせURL、法人名、接触状態を使い、送信済み、返信待ち、再送保留、永久除外を下書き生成前に落とします。
営業リスト重複防止の5段階
- 接触履歴を一つの機械用台帳へ集約する
- 会社名、ドメイン、URLを照合用に正規化する
- 収集直後、採点前に既存接触を除外する
- 除外理由と照合キーを候補ログへ残す
- 送信直前にも同じ台帳で最終確認する
送信直前だけの重複確認では遅い

候補収集、サイト診断、採点、順位付け、文面作成の順で処理する場合、最後だけ接触台帳を見ても、重複先へ途中工程の時間を使っています。候補がタスク一覧へ追加されると、人は「新しい見込み客」と認識しやすくなり、過去の送信記録を見落とすこともあります。
実運用では、送信済み11件が新規候補の下書きへ再び混入したことがありました。原因は接触履歴を持っていなかったことではありません。台帳は存在していたものの、候補収集と採点の入口で参照せず、後段の確認に任せていたことでした。重複防止は台帳の有無ではなく、照合する位置で決まります。
| 照合する位置 | 止められるもの | 残る無駄・リスク |
|---|---|---|
| 収集直後 | 診断、採点、下書き、タスク化 | 最小 |
| 採点後 | 下書き、タスク化 | 診断と採点コスト |
| 下書き後 | 送信 | 文面作成と人の確認コスト |
| 送信後 | 止められない | 重複送信、信用低下、対応負荷 |
接触台帳は状態と照合キーを分けて持つ
営業担当が読む表示名と、機械が照合するキーは同じでなくて構いません。会社名は全角・半角、株式会社の位置、屋号、支店名で揺れます。URLも`www`、末尾スラッシュ、問い合わせページのパス、HTTPからHTTPSへの転送で表記が変わります。
台帳へ残したい項目
- 接触IDと表示用の事業者名
- 正規化した法人名または屋号
- 主ドメインと問い合わせフォームURL
- 初回接触日、最終接触日、接触チャネル
- 未送信、送信済み、返信待ち、再送保留、除外の状態
- 次回確認日と再接触の可否
- 除外理由と根拠URL
- 同一事業者と判断した別名・旧URL
連絡先や個別のやり取りは、必要な権限のある台帳で管理します。候補生成スクリプトへ渡すのは、照合に必要なキーと状態だけに絞れます。営業文面や担当者の個人情報を生成AIへ毎回渡さなくても、重複除外は実装できます。
会社名・ドメイン・URLを段階的に照合する

一つのキーだけでは見落としと誤除外が起きます。まずドメインの完全一致を強い一致として確認し、次に問い合わせURL、正規化会社名を見ます。フリーメール、ポータルの共通ドメイン、制作会社配下のページなど、ドメインだけで同一事業者と判断できない場合は複数項目を組み合わせます。
- URL正規化: 小文字化、末尾スラッシュ整理、追跡パラメータ除去
- ドメイン抽出: `www`を整理し、主ドメインを比較する
- 名称正規化: 空白、全半角、法人格表記を照合用にそろえる
- 強い一致: 主ドメインまたは問い合わせURLが一致したら既存候補にする
- 弱い一致: 名称だけが近い場合は所在地や公式URLを追加確認する
- 状態判定: 送信済み、保留、除外なら候補化せず理由を記録する
表記を変える正規化処理では、元の値も残します。照合キーだけを見ると、なぜ同じ事業者と判定したか分からなくなるためです。候補ログへ「主ドメイン一致」「問い合わせURL一致」「名称と公式URL一致」のように根拠を残すと、誤判定の修正がしやすくなります。
同じドメインに複数の店舗や部署がある場合は、問い合わせ先の役割も確認します。本部へ一度連絡した後に各支店を新規候補として並べると、相手側には重複営業に見えることがあります。反対に、独立採算の別法人をドメイン一致だけで除外すると機会を失います。完全一致で自動除外する条件と、人が確認する曖昧一致を分けてください。
状態ごとに再提案ルールを変える
接触履歴に存在するすべての相手を永久除外すると、適切なフォローまで止まります。重複防止と再接触は別のルールとして設計します。新規候補生成は既存接触を除外し、返信待ちや7日フォローは接触台帳の期限から別工程で起動します。
| 状態 | 新規候補への追加 | 次の動作 |
|---|---|---|
| 未送信 | 既存候補を再利用 | 現物確認後に送信判断 |
| 送信済み | 追加しない | 返信確認日を待つ |
| 返信待ち | 追加しない | 受信箱を現物確認 |
| フォロー期限 | 新規扱いにしない | フォロー専用工程へ渡す |
| 再送保留 | 追加しない | 重複リスクが解消するまで停止 |
| 永久除外 | 追加しない | 理由を保持して探索対象外 |
未確認を未返信へ変えない
受信箱や管理画面を確認していない状態は、返信なしと同じではありません。自動化では「未確認」「返信なし」「返信あり」を分け、現物確認が必要な状態を勝手に確定させないようにします。
候補生成と送信の二重ゲートを作る
入口で除外しても、候補作成後に人が別経路から送信する場合があります。そのため、候補生成前と送信直前の二か所で同じ台帳を確認します。前者は無駄な処理を減らし、後者は作成後に変わった接触状態を反映します。
- 収集時点の台帳更新時刻を候補ログへ残す
- 候補ごとに使った照合キーと判定理由を保存する
- 送信直前に最新状態と最終接触日を再取得する
- 状態が変わった候補は送信せず再評価へ戻す
- 送信完了後は同じ処理内で接触IDと日付を登録する
- 外部送信は明示された承認範囲だけで行う
問い合わせの入口を整える場合はACS Contact Form、フォーム自体の公開前確認は問い合わせフォームの送信テスト、自動処理の二重起動は定期タスクの二重実行防止を参考にしてください。既存台帳と候補生成を接続する実装は開発依頼で相談できます。
よくある質問
Q. 会社名が一致すれば同じ相手として除外できますか?
A. 会社名だけでは同名企業や支店を誤除外する可能性があります。主ドメイン、公式URL、問い合わせURLなどを組み合わせ、名称だけの一致は確認待ちにしてください。
Q. 送信済み企業は永久に候補から外すべきですか?
A. 新規候補からは外しますが、正当なフォローは別工程で管理します。接触状態、次回確認日、再接触可否を台帳に持たせてください。
Q. スプレッドシートだけでも重複防止できますか?
A. 件数が少なければ可能です。照合キーと状態の列を固定し、候補生成前と送信直前に同じ表を参照できれば機能します。件数や経路が増えたら自動照合を検討します。
Q. 生成AIへ過去の営業文面を全部渡す必要がありますか?
A. 重複除外だけなら不要です。正規化した照合キー、接触状態、次回確認日など必要最小限のデータで判定し、個別の連絡内容は権限を分けて管理できます。
まとめ
営業リストの重複を防ぐには、送信直前だけでなく候補生成前に接触履歴を照合します。会社名、ドメイン、問い合わせURLを正規化し、送信済み、返信待ち、再送保留、除外を下書き作成前に落とします。候補生成と送信の二重ゲートを持ち、フォローは別工程へ分ければ、誤送信を防ぎながら必要な再接触を残せます。
この記事は役に立ちましたか?
ありがとうございます!