> For the complete documentation index, see [llms.txt](https://support.bridge-funeral.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.bridge-funeral.com/huan-jing-gou-zhu-yun-yong/22-duplicate-and-matching-rules.md).

# 重複管理｜一致ルール・重複ルールとレコードマージ

「同じお客様が 2 件登録されてしまった」「受電時に新規登録したけど、実は既存だった」 — 葬儀社の業務でよく発生するデータ品質の問題です。Salesforce には **重複管理 (Duplicate Management)** という標準機能があり、**一致ルール (Matching Rule)** と **重複ルール (Duplicate Rule)** の組み合わせで、重複の早期発見・抑止を実現できます。

### 重複管理の 3 要素

```
┌─────────────────────────────────────────────────┐
│ ① 一致ルール (Matching Rule)                    │
│   「どんなレコードが似ていれば重複か」を定義       │
│   (例: 姓名+電話が一致なら重複)                  │
├─────────────────────────────────────────────────┤
│ ② 重複ルール (Duplicate Rule)                  │
│   「重複を見つけたらどうするか」を定義           │
│   (例: 警告表示 / 保存ブロック / 監査ログのみ)   │
├─────────────────────────────────────────────────┤
│ ③ レコードのマージ (Merge)                      │
│   既に重複してしまったレコードを統合する         │
└─────────────────────────────────────────────────┘
```

### ① 一致ルール (Matching Rule)

**「どんな条件で 2 つのレコードが似ているか」** を定義するルールです。

#### 設定場所

`Setup → データ → 一致ルール`

#### 設定項目

| 項目           | 説明                           |
| ------------ | ---------------------------- |
| **対象オブジェクト** | お客様 / 家族 / 取引先 など            |
| **一致条件**     | 比較する項目 (姓・名・電話・メール 等)        |
| **マッチング方式**  | 完全一致 / あいまい (Fuzzy) / 表記ゆれ吸収 |

#### あいまい (Fuzzy) マッチングの種類

Salesforce のあいまいマッチングは複数の方式を提供:

| 方式                 | 例                                                 |
| ------------------ | ------------------------------------------------- |
| **完全一致 (Exact)**   | `山田 太郎` ≠ `山田太郎` (空白の有無を区別)                       |
| **あいまい一致 (Fuzzy)** | `山田 太郎` ≈ `山田太郎` (空白・全半角の違いを吸収)                   |
| **姓名のあいまい**        | `Yamada` ≈ `ヤマダ` ≈ `山田` (表記揺れ判定)                  |
| **電話番号の正規化**       | `03-1234-5678` ≈ `0312345678` ≈ `+81-3-1234-5678` |
| **メールの正規化**        | `Foo@Example.COM` ≈ `foo@example.com` (大文字小文字無視)  |
| **キー無視**           | 空白・記号・接頭語を無視して比較                                  |

#### 標準の一致ルール

Salesforce には **標準一致ルール** が用意されています:

| 標準ルール          | 対象      | 内容                       |
| -------------- | ------- | ------------------------ |
| 標準の取引先一致ルール    | Account | 会社名 + 住所 + 電話 を fuzzy 比較 |
| 標準の取引先責任者一致ルール | Contact | 姓 + 名 + メール を fuzzy 比較   |
| 標準のリード一致ルール    | Lead    | 姓 + 名 + メール / 会社 を比較     |

これらは標準で有効化されていることが多いですが、葬儀社の業務には不十分な場合があるため、**カスタム一致ルール** を作るのが推奨。

#### ブリッジ葬儀向けカスタム一致ルール例

**お客様 (Contact) — 同姓同名対策**

葬儀社では同姓同名 (`山田 太郎` 多数) が発生しやすいため、**「姓+名+電話番号 (or 生年月日)」** で重複判定するのが現実的:

| 項目                   | 一致方式                        |
| -------------------- | --------------------------- |
| **姓 (LastName)**     | 完全一致                        |
| **名 (FirstName)**    | 完全一致                        |
| **電話番号 (Phone)**     | 電話番号正規化                     |
| **生年月日 (Birthdate)** | 完全一致                        |
| マッチ条件                | (姓+名+電話) または (姓+名+生年月日) で一致 |

**家族 / 会社 (Account) — 当家の重複対策**

| 項目                 | 一致方式                        |
| ------------------ | --------------------------- |
| **取引先名 (Name)**    | あいまい一致 (空白無視)               |
| **住所 (郵便番号+市区町村)** | 完全一致                        |
| **電話 (Phone)**     | 電話番号正規化                     |
| マッチ条件              | (取引先名+住所) または (取引先名+電話) で一致 |

#### 一致ルールの作成

1. `Setup → データ → 一致ルール → 新規ルール`
2. **対象オブジェクト** を選択 (Contact / Account 等)
3. **ルール名 / 説明**
4. **照合する項目** を選択し、それぞれの一致方式を指定
5. **照合条件 (基準)** を組み立て (AND / OR)
6. **保存** → **「有効化」**

> 一致ルールは作成しただけでは効きません。次の **重複ルール** で参照して初めて動作します。

### ② 重複ルール (Duplicate Rule)

**「一致ルールに該当した時、どう振る舞うか」** を定義。

#### 設定場所

`Setup → データ → 重複ルール`

#### 主な動作

| アクション                   | 動作                    |
| ----------------------- | --------------------- |
| **保存時に警告 (Allow)**      | 重複候補を表示するが、保存は許可      |
| **保存をブロック (Block)**     | 重複候補があれば保存させない        |
| **何もしない (Report only)** | 重複ログのみ記録 (ユーザーには見せない) |

#### 設定項目

| 項目                | 説明                  |
| ----------------- | ------------------- |
| **対象オブジェクト**      | Contact / Account 等 |
| **一致ルール**         | 上で作ったものを選択          |
| **アクション on 新規作成** | Allow / Block       |
| **アクション on 編集**   | Allow / Block       |
| **重複時のメッセージ**     | 警告文言 (ユーザーに見せる文章)   |
| **レポートに含める**      | 重複ログを「重複レコードセット」に記録 |

#### ブリッジ葬儀の推奨設定

**Contact (お客様) の重複ルール**

```
一致ルール: カスタム「お客様 - 姓+名+電話 or 生年月日」

新規作成時のアクション: 警告 (Allow + 重複候補を表示)
編集時のアクション:    警告 (Allow)
重複メッセージ:
  「同じ姓名・電話または生年月日のお客様が既に登録されています。
   既存レコードを使うか確認してください。
   それでも新規登録する場合は『保存』を続行してください。」
```

> **ブロック (Block) ではなく警告 (Allow) を推奨** 。葬儀社では電話受電中に新規登録することが多く、ブロックすると業務が止まるためです。

**Account (家族 / 会社) の重複ルール**

```
一致ルール: カスタム「家族 - 取引先名+住所 or 電話」

新規作成時のアクション: 警告 (Allow)
編集時のアクション:    警告 (Allow)
重複メッセージ:
  「同じ当家名・住所のレコードが既に存在します。確認してから登録してください。」
```

#### 重複候補の表示

ユーザーが新規作成・編集時、重複候補が出ると以下のような画面表示:

```
⚠ 重複の可能性があるレコードがあります
─────────────────────────────────
山田 太郎 (Contact)        [既存レコード]
  電話: 03-1234-5678
  生年月日: 1942-05-12
  所属: 山田家
─────────────────────────────────
[ 既存レコードを使用 ] [ 新規として保存 ]
```

担当者はここで「既存を使う」「新規として保存」を選べます。

### 重複ルールが効くタイミング

| タイミング                                     | 動作                      |
| ----------------------------------------- | ----------------------- |
| **UI 入力 (画面操作)**                          | 重複ルールが効く ✓              |
| **データインポートウィザード**                         | 重複ルールが効く ✓              |
| **Data Loader**                           | 効く (要設定 / `--upsert` 等) |
| **API 経由 (Apex / REST)**                  | 効く (DmlOptions で制御可)    |
| **データ移行 (Bulk API + skipDuplicateBlock)** | スキップ可能                  |

データ移行時は重複ルールを **一時的にバイパス** することもできます (大量データを意図的に入れる場合)。

### ③ レコードのマージ (Merge)

既に重複してしまったレコードを **1 つに統合** する機能。

#### マージできるオブジェクト

| オブジェクト               | 標準マージ      |
| -------------------- | ---------- |
| **取引先 (Account)**    | ✓          |
| **取引先責任者 (Contact)** | ✓          |
| **リード (Lead)**       | ✓          |
| **カスタムオブジェクト**       | ✗ (標準では不可) |

> 葬儀社で重要な **施行情報・伝票・会員権 (カスタムオブジェクト)** は標準のマージ機能では統合できません。これらは手動で関連付け変更後、片方を削除する運用になります。

#### マージの手順 (Contact / Account)

**方法 1: 重複レコードセットから**

1. 重複ルールで記録された重複候補が、`重複レコードセット` オブジェクトに溜まる
2. レポートで「未解決の重複レコードセット」を抽出
3. レコードセットを開く → 「マージ」ボタン
4. **マスター** (残す方) を選択
5. 統合後のレコードで採用する項目を 1 つずつ選択
6. **「マージ」** 実行

**方法 2: レコード詳細画面から**

1. 重複の片方の Account / Contact を開く
2. **「重複のチェック」** ボタンをクリック
3. 候補一覧から **マージするレコード** を選択 (最大 3 件)
4. マスター選択 + 項目選択 → 「マージ」

#### マージで起こる事

* マスター側のレコードが残る
* 副レコードは削除される
* **関連レコード** (子施行情報・伝票・会員権 etc.) はすべてマスター側に紐付け変更
* 副レコードの削除は **ゴミ箱に入る** (一定期間内なら復元可)

#### マージ前のチェックリスト

* [ ] 関連する施行情報・伝票・会員権の件数を両レコードで確認
* [ ] PDF 帳票やメールアドレス・電話などの最新値を確認
* [ ] マスターとしてどちらを残すかチームで合意
* [ ] 失敗した場合の復元手順 (ゴミ箱 / バックアップ) を確認

### ブリッジ葬儀でよくある重複シーン

#### シーン 1: 受電時の重複登録

電話受電で「山田太郎の件で」と言われ、検索せずに新規登録してしまった。重複ルール (Allow) が効いていれば候補が出てくる → 「既存を使う」を選択 → 重複回避。

#### シーン 2: データ移行時の重複

旧 CRM からのデータを Data Loader でインポートした際、既存と重複した。

**対処**:

1. 旧 CRM のデータに **外部 ID** (旧システムの主キー) を入れる
2. **Upsert** モードでインポート (外部 ID マッチで既存を更新)
3. 重複ルールはバイパスせず通常動作

#### シーン 3: 同じ家族で姓が違うご家族

夫婦別姓・婿養子で「山田家」と「鈴木家」が同じ家族として登録される。

**対処**:

* 一方を正と決め、もう一方の関連レコードを移管 → 副を削除
* 取引先名に通称を入れる (例: `山田家 (旧 鈴木家)`)

#### シーン 4: 法人 (取引先業者) の重複

「◯◯花店 山田支店」「◯◯花店 山田」など微妙な表記違いで複数登録された。

**対処**:

* マスター選択 → マージ
* 取引先名のあいまい一致ルールを強化

#### シーン 5: 故人と喪主のレコードが両方とも別の家族に所属

データ整理ミスで、故人 → A 家、喪主 → B 家 のように所属がズレている。

**対処**:

* 一方の喪主レコードの「所属する家族」を変更して同じ家族に統合
* マージは不要 (人物自体は別)

### カスタムオブジェクト (Ceremony / Slip 等) の重複対策

標準マージ機能は使えないので、別の方法で対応:

#### 重複ルールは使える

カスタムオブジェクトにも一致ルール・重複ルールは設定可能。ただし **マージはできない** 。

例: 施行情報の重複ルール

```
一致条件: 当家 + 故人 + 葬儀日
アクション: 新規作成時に警告
```

これで同じ家族・同じ故人で同じ日に複数の施行情報を作ろうとした場合に警告が出ます。

#### 重複した時の対応

1. 一方を選んで残す
2. もう一方に紐づく関連レコードを移管 (Apex / Data Loader で UPDATE)
3. 不要な方を削除

> 関連レコードが少なければ手動でも対応可能ですが、多い場合はスクリプト化が現実的。

### 既存重複データの一括検出

「設定する前から重複データが溜まっている」場合、まずは現状把握:

#### 標準レポート

`Setup → データ → 重複ルール → 「Salesforce 重複ジョブ」` で全件スキャン → レポート出力。

#### 標準アプリ: Duplicate Record Sets

`重複レコードセット` オブジェクトに記録 → レポートで未解決数を集計。

#### サードパーティツール

* **DemandTools** (Validity 社) — 高機能 / 有償
* **Cloudingo** (Cloudingo 社) — 有償
* **Salesforce 標準で足りない場合** に検討

### 重複管理の運用ルール

組織で定めておきたいルール:

| ルール       | 内容                       |
| --------- | ------------------------ |
| 受電時の確認    | 必ず検索バーで既存お客様を探してから新規登録   |
| 重複警告の対応   | 警告が出たら「既存を使う」を優先         |
| マージは管理者承認 | 担当者が勝手にマージしない (履歴整合性のため) |
| 月次重複チェック  | 月 1 回、重複レコードセットを確認       |
| 退職者データの整理 | 退職時に担当レコードを別ユーザーに移管      |

### こんなときは

#### 重複ルールが効いていない

* ルールが「**有効**」になっているか確認
* 一致ルールが「有効」かも確認 (両方が有効でないと効かない)
* データインポート時はバイパスされている可能性

#### 警告メッセージがわかりにくい

→ 重複ルールのメッセージ欄を編集。**何をすべきか** を明示すると親切。

#### Block にしたら業務が止まった

→ Allow に変更 (警告だけ表示)。葬儀社のような即応業務では Allow 推奨。

#### マージ後にデータが壊れた

→ Salesforce のゴミ箱から **15 日以内なら復元可能** 。すぐに `Setup → ゴミ箱` で確認 → 該当レコードを復元 → マージをやり直し。

#### 「重複の可能性 0 件」と出るが目視で見つかる

→ 一致ルールの条件が厳しすぎる可能性。一致ルールを編集して **fuzzy 一致** を強化。

#### カスタムオブジェクトでもマージしたい

→ Salesforce 標準では非対応。AppExchange の **DemandTools** や、自社カスタム開発でマージ機能を構築する必要あり。

### ブリッジ葬儀パッケージ標準の重複ルール

ブリッジ葬儀パッケージ本体には、**重複ルール / 一致ルールは同梱されていません** (本記載時点)。

組織側で必要な重複ルールを定義する形になります。Sandbox で先にルール設計・テストしてから本番にデプロイするのがおすすめ。

### 次に進む

* [入力規則とエラーメッセージ](/salesforce-ji-chu/12-validation-rules.md) — データ品質確保のもう一つの手段
* [データインポート](/huan-jing-gou-zhu-yun-yong/21-data-import.md) — 重複ルール考慮のインポート
* [整合性を保つコツ (一般ユーザー向け)](/nori/23-data-integrity-tips.md) — 業務側のルール

***

📅 最終更新日: 2026-06-16


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://support.bridge-funeral.com/huan-jing-gou-zhu-yun-yong/22-duplicate-and-matching-rules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.