Salesforce 重複管理のマスター：アーキテクト向け技術ガイド

背景と適用シナリオ

データは現代のビジネスにおける最も価値ある資産の一つですが、その価値は品質に大きく依存します。「Garbage In, Garbage Out」（ゴミを入れれば、ゴミしか出てこない）という原則が示すように、不正確で一貫性のないデータは、誤ったビジネス上の意思決定、顧客満足度の低下、そして生産性の損失に直結します。Salesforce 環境において、最も一般的で厄介なデータ品質の問題の一つが重複データです。

重複データは、以下のような様々なシナリオで発生します。

手動入力：営業担当者が既存の取引先や取引先責任者に気づかずに新しいレコードを作成する。
データインポート：外部リストやスプレッドシートをインポートする際に、既存のデータとの照合が不十分である。
API連携：外部システムとの連携時に、重複をチェックするロジックが欠如している。
Web-to-Lead：既存のリードや取引先責任者が、再度 Web フォームから問い合わせを行い、新しいリードとして作成される。

これらの重複は、レポートやダッシュボードの数値を歪め、マーケティング活動のROIを低下させ、同じ顧客に複数の担当者がアプローチしてしまうといった混乱を引き起こします。結果として、Salesforce システム全体に対するユーザーの信頼が損なわれる可能性があります。

この課題に対処するため、Salesforce は標準機能として強力な Duplicate Management (重複管理) ツールを提供しています。このツールを正しく理解し、設計・実装することが、データ品質を維持し、Salesforce の投資対効果を最大化するための鍵となります。本記事では、Salesforce の重複管理機能の原理、アーキテクチャ、そしてベストプラクティスについて、技術アーキテクトの視点から深く掘り下げていきます。

原理説明

Salesforce の Duplicate Management は、主に二つのコンポーネント、Matching Rule (一致ルール) と Duplicate Rule (重複ルール) によって構成されています。これらが連携して、レコードの作成・更新時に重複の可能性を検知し、定義されたアクションを実行します。

Matching Rule (一致ルール)

Matching Rule は、「何をもって重複と見なすか」を定義するルールです。これは、レコードのどの項目を、どのような条件で比較するかを指定します。

標準一致ルール：Salesforce が主要な標準オブジェクト（取引先、取引先責任者、リードなど）に対してあらかじめ用意しているルールセットです。多くの場合、これらを有効化するだけで基本的な重複管理を開始できます。
カスタム一致ルール：ビジネス固有の要件に合わせて、カスタムオブジェクトや、標準ルールではカバーできない項目（カスタム項目など）の組み合わせでルールを独自に作成できます。

一致条件を定義する際には、Matching Algorithm (一致アルゴリズム) を選択します。

Exact (完全一致)：指定された項目値が完全に一致する場合にのみ、重複と見なします。例えば、電話番号やメールアドレスの完全一致チェックに使用されます。
Fuzzy (あいまい一致)：スペルミスや略語、ニックネームなどを考慮して、類似した値を持つレコードを重複候補として検出します。例えば、「Salesforce.com」と「Salesforce Inc.」を同一の企業として認識させたい場合に使用します。Fuzzy マッチングは非常に強力ですが、パフォーマンスへの影響も考慮する必要があります。

Duplicate Rule (重複ルール)

Duplicate Rule は、Matching Rule によって重複候補が検出された場合に、「どのようなアクションを実行するか」を定義するルールです。一つのオブジェクトに対して、複数の Duplicate Rule を作成し、それぞれ異なる Matching Rule や条件を割り当てることができます。

主な設定項目は以下の通りです。

アクション：
- Allow (許可)：ユーザーがレコードを保存することを許可しますが、画面上に警告メッセージを表示し、重複の可能性を通知します。ユーザーは警告を無視して保存することも、重複レポートに記録することも選択できます。これが最も一般的な設定です。
- Block (ブロック)：ユーザーが重複レコードを保存することを完全にブロックします。エラーメッセージが表示され、保存操作は失敗します。データ入力の厳格な統制が求められる場合に選択します。
操作：どの操作（作成時、編集時）でルールを適用するかを選択します。
クロスオブジェクト重複：リードが既存の取引先責任者と重複している場合など、異なるオブジェクト間で重複を検出することも可能です（一部の標準オブジェクト間でのみサポート）。

実行フロー

ユーザーまたは API がレコードを保存しようとすると、以下のプロセスが実行されます。

対象オブジェクトに有効な Duplicate Rule が存在するかチェックします。
Duplicate Rule に関連付けられた Matching Rule が実行され、既存レコードとの比較が行われます。
Matching Rule の条件に合致するレコードが見つかった場合、重複と判断されます。
Duplicate Rule で定義されたアクション（Allow または Block）がトリガーされます。UI 上ではアラートやエラーメッセージが表示され、Apex や API 経由の場合は特定のエラーコードが返されます。

示例コード

通常、Duplicate Management は宣言的な設定（クリック操作による設定）で完結しますが、Apex を用いた複雑なデータ処理や一括処理を行う際には、プログラム側で重複ルールを制御する必要が出てきます。例えば、特定の条件下でのみ重複チェックをバイパスしたい、または重複エラーを検知して独自のフォールバック処理を行いたいといったケースです。

これを実現するために、Salesforce は Apex DML 操作において `Database.DMLOptions` クラスを提供しています。このクラスの `DuplicateRuleHeader` プロパティを使用することで、DML 操作単位で重複ルールの動作を詳細に制御できます。

以下のコードは、Salesforce 公式ドキュメントに基づくサンプルです。取引先責任者 (Contact) を挿入する際に、Duplicate Rule が「Block」に設定されていても、それを意図的にバイパスしてレコードを保存する方法を示しています。

Apex: DMLOptions を使用した重複ルールの制御

// DMLOptions インスタンスを作成し、重複ルールヘッダーを設定します。
Database.DMLOptions dmlOptions = new Database.DMLOptions();

// allowSave を true に設定することで、「Block」アクションの重複ルールをバイパスし、
// レコードの保存を強制的に許可します。
// ただし、重複が検出されたという情報は SaveResult に返されます。
dmlOptions.DuplicateRuleHeader.allowSave = true;

// runAsCurrentUser を true に設定すると、重複ルールは現在のユーザーの権限に基づいて評価されます。
// これがデフォルトの動作です。
dmlOptions.DuplicateRuleHeader.runAsCurrentUser = true;

// 重複の可能性があるレコードの詳細情報を取得したい場合は、
// includeRecordDetails を true に設定します (API バージョン 39.0 以降)。
// デフォルトは false です。
dmlOptions.DuplicateRuleHeader.includeRecordDetails = false;

// 新しい取引先責任者レコードを作成します。
// このレコードが既存のデータと重複する可能性があると仮定します。
Contact newContact = new Contact(
    LastName = 'Smith',
    FirstName = 'John',
    Email = 'john.smith@example.com',
    Phone = '555-123-4567'
);

// DMLOptions を setOptions メソッドで DML 操作に適用します。
// これにより、この insert 操作に限り、指定した重複ルールヘッダーが有効になります。
Database.SaveResult saveResult = Database.insert(newContact, dmlOptions);

// DML 操作の結果を検証します。
if (saveResult.isSuccess()) {
    System.debug('Contact inserted successfully: ' + saveResult.getId());
} else {
    // 保存が失敗した場合、または成功したが重複が検出された場合
    for (Database.Error error : saveResult.getErrors()) {
        // ステータスコードをチェックして、エラーの原因を特定します。
        // DUPLICATES_DETECTED は、allowSave = true の場合に返されるコードです。
        // この場合、レコードは保存されていますが、重複が検出されたことを示します。
        if (error.getStatusCode() == StatusCode.DUPLICATES_DETECTED) {
            System.debug('Duplicate was detected. The record was saved anyway.');
            
            // getDuplicateResult() を使用して、重複の詳細情報を取得できます。
            Datacloud.DuplicateResult duplicateResult = error.getDuplicateResult();
            System.debug('Matching Rule: ' + duplicateResult.getMatchResults()[0].getMatchingRule());
        } 
        // もし allowSave = false (デフォルト) でブロックされた場合は、
        // DUPLICATE_VALUE ステータスコードが返され、レコードは保存されません。
        else {
            System.debug('An error occurred: ' + error.getMessage());
        }
    }
}

このコードからわかるように、`dmlOptions.DuplicateRuleHeader.allowSave = true;` が重要な役割を果たします。これにより、アーキテクトはデータ移行や特定のバッチ処理など、ビジネスルール上、一時的に重複を許容する必要があるシナリオに対して、柔軟な制御を行うことができます。

注意事項

Duplicate Management を設計・運用する際には、以下の点に注意が必要です。

権限とアクセス制御

ルールの設定：Matching Rule および Duplicate Rule を作成・編集するには、「アプリケーションのカスタマイズ」権限が必要です。
重複ジョブの実行：既存データの重複をスキャンする Duplicate Job (重複ジョブ) を実行するには、「すべてのデータの参照」および「重複ジョブの実行」権限が必要です。
レコードのマージ：重複として検出されたレコードをマージするには、対象オブジェクトに対する「削除」権限が必要です。

API 制限とガバナ制限

有効なルールの数：1 つのオブジェクトに対して有効化できる Duplicate Rule は最大 5 つまでです。
Matching Rule の複雑さ：1 つの Matching Rule に含めることができる項目は最大 10 個です。また、Fuzzy マッチングが可能な項目は一部の標準項目に限られます。
API 経由の動作：Duplicate Rule は、UI からの操作だけでなく、SOAP API, REST API, Bulk API を含むすべての DML 操作でトリガーされます。Apex で制御しない限り、API 経由で作成・更新されたレコードも重複チェックの対象となります。
トリガーされない操作：レコードのマージ、削除、復元（Undelete）操作では、Duplicate Rule はトリガーされません。

パフォーマンスへの影響

特に Fuzzy マッチングを含む複雑な Matching Rule は、レコードの保存時のパフォーマンスに影響を与える可能性があります。特に、数百万件以上の大規模なデータボリュームを持つオブジェクトに対してルールを適用する場合、慎重な設計とテストが求められます。ルールの条件は、できるだけ絞り込み（例：「取引先名が空でない場合」など）、不要な評価を避けるべきです。

エラーハンドリング

Apex で DML 操作を行う際は、必ず `Database.SaveResult` や `try-catch` ブロックを用いてエラーハンドリングを実装してください。特に重複エラーをハンドリングする場合、`error.getStatusCode()` を確認し、`StatusCode.DUPLICATES_DETECTED`（許可モードでの検出）と `StatusCode.DUPLICATE_VALUE`（ブロックモードでのエラー）を区別して処理することが重要です。

まとめとベストプラクティス

Salesforce の Duplicate Management は、単なる機能ではなく、組織のデータガバナンス戦略の中核をなすものです。高品質なデータを維持することは、ユーザーの信頼を獲得し、Salesforce プラットフォームから最大限の価値を引き出すための前提条件です。

以下に、重複管理を成功させるためのベストプラクティスをまとめます。

スモールスタートで始める：最初からすべてのオブジェクトに複雑なルールを適用するのではなく、まずは取引先、取引先責任者、リードといった主要なオブジェクトに対して、標準の Matching Rule を有効化することから始めましょう。
「許可 (Allow)」モードを優先する：いきなり「ブロック (Block)」モードにすると、ユーザーの業務を妨げ、反発を招く可能性があります。まずは「許可」モードで警告を表示させ、ユーザーにデータ品質への意識を促しながら、検出された重複のパターンを分析するのが効果的です。
ユーザーへのトレーニングと啓蒙：ツールを導入するだけでなく、「なぜ重複データが問題なのか」「警告が表示された際にどう対応すべきか」をユーザーに継続的にトレーニングすることが不可欠です。
宣言的ツールとプログラム的制御の組み合わせ：通常の UI 操作や標準的なインポートには宣言的なルールを適用し、複雑なロジックや特定のインテグレーション、データ移行のシナリオでは Apex の `DMLOptions` を活用して、柔軟性と堅牢性を両立させます。
定期的なクリーンアップ：新しい重複の発生を防ぐだけでなく、Duplicate Job (重複ジョブ) を定期的に実行して、既存の重複データを特定し、クリーンアップするプロセスを確立します。
継続的な監視と改善：重複ルールの効果を定期的にレビューし、ビジネスの変化やデータの傾向に合わせて Matching Rule を微調整していくことが重要です。重複レポートを活用して、どのルールが最も多くヒットしているか、誤検知（False Positive）が多くないかなどを分析しましょう。

これらのプラクティスを実践することで、Salesforce 技術アーキテクトは、単にシステムを構築するだけでなく、ビジネスの成功を支える信頼性の高いデータ基盤を築くことができるのです。

にゃんこのSalesforce日記

このブログを検索