Salesforce重複ルール・一致ルール実務ガイド【前編】 重複判定設定後の挙動・データローダ/API・実行順序まで

2026.07.02

#Salesforce #重複ルール #一致ルール #重複判定設定後

Salesforce を運用していると、同じ顧客や同じ会社が複数レコードとして登録されてしまうことがあります。重複データは、営業活動の二重対応、古い情報による顧客対応、レポートの集計ずれなどにつながります。
本記事では、全2回に渡ってSalesforce の「重複ルール」と「一致ルール」について、基本的な設定手順だけでなく、実務でつまずきやすいデータローダ・API 経由の挙動、Lightning ページの「潜在的な重複」表示、マージ後の処理、複数一致ルール・クロスオブジェクト判定まで整理します。

後編記事はこちらから「Salesforce重複ルール・一致ルール実務ガイド【後編】」
 

第1回である今回は下記の範囲を整理していきましょう。

この記事で扱う範囲

記載カテゴリ	内容
基本構造	一致ルールと重複ルールの役割の違い
設定の考え方	リードを例にした一致ルール・重複ルールの設定方針
実務上の落とし穴	許可時のオプション、ブロック時の保存不可、画面表示との違い
データ移行・連携	データローダ/API 経由で Insert/Update した場合のエラー条件と例外
自動化順序	before フロー、before Apex トリガ、重複ルール、after Apex トリガ、after フローの関係

 

重複管理の全体像

Salesforce の重複管理は、主に「一致ルール」「重複ルール」「潜在的な重複コンポーネント」「重複レコードセット／重複レコード項目」「重複ジョブ」で構成されます。

機能	役割	実務上のポイント
一致ルール	どの項目をどう比較して重複とみなすかを定義する。	メール完全一致、電話番号あいまい一致、氏名＋会社名などの判定ロジックを設計する。
重複ルール	一致ルールで重複と判定されたときに、許可・ブロック・アラート・レポート作成を制御する。	「保存させるか」「画面に出すか」「レポートに残すか」はここで決まる。
潜在的な重複コンポーネント	Lightning レコードページ上に重複候補を表示する。	画面上でマージ運用をさせたい場合に重要。レポート用の重複レコードセットとは別経路で判定される。
重複レコードセット	重複として識別されたレコードのグループを表す親レコード。	重複ルールのレポートオプションや重複ジョブにより作成される。マージ後も残る場合がある。
重複レコード項目	重複レコードセットに含まれる各候補レコードを表す子レコード。	カスタムレポートタイプでは対象オブジェクトと組み合わせて使うことが多い。
重複ジョブ	既存データ全体から重複候補を洗い出す機能。	既存データを一括で見つけたい場合は、レコード表示時の候補表示だけに頼らない。

 

一致ルールと重複ルールの違い

重複管理をする上でのベースとなる一致ルール、重複ルールの違いを整理します。
一致ルールで「何をもって重複と判断するか」を定義し、
重複ルールで「重複と判断されたときのアクション」を定義します。

観点	一致ルール	重複ルール
目的	「何をもって重複と判断するか」を定義する。	「重複と判断されたときに何をするか」を定義する。
主な設定	比較項目、一致メソッド、条件ロジック、空白項目の扱いなど。	許可／ブロック、許可時のアラート・レポート、レコードセキュリティ、実行条件など。
例	メールが完全一致する。電話番号があいまい一致する。氏名と会社名が一致する。	保存を許可して警告する。保存をブロックする。保存された重複をレポート対象にする。
設計のコツ	重複判定そのものの精度を高める。	誰に・いつ・どの場面で重複判定を適用するかを制御する。

 

 

設定例：リードの電話番号重複を検知する

ここではリードオブジェクトで「既存リードと電話番号が一致する新規リードを保存したときにアラートを表示する」例で
一致ルールと重複ルールの設定例を説明します。

●一致ルール

手順	設定内容	補足
1	設定画面で「一致ルール」を検索し、新規一致ルールを作成する。	対象オブジェクトは「リード」
2	ルール名・一意の名前・説明を入力する。	例：リード一致ルール
3	一致条件として「電話」を選択し、一致メソッドを設定する。	完全一致またはあいまい一致を選択。電話番号のあいまい一致は後述の注意点あり。
4	一致ルールを保存し、有効化する。	有効化しないと重複ルール側で動作しない。

 

 

●重複ルール

手順	設定内容	補足
1	設定画面で「重複ルール」を検索し、新規重複ルールを作成する。
2	リード用の新規重複ルールを作成する。	対象オブジェクトは「リード」。
3	ルール名・説明を入力する。	例：リード重複ルール。
4	作成時のアクションを「許可」、アラートを ON にする。	画面上で警告を出して保存続行を許す構成。データローダ/API では挙動が異なるため後述。
5	比較対象に「リード」を選び、作成した一致ルールを指定する。	保存後、有効化してテストする。

 

 

一致メソッドの考え方、電話番号「あいまい一致」の注意点

一致ルールでは、項目ごとに「完全一致」や「あいまい一致」などの一致メソッドを指定できます。便利な一方で、日本の電話番号では誤検知も起きやすいため、実データに近いパターンで検証することが重要です。

一致メソッド	特徴	向いているケース	注意点
完全一致	値が完全に一致した場合に重複とみなす。	メールアドレス、正規化済み電話番号、外部 ID など。	表記ゆれを吸収できない。ハイフン有無や全角半角差がある場合は別値になる可能性。
あいまい一致	値を分解・スコアリングし、一定以上似ている場合に重複とみなす。	氏名、会社名、電話番号など表記ゆれが起きる項目。	似ているが別物の値を重複と判定することがある。

 

●電話番号にあいまい一致を適用する際の例
下記のようにハイフン有無の表記ゆれを吸収できる一方で、日本環境では意図せず一致判定される場合があるため注意が必要です。

比較例	期待されるメリット	注意点
03-1111-1111 と 0311111111	ハイフン有無の表記ゆれを吸収可能。	入力形式の差を吸収できるため、メンテナンス観点では便利。
03-1111-1111 と 03-1111-1112	一部の桁だけが違う近い番号も、スコア次第で一致判定される可能性がある。	検証環境では一致判定されるケースがあった。日本環境では必ず検証する。

 

 

重複ルールのアクション・アラート・レポート

重複ルールは「アクション（許可orブロック）」「アラート」「レポート」の組み合わせで設定できます。
下記の観点を元に最適な設定を検討しましょう。

設定	意味	画面操作への影響	運用上のポイント
アクション：許可	重複候補であってもレコード保存自体は許可する。	ユーザーは警告を確認して保存続行できる構成にできる。	アラート／レポートの有無を組み合わせて、画面通知とレポート記録を制御する。
アクション：ブロック	重複候補の保存を許可しない。	ユーザーはレコード保存できない。	ブロック時は保存不可の制御として扱う。アラート／レポートの ON/OFF 組み合わせで設計するものではない。
アラート ON（許可時）	ユーザーに重複の可能性を知らせる。	画面では警告や候補表示により、ユーザーが確認して保存続行する導線を作れる。	画面でのマージ導線を考える場合に重要。データローダ/API ではエラー要因になるため要注意。
アラート OFF（許可時）	ユーザーに警告を出さない。	画面上の通知を抑えつつ保存できる。	大量移行やシステム連携で重複を保存したい場合に検討する。
レポート ON（許可時）	保存された重複候補を重複レコードセット／重複レコード項目として記録する。	画面上のアラート表示そのものは「アラート」が担う。	後からレポートで確認・運用するなら ON が必要。ブロックされて保存されなかったレコードを記録する設定ではない。
レポート OFF（許可時）	保存された重複候補をレポート用レコードとして残さない。	画面上のアラート表示そのものは「アラート」が担う。	運用で重複判定を後追い確認しない設計の場合のみ検討する。

 

 

データローダ・API 経由でレコード作成／更新時の挙動

重複判定の運用を考える上で重要な観点の１つです。
画面操作では「警告を見て保存続行」ができますが、データローダや API 連携ではユーザーが画面上でアラートを確認する操作がありません。そのため、[アラート]ON の場合はデータローダ・API 経由での取込みエラーとなるため、運用上注意が必要です。

重複ルール設定	データローダによる作成／更新時の考え方	レポート記録	補足
許可＋アラート ON＋レポート ON	取込みエラー。画面では保存続行できても、データローダ側でアラートを承認できないため。API で DuplicateRuleHeader.allowSave=true 相当を指定できる場合は保存可能。	保存された場合は重複レコードセット／重複レコード項目が作成される。	アラート ON の場合はデータローダではエラーになる前提で設計する。
許可＋アラート ON＋レポート OFF	取込みエラー。レポート有無は保存可否ではなく記録有無に関係する。API で allowSave=true 相当を指定できる場合は保存可能。	レポート用レコードは作成されない。	重複を保存したいだけなら、アラート OFF の構成も検討する。
許可＋アラート OFF＋レポート ON	取込み成功。重複判定に合致しても保存される。	複レコードセット／重複レコード項目が作成される。	データローダなどでの大量取込後に運用者が確認する構成に向く。
許可＋アラート OFF＋レポート OFF	取込み成功。重複判定に合致しても保存される。	レポート用レコードは作成されない。	重複検知しても具体的に何もアクションは起こさない点に注意。
ブロック	取込みエラー。保存自体がブロックされる。	保存されないため、保存された重複としてのレポート記録は発生しない。	データ品質を強制できるが、業務停止や連携エラーのリスクがある。

 

 

リストビューインライン編集時の挙動

データローダなどのAPI経由と似た観点ですが、リストビューからのインライン編集時も注意が必要です。
重複ルールで[アラート]ONにしていると、インライン編集時にはアラートを確認する操作がありません。
そのため[アラート]ON の重複ルールに該当する更新は、リストビューのインライン編集では保存エラーになる場合があります。インライン編集を多用する運用では、対象オブジェクト・対象項目・重複ルールの設定を事前に検証しておく必要があります。

 

実行順序：重複ルールはどのタイミングで動くか

保存時の実行順序では、重複ルールは保存前レコードトリガーフローと before Apex トリガの後に実行されます。ブロックアクションに該当するとレコードは保存されず、after Apex トリガや保存後レコードトリガーフローなどの後続処理は実行されません。

順序	処理	実務上の注意点
1	保存前レコードトリガーフロー（before-save flow）	値を整えてから重複判定したい場合に有効。
2	before Apex トリガ	before トリガで更新した値も重複判定に使われる。
3	重複ルール	ここでブロックされると保存されず、後続処理は実行されない。
4	レコード保存（まだコミット前）	保存が許可された場合に進む。
5	after Apex トリガ	保存後に実行される。after フローより先。
6	ワークフロールールなどの後続処理	ワークフロー項目自動更新がある場合は再評価が発生することがある。
7	保存後レコードトリガーフロー（after-save flow）	重複判定後の処理。ここで更新した値はその保存操作の重複判定には使われない。

 

FAQ

質問	回答
重複ルールを有効化すると、既存の重複データも自動修正されますか？	いいえ。重複ルールは主に作成・更新時やレコード表示時の判定に使われます。既存データを網羅的に洗い出すには、重複ジョブやレポートを検討します。
データローダで重複も取り込みたい場合はどうしますか？	アクションを「許可」、アラートを OFF にする構成を検討します。レポートで後から確認したい場合はレポート ON にします。API では allowSave の利用可否も確認します。
重複ルールが機能しないタイミングはありますか？	重複ルールが実行されない主なタイミングは下記です。 ・リードを取引先または取引先責任者に変換する場合（「Apex リード変換の使用」が無効の場合） ・「復元」ボタンを使用してレコードを復元した場合 ・Einstein 活動キャプチャによってレコードが追加された場合

 

 

まとめ

前編では、重複ルール・一致ルールの基本構造、許可／ブロック、アラート、レポート、
およびデータローダ/API の挙動、実行順序を整理しました。
実務では、ブロック時は保存不可であること、アラート／レポートは許可時の運用オプションとして扱うこと、アラート ON はデータローダ取込み時のエラー要因になることを押さえて設計する必要があります。

後編記事はこちらから「Salesforce重複ルール・一致ルール実務ガイド【後編】」

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら