同意と忘れられる権利
ほかに 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)
モジュール5／6：Data Architectコース第5章「データの品質とガバナンス」。各モジュールは単独でも読めます。 前へ：プライバシー法が設計を形づくる · 次へ：保護し、保持し、証明する
このモジュールが答える問い： 同意に向けて、そして人を消去することに向けて、どう設計するのか？
Steve Truckingは受取人の電話番号を持っています。シンプルな問いです。その人にSMSを送ってよいか？ そうかもしれません。今日の配送について？ 明日の配送について？ その番号をキャンペーンに使ってよいか？ その人がSMSは要らないと言っていたら、あるいは配送の更新にはイエス、マーケティングにはノーと言っていて、その後で気が変わったら？
今度は反対の方向です。受取人が言います。私の個人情報を削除してください。 それはどこにあるのでしょう？ おそらくSalesforceですが、それがすべての答えではないことを学んできました。小売パートナーから来ました。顧客データプラットフォーム、項目履歴、アーカイブ、配送メモ、エクスポート、連携のログ、エージェントの会話にあるかもしれません。同意と削除はポリシーの問いに聞こえますが、いずれシステムがそれに答えなければなりません。それがアーキテクチャです。
同意はデータである
Section titled “同意はデータである ”第一の原則は、同意はデータであることです。それをHas_Opted_In__c = trueに切り詰めないでください。本当の問いは決して「同意したか？」だけではありません。**何に、どのチャネルで、どの連絡先や番号に、どんな目的で、いつ同意したのか、それは変わったのか、そしてそれを証明できるのか？**です。ビジネスがその答えに基づいて判断を下すなら、それは構造化されたデータとして保存されなければなりません。プライバシーポリシーの一段落では足りませんし、Webフォームのチェックボックスでも足りません。チェックボックスは出来事を記録するだけで、アーキテクチャはその出来事が何を意味するかを保持しなければなりません。
Salesforceがすでに作ったモデルを使う
Section titled “Salesforceがすでに作ったモデルを使う ”私の立場は、できる限り標準の同意モデルを使うことです。同じものをカスタム項目で作り直すのではなく。Salesforceの同意データモデルは、同意を4つのレベルで管理し、それぞれがより具体的な問いに答えます（Understand the Salesforce Consent Data Model (opens in a new tab)、英語）。
- グローバルな同意、個人（Individual）の上で： この人は誰か、そしてすべてにノーと言っているか？
- エンゲージメントチャネルの同意（Contact Point Type Consent）：SMSやメールのような、この種類のチャネルを使ってよいか？
- 連絡先ポイントの同意： この特定の電話番号やメールアドレスについてはどうか？
- データ使用目的（Data Use Purpose）：どんな理由で。配送の通知、サービス、マーケティング？
これらを合わせると、アーキテクチャは**「この人の情報を、この連絡先ポイントを通じて、この目的のために使ってよいか？」**に答えられます。「同意 = はい」よりはるかに役に立ちます。個人に関係するどんなレコードも参加できます。リード、取引先責任者、個人取引先、ユーザー。
前のものより一つずつ狭くなる4つの問い。一つのオプトインのフラグでは、どれにもうまく答えられません。
目的が重要
Section titled “目的が重要 ”小売パートナーがSteve Truckingに受取人の番号を送るのは、クルーが配送を調整するためです。だからといって、受取人がマーケティングのリードになるわけではありません。同じデータでも、許される用途は違い得ます。配送の調整、サービスのフォローアップ、マーケティング、AIによるパーソナライズ。ポリシーや法律がそれらを違うものとして扱うなら、モデルはそれらを区別しなければなりません。問いは**電話番号を持っているか？**ではありません。**それで何をすることが許されているか？**です。
そして、同意がいつも法的根拠であるとは限りません。法律が定める別の根拠に基づく用途もあり、それを判断するのは法務です。すべてのプライバシーの判断がオプトインのチェックボックスだと決めつけたアーキテクチャを作らないでください。ポリシーが言うことは何であれ支えましょう。ある用途が同意に依存するなら、同意をモデリングして強制する。別の根拠が当てはまるなら、それでもその用途が許されるかを判断するのに必要なものを保存する。
同意にはライフサイクルと権威がある
Section titled “同意にはライフサイクルと権威がある ”人は同意を与え、撤回し、好みを変え、番号を変えます。ビジネスは新しい目的を加え、法律は変わります。ですからライフサイクルを設計しましょう。何が選ばれたのか、いつ、どうやって、どの目的について、そして撤回されたら何が起きるのか。そしてここから面白くなります。受取人が同意を撤回したとき、Salesforceはそれを知っています。メッセージングのプラットフォームは？ 分析は？ エージェントは？ 一つのシステムにだけ同意があり、ほかのシステムが古い許可に基づいて動いているなら、それは管理策とはとても言えません。
つまり、どのシステムが同意について権威を持つのかを問うということです。Salesforceか、好み管理のプラットフォームか、それともどこか別の場所か？ 答えが何であれ、同じ人が同じ用途に同意したかどうかを、5つのシステムがばらばらに判断することがないようにしましょう。同意には、統制されたどんなデータにも必要なものが必要です。オーナー、権威あるレコード、同期の方法、そして強制です。
そして、その人が言う：私を忘れてください
Section titled “そして、その人が言う：私を忘れてください ”最初の直感は、取引先責任者を削除して終わりにすることです。しかし、その人のデータは取引先責任者、配送、配送メモ、ケース、写真、項目履歴、Snowflake、アーカイブ、連携のログ、検索インデックス、エージェントの会話履歴にあるかもしれません。だから消去についての私の立場は、もっと早くから始まります。削除は実際にはまれで難しいので、まず個人データがどこへ行くかを管理する。 個人データができるだけ少ない場所にしか着地しないように設計しましょう。そして請求が来たら、ポリシーを満たすところでは難読化したり結びつきを断ったりし、すべてのコピーを探し出します。項目履歴、アーカイブ、Data 360、そして今では検索インデックスとエージェントの会話も。
請求が届いてから探し始めないでください。そのときには、全体像を理解し始めるには遅すぎます。モジュール3の辞書、系統、分類は書類仕事ではありませんでした。これを可能にするものです。どの項目が個人データを持ち、コピーがどこへ行ったのかを、あなたはすでに知っています。
「私を忘れてください」という請求は、すべてのコピーについての判断です。
時計はもう動いている
Section titled “時計はもう動いている ”こうした請求には期限があります。GDPRでは、組織はその人の請求に対して、不当に遅れることなく、受け取ってから1か月以内に対応しなければなりません。複雑な請求や数の多い請求では、さらに2か月延長できますが、最初の1か月以内に、理由を添えてその人に伝えなければなりません（第12条第3項、Regulation (EU) 2016/679 (opens in a new tab)、英語）。ほかの法律にはそれぞれの期限があり、どれが適用されるかは法務が教えてくれます。いずれにしても、1か月はシステム全体像を探り当てるには短すぎます。コピーの地図が間に合わなければならないのは、この期限なのです。
削除か、非識別化か、保持か？
Section titled “削除か、非識別化か、保持か？ ”請求があったからといって、すべてがあらゆる場所から消えるとは限りません。保持しなければならない、あるいは保持してよいレコードもあれば、残しておけるがもうその人を識別しない業務レコードもあり、非識別化できるデータもあります。適用されるポリシーと法律が決め、アーキテクチャは場所ごとにそれぞれの結果を支えます。削除する、非識別化する、あるいは承認された要件のもとで保持する（そのとき、誰が、どれくらいの期間、なぜ見てよいのか？）。
モジュール4の区別を思い出してください。結びつきを断つことが忘れることになるのは、その人を合理的に再識別できない場合だけです。仮名化されたデータはやはり個人データです。難読化を、法的要件を回避する近道として使わないでください。
見つけられないものは削除できない
Section titled “見つけられないものは削除できない ”誰かを消去する前に、その人を見つけなければなりません。請求はあるメールアドレスから来ます。ある小売パートナーは「Jane Smith」を送ってきて、別のパートナーは「J. Smith」を送ってきて、電話番号は変わっています。受取人は取引先責任者ですらなく、その詳細はそれぞれの配送の上にあります。同じ人が、2つの別々のパートナーの配送を受け取りました。あるシステムはその人をメールアドレスで、別のシステムは外部IDで知っています。消去は識別に依存し、照合が強引すぎたせいで別の人のデータを削除したくはありません。IDのアーキテクチャは、プライバシーのアーキテクチャの一部です。
Steve Truckingでは、さらに難しくなります。ある小売パートナーが別のパートナーの配送や受取人を見ることは決してあってはなりません。同じ人が2つのパートナーの配送を受け取っていたら、業務ではそれらの関係を分けておかなければならない一方で、プライバシーのためには両方をまたいでその人を見つける必要があるかもしれません。セキュリティの境界を壊してプライバシーを解決しないでください。境界を守るためにプライバシーの請求を不可能にしないでください。アーキテクチャは両方をこなさなければなりません。
写真と自由記述もデータである
Section titled “写真と自由記述もデータである ”プライバシーを項目、つまり名前、メールアドレス、電話番号、住所として考えるのは簡単です。しかしSteve Truckingは年に何百万枚もの配送写真を撮っていて、その一部には人や家の中が写っています。構造化された項目だけを見る保持や消去のポリシーは不完全です。ファイル、文書、文字起こし、ログ、AIのプロンプトと応答を無視するポリシーもそうです。
そして自由記述は危険です。名前、電話番号、住所を取り除いたら、こんな配送メモが見つかります。「ジェーンに602-555-0198で電話すること。門の暗証番号は4821。庭に犬がいる。」 そこにあります。配送メモを機密として分類すれば、問題があるかもしれないとわかります。テキストの中の個人データを見つけて取り除いてはくれません。ときには、不要な個人の詳細がそもそもそこに着地しないようにするのが最善の答えです。まず個人データがどこへ行くかを管理しましょう。
Privacy Centerは道具であって、アーキテクチャのすべてではない
Section titled “Privacy Centerは道具であって、アーキテクチャのすべてではない ”SalesforceのPrivacy Centerは、こうしたプロセスを動かす助けになります。その忘れられる権利のポリシーは、削除したいものすべてを捉えるようにオブジェクトごとに作られ、特定の顧客レコードに対して実行されます（Delete Data with Right to Be Forgotten Policies (opens in a new tab)、英語）。役に立ちます。しかし「Privacy Centerを買ったので終わり」はアーキテクチャではありません。その人のデータは、どの一つの道具の手も届かない場所にあるかもしれません。Data 360、ウェアハウス、パートナーのシステム、アーカイブ、ログ、検索、ファイル、エージェントの会話。企業にはやはり企業としての答えが必要であり、それぞれの道具が実際に何をカバーしているかを、頼る前に確かめる必要があります。
ポータビリティと証明
Section titled “ポータビリティと証明 ”法律によっては、人が自分のデータのコピーを受け取る権利も定めています。同じ発見の問題であることに気づいてください。削除は**この人のデータはどこにあるか、それに対応するために？と問います。ポータビリティはそれはどこにあるか、提供するために？**と問います。どちらも、識別、分類、系統、システムの一覧、所有の上に成り立っています。
そして、それをやったことをどう証明するのでしょう？ 請求の受領、本人確認、検索したシステム、実施した対応、記録した例外、保持したデータの正当化、完了の記録。ここには本物の緊張関係があります。ある人の個人データを取り除きながら、請求を適切に扱ったことを示すのに十分な証拠は残しておくのです。だからこそ、アーキテクトが自分だけで保持のルールを発明すべきではないのです。どんな証拠を残さなければならないかは法務とコンプライアンスが決め、アーキテクチャは、取り除くはずだったデータを残すことなく、それを保持します。
試験の先へ：AIが変えること。 AIは新しい目的と新しいコピーを生みます。サービスを提供するためにデータを使う許可は、エージェントのグラウンディング、パーソナライズ、学習を自動的にはカバーしません。データ使用目的は、それらを区別するのに自然な場所です。そして個人データは、プロンプト、グラウンディングのコンテキスト、会話、要約、検索とベクトルのインデックス、ログの中に生き残ることがあります。AIの層がまだ覚えているなら、「元のレコードは削除しました」は完全な答えではありません。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- システムが、誰が、どのチャネルで、どの連絡先ポイントに、どんな目的で、に答えられるように、同意と許可された利用をどうモデリングするか。
- どのシステムが同意について権威を持ち、撤回がそれに基づいて動くすべてのシステムにどう届くか。
- 個人データがどこに広がり得るか：項目、自由記述、ファイル、履歴、分析、アーカイブ、連携、検索、AI。
- 請求が正しい人をどう見つけ、それぞれの場所で削除、非識別化、承認された保持をどう動かすか。
- 同意とプライバシーの請求が適切に扱われたことを証明するために、どんな証拠を残すか。
同意と消去は正反対に見えます（このデータを使ってよいか？ 使うのをやめて取り除けるか？）。しかし同じ土台の上に成り立っています。識別、目的、分類、系統、所有、強制、証拠です。標準の同意モデルを使い、個人データがどこへ行くかを管理し、コピーがどこにあるかを知り、最初の請求が届く前に消去のプロセスを設計しましょう。誰かが「私を忘れてもらえますか？」と尋ねたとき、アーキテクチャには「たぶん」よりよい答えが必要です。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforceヘルプ、Understand the Salesforce Consent Data Model (opens in a new tab)（英語）、2026-10-14確認。
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab)（英語）、第12条第3項、請求に対応する期限、2026-10-14確認。
- Salesforceヘルプ、Delete Data with Right to Be Forgotten Policies (opens in a new tab)（Privacy Center、英語）、2026-10-14確認。