照合、マージ、サバイバーシップ
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール3／6：Data Architectコース第6章「マスターデータとID」。各モジュールは単独でも読めます。 前へ：データをマスター管理する4つの方法 · 次へ：地図は判断ではない
このモジュールが答える問い： 重複をどう見つけ、どの値が残るかをどう決めるのか？
Salesforceに取引先責任者が2人います。Daniel Reyes、Dallas、d.reyes@example.comと、Dan Reyes、Dallas、d.reyes@example.com。同じ人でしょうか？ おそらく。マージすべきでしょうか？ それは別の問いです。そしてマージするなら、どの電話番号、住所、役職が残るのでしょう？ これもまた別の問いです。アーキテクトは3つの判断を分けておく必要があります。
- 照合： これらのレコードは同じものを表しているか？
- マージ： それらは一つのレコードになるべきか？
- サバイバーシップ： データを組み合わせるなら、どの値が勝つか？
第3章でSalesforceの重複ルールと一致ルールを扱ったので、仕組みを教え直すことはしません。アーキテクチャの問いは、**これらが同じかもしれないと言えるほど強い証拠は何か？**です。人なら：メールアドレス、電話番号、名前と住所、顧客番号、あるいはその組み合わせ。会社なら：正式名称、納税者番号、ERPの顧客ID、住所、Webのドメイン。「Salesforceはこれらの項目を比較できるか？」ではなく、「どの組み合わせなら、行動するのに十分な確信を与えてくれるか？」です。
そして完全一致は確実ではありません。共有のメールアドレスは強い兆候であって、証拠ではありません。家族は住所を共有し、会社はpurchasing@company.comを使い、電話番号は世帯のものであり、名前と住所は一意ではなく、強い識別子でさえ再利用され、打ち間違えられ、使い回されます。照合は文字列の比較ではありません。識別についての表明なのです。
間違えたときのコスト
Section titled “間違えたときのコスト ”これを教えるとき、私は領域を変えます。自動車のマーケティングのデータで、2人のDaniel Reyesが同じ人だと誤って判断し、違うほうにSUVのオファーが届きます。よくはありませんが、リスクは低い。では同じ誤った照合を医療データでしてみましょう。2人の別々の人の病歴が一つにまとめられます。同じ照合の誤り、まったく違う結果です。だから普遍的な「よい」照合のしきい値はないのです。照合を見逃すことがより大きなリスクのこともあれば、同じではない2人をまとめることがより大きなリスクのこともあります。誤った照合が高くつくところでは、私は意図的に照合を控えめにします。
調和させ、照合し、統合する
Section titled “調和させ、照合し、統合する ”照合はデータの形にも依存します。AZ、Arizona、Ariz.。6025550198、(602) 555-0198、+1 602 555 0198。調和（ハーモナイゼーション）は値を比較できるようにします。標準の形式、正規化された略語、対応づけられたコード。それから照合します。レコードが一緒だとわかって初めて、その情報を一つの表現に統合（コンソリデーション）します。調和は照合ではなく、照合はマージではなく、統合は必ずしもマスター管理ではありません。
IDについての判断は段階的に行われます。
一致してもマージする必要はない
Section titled “一致してもマージする必要はない ”これはこの章で最も重要な区別の一つです。2つの古いシステムから来た2つの顧客レコードが同じ会社だと確信しています。マージしなければならないでしょうか？ いいえ。それぞれがソースシステムでの識別を持っているかもしれず、過去のトランザクションがそれぞれを指しているかもしれず、監査人が証跡を必要とするかもしれず、まだ移行中かもしれず、古いシステムが何と言っていたかを正確に知る必要があるかもしれません。2つのレコードが同じものだとわかっても、それをまとめる必要はありません。つなぐことができ、多くの場合それがより安全なアーキテクチャです。
私のマージのルール：はっきりした勝者
Section titled “私のマージのルール：はっきりした勝者 ”私の立場はこうです。勝者がはっきりしていて、重複に残しておく必要のあるものが何もないときだけマージする。 営業担当者が昨日、重複した取引先を作りました。元のレコードがはっきりと確立されたレコードです。マージのよい候補です。では状況を変えましょう。従来のシステムから顧客をインポートしました。独自のID、古い値、もしかするとそれに結びついたトランザクションや監査の要件があります。私はずっと慎重になります。古い値にさかのぼる必要があるかもしれないなら、外部からのロードの重複は残しておく。 マージはその履歴を壊すからです。
Salesforceのマージが実際にすること
Section titled “Salesforceのマージが実際にすること ”つながりは「これらは一緒だ」と言います。マージは「これらは今や一つだ」と言い、Salesforceではそれは本物の変更です。取引先では、最大3つのレコードを選び、一つをマスター（principal）として選びます。ほかのレコードのどの項目の値を残すかを選び、非表示の項目と読み取り専用の項目はマスターから来ます。マージされたレコードは、どれがマスターであっても、最も古いレコードの作成者と作成日を保持します。マスターでないレコードはごみ箱に行きます。 活動のような関連レコードは、例外を除いてマージされたレコードに移ります。Lightningでは、マージは重複ルールが検出した重複に対して動きます。そして個人取引先では、連絡先ポイントのオブジェクトはマージに対応していません。そのつながりは失われます（Considerations for Merging Duplicate Accounts (opens in a new tab)、Merge Duplicate Accounts in Lightning Experience (opens in a new tab)、英語）。
試験に出やすい知識。 Salesforceの取引先のマージが何をするかを知っておきましょう。最大3件のレコード。一つのマスターレコードがあり、その非表示の項目と読み取り専用の項目が保持される。どれがマスターであっても、最も古いレコードの作成者と作成日が残る。ほかのレコードはごみ箱へ行く。そして個人取引先では、連絡先ポイントのオブジェクトはマージされない。
判断を下すのに、すべての例外ケースを知る必要はありません。必要なのはその結果です。マージの後、始めたときの独立したレコードはもう存在しない。 第1章の可逆性テストが当てはまります。つなぐことは元に戻しやすく、マージは戻しにくい。そして顧客がそれだけで存在していることはめったにありません。取引先責任者、ケース、商談、ファイル、同意のレコード、カスタムの子、外部ID、連携の参照。親をマージする前に、それにぶら下がっているすべてに何が起きるかを理解しましょう。ロードで重複が入ってきたとき、私はチームに子レコードについて3つの選択肢を示します。残るレコードに移す。誰も必要としないならそもそもロードしない。あるいは**もう一方のレコードに非アクティブの印を付けて残し、**検索では引き続き見つかるようにする。1つ目はマージがやってくれることです。ほかの2つは痕跡を残します。そして、たいていはそれこそが大事なのです。
サバイバーシップ：どの値が勝つのか？
Section titled “サバイバーシップ：どの値が勝つのか？ ”レコードは一緒ですが、食い違っています。Salesforceと請求は602-555-0100、ERPは602-555-0188と言っています。サバイバーシップのルールが勝者を選びます。よく使われるのは、最新（最後の更新）、最頻（最も多くのソースが合意している値）、ソースの優先順位（こちらのソースをあちらより信頼する）、そして組み合わせ、しきい値、重み付け、ビジネス固有のルールです。どれも本来的に正しいわけではありません。
「最新」は技術的な設定ではありません。信頼についての表明です。システムが食い違うとき、最も新しい値のほうが正しい可能性が高い。 携帯電話の番号には筋が通っています。正式名称にはひどいものです。ERPがそれを所有しているなら、5分前に誰かがSalesforceのコピーを変えたことなど気にしません。「最頻」は合意が証拠だと前提にしていますが、下流の3つの古いコピーが記録の源を多数決で負かすことはありません。「ソースの優先順位」ははっきり言っています。私たちはこのソースのほうを信頼する。 ですからサバイバーシップはアーキテクチャとガバナンスに属し、すべてのルールにはオーナーが必要です。 一番新しい住所が勝つ、あるいはERPがSalesforceより上だと、誰が決めたのでしょう？
モジュール1の権威の地図で、ERPが与信限度額を所有するとすでに言っているなら、サバイバーシップは簡単です。ERPが勝ち、巧妙なスコアリングは要りません。難しいのは、権威が共有されているか、不明確か、一つのマスターではなく証拠に基づいている属性です。サバイバーシップのルールが真価を発揮するのはそこです。
サバイバーシップのルールは、信頼についての表明です。
しきい値、レビュー、エンリッチメント
Section titled “しきい値、レビュー、エンリッチメント ”照合の中には証拠を重み付けするものがあります。顧客IDの一致はとても強く、メールアドレスは強く、電話番号は中程度、似た名前は弱く、似た住所は補強。あるスコアを上回れば一致、別のスコアを下回れば別物、その間なら人がレビューします。教訓はアルゴリズムではありません。しきい値は誤りに対する許容度であり、 ビジネスのリスクに従うべきです。そして証拠が問いを投げかけるだけで決着をつけないときは、システムがわかっているふりをしないでください。レビューに回しましょう。遅くなりますが、それでかまいません。2人の違う顧客を自信満々にマージする自動化に価値はありません。
エンリッチメント（データの補強）は、出どころについての問いをもう一つ加えます。郵便の参照データ、業種コード、企業情報、外部のリスクスコアはマスターデータをよくしますが、それぞれの値はどこから来たのか、どれくらい信頼でき新しいのか、この目的に使ってよいのか、個人データを含むのか？ データ提供会社による「業種 = 運輸」は、顧客本人がそう言ったのとは同じではありません。その区別を保ちましょう。
Steve Trucking：似ていることは同じことではない
Section titled “Steve Trucking：似ていることは同じことではない ”2社の小売パートナーが、同じ電話番号のJohn Smith、123 Main Street、Columbusに配送を送ってきます。同じ人でしょうか？ おそらく。Steve Truckingはそれを統合すべきでしょうか？ 誰のものかを思い出してください。その受取人たちはパートナーの顧客であり、あるパートナーが別のパートナーの顧客を見ることは決してあってはなりません。誤った照合は、その境界を越えてデータを混ぜ合わせてしまいます。突然、それはデータ品質の問いではなく、プライバシーと分離の問いになります。まさにだから、しきい値は結果に依存するのです。判断はチェックポイントで下します。今はこう覚えておきましょう。照合の便利さに、ビジネスの判断をさせない。
ときには、散らかったものを残しておくことが何かを教えてくれます。このレコードは古いシステムから、あのレコードはSalesforceから、このレコードは買収した会社から来た。そのID、その履歴、そしてそれらが食い違っていたという事実が、すべて重要かもしれません。きれいなデータには価値があります。たどれることにも価値があります。その用途にとってどちらがより重要かを決めるのはアーキテクトです。
試験の先へ：AIが変えること。 以前は、悪い照合とは2通のメールや分断されたサービス履歴のことでした。今ではエージェントが顧客だと思うものを見つけ、その注文、ケース、住所、メモを引き出します。2人が誤って照合されていたら、ある人の情報に基づいて別の人のために行動してしまうかもしれません。照合の判断はセキュリティの境界の一部になったのです。そして混ぜ合わせると高くつくところでは、より厳しい照合がより安全な設計です。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- それぞれのデータ領域で、重複の可能性を示すのにどんな証拠で十分か。
- 確認された一致が、マージになるのか、つながりになるのか、人によるレビューになるのか。
- 食い違いの中でどの値が残り、誰がそれぞれのサバイバーシップのルールを所有するか。
- 照合を見逃すリスクに対して、ビジネスが誤った照合のリスクをどれだけ許容できるか。
- マージの前に、どのソースでの識別、履歴、関連レコードを保たなければならないか。
注意深く照合し、意図的にマージし、意図をもってサバイバーシップのルールを選びましょう。間違った顧客同士をまとめてたどり着いたきれいな顧客レコードには、あまり価値がありません。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Considerations for Merging Duplicate Accounts (opens in a new tab)とMerge Duplicate Accounts in Lightning Experience (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Things to Know About Duplicate Rules (opens in a new tab)（英語）、2026-10-14確認。