Salesforceの重複データを安全に統合する方法——標準機能の限界と実務手順

2026.08.14Salesforce比較・選び方

Salesforceの重複データは、「見つける」より「消す」のが難しい問題です。取引先には商談・活動・ケースがぶら下がっているため、安易に削除もマージもできない。標準機能は検出までは助けてくれますが、統合の実行は手作業が前提です。この記事では、Salesforce標準機能でできること・できないことを整理したうえで、重複データを安全に統合するための実務手順5ステップと、つまずきやすい落とし穴を解説します。

Salesforceの重複が「消すに消せない」理由

ExcelやCSVの重複なら、行を消せば終わりです。Salesforceの重複が厄介なのは、レコードが単体で存在していないからです。

取引先には商談・活動（行動/ToDo）・ケース・取引先責任者がぶら下がっている
重複した2件の取引先には、それぞれ別の商談や対応履歴が記録されている
片方を消せば、そちら側の商談・履歴ごと見えなくなる——営業の記録が失われる
レポートやダッシュボードは重複を含んだまま集計され、同じ会社の売上が2つに割れて数字が信用されなくなる

重複した取引先2件それぞれに商談・活動・ケースがぶら下がっている統合前の状態と、統合後に関連レコードがすべて勝ちレコードへ付け替わり件数の合計が保たれる状態を示すbefore/after図 — 統合の正体は「削除」ではなく、関連レコードを勝ちレコードへ付け替えたうえでの集約

具体的に想像してみてください。「株式会社プラート」と「㈱プラート」が別レコードとして存在し、片方には今期の商談2件と最近の活動履歴、もう片方には過去の商談1件と請求関連の情報が記録されている——どちらも消せません。営業現場では「どちらに活動を記録するか」が人によってバラバラになり、履歴は割れ続けます。経営会議では顧客別売上ランキングの上位に同じ会社が2回登場し、「この数字、合ってるの？」という一言でダッシュボード全体の信用が下がります。

つまりSalesforceの重複統合は「削除」ではなく、残す1件を決めて、消える側の関連レコードを付け替えたうえで統合する作業です。上の図のとおり、統合の前後で商談・活動・ケースの件数の合計が保たれていることが「安全に統合できた」ことの定義になります。ここを丁寧にやらないと、データはきれいになっても業務の記録が壊れます。だからこそ多くの組織で重複が放置され、増え続けるのです。増える経路も分かっていて、日々の手入力に加えて、展示会リードの一括インポート、名刺管理ツールからの取り込み、マーケティングオートメーションとの連携が代表格です。放置している限り、重複は入り口の数だけ複利で増える——これが「いつか片づける」が通用しない理由です。

標準機能でできること・できないこと

Salesforceには重複対策の標準機能が用意されています。まず守備範囲を正確に押さえましょう。

機能	できること	限界
重複ルール／一致ルール	登録・編集時に重複候補を検出し、警告またはブロック。重複レコードセットとしてレポートも可能	あくまで検出と入力時の警告まで。既存の重複を統合してはくれない。一致ルールの条件も表記揺れの吸収には限界がある
レコードのマージ（取引先・取引先責任者・リード）	重複候補から残すレコードと残す項目値を選んで統合。関連レコードは残るレコードに引き継がれる	一度に扱えるのは3件までの手作業。項目値の選択はできるが、関連レコードの付け替え方を細かく選ぶ余地は少ない
一括処理	——	標準のマージUIに一括マージの機能はない。数百組の重複を標準機能だけで処理するのは現実的でない

入力時の警告・重複候補の検出・1組ずつの手動マージはSalesforce標準機能で対応でき、溜まった重複の一括マージ・表記揺れを吸収する検出・付け替えのプレビュー・ロールバックは外部ツールやAPIの領域であることを示す境界図 — 標準機能の守備範囲と、その外側——数百組を超えたら右側の手段が必要になる

まとめると、標準機能は「これから入る重複を水際で減らす」ことと「見つけた重複を1組ずつ手で統合する」ことはできますが、すでに溜まった重複をまとめて安全に統合する機能は持っていません。なお、重複管理機能の細かい挙動や利用可否はエディションや設定により異なります。

実務での使いこなしとしては、まず重複ルールを有効化して入り口を締めるのが最初の一手です。設定の際は「警告」と「ブロック」の使い分けに注意してください。いきなりブロックにすると、正当な新規登録（同名の別会社や支店）まで止まり、営業から不満が出ます。まず警告で運用し、誤検知が少ないことを確認してからブロックに切り替えるのが安全です。また、一致ルールは標準設定だと「株式会社」の有無や全角/半角のような揺れを拾いきれないことが多く、あいまい一致の調整にも限界があります。検出の網は思っているより粗いという前提で、すり抜けを定期的に確認する運用が必要です。

規模の判断は、重複レコードセットのレポートで概算できます。重複が数十組ならば手作業のマージで十分です。問題は数百〜数千組の場合で、1組あたり数分としても数十時間規模になり、外部ツールやAPIによる統合を検討することになります。その際のツールの見極め方は「名寄せツールの選び方——外してはいけない5つのチェックポイント」を参考にしてください。

安全に統合する実務手順——5ステップ

手作業でも外部ツールでも、安全な統合の手順は共通です。順番を飛ばさないことが何より重要です。着手前にひとつだけ体制の話をすると、「このデータの責任者は誰か」を1人決めてください。統合は「どちらを残すか」という判断の連続で、判断基準が人によってブレると、後から監査も説明もできなくなります。以下の5ステップは、その責任者が回す前提で書いています。

ステップ1：バックアップ／スナップショットを取る

統合を始める前に、対象オブジェクト（取引先・取引先責任者・商談・活動など）のエクスポートを取ります。週次エクスポートやデータローダーによる全件バックアップでも構いませんが、大事なのは「マージ実行の直前の状態」が残っていることです。注意点は2つ。取引先だけでなく関連オブジェクトも一緒に取ること（取引先単体のバックアップでは、付け替えの検証も復旧もできません）、そして各レコードのIDを必ず含めることです。誤マージが起きたとき、これがあるかないかで復旧の工数が桁で変わります。

ステップ2：重複条件を定義する

「何をもって同じ会社とみなすか」を先に文章化します。会社名の完全一致だけでは「㈱プラート」と「株式会社プラート」を拾えず、名前だけで寄せると同名の別会社を誤って統合します。会社名（正規化後）＋住所や電話番号、可能なら法人番号を組み合わせるのが定石です。実務のコツは、条件を1本で完璧にしようとせず、確信度の高い順に複数本へ分けることです。第1弾は法人番号の一致（ほぼ確実）、第2弾は正規化した社名＋電話番号の一致、第3弾は社名の類似＋住所の部分一致（要目視）——のように分けると、確実な組から安全に消化できます。あわせて「どちらを残すか」（作成日が古い方、活動が多い方、など）のルールも決めておきます。

ステップ3：プレビューで件数と中身を確認する

定義した条件でマージ候補を抽出し、実行する前に件数と組み合わせの中身を確認します。想定より件数が多すぎる場合は条件が緩すぎるサイン、少なすぎる場合は表記揺れを拾えていないサインです。目視のサンプルは最低30組、できれば100組。そして誤検出（別会社の組）が1組でも見つかったら、その1組を例外処理にするのではなく条件そのものを締めてやり直すのが原則です。1組見えたなら、見えていない同種の誤りがまだあると考えるべきだからです。

ステップ4：承認して実行する

確認した内容を、データの責任者が承認してから実行します。担当者ひとりの判断で数百組をマージしない、というのが組織としての安全装置です。件数が多い場合は、確信度の高い組から段階的に実行するのが安全です。もうひとつ大事なのが現場への事前アナウンスです。「金曜の夜に取引先の統合を実行します。月曜に見え方が変わっているレコードがあります」と伝えておくだけで、「勝手にデータが変わった」という不信と問い合わせの山を防げます。

ステップ5：関連レコードの整合を確認する

実行後、消えた側にぶら下がっていた商談・活動・ケースが残った側に付け替わっているか、件数ベースで突き合わせます。「マージ前の商談合計件数＝マージ後の商談件数」が成立していれば、記録は失われていません。レポートでマージ前後のスナップショットを取って比較すると、この確認は数分で終わります。あわせて、統合後の取引先に紐づく取引先責任者に同一人物の重複が残っていないか（取引先を統合すると責任者の重複が顕在化しがちです）も見ておくと、二度手間を防げます。

実行前の状態に戻せるバックアップ／スナップショットはあるか？（関連オブジェクト・ID込みで）
重複条件と「どちらを残すか」のルールは文章になっているか？
実行前に件数と組み合わせをプレビューで確認したか？（誤検出1組でも条件を見直す）
データの責任者が承認し、現場に事前アナウンスしてから実行しているか？
実行後に関連レコードの件数を突き合わせたか？

付け替えの落とし穴——親子関係・ゴミ箱・書き戻し中の競合

手順どおりに進めても、つまずきやすいポイントが3つあります。事前に知っておくと事故を防げます。

落とし穴	何が起きるか	対策
親子関係のある取引先	統合対象が別の取引先の親（または子）だった場合、階層構造が意図せず組み替わる。グループ企業の集計が崩れる	マージ候補に親取引先・子取引先が含まれていないかを事前に抽出し、階層の扱いを先に決める
ゴミ箱の挙動	マージで消えた側のレコードはゴミ箱に入るが、保持期間を過ぎると完全に消える。「後で見返せばいい」は期間限定でしか通用しない	ゴミ箱を復旧手段として当てにせず、ステップ1のバックアップを正とする。保持期間は設定により異なるため事前に確認
書き戻し中の競合	外部ツールで統合処理を走らせている最中に、営業担当が元レコードを更新すると、更新が統合結果に反映されず消えることがある	実行時間帯を業務時間外にする、または実行中の変更を検出して該当の組だけ処理を止められる仕組みを使う

この3つのほかにも、細かい仕様のつまずきどころがあります。マージ後のレコードの所有者や共有の見え方が変わり、消えた側を担当していた営業からレコードが見えにくくなることがあります。また、消える側に紐づいていた情報の中には、マージで引き継がれない種類のもの（フィード投稿など）もあります。細かい挙動はオブジェクトや設定によって異なるため、本番の前にSandboxで代表的な組を統合してみて、引き継がれるもの・消えるものを自社の構成で確認しておくのが確実です。

3つ目の「書き戻し中の競合」は、具体的にはこういう事故です。金曜夜に数千組の統合バッチを流し始めたが、処理が土曜朝までかかった。その間に海外拠点の担当者が対象レコードの電話番号を更新していた。統合結果はバッチ開始時点のデータで書き戻されたため、更新は誰にも気づかれずに消えた——。この種の消失はエラーにならないのが厄介な点で、レコード数が多く処理時間が長いほど起きやすくなります。数千組規模の統合では、競合の検出が仕組みとして備わっているかどうかが、ツール選定の実質的な分かれ目になります。

ナヨセルのSalesforce対応

当社が提供するAI名寄せ・顧客データ統合クラウド「ナヨセル」は、ここまで述べた実務手順と落とし穴への対策を、Salesforce向けの標準機能として備えています。

標準マージ処理による統合——Salesforce標準のマージ処理を外部から実行して統合します。標準UIの手作業と違い、承認済みの組を件数の制限なくまとめて処理できます
関連レコードの付け替え——商談・対応履歴などの関連レコードを、残るレコードへ付け替えます。付け替えの結果は実行前にプレビューで確認できます
実行前スナップショット——マージ実行の直前の状態を自動で保存。誤りに気づいたら1クリックでロールバックできます
書き戻し中の競合検出——書き戻しの最中に元レコードが更新された場合はそれを検出し、該当の組を承認キューへ差し戻します。営業の更新が黙って消えることはありません
承認キューと監査ログ——AIが叩き台をつくり、確定は人の承認で。確信度に応じて自動マージ・承認待ち・対象外に分類され（しきい値調整可）、誰が・いつ・どのルールで・何と何を統合したかは監査ログに残りCSV出力できます

5ステップの手順でいえば、ステップ1のスナップショット、ステップ3のプレビュー、ステップ4の承認、ステップ5の検証までが製品の中に組み込まれており、手順書を人力で回す必要がありません。規模の面でも、582万件の突合シミュレーションが90秒で完了する処理性能（実測）があるため、レコード数を理由に統合を諦める必要はありません。重複条件はAIのレコメンド／日本語で書くだけ／SQLの直接指定から選べ、表記揺れは文字の正規化・辞書・類似度の3層で吸収します。gBizINFO・法人番号公表サイト由来の法人マスタ（500万法人超）を同梱しているため、同名別会社の見分けにも使えます。AIを使った名寄せの仕組みそのものは「AI名寄せとは何か」で、ツール全体の比較は「名寄せツール比較——方式別4タイプ」で解説しています。料金はプランページをご覧ください。