地図は判断ではない
ほかに 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)
モジュール4／6：Data Architectコース第6章「マスターデータとID」。各モジュールは単独でも読めます。 前へ：照合、マージ、サバイバーシップ · 次へ：権威が共有されるとき
このモジュールが答える問い： 統合プロファイルはゴールデンレコードと同じものなのか？
同じ顧客が3つのシステムにいます。SalesforceはDaniel Reyes、d.reyes@example.com、Dallasを知っています。EコマースはDan Reyes、同じメールアドレス、Dallas, TXを知っています。サポートはDaniel Reyes、214-555-0100、Dallasを知っています。Data 360は3人とも同じ人だと判断し、統合プロファイルを作ります。すばらしい。これでゴールデンレコードを手にしたのでしょうか？ 必ずしもそうではありません。 レコードが一緒であることはわかりました。どのソースが真実を所有しているかはまだ決めていません。ここは混乱しやすいところです。ID解決は統合された個人を作りますが、ゴールデンレコードは作りません。 ですから私はその違いを正面から教えます。
統合プロファイルは地図である。ゴールデンレコードは判断である。
ID解決は「誰？」に答える
Section titled “ID解決は「誰？」に答える ”ID解決がなければ、一人の人がばらばらのプロファイルとして現れます。マーケティングは一つを、営業は別のものを、サービスはさらに別のものを見ています。Data 360はそれらを取り込み、ID解決のルールを使ってどれが一緒かを決めます。そこでこれらのレコードは同じ人のようだと言えるようになります。それは識別を解決します。マスター管理は解決しません。
そして統合プロファイルは、ソースへの地図を保持しています。Salesforce自身の説明では、統合プロファイルはゴールデンレコードではありません。それはキーの集まりであり、IDリンクのオブジェクトがそれぞれのソースレコードのIDを統合プロファイルのIDに結びつけています（Data 360 Architecture (opens in a new tab)、英語）。統合された人10042は、Salesforceの取引先責任者003…、Eコマースの顧客EC-48372、サポートの顧客SUP-9128に対応しています。元のレコードは消えません。それはモジュール2のレジストリ型にとても近いものです。
統合プロファイルは、ソースの識別へとさかのぼる地図です。
一致ルール：厳しさはリスクの判断である
Section titled “一致ルール：厳しさはリスクの判断である ”Data 360は誰を統合するかをどう決めるのでしょう？ 一致ルールです。プロファイルはルールのすべての条件を満たすと一致し、ルールが複数あれば、どれか一つでの一致が統合プロファイルを作ります。Salesforce自身のガイダンスはこうです。精度のためには条件を増やし（別々のプロファイルが増える）、統合のためには減らす（Identity Resolution Match Rules (opens in a new tab)、英語）。つまりルールに条件を加えると厳しくなり、別のルールを加えるとプロファイルが一致する道が広がります。ID解決を設定することは「照合をオンにする」ことではありません。これらのプロファイルが一人の人だと言うのにどんな証拠で十分かを定義することです。
照合が増えることは、自動的によいことではありません。1,000万のソースプロファイルが800万の統合プロファイルになります。ルールを緩めると、600万になります。よくなったのでしょうか？ より多くの重複を見つけたのかもしれません。あるいは違う人をまとめ始めたのかもしれません。数が減ったことは、データがよくなった証拠ではありません。目標はプロファイルを最も少なくすることではなく、目的に対して最も弁護できる識別です。そしてそれぞれの条件には一致方法があります。完全一致（Exact）、正規化後の完全一致（Exact Normalized）、または精度が高・中・低のあいまい一致（Fuzzy）です。Salesforce自身の警告がまさに要点です。精度の低い方法は統合率を上げますが、「望ましくない一致を生む可能性があります」。（あいまい一致は取引先の項目では使えません。また正規化された値は比較にだけ使われ、統合プロファイルには保存されません。モジュール3の調和の段階が働いているのです：Identity Resolution Match Methods (opens in a new tab)（英語）。）方法が緩いほど、識別そのものが判断になっていきます。それが間違っていたら、ページのパーソナライズを失敗するだけなのか、ある人のサポート履歴を別の人に見せるのか、エージェントに2人のデータに基づいて行動させるのか？
それが私の立場です。照合の厳しさはリスクの判断である。 照合する項目がどれだけ人を一意に識別するかと、誤った照合のコストによります。混ぜ合わせると高くつくところでは、意図的に照合を控えめにしましょう。一人に2つのプロファイルは不便です。2人を抱えた一つのプロファイルは危険になり得ます。
調整してもマスター管理ではない
Section titled “調整してもマスター管理ではない ”プロファイルが統合されても、ソースは食い違ったままです。SalesforceはDallas、EコマースはPlano、サポートはDallasと言っています。統合プロファイルは何を表示するのでしょう？ 調整ルールが決めます。Last Updated、Most Frequent、Source Priority（最終更新、最頻、ソースの優先順位）で、オブジェクトごとに設定し、項目ごとに上書きできます（Identity Resolution Reconciliation Rules (opens in a new tab)、英語）。モジュール3のサバイバーシップのように聞こえるはずです。
チームが困ったことになるのはここです。統合プロファイルがDallasと表示し、誰かが「よし、Dallasが私たちのゴールデンな値だ」と言います。ペースを落としましょう。EコマースはまだPlanoと言っています。Salesforceは、調整はソースのデータを削除も変更もせず、ソースのシステムを更新もしないこと、そしてすべてのアプリケーションのために「最良の」値を選ぶためのものではないことをはっきり言っています。決めるのは統合プロファイルが何を表示するかだけです（同じ情報源）。表示は権威ではありません。
試験に出やすい知識。 Data 360のID解決がどう判断し、どう表示するかを知っておきましょう。一致ルールではすべての条件が一致しなければならず、どれか一つのルールが一致すればプロファイルは統合されます（精度のためには条件を増やし、統合のためには減らす）。3つの調整ルールはLast Updated、Most Frequent、Source Priority（最終更新、最頻、ソースの優先順位）で、オブジェクトごとに設定し、項目ごとに上書きできます。そして調整はソースのデータを変えず、連絡先ポイントは調整されません。
連絡先ポイントは、その点をさらにはっきりさせます。人は個人用と仕事用のメールアドレス、携帯と自宅の電話を持つことができ、すべて正当です。Data 360は連絡先ポイントをまったく調整しません。すべてのメールアドレスと電話番号が統合プロファイルに残ります（同じ情報源）。複数の値が単に真実であることもあります。「統合された」は、すべてについて値が一つという意味ではありません。
ゴールデンレコードは判断である
Section titled “ゴールデンレコードは判断である ”本物のマスター管理の要件と比べてみましょう。ビジネスは、ERPが正式名称について権威を持ち、マスター管理された値は「Oakline Logistics LLC」だと言います。Salesforce、請求、サービスのすべてがそれを使わなければならず、どれかが食い違えば、マスター管理のプロセスが統制された値を送り返します。それは違うアーキテクチャです。一つの見方が何を表示するかを選んでいるのではありません。これが企業が使う値であり、参加するすべてのシステムがそれに収束すると決めているのです。
つまり、統合プロファイルは識別と情報を一つにまとめます。ゴールデンレコードは、どの値が権威を持つのかについての、統制された判断です。統合プロファイルは、権威あるソースから組み立てた、すばらしい顧客の単一ビューになり得ます。だからといって、それが顧客をマスター管理するシステムになるわけではありません。
統合プロファイルは地図である。ゴールデンレコードは判断である。
たどれること
Section titled “たどれること ”統合プロファイルがDallasと言っているなら、それはどこから来たのでしょう。Salesforce、ERP、Eコマース？ 最終更新、最頻、ソースの優先順位のどれで選ばれたのか？ その出どころは、監査、プライバシー、トラブルシューティング、データ品質の修正、エージェントの判断にとって重要であり、何よりも訂正をどこで行うべきかを知るために重要です。Dallasが間違っているなら、組み立てられた見方を編集してもソースは直りません。変えるべきレコードまでさかのぼるために、外部ID、IDのつながり、系統の項目が必要です。
3つの仕事に3つの道具
Section titled “3つの仕事に3つの道具 ”私はこう区別しています。
- 重複管理とマージ： 一つのSalesforce組織の中で、勝者がはっきりしていて、もう重複が必要ないとき（モジュール3）。
- Data 360のID解決： 複数のソースをまたぐ一つの識別と一つの見方のために。ソースを変えずに。 レジストリです。
- 専用のMDMプラットフォーム： 値を一度決めて、参加するすべてのシステムに送り返さなければならないとき。共存型か集中型です。
3つの仕事に3つの道具：マージする、つなぐ、マスター管理する。
地図が必要なときにMDMを買わないでください。「このSalesforceの顧客がオンラインで購入したのと同じ人だと、サービスエージェントにわかってほしい」には、集中型MDMではなく、ID解決とまとめたコンテキストが必要かもしれません。「ERP、Salesforce、Eコマース、請求のすべてが統制された同じ正式名称を使わなければならず、変更はそのすべてに戻らなければならない」は違います。それはマスター管理です。前者があるときに後者を解こうとしないでください。そして前者で後者が解けたふりをしないでください。
一つの識別は一つの許可ではない
Section titled “一つの識別は一つの許可ではない ”ID解決は、これらのレコードが一人の人だと言います。だからといって、あるソースレコードを見られる人が全員、統合されたIDに付いているすべてを見てよいわけではありません。小売パートナーは自分が送った配送を見られます。同じ受取人への別のパートナーの配送は、IDの層がそれらが関係していると知っていても、そのパートナーには関係のないことです。IDのグラフが正しくても、アクセスの設計が間違っていることはあり得ます。識別を統合しても、セキュリティの境界は消えません。 だから照合しすぎることはプライバシーの問題になり、だからSteve Truckingのチェックポイントは受取人の統合をこれほど慎重に扱うのです。誰が誰かの地図は、所有もアクセスも与えません。
試験の先へ：AIが変えること。 エージェントには行動の対象となる一つの識別が必要で、統合プロファイルがそれを与えます。それは両方向に賭け金を引き上げます。照合しすぎることは今やプライバシーのインシデントです。ある人のために別の人のデータに基づいて行動するエージェント。そして「顧客を更新する」エージェントは、統合プロファイルではなく、モジュール1の権威の地図を使って、その属性の記録システムに書き込まなければなりません。地図はエージェントにその人が誰かを教え、権威のモデルは変更がどこに属するかを教えます。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- プロファイルを統合するのにどんな証拠で十分か、そして誤った照合のコストが厳しさをどう決めるか。
- どの調整ルールが、統合プロファイルが何を表示するかを決めるか。
- 必要なのが一つの組織での重複の整理なのか、ソースをまたぐ識別なのか、本物の企業のマスター管理なのか。
- Data 360が調整された値を表示していても、それぞれの属性についてどのソースが権威を持ち続けるか。
- 統合された識別が、セキュリティ、プライバシー、出どころ、エージェントの行動とどう関わるか。
Data 360は、これらのプロファイルが一緒だと教え、統合された識別を与え、表示するものを調整し、すべてのソースへのつながりを保持してくれます。それは非常に価値のあることです。しかしSalesforceがあることを言い、ERPが別のことを言うなら、どのシステムが企業の真実を変えてよいかを、やはり誰かが決めなければなりません。ですから誰かが「統合プロファイルがあるので、ゴールデンレコードがある」と言ったら、こう問いましょう。私たちはデータを統合したのか、それともマスター管理したのか？
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Architects、Data 360 Architecture (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Data 360：Identity Resolution Match Rules (opens in a new tab)とIdentity Resolution Match Methods (opens in a new tab)とIdentity Resolution Reconciliation Rules (opens in a new tab)（英語）、2026-10-14確認。