Salesforce重複ルールの検証方法｜警告・ブロック・例外経路を試すテスト設計

展示会で集めたリードを取り込み、翌日に営業担当者が同じ人を手入力すると、活動履歴が別々のレコードへ分かれることがあります。一方、名前が似ている別人までブロックすれば、営業は必要な登録を進められません。重複防止の確認では、重複を見逃すケースと、別人を誤って止めるケースの両方を用意します。

顧客を同一人物として扱う基準自体が未確定なら、先にCRMの名寄せで決める同一人物判定のルールを整理してください。ここでは既存データをまとめて統合する操作ではなく、Salesforceのルールを有効化・変更する前に、登録と編集の挙動を小さなテストで確かめる手順を扱います。

---

本記事のポイント

1. 照合ルールの一致条件と、重複ルールの警告・保存ブロック・記録を分け、作成と編集をそれぞれ検証します。
2. 項目アクセスと登録経路で検出・保存結果が変わり得るため、管理者の画面操作だけで検証を終えません。
3. 同時保存の制約を踏まえ、期待結果・実測結果・設定を戻す条件と後処理を残してから有効化を判断します。

---

照合ルールと重複ルールの役割を分ける

SalesforceのMatching Rule（照合ルール）は、どの項目をどう比較して一致とみなすかを定義します。Duplicate Rule（重複ルール）は、その照合ルールを使い、一致した場合に警告を出す、保存をブロックする、レポート対象として記録するなどの動作を設定します。作成と編集で動作を分けられるため、設定名だけでなくそれぞれの内容を記録します。

たとえばメールアドレスが同じリードを検出したい場合、照合条件が一致を返すかという試験と、その結果を受けて登録を止めるかという試験は別です。同じ条件でも保存を許可する運用はあり得ますし、厳しいブロックを設定しても照合条件が相手を見つけなければ止まりません。

この三段階に分けると、結果が違ったときも確認箇所を絞れます。重複を見つけない場合は照合条件や権限、見つけたのに保存できる場合は動作や登録経路、保存は止まるのに利用者が判断できない場合は警告文や運用手順を調べます。

公式ヘルプでは、重複ルールに関連付けた照合ルールがすべて有効でなければ、その重複ルールは機能しないと説明されています。有効化したつもりでも、組み合わせの一部が無効でないかを最初に確認します。複数の重複ルールを使う場合は、どのルールが結果を返したかも区別してください。

複数ルールの順序も検証対象です。公式ヘルプでは、最初の重複ルールが一致を見つけると、後続の重複ルールはそのレコードをスキップすると説明されています。BlockをAllowより前に配置する推奨を踏まえ、各ルール単独の結果と、実際の処理順序での結果を分けて試します。

設定を作成・編集・有効化する担当には「Customize Application」権限が必要です。設定を閲覧する権限と、対象オブジェクトのレコードを参照する権限は別に確認します。管理者が設定を見られることを、営業担当者の検査条件が同じであることの根拠にしないでください。

公式ヘルプは、Lightning ExperienceとSalesforce Classic、およびEssentials、Professional、Enterprise、Performance、Unlimited、Developerエディションを対象にしています。自組織で利用できる機能、対象オブジェクト、担当者の設定権限を確認してから検証範囲を決めてください。

変更前に期待結果とテストデータを固定する

最初に対象オブジェクト、照合ルール名、重複ルール名、作成時と編集時の動作、適用条件、実行順序、検証用ユーザーを一枚の表へまとめます。検証環境には、実在の顧客情報を無用に持ち込まず、識別できる架空のレコードを用意します。本番と異なる権限や設定がある場合は、相違を記録して結果の適用範囲を限定します。

以下は検証計画の例です。Salesforceがすべての行で同じ結果を保証する表ではありません。組織で採用する条件に基づき、実行する前に期待結果を記入し、実測結果と比べてください。「重複あり」の判定と「保存可否」を別の列にすると、不一致を説明しやすくなります。

たとえば架空の「テスト担当A」を既存レコードにし、別の「テスト担当B」に同じ検証用メール値を入れるケースを作ります。別人ケースでは、そのメール値を変え、名前だけを似せます。期待結果が両方とも「止まる」になってしまうなら、同一人物とする条件を見直す余地があります。

項目ごとの比較方法も明記してください。ExactとFuzzyでは照合の意味が違います。大文字・小文字や前後の空白、電話番号の表記などを一律に「自動で揃う」とは考えず、採用した項目と比較方法で試します。標準ルールの仕様を、独自の照合ルールへそのまま当てはめないことも大切です。

空欄は独立したケースにします。公式のMatching Rule説明では、「Match Blank Fields」を選択し、比較する両方が空欄なら一致として扱います。一方だけが空欄のケースや、この選択をしないケースは同じ結果ではありません。ただし、項目一つの一致がルール全体の一致を意味するかは、他の条件と組み合わせて確認します。

作成・編集・権限を変えて保存結果を確かめる

まず画面から新規レコードを作成し、警告、保存成功、保存ブロックを別々に記録します。警告が表示された後に利用者が保存を続けられるなら、その事実と、続行を認める業務上の条件を残します。警告の文面が理解できるか、既存レコードを確認できるか、誤検出の相談先が分かるかも利用者側で試してください。

次に、登録済みレコードを編集します。公式ヘルプでは、編集時の重複ルールは、変更した項目が関連付けられた照合ルールに含まれる場合に実行されると説明されています。メモなどの照合外項目を変えただけで、既存の重複が必ず再検査されるとは考えないでください。

そのため編集の試験は、比較する値を重複する値へ変更するケースと、比較する値を変えずに別項目だけ更新するケースに分けます。作成時にブロックできても、編集時の設定が違えば結果は変わります。見逃しを調べる際は「編集した」という記録だけでなく、どの項目が変更されたかを確認します。

権限差も結果に影響します。Salesforceは、利用者が照合ルールで参照する項目のいずれかへアクセスできないと、重複ルールが期待どおりに動作せず、重複が見つからない可能性があると注意しています。管理者だけで検証を終えず、実際に入力する利用者の権限条件で同じケースを試します。

ただし、重複防止のために全員へ広い参照権限を付ける判断は避けます。必要な照合項目、機密性、入力担当の役割を整理し、情報へのアクセスとデータ品質の両方を満たす設計を検討します。権限を変えた場合は、重複検出だけでなく、本来見せない情報が表示されないかも確認してください。

レポート対象として記録する設定を使う場合は、保存可否とは別に、どの重複レコードセット・レコード項目が作られるかを確かめます。記録された件数だけで入力経路全体を評価せず、実際に保存されたレコードIDと照合します。テストを繰り返す前に初期データへ戻すと、前の試験で作った重複を次の試験結果と混同しにくくなります。

API・インポート・同時保存を別の経路として検証する

画面で表示される警告は、APIやインポートの画面・応答へ同じように出るとは限りません。公式ヘルプは、これらの経路で警告が表示されず保存できない場合を説明しています。一方、REST APIには重複ルールの挙動を指定する専用ヘッダーがあるため、「APIなら全部ブロックされる」「警告設定なら必ず保存される」といった一律の理解は避けます。

REST APIのSforce-Duplicate-Rule-HeaderはAPIバージョン52.0以降で利用でき、allowSave、includeRecordDetails、runAsCurrentUserが定義されています。allowSaveは、その操作で警告が有効な場合に、警告を認めて重複レコードを保存できるかを指定します。すべてのBlock設定を解除する指定として扱わないでください。

使用するAPIの種類・バージョンと、実際に送るヘッダーを記録して、保存可否、応答に含まれる重複情報、共有条件を分けて試します。REST APIの契約を、Bulk APIや別のツールへ無条件に当てはめないでください。

連携製品がヘッダーを送るか、設定を変更できるかは、その製品の現行仕様で確認します。失敗応答を受け取ってもツールが独自に再送していれば、初回の保存結果だけでは最終件数を説明できません。要求ごとの処理結果、作成されたレコードID、再試行の有無を残すと、連携側とSalesforce側の切り分けができます。

CSV等のインポートでは、実際に使う取込方法、作成・更新の区別、識別キー、同じ取込データ内の重複を確認します。結果ファイルのエラー件数と保存済み件数を突き合わせ、失敗行だけを再投入した後にも重複が増えないかを確かめます。登録キーの問題と照合条件の問題を分けたい場合は、CRM外部ID・Upsertキーの設計も参照できます。

同時保存には明確な制約があります。公式ヘルプでは、重複する複数レコードを同時に保存した場合、警告・ブロックについては、それらのレコード同士ではなく、組織内にすでに存在するレコードと比較すると説明されています。レポートの記録はこの制約の影響を受けず、同時保存された一致レコードを重複レコードセットへ含めるとされています。

したがって「一件ずつ登録して二件目が止まった」という試験だけでは、同時投入への保証にはなりません。同時保存ケースを独立して試し、ブロックに頼りきれない登録経路では、取込前の重複確認と取込後の件数照合を組み合わせます。大量登録の前に小さなデータで実際の経路を確認するほうが、後から統合する手間を抑えられます。

重複ルールが実行されない操作もあります。公式ヘルプは、削除取り消し、手動マージ、Lightning SyncやEinstein Activity Captureなどを例として挙げています。連携や復元操作を使う組織は、ルールの対象外となる経路を確認し、別の点検が必要かを判断してください。ルールの有効化を、すべてのデータ流入に対する重複防止保証として扱わないことが重要です。

有効化の条件と戻す手順を検証記録へ残す

結果表には、ケースID、実施日時、検証環境、ルールと設定の版、利用者、登録経路、入力差分、期待結果、実測結果、保存されたレコードID、応答・画面の証拠、判定者を残します。失敗したケースは原因と修正後の再試験を同じ行へつなぎ、合格したケースだけを選んで報告しないでください。

有効化の判断は、警告が出たかではなく、必要な業務を誤って止めず、重要な重複ケースを把握できるかで行います。たとえば通常画面の作成・編集が合格しても、日次取込で予期しない保存失敗が出るなら、対象条件や取込方法を修正してから進めます。想定外の経路を残す場合は、その件数を誰がいつ照合するかまで決めます。

変更前の設定と有効化状態を保存し、問題が出た際にどのルールをどの状態へ戻すかを具体化します。戻す操作は将来の保存動作に関わるもので、すでに登録された重複を自動で統合する手順ではありません。誤検出で保存できなかった入力と、見逃しで保存された重複は、後処理の対象も分けて管理します。

公開フォーム、展示会取込、営業の手入力が混在する組織では、代表的な一経路だけを試して完了にしないでください。入力経路を一覧にし、利用者の権限条件と同時投入の有無を対応付けると、検証する順序を決めやすくなります。変更後は試験済みの経路から小さく適用し、保存失敗・誤検出・見逃しの実績を確認して適用範囲を見直します。

最後に営業担当者へ、警告時に既存レコードを確認する手順、続行できる条件、登録を止められた際の連絡先を共有します。重複が見つかった後の判断が担当者任せにならないように、入力ルールと例外の承認を揃えることが、検証結果を日常運用へつなぐ鍵です。

よくある質問

照合ルールだけを有効化すれば保存は止まりますか？

止まるとは限りません。照合ルールは一致条件を定義し、重複ルールが警告・ブロック等の動作を設定します。組み合わせと作成・編集それぞれの動作を確認してください。

編集すれば既存の重複を毎回検出できますか？

毎回ではありません。公式ヘルプでは、編集した項目が関連する照合ルールに含まれる場合に実行されると説明されています。照合項目の編集と、照合外項目だけの編集を別々に試します。

管理者の試験だけで権限差も確認できますか？

確認できません。利用者が照合に使う項目へアクセスできない場合、重複が検出されない可能性があります。実際の入力担当と連携用ユーザーの権限条件で検証してください。

APIでは画面と同じ警告が出ますか？

同じ表示にはなりません。使用APIの応答と保存件数で確認します。REST APIの重複ルール用ヘッダー、APIバージョン、利用ツールの設定も記録し、別APIへ結果を一般化しないでください。

同じCSV内の重複もすべてブロックされますか？

保証できません。同時保存では、警告・ブロックの比較対象は既存レコードであり、同時に保存されるレコード同士ではありません。取込方法に応じた試験と、取込前後の重複・件数照合が必要です。

ルールを無効化すれば登録済みの重複も元に戻りますか？

元には戻りません。ルールの無効化と、保存済みレコードの統合・修正は別の作業です。設定を戻す条件と、誤登録・保存失敗の後処理を分けて用意してください。

確認に使える公式資料

• Salesforce Help：Customize Duplicate Management
• Salesforce Help：Duplicate Rules
• Salesforce Help：Things to Know About Duplicate Rules
• Salesforce Help：Customize Duplicate Rules
• Salesforce Help：Matching Criteria in Matching Rules