データの品質とガバナンス
ほかに 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コース第5章の学習ガイドです。まず6つのモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、Salesforceが公開している試験ガイドの出題目標の一覧だけをもとに作られています。実際の試験問題をもとにしたことは一度もなく、試験に何が出るかを知っているとも主張しません。すでに受験した方は、どうか試験の問題を私に送らないでください。認定資格の契約で共有が禁じられていますし、そもそも答えを暗記するのはアーキテクトになる方法として間違っています。
この章は、試験のData Governanceセクション（10%）と、Data Modeling（メタデータ）およびSalesforce Data Management（一貫性）の一部を担っています。そしてプライバシー法がデータモデルと出会う場所でもあります。これはアーキテクチャであって法的助言ではありません。何が適用されるかは法務が決め、アーキテクトはそれを強制できるようにします。プラットフォームの数値は変わるので、頼る前に現在の数値を確認しましょう。
進めながらチェックしていきましょう。各項目には、それを教えている箇所へのリンクがあります。
GOV-2：データガバナンスのプログラムを設計する
- レコード所有者（アクセスのためのプラットフォームの仕組み）はデータオーナー（ビジネス資産としてのデータに責任を持つ人）ではないこと、そして各項目にデータ所有者を記録できることを知っている。（レコード所有者はデータオーナーではない）
- データオーナー（ポリシーを決める）、データスチュワード（それを機能させ続ける）、カストディアン（システムを運用する）を見分けられる。（オーナー、スチュワード、カストディアン）
- 試験に出やすい知識： ガバナンスのプログラムを運営する3つのやり方、集中型、連邦型（分散型）、ハイブリッド型と、それぞれが、誰がポリシーを定め、共有の定義がどこに置かれるかにとって何を意味するかを知っている。（プログラムをどう運営するか）
- RACIを使って、データがどこで作成され、編集され、参照されるのかに答えられる。（RACIにその場所を勝ち取らせる）
- ガバナンスのポリシーについて、トレーニングだけでなく、強制の場所（権限、入力規則、連携だけが書き込む項目、項目履歴）を挙げられる。（ガバナンスは機械的にならなければならない）
- 測る価値のある品質の兆候は、誰かが行動を起こすものだと知っている。（誰かが行動を起こすものを測る）
SDM-2とMDM-4：悪いデータを入れない
- 取引先の作成を開放するか制限するかを決められ、ERPでマスター管理される取引先のための仮のレコードタイプの道を知っている。（開放するか、制限するか？、中間の道）
- Salesforce自身の項目は編集できるようにしたまま、統制された属性（ERPのID、正式名称）を守れる。これがハイブリッドなゴールデンレコードである。そして、Dynamic Formsのページで項目を読み取り専用にしても強制にはならず、項目レベルセキュリティや入力規則がそれであることを知っている。（統制されたレコードを守る、流れごとのレコードタイプ）
- 双方向の連携が最も難しいことを知っている。ERPがある項目をマスター管理しているなら、Salesforceはその変更を依頼しているのであり、衝突にはルール（ERPが優先する、変更されていたら拒否する、人が解決する）が必要である。（統制されたレコードを守る）
- 必須項目が偽のデータ（
N/A、999999）を生み得ることと、その代わりになる方法を知っている。（必須項目に偽のデータを作らせない） - チェックに失敗した受信データに何が起きるか（受け付け、拒否、隔離）と、誰がその例外を所有するかを決められる。（すべてのデータの境界には品質の判断が必要）
- 参照データにもメタデータが必要であることを知っている：定義、所有者、源、システム間の対応表。（参照データにもメタデータが必要）
DM-3：ビジネスと技術のメタデータ
- 試験に出やすい知識： ビジネスメタデータ（意味、定義、オーナー、ルール、機密度）と技術メタデータ（オブジェクト、項目、型、API参照名、スキーマ、マッピング、系統）を区別できる。（2種類のメタデータ）
- ビジネス辞書（何を意味するか）、系統（どこから来たか）、分類（どう扱われるべきか）の違いを知っている。（データを知る）
- Salesforceの分類項目を知っている：データ所有者、項目の使用状況、データ機密度、コンプライアンス分類。標準項目とカスタム項目の両方で使える。（分類は別の問いに答える）
- すべての項目ではなく機密の項目を分類すること、そして強制のない分類は飾りであることを知っている。（強制のない分類は飾りである）
GOV-1：個人データと機密データ
- 主要な法律（GDPR、CCPA/CPRA、PIPEDA、LGPD、オーストラリアのPrivacy Act、HIPAA、PCI DSS、SOX、COPPA）がわかり、GDPRがEUの外の組織にも及び得ることと、法律に共通すること（権利、移転、侵害の通知、説明責任）を知っている。（知っておくべき規制、法律は国境で止まらない）
- 暗号化、マスキング、仮名化、匿名化の違いと、仮名化されたデータはやはり個人データであることを知っている。（匿名化、仮名化、暗号化、マスキング）
- 集めるものを減らすことはプライバシーの管理策であり、保持は最初から設計するものだと知っている。（集めるものを減らすことはアーキテクチャ上の判断である、保持はモデルの一部である）
- 同意データモデルを知っている：個人（Individual）の上のグローバルな同意、エンゲージメントチャネルごとの同意、連絡先ポイントごとの同意、そしてデータ使用目的。（Salesforceがすでに作ったモデルを使う）
- 請求には期限がある（GDPR：1か月、さらに2か月延長可能）ので、コピーの地図が先に存在していなければならないことを知っている。（時計はもう動いている）
- 忘れられる権利とは、すべてのコピー（履歴、アーカイブ、分析、ログ、ファイル、自由記述のテキスト）を見つけることであり、Privacy Centerのポリシーは顧客レコードに対してオブジェクトごとに実行されることを知っている。（そして、その人が言う：私を忘れてください、Privacy Centerは道具であって、アーキテクチャのすべてではない）
- Shield Platform Encryptionのトレードオフを知っている：確率的な暗号化の項目はSOQLで絞り込み、グループ化、並べ替えができない。決定論的な暗号化なら絞り込める。暗号化された項目は条件ベースの共有を決められない。（暗号化は管理策であって、コンプライアンスではない）
- 本番の機密データをサンドボックスにコピーしないこと、そしてData MaskがData Mask & Seedに置き換えられつつあることを知っている。（本番のリスクをサンドボックスにコピーしない）
- 項目履歴管理（オブジェクトごとに最大20項目。18か月、API経由のみ24か月。ロングテキストは編集されたことだけを記録）とField Audit Trail（最大200項目、削除するまで保持）を知っている。（履歴もデータである）
- Event Monitoringのログの保持期間（アドオンなしでは一部のイベントについて1日、アドオンありでデフォルト30日、延長すれば最大365日）と、必要になる前にイベントをSIEMにエクスポートすることを知っている。有料のログは、契約開始より前の分は取得できない。（監査と監視は同じではない）
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- 強制の場所のないポリシーは、ほとんど願望である。
- オーナーがポリシーを決め、アーキテクトがそれを強制する。 ポリシーを発明しないこと、そして弁護士を演じないこと。
- ガバナンスは決して終わらない。 満ち引きを繰り返します。フィードバックを設計しましょう。
- 善い振る舞いに頼らない。 管理策を作りましょう。人、連携、エージェントは間違いを犯します。
- すべてではなく、十分に統制する。
- まず高くつく誤りを防ぐ。 2年分の履歴を持つ重複は大きな問題です。
- 人が読むものと、機械が判断に使うものを区別する。
- 説明は広く、分類は意図的に。
- 統制するのが最も安い機密データは、決してコピーしなかったデータである。
- 同意はデータである。 そしてデータを使う許可は、データとして表現できなければならない。
- まず個人データがどこへ行くかを管理する。 削除はまれで難しいからです。
- コンプライアンスは製品ではない。
- 取り込む → 分類する → 保護する → 使う → 保持する → 削除する → 監査する。
- 誰かに求められる前に証拠を記録しておく。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| データガバナンス | データについてのポリシーと、それを真実にするアーキテクチャ |
| データオーナー | ある種類のデータに責任を持つ人や部門 |
| データスチュワード | 日々データを健全に保つ人 |
| カストディアン | データを保持するシステムを運用するチーム |
| RACI | 実行責任者（Responsible）、説明責任者（Accountable）、相談先（Consulted）、報告先（Informed） |
| 仮のレコード | 権威あるシステムに受け付けられる前に作られたレコード |
| ビジネス辞書 | 重要なビジネス用語の合意された定義 |
| 系統（リネージ） | 値がどこから来て、その途中で何が起きたか |
| データ分類 | データに機密度とコンプライアンス分類のラベルを付け、適切な管理策を受けるようにすること |
| 分類体系（タクソノミー） | 組織がデータを分類するのに使うラベルの集まり |
| 個人データ | 人を識別する、あるいは人に結びつけられ得る情報 |
| 仮名化 | 元に戻る道を残したまま識別子を置き換えること。やはり個人データ |
| 匿名化 | その人を識別する合理的な可能性を取り除くこと |
| 同意データモデル | 人、チャネル、連絡先ポイント、目的ごとの同意のためのSalesforceのオブジェクト |
| 忘れられる権利 | 法律が認める場合に、自分の個人データを消してもらう人の権利 |
| ハイブリッドなゴールデンレコード | マスターシステムの項目とSalesforce自身の項目を持ち、それぞれのソースが一つに決まっているレコード |
| ビジネスメタデータ / 技術メタデータ | データが何を意味し、誰が所有するか / それがどう作られ、どう動くか |
| Field Audit Trail | より長い項目履歴：オブジェクトごとに最大200項目、削除するまで保持 |
| Event Monitoring | ログイン、エクスポート、API呼び出し、閲覧のログ。限られた期間だけ保持される |
| SIEM | イベントログを保存し分析するセキュリティのリポジトリ |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. ポリシーでは、顧客の正式名称を変えられるのは財務だけです。チームはそれをトレーニングで扱うつもりです。何が足りないでしょうか？
強制の場所です。トレーニングは管理策ではありません。項目レベルのアクセス、連携だけが書き込む項目、入力規則、管理されたプロセスを使いましょう。オーナーがポリシーを決め、アーキテクトがそれを機械的に真実にします。ガバナンスは機械的にならなければならないを読み直しましょう。
2. 顧客はERPでマスター管理されています。営業担当者は新しい見込み客にすぐに売り始める必要があります。2つのシステムがマスターレコードを作ることなく、どうやってそれを可能にしますか？
営業担当者に仮のレコードタイプで取引先を作らせ、管理されたプロセスで変換します。財務が承認するか、連携がそれをERPに送り、ERPが顧客を照合または作成して、権威ある識別子を返します。中間の道を読み直しましょう。
3. 新しい必須項目が「N/A」と「999999」で埋まっていきます。何が起き、代わりにどうしますか？
ユーザーが答えを知る前に答えることを強いられたのです。プロセスの後のほうで必須にするか、別のシステムに提供させるか、仮の状態を使うか、それが本当の答えであるなら明示的な「不明」を用意しましょう。必須項目に偽のデータを作らせないを読み直しましょう。
4. チームは名前をトークンに置き換え、データは匿名化されたので削除の請求は解決したと言っています。本当にそうでしょうか？
トークンをその人に結びつけ直せるなら、違います。それは仮名化であり、データはやはり個人データです。システムが何をしているのか、対応表がどこにあるのかを正確に伝え、それが要件を満たすかどうかは法務に判断してもらいましょう。匿名化、仮名化、暗号化、マスキングを読み直しましょう。
5. ある受取人は、配送についてのSMSは受け付けますが、マーケティングは受け付けません。モデルはそれをどう保存すべきでしょうか？
一つのチェックボックスではなく、同意データモデルでです。人、チャネル（SMS）、特定の番号、データ使用目的（マーケティングではなく配送の通知）。そして、撤回がそれに基づいて動くすべてのシステムに届くように、どのシステムが同意について権威を持つかを決めましょう。Salesforceがすでに作ったモデルを使うを読み直しましょう。
6. コンプライアンス部門は、暗号化された社会保障番号の項目でレポートを絞り込む必要があります。項目はデフォルトの暗号化方式を使っています。何が問題でしょうか？
確率的な暗号化では、SOQLのWHERE句やデータ管理の絞り込み条件で絞り込めません。決定論的な暗号化なら、強度を少し犠牲にして絞り込めます。暗号化は最後に付けるチェックボックスではなく、トレードオフを伴う設計上の判断です。暗号化は管理策であって、コンプライアンスではないを読み直しましょう。
7. インシデントから半年後、誰かがあるレコードの集まりをエクスポートしたのは誰かと尋ねます。Event Monitoringの保存は誰も設定していませんでした。何と答えられますか？
おそらく何も答えられません。イベントログは限られた期間しか保持されず（延長しても最大1年）、それより古いものはエクスポートしていなければ消えています。Event Monitoringを設定し、必要になる前にイベントをSIEMに送っておきましょう。監査と監視は同じではないを読み直しましょう。
8. 営業担当者が、ERPがマスター管理している顧客の正式名称を変更するようSalesforceに求めます。その数分の間に、誰かがERPでそれを変更します。設計は何と言うべきでしょうか？
Salesforceは変更していたのではなく、依頼していたのだということです。その項目をマスター管理しているのはERPです。衝突のルール（ERPが優先する、値が変更されていたら拒否する、人が解決する）と、関連する項目を一緒に動かすかどうかを、前もって決めておきましょう。統制されたレコードを守るを読み直してください。
9. ある人の消去の請求が届きました。チームは、その人のデータがどこにあるかの洗い出しを始めようとしています。何が問題でしょうか？
時計はもう動いています。GDPRでは1か月、複雑な請求ならさらに2か月延長できます。コピーの地図は、請求が届く前に存在していなければなりません。時計はもう動いているを読み直してください。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)、Salesforceヘルプ（英語、2026-09-25確認）：出題目標とその配分の公式一覧。受験を予約する前に、必ず最新版を確認しましょう。
- 各モジュールの「さらに学ぶ」には、そのデータの裏づけとなるSalesforceのドキュメントと法律が、確認した日付とともに載っています。