保護し、保持し、証明する
ほかに 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)
モジュール6／6：Data Architectコース第5章「データの品質とガバナンス」。各モジュールは単独でも読めます。 前へ：同意と忘れられる権利 · 次へ：次の章、マスターデータとID
このモジュールが答える問い： データをどう守り、必要な期間保持し、それを証明するのか？
オーナーとポリシーを決め、悪いデータを締め出し、辞書を書き、系統をたどり、重要なものを分類し、法律を学び、同意をモデリングしました。今度はそれを運用しなければなりません。データが届き、使われ、コピーされ、変更され、古くなり、いずれその一部は消えなければなりません。そしていつか誰かが尋ねます。何が起きたかを証明してください。
ガバナンスはデータについていく
Section titled “ガバナンスはデータについていく ”私はガバナンスを一つの機能としては考えません。データが入ってきた瞬間から、それを使い終わるまでに何が起きるかを考えます。
取り込む → 分類する → 保護する → 使う → 保持する → 削除する → 監査する
7つの技術的なプロセスではありません。アーキテクチャが答えなければならない7つの問いです。取り込みと分類はすでに扱いました。高くつく誤りを締め出すこと（モジュール2）と、どのデータが機密かを知ること（モジュール3）です。分類がその後のすべての段階で何が起きるかを決めるので、このモジュールはそこから先を扱います。
データの一生にわたる7つの問い。ツールはポリシーを支えますが、ポリシーを定義するわけではありません。
保護する：管理策をデータに合わせる
Section titled “保護する：管理策をデータに合わせる ”誰がそれを見て、変えて、受け取れるのか？ 暗号化すべきか、本番の外ではマスキングすべきか、エクスポートできるか、エージェントが届くか？ ここでSalesforceのセキュリティがデータガバナンスの一部になります。共有、オブジェクトと項目の権限、暗号化、マスキング、連携のアクセス。これらのテーマはそれぞれコースが丸ごと一つ必要なので、ここでは繰り返しません。ガバナンスとしてのポイントは、保護は分類とポリシーに従うということです。すべての項目に同じ保護が必要なわけではなく、すべてのユーザーに同じアクセスが必要なわけではなく、すべての下流のシステムにすべての項目が必要なわけではありません。
暗号化は管理策であって、コンプライアンスではない
Section titled “暗号化は管理策であって、コンプライアンスではない ”規制対象のデータでは保存時の暗号化が求められることがあり、私の立場は、そうした主要な規制要件にはShieldが答えになるというものです。Shield Platform Encryptionは、保存時の項目とファイルを暗号化します。しかし「暗号化したので、コンプライアンスを満たしている」は二重に間違っています。暗号化は、アクセス、保持、監査、同意、監視、最小化、削除と並ぶ管理策の一つにすぎません。そして、前もって設計すべき機能上のトレードオフがあります。デフォルトの確率的な方式では、暗号化された項目はSOQLのWHERE、GROUP BY、ORDER BY句やデータ管理の絞り込み条件に使えません。決定論的な暗号化は強度を少し犠牲にして、その項目で絞り込めるようにします。暗号化された項目は条件ベースの共有ルールを動かせず、リストビューをそれで並べ替えることもできません（General Shield Platform Encryption Considerations (opens in a new tab)、Filter Encrypted Data with Deterministic Encryption (opens in a new tab)、英語）。ですから暗号化は最後に付けるチェックボックスではありません。アーキテクチャ上の判断です。データセキュリティの章でさらに掘り下げます。
本番のリスクをサンドボックスにコピーしない
Section titled “本番のリスクをサンドボックスにコピーしない ”本番は厳重に守られています。そこで誰かがフルサンドボックスを更新すると、開発者、テスター、外部の協力者、テスト用の連携が、必要としたこともない本物の個人データのコピーを持つことになります。環境は変わっても、データの機密性は変わっていません。Salesforceのマスキングツールはまさにこのためにあります。変更に注意してください。Data Maskの管理パッケージは2026年12月31日にサービスを終了し、後継はData Mask & Seedです（Data Mask (Legacy) (opens in a new tab)、英語）。しかし、道具はポリシーを支えるもので、問いが先に来ます。この環境は、そもそも本物の機密データを必要としているのか？ 現実的で機密でないデータでテストできるなら、それがよりよい答えです。
使う：許可は人だけの話ではない
Section titled “使う：許可は人だけの話ではない ”ユーザー、連携、分析、パートナー、自動化、エージェントのすべてがデータを使います。同意（モジュール5）、所有（モジュール1）、分類（モジュール3）が、実行時にここで出会います。このユーザーは受取人の電話番号を見るべきか？ この連携は受け取るべきか、Snowflakeは、このエージェントはグラウンディングとして？ 答えが「まあ、技術的にはできます」であってはいけません。それが機能とガバナンスの違いです。それをすべきかどうかを決めるのはアーキテクチャです。
保持する：すべてを永遠に残すことは中立ではない
Section titled “保持する：すべてを永遠に残すことは中立ではない ”多くの組織には、偶然の保持ポリシーがあります。永遠に、です。誰も決めていません。ストレージがあったので、データが残っただけです。しかしデータを保持することには、ストレージと性能のコストがかかり、プライバシーとセキュリティのリスクが広がり、開示の義務が増え、誰かが忘れてほしいと言ったときに探す場所が増えます。重要な分類ごとに：なぜ保持するのか、どれくらいの期間か、何が時計を動かし始めるのか、法的な最短期間やプライバシー上の最長期間はあるのか、そして終わりに何が起きるのか。アーカイブ、削除、非識別化？
そしてアーカイブは、保持の問題を解決することと同じではありません。「アーカイブしました」。保持の要件はなくなったのでしょうか？ プライバシーの要件は？ セキュリティは？ 変えたのはデータの置き場所であって、データが何であるかではありません。アーカイブには、アクセス管理、保持と削除のルール、開示、監査が必要です。個人データを誰もが忘れてしまうアーカイブに移せば、ガバナンスは悪くなっただけです。
削除する：ライフサイクルには出口が必要
Section titled “削除する：ライフサイクルには出口が必要 ”削除は、個人のプライバシーの請求のためだけのものではありません。データは保持期間の終わりに達し、一時的なレコードは用途を過ぎても残り、アーカイブは期限を迎え、あるプロセスは決められた時間の後に非識別化します。ポリシーが何と言っていても、アーキテクチャには出口が必要です。取り込む → 保存する → もっと保存する → 永遠に保存する、ではいけません。そしてモジュール5で見たように、コピーがほかの場所にあるなら、Salesforceのレコードを削除するだけでは足りません。
履歴もデータである
Section titled “履歴もデータである ”現在の値だけでは足りないこともあります。パートナーの正式名称、顧客の分類、同意のステータス、財務の属性。ビジネスや規制当局が、以前は何だったのか、いつ変わったのか、誰が変えたのかを知る必要があるかもしれません。その履歴はデータであり、独自の保持の判断が必要です。
標準の項目履歴管理は、オブジェクトごとに最大20個の項目を追跡し、変更を最大18か月保持します。最大24か月になるのはAPI経由、つまりData LoaderかqueryAll()を使う場合だけです（Field History Tracking Overview (opens in a new tab)、英語）。そしてロングテキストエリア項目については、項目が編集されたことしか記録せず、何が書かれていたかは記録しません。それが証拠になるのなら、穴です。Field Audit Trail（Shieldの一部、または単体で購入）は、オブジェクトごとに最大200個の項目を追跡し、APIでアクセスするアーカイブに、履歴を削除するまで保持します（Field Audit Trail (opens in a new tab)、英語）。私の立場は、標準の項目履歴がデフォルトで、規制やコンプライアンスの義務がより長く証明できる履歴を求めるときにField Audit Trailを使うことです。「監査」が聞こえがいいからではありません。
監査と監視は同じではない
Section titled “監査と監視は同じではない ”項目履歴は、選んだ項目の変更についての問いに答えます。より広い問い（誰がログインしたのか、誰がデータをエクスポートしたのか、どのAPIが呼び出されたのか、誰が何を見たのか）は監視であり、それがEvent Monitoringです。私の経験では、より規制の厳しいお客様で必要になるのが一般的です。そしてこれが、この章で私の最も強い立場です。必要になる前に設定し、イベントを前もってSplunkのようなリポジトリやほかのSIEMに流し込んでおく。
理由はこうです。イベントログファイルは、アドオンなしでは1日しか保持されず、それも一部のイベントタイプだけです。ShieldかEvent Monitoringのアドオンがあればデフォルトで30日、保持を延長すれば最大365日です（Event Monitoring FAQ (opens in a new tab)、英語）。それより古いものは、エクスポートしていなければ消えています。そして有料のログは、契約が始まる前の期間については取得できません（同じFAQ）。インシデントの後でアドオンを買っても、過去は戻ってこないのです。ですから、アーキテクトがする最悪の会話の一つはこうなります。「半年前に何が起きたか見られますか？」「いいえ」「なぜですか？」「記録していなかったからです」。問題にぶつかってから、そうしたイベントを記録も保存もしていなかったと気づくのではいけません。 そのときには、答えはもうただ消えているのです。
必要になる前に準備しましょう。
しかし「すべてをログに残す」に振れすぎないでください。何を証明しようとしているのか？ どのイベントが重要で、誰がそれを必要とし、どれくらいの期間で、誰がログを読んでよく、ログ自体が機密データを含んでいないか？ ログはデータを生み、そのデータにもガバナンスが必要です。そして証拠にはオーナーが必要です。誰がリポジトリを所有し、アラートを確認し、保持が機能しているかを確かめ、フィードが3か月前に黙って止まっていたことに気づくのか？ オーナーのいないテクノロジーはガバナンスではありません。モジュール1のオーナー、スチュワード、カストディアンに戻ってきました。
設定だけでなく、管理策を証明する
Section titled “設定だけでなく、管理策を証明する ”「受取人のデータを使えるのは、その停車地に割り当てられたクルーだけ」。どうやってそれがわかるのでしょう？ セキュリティの設定は、何が起きるべきかを示します。業務上の証拠（誰が実際にアクセスしたのか、普段と違うエクスポート、それを引き出す連携、変更されたアクセス管理）は、何が起きたかを示します。よいガバナンスには、しばしばその両方が必要です。
試験の先へ：AIが変えること。 エージェントが答えることから行動することへと進むにつれて、ガバナンスには、エージェントが何を見て、何を判断したり生成したりして、何をしたのか、そして誰が、何が、どのポリシーのもとでそれを始めたのかの証拠が必要になります。ログの仕組みは変わっていくでしょう。要件は変わりません。自律的な行動が重要なら、後でそれをどう再構成するかを今設計しておきましょう。
Steve Trucking：一つの項目のライフサイクル
Section titled “Steve Trucking：一つの項目のライフサイクル ”受取人の電話番号を例にとりましょう。取り込む： パートナーの積荷目録で届く。プロセスがそれを必要とするところで、使える番号かを確認する。分類する： 個人データ。保護する： 業務上の必要がある人とシステムだけが受け取り、クルーは自分の停車地について、その日だけ見る。使う： クルーが配送を調整する。メッセージングは承認された目的のためにそれを使う。エージェントはポリシーが許す場合にだけ使う。保持する： 承認されたビジネスとプライバシーのポリシーが言う期間。削除または非識別化する： その期間が終わったとき、あるいは有効な請求が届いたとき、全体像の中のすべてのコピーで。監査する： 管理策と対応が行われたという証拠を残す。
次は物流センターのコードです。正確に取り込み、機密でない参照データとして分類し、通常の業務上のアクセスで保護し、広く使い、ビジネスが必要とする間保持し、重要なら変更を監査する。同じライフサイクル、違う管理策。それが分類の目的です。
ガバナンスは決して終わらない
Section titled “ガバナンスは決して終わらない ”新しい規制が現れる。新しいシステムや連携がもう一つのコピーを作る。あるチームがもう一つ項目を作る。新しいプラットフォームが稼働する。エージェントがアクセスを得る。保持のルールが変わる。新しい小売パートナーがやって来る。アーキテクチャが動き、ガバナンスもそれとともに動きます。目標は完璧なデータでも、無限の管理策でも、誰も読まないガバナンスの文書でもありません。データについての意図的な判断を、アーキテクチャに組み込むことです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 分類、ポリシー、実際の利用に基づいて、それぞれの種類のデータにどの保護の管理策を適用するか。暗号化のトレードオフも含めて。
- データとその履歴をどれくらいの期間保持するか、何が時計を動かし始めるか、そして終わりに何が起きるか。
- 標準の項目履歴で十分なのはいつで、規制がField Audit Trailを求めるのはいつか。
- どのイベントを記録し、プラットフォームの保持期間を超えて証拠をどこに保存し、誰がそれを所有するか。
- 人、連携、エージェントの重要な行動を、アーキテクチャが事後にどう証明するか。
この章は一つの考えから始まりました。ガバナンスは組織の横に書かれるのではなく、組織に組み込んで設計される。オーナーがポリシーを決め、アーキテクトがそれを強制する。重要なところで悪いデータを締め出す。データが何を意味し、どこから来て、どれくらい機密なのかを知る。法律を尊重し、同意をモデリングし、個人データがどこへ行くかを管理する。ポリシーに従って保護し、保持し、削除する。そして誰かに求められる前に証拠を記録しておく。インシデントから半年後というのは、証拠が30日間しか存在していなかったと知るには最悪のタイミングだからです。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、General Shield Platform Encryption Considerations (opens in a new tab)とFilter Encrypted Data with Deterministic Encryption (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Field History Tracking Overview (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Field Audit Trail (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab)（英語）、2026-10-14確認。
- Salesforceヘルプ、Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab)（英語）、2026-10-14確認。