マスターデータとID
ほかに 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)
Data Architectコース第6章の学習ガイドです。チェックポイント1の解説も含め、まず6つのモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、Salesforceが公開している試験ガイドの出題目標の一覧だけをもとに作られています。実際の試験問題をもとにしたことは一度もなく、試験に何が出るかを知っているとも主張しません。すでに受験した方は、どうか試験の問題を私に送らないでください。認定資格の契約で共有が禁じられていますし、そもそも答えを暗記するのはアーキテクトになる方法として間違っています。
この章は、試験のMaster Data Managementセクション（5%）と、Salesforce Data Managementの顧客の単一ビューを担っています。配分では小さなセクションですが、その考え方（権威、照合、サバイバーシップ）はほかの多くのシナリオの中に現れます。プラットフォームの数値は変わるので、頼る前に現在の数値を確認しましょう。
進めながらチェックしていきましょう。各項目には、それを教えている箇所へのリンクがあります。
MDM-2：ゴールデンレコードと真実のシステム
- 権威はレコードごとではなく属性ごとに割り当てられることを知っている：一つの取引先が、ERPでマスター管理される項目とSalesforceでマスター管理される項目を持ち得る。（真実は属性に属する）
- それぞれの属性がどこで作成され、編集され、参照されるのか、そして変更の遅延を問える。（どこで作成され、編集され、参照され、どれくらい速く変わるのか？）
- 権威の地図を作れ、ビジネス上のオーナーと権威を持つシステムは同じではないことを知っている。（権威の地図を作る）
- 権威はライフサイクルを通じて変わり得ること（Salesforceの見込み客がERPに統制された顧客になる）、そしてコピーは権威ではないことを知っている。（権威はライフサイクルを通じて変わる、コピーは権威ではない）
MDM-1：MDMの手法
- 試験に出やすい知識： 4つのMDMの実装スタイル、レジストリ型、コンソリデーション型、共存型、集中型を知っている：それぞれが何を中央に集め、値を送り返すかどうか。（4つを並べて）
- 4つのMDMのスタイル、レジストリ型、コンソリデーション型、共存型、集中型を見分け、問題を解決する最も軽いものを選べる。（4つを並べて）
- 標準データモデルは構造を調和させるが、権威は決めないことを知っている。（共通のモデルは共通の真実ではない）
- 順序を知っている：調和させ、照合し、統合する。（調和させ、照合し、統合する）
- しきい値は誤りに対する許容度を反映し、エンリッチメントには出どころが必要だと知っている。（しきい値、レビュー、エンリッチメント）
- 試験に出やすい知識： 階層の管理を知っている：親取引先が階層を作り（Lightningのビューは最大2,000件の取引先を表示し、個人取引先は含まない）、階層はしばしば複数のマスターを持ち、一つの会社が複数の正当な階層を持ち得る。（階層もマスターデータである、一つの階層、複数のマスター）
MDM-3：勝つ属性を選ぶ
- 照合、マージ、サバイバーシップを分けておける。（照合、マージ、サバイバーシップ）
- サバイバーシップのルール、最新、最頻、ソースの優先順位と、すべてのルールにオーナーが必要なことを知っている。（サバイバーシップ：どの値が勝つのか？）
- 一致してもマージする必要はないこと、そしてはっきりした勝者がいるときだけ、子をどうするかを先に決めてからマージすることを知っている。（一致してもマージする必要はない、私のマージのルール：はっきりした勝者）
- 試験に出やすい知識： Salesforceの取引先のマージが何をするかを知っている：最大3つのレコード、マスターが一つ、最も古い作成者と作成日を保持、ほかはごみ箱へ、そして個人取引先では連絡先ポイントのオブジェクトがマージされない。（Salesforceのマージが実際にすること）
SDM-3：顧客の単一ビュー
- Data 360のID解決が、ソースのプロファイルを統合プロファイルにつなぎ、つながりを保持することを知っている。レジストリ型に最も近い。（ID解決は「誰？」に答える）
- 試験に出やすい知識： Data 360の一致ルールを知っている：ルールのすべての条件が一致しなければならず、どのルールでも一致し得る。精度のためには条件を増やし、統合のためには減らす。（一致ルール）
- 一致方法（完全一致、正規化後の完全一致、3段階の精度のあいまい一致）を知っている：精度の低い方法は統合を増やし、誤った一致のリスクも増やす。（一致ルール）
- 試験に出やすい知識： 調整ルール（Last Updated、Most Frequent、Source Priority）は統合プロファイルが何を表示するかを決めるが、ソースを変えないこと、そして連絡先ポイントは調整されないことを知っている。（調整してもマスター管理ではない）
- 仕事に応じて、重複管理、ID解決、専用のMDMプラットフォームを選べる。（3つの仕事に3つの道具）
MDM-4と双方向のデータ
- 双方向のデータは2つのマスターを意味しないことを知っている：ERPが所有する項目へのSalesforceでの編集は依頼なので、保留の状態を持つ依頼 → 検証 → 受け付け → 公開として設計する。（双方向のデータは2つのマスターを意味しない、マスターが「ノー」と言ったとき）
- ループと衝突の避け方を知っている：生み出された変更をその反響と区別し、どの項目を一つのトランザクションとして一緒に送るかを決める。（ループと衝突）
- 2つのERPにある一つの顧客について、クライアントがERP同士をどれだけ同期させているかによって、階層、対等な取引先、ERPごとの子を持つ一つの取引先から選べる。（1人の顧客、2つのERP、ERP同士をどう同期させているかを尋ねる）
チェックポイント1：第1部をまとめる
- 試験に出やすい知識： どの外部ライセンスが標準の共有を持つかを知っている：Customer Community PlusとPartner Communityで、外部ユーザーのロールが必要。Customer Communityは共有セットを使う。（誰が何を見て、誰にライセンスが必要か）
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- 「信頼できる唯一の情報源」：どの真実？ それは一つのレコードではなく、真実のアーキテクチャです。
- スキーマの中で権威を見えるようにする： 別のシステムが所有する項目には接頭辞を。
- 信頼には値以上のものが必要： ソース、最後の確認、誰が変えたか。
- MDMの製品ではなく、問題から始める。 MDMは権威についてのビジネスの判断です。
- つなぐことはマスター管理ではない。
- 誤った照合が高くつくところでは、意図的に照合を控えめにする。
- さかのぼる必要があるかもしれないなら、外部からのロードの重複は残しておく。
- 統合プロファイルは地図である。ゴールデンレコードは判断である。
- 表示は権威ではない。
- 識別を統合しても、セキュリティの境界は消えない。
- 一番難しいのは双方向の連携だ。 共有された権威が問題なのではなく、曖昧な権威が問題なのです。
- 拒否された依頼を、競合する真実にしてはいけない。
- これはマスターデータだと示す項目が編集可否を決める。レコードタイプではない。
- 私たちはERPをコントロールしない。コントロールするのは、それをSalesforceでどう表現するかだ。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| マスターデータ管理（MDM） | システムをまたいで、主要なデータの権威ある識別と値を確立し、統制すること |
| 権威の地図 | 属性ごとに：誰が作成し、誰が判断を所有し、どのシステムが権威を持ち、誰が変えてよいか |
| ゴールデンレコード | どの値が権威を持つかについての、統制された判断 |
| ハイブリッドなゴールデンレコード | 一部の属性はほかでマスター管理されてコピーされ、一部は手元で所有されているレコード |
| レジストリ型 | ソースを変えずに、レコードを同じエンティティとしてつなぐMDM |
| コンソリデーション型 | たいていは分析のために、送り返さずにデータを中央にまとめるMDM |
| 共存型 | マスター管理された値を決め、それをソースに公開し直すMDM |
| 集中型MDM | 統制されたデータをマスターで作成し、配布するMDM |
| 標準データモデル | ある概念についての合意された企業の形。システム同士を対応づけるのに使う |
| 調和（ハーモナイゼーション） | 値を比較できるようにすること：標準の形式、コード、略語 |
| 照合（マッチング） | レコードが同じものを表しているかを判断すること |
| サバイバーシップ | ソースが食い違うとき、どの値が勝つかのルール |
| マスターレコード（Principal record） | Salesforceのマージで残り、非表示の項目と参照のみの項目を保持するレコード |
| 一致方法 | Data 360の一致条件が値を比較する方法：完全一致、正規化後の完全一致、あいまい一致 |
| ID解決 | Data 360による、ソースのプロファイルの統合プロファイルへの照合 |
| 統合プロファイル | 一人の人や一つの会社を表すソースレコードをつなぐキーの集まり |
| 調整ルール | 統合プロファイルがどの値を表示するかについてのData 360のルール |
| 複数のマスターを持つ階層 | 枝ごとに違うシステムが所有している階層 |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. 「Salesforceが顧客についての私たちの唯一の情報源です」。何を尋ねますか？
どの真実ですか？ 権威は属性ごとです。ERPが正式名称、請求先住所、与信限度額を所有し、Salesforceが営業責任者とサクセスの階層を所有しているかもしれません。権威の地図を作りましょう。真実は属性に属するを読み直しましょう。
2. サービスエージェントは、Salesforceの取引先責任者がオンラインで購入したのと同じ人だとわかる必要があります。誰もシステムを変える必要はありません。どのMDMのスタイルですか？
レジストリ型です。ソースを変えずにレコードを一つの識別としてつなぎます。それがData 360のID解決のすることです。問題を解決する最も軽いパターンを選びましょう。レジストリ型：誰が誰なのかを教えてを読み直しましょう。
3. サバイバーシップが、すべての項目で「最新が勝つ」に設定されています。誰かが、ERPが所有する正式名称のSalesforceのコピーを変えます。何が起き、何が間違っているのでしょうか？
最も新しい値が勝ち、コピーが権威を上書きします。「最新」は、ある属性（携帯電話の番号）には合い、ほかには合わない、信頼についての表明です。権威の地図でERPがその項目を所有しているなら、ERPが勝ちます。サバイバーシップ：どの値が勝つのか？を読み直しましょう。
4. 従来のシステムの顧客レコードがインポートされ、既存の取引先と一致します。マージしますか？
慎重に。一致してもマージする必要はなく、マージはさかのぼる必要があるかもしれない従来のIDと古い値を壊します。勝者がはっきりしていて、重複に必要なものが何もない場合を除いて、つなぎましょう。私のマージのルール：はっきりした勝者を読み直しましょう。
5. Data 360の統合プロファイルがDallasと表示しています。チームは、Dallasが今やすべてのシステムにとってのゴールデンな値だと言います。そうでしょうか？
違います。調整は統合プロファイルが何を表示するかを決めるだけで、ソースを変えることも、マスター管理の判断を下すこともしません。すべてのシステムが統制された一つの値を使わなければならないなら、それはオーナーを持つ共存型か集中型のMDMです。調整してもマスター管理ではないを読み直しましょう。
6. 医療のレコードとマーケティングのレコードの照合：同じルールでよいでしょうか？
いいえ。マーケティングでの誤った照合は間違ったオファーを送ります。医療データでは2人の病歴をまとめてしまいます。間違えたときのコストで厳しさを決め、混ぜ合わせると高くつくところでは照合を控えめにしましょう。間違えたときのコストを読み直しましょう。
7. 営業担当者は、ERPが所有する請求先住所をSalesforceから更新したいと言います。どう設計しますか？
編集ではなく依頼として設計します。Salesforceが提案値を送り、ERPがそれを検証して受け付け、権威ある値を公開し直します。それまでは保留の状態を持ち、拒否、衝突、反響に対応します。双方向のデータは2つのマスターを意味しないを読み直しましょう。
8. Steve Truckingで、同じJohn Smithが2社の小売パートナーの積荷目録に現れます。統合しますか？
いいえ、意図的にしません。どのパートナーも別のパートナーの受取人を見てはならず、統合されたIDは漏れが通る橋になります。混ぜ合わせると高くつくところでは照合を控えめにし、パートナーが繰り返し受け取る人を認識したいなら、そのパートナーだけに限定しましょう。パートナーをまたいで受取人を統合するか？を読み直しましょう。
9. 営業担当者がERPの所有する住所に新しい番地を送り、同じ1分のうちに、ERPの誰かが市区町村を変えます。何を決めますか？
住所を一つのトランザクションとして送るかどうかです。そうするなら、項目はすべて一緒に通るか一つも通らないかで、その間に住所が変わったので依頼は拒否されます。それを最初の衝突の前に決めましょう。そして依頼はERPの値を変えるよう求めているのであって、変えているのではないことを忘れないでください。ループと衝突を読み直しましょう。
10. あるクライアントでは一つの顧客が2つのERPにあり、誰も2つのレコードを同期させていません。営業は一つの取引先を望んでいます。何を勧めますか？
一つの取引先ではありません。自分たちのERPの中でレコードを同期させられないなら、Salesforceが代わりにそれをすることはできません。対等な取引先か階層として表し、営業がすでに知っている構造を見せましょう。ERPごとの子を持つ一つの取引先には、共有の値を同期させているクライアントが必要です。ERP同士をどう同期させているかを尋ねるを読み直しましょう。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)、Salesforceヘルプ（英語、2026-09-25確認）：出題目標とその配分の公式一覧。受験を予約する前に、必ず最新版を確認しましょう。
- 各モジュールの「さらに学ぶ」には、そのデータの裏づけとなるSalesforceのドキュメントが、確認した日付とともに載っています。