プライバシー法が設計を形づくる
ほかに 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コース第5章「データの品質とガバナンス」。各モジュールは単独でも読めます。 前へ：データを知る · 次へ：同意と忘れられる権利
このモジュールが答える問い： プライバシーと業界の規制は、Salesforceの設計に何を求めるのか？
オーストラリアで仕事をしていたとき、GDPRを聞いたこともないというアーキテクト志望の人たちにたくさん出会いました。ヨーロッパの人たちは、カリフォルニア、カナダ、ブラジルのプライバシー法を聞いたことがないことがよくあります。自然なことです。人は自分が働いている場所のルールを知っているものです。しかし、こうした法律は国境を越えて届き、どれもSalesforceについての法律ではないにもかかわらず、システムの設計を形づくります。だからデータアーキテクチャのコースに属するのです。
弁護士になる必要はありません。必要なのは、規制が次のことを変え得ると見抜くことです。データをどこに保存するか、何を集めるか、誰が見るか、なぜ使ってよいのか、どれくらいの期間保持するか、どこへ送るか、削除できるか、どんな履歴を残すか、そして後で何を証明できるか。それらは法的な問いであるだけではありません。データアーキテクチャの問いなのです。
このモジュールはアーキテクチャのガイダンスであり、法的助言ではありません。 どの法律が適用され、それが何を求めるかを決めるのは法務とコンプライアンスのチームです。アーキテクトはその要件を、強制できる設計にします。
法律は国境で止まらない
Section titled “法律は国境で止まらない ”まず最大の誤解から。「私たちはヨーロッパにいないので、GDPRは適用されない」。そうかもしれないし、そうでないかもしれません。GDPRの地理的適用範囲は、EU域内の人々に商品やサービスを提供したり、そこでの行動を監視したりする、EU域外の組織にも及びます（第3条、Regulation (EU) 2016/679 (opens in a new tab)、英語）。ですから、会社の本社がどこにあるかで問いは終わりません。顧客、従業員、データを持っている人々、システム、処理者はどこにいるのか？ データはどこへ移動するのか？ これもまた第4章の全体像です。データがどこへ行くのかを知らずに、よいプライバシーの判断は下せません。
知っておくべき規制
Section titled “知っておくべき規制 ”アーキテクトが知っておくべき名前と、それぞれが対象とするものです。これは見分けるための表であって、適用の判定表ではありません。これを読んで「カリフォルニアに顧客がいるので、要件Xが適用される」と判断しないでください。それは法務が判断することです。あなたの仕事は、システムが作られる前にその問いを立てられるだけのことを知っておくことです。
| 法律または基準 | 地域または対象 | アーキテクトが知っておくべき理由 |
|---|---|---|
| GDPR (opens in a new tab) | 欧州連合 | 個人データ、適法な処理、個人の権利、保持、移転、プライバシー・バイ・デザイン |
| CCPA（CPRAによる改正後） (opens in a new tab) | カリフォルニア州 | 企業が消費者について収集する個人情報に対する消費者の権利 |
| PIPEDA (opens in a new tab) | カナダ | 民間組織による個人情報の取り扱い |
| LGPD (opens in a new tab) | ブラジル | ブラジルの個人データ保護の一般法 |
| Privacy Act 1988 (opens in a new tab) | オーストラリア | オーストラリアのプライバシー原則のもとでの、組織による個人情報の取り扱い |
| HIPAA (opens in a new tab) | 米国の医療 | 対象となる文脈での保護対象保健情報 |
| PCI DSS (opens in a new tab) | 決済カード | 決済カードのアカウントデータの保護 |
| サーベンス・オクスリー法（SOX） (opens in a new tab) | 米国の上場企業 | 財務報告の背後にある統制と証拠 |
| COPPA (opens in a new tab) | 米国、オンラインの子ども | 子どもからオンラインで収集される個人情報 |
このリストは増えていき（米国では独自の法律を持つ州が増えています）、法律は変わります。だから、表を暗記してプライバシーのアーキテクチャを学んだと思ってほしくはないのです。名前を覚え、それから法律より長生きする問いを学びましょう。
法律に共通すること
Section titled “法律に共通すること ”細部は違っても、主要なプライバシー法は同じいくつかのことに繰り返し立ち返ります。そして、そのどれもがアーキテクチャに降りてきます。
権利。 人は自分のデータを見ること、訂正すること、削除すること、持ち出すことを求められます。カリフォルニア州とブラジルの法律では、データの販売をオプトアウトすることもできます。そうした請求の一つひとつが、その人のデータを、すべて見つけ出すことを意味します。
移転。 GDPRとLGPDは、個人データが自らの管轄の外へ出ることを規制し、移転先で十分な保護を求めます。PIPEDAは、第三者がデータを処理するとき、それがどこであっても同じ水準の保護を求めます。ここでもまたシステム全体像です。どの矢印が国境を越えているでしょうか？
侵害の通知。 個人データが漏えいしたとき、法律は当局に、ときには影響を受けた人にも、法律ごとに異なる期限内に知らせることを求めます。持っていると知らなかったデータについて通知することはできませんし、コピーを見つけられなければ、何が漏えいしたのかを言うこともできません。
説明責任。 コンプライアンスを示せなければなりません。何を、なぜ処理しているのかの記録、高リスクな処理についての影響評価、そしてGDPRとLGPDではデータ保護責任者。その記録を生み出すのはアーキテクチャです。
何が個人に関わるかから始める
Section titled “何が個人に関わるかから始める ”個人情報を守る前に、それを見つけましょう。明らかなものもあります。名前、自宅の住所、電話番号、メールアドレス。そうでないものもあります。位置情報、デバイスの識別子、IPアドレス、画像、行動データ、人に結びつけられ得るあらゆるもの。そして文脈が重要です。Steve Truckingの配送は、受取人の名前、住所、電話番号、配送メモ、写真を持っています。写真には玄関先の箱が写っているかもしれないし、人や家の中が写っているかもしれません。配送は業務データですが、その属性のいくつかは個人に関わるものです。だからモジュール3で項目を分類したのです。プライバシーは、何を持っているかを知ることから始まります。
それはどこにあるのか？
Section titled “それはどこにあるのか？ ”「Salesforceです」。おそらくSalesforceだけではありません。小売パートナーから来たのか？ Snowflakeにコピーされたのか、Data 360に取り込まれたのか、連携のログに書かれたのか、ユーザーがエクスポートしたのか、項目履歴に残っているのか、アーカイブされたのか、サンドボックスにコピーされたのか、パートナーに渡されたのか、エージェントの会話で使われたのか？ 個人データは広がります。ですから法務が「この人の情報をどこに持っているのか？」と尋ねたとき、「現在の値がどこにあるかはわかっている」は答えになりません。私がほしいのは全体像と系統、つまりコピーがどこへ行ったかです。
一つの電話番号、多くのコピー。プライバシーはコピーにも適用されます。
なぜそれを使ってよいのか？
Section titled “なぜそれを使ってよいのか？ ”データを持っていることと、それを使ってよいことは同じではありません。Steve Truckingが受取人の電話番号を持っているのは、今日の配送を調整するためです。だからといって、それがマーケティングのリストになるでしょうか？ なりません。法的根拠は法域と状況によって違い、それは法務が導きますが、アーキテクチャはその答えを運ばなければなりません。なぜそれが集められたのか、どんな利用が認められたのか、同意が必要だったのか、与えられたのか、撤回されたのか、そしてどのチャネル、どの連絡先、どの目的についてなのか。データを使う許可は、データとして表現できなければなりません。 ポリシーの文書は実行時に判断を下せないからです。次のモジュールでそれをモデリングします。
集めるものを減らすことはアーキテクチャ上の判断である
Section titled “集めるものを減らすことはアーキテクチャ上の判断である ”最も強いプライバシーの管理策の一つは、データを集めないこと、あるいは必要のない場所にコピーしないことです。Snowflakeは受取人の電話番号を必要としているでしょうか？ 分析には番地まで含めた住所が必要でしょうか？ サンドボックスに本物の配送写真が必要でしょうか？ この問いに答えるのに、エージェントは受取人の個人的な詳細を必要としているでしょうか？ 必要ないなら、最も強い管理策はそこに置かないことかもしれません。作らなかったコピーの一つひとつは、守る必要も、保持する必要も、削除する必要も、同意を追跡する必要も、監査する必要も、漏洩時に報告する必要もないものです。統制するのが最も安い機密データは、決してコピーしなかったデータです。
保持はモデルの一部である
Section titled “保持はモデルの一部である ”「とりあえず全部保持しておこう」も保持ポリシーです。悪いポリシーだというだけです。重要なデータについては、設計の時点で知りたいのです。どれくらいの期間、なぜそれが必要なのか。ある規制が最短期間を定め、別の規制が最長期間を定めているか。時計はいつ動き始めるのか。そして終わりに何が起きるのか。削除、アーカイブ、非識別化、そしてコピーはどこにあるのか？ 財務記録は決められた期間残しておかなければならないかもしれません。受取人の門の暗証番号は、配送から何年もたてば何の目的もありません。そうした判断は、データベースが大きくなるまで待ってはくれません。
匿名化、仮名化、暗号化、マスキング
Section titled “匿名化、仮名化、暗号化、マスキング ”「ジェーン・スミス」を7F92A1に置き換えます。ジェーンは匿名化されたでしょうか？ 別のテーブルにまだ7F92A1 = ジェーン・スミスとあるなら、そうではありません。それは仮名化です。直接の識別子は置き換えられていますが、別に保持されている情報を使えばデータを再び結びつけられます。そしてGDPRのもとでは、仮名化されたデータはやはり個人データです（第4条第5項）。匿名化はさらに進みます。データをもはや合理的にその人と結びつけられない状態です（前文第26項）。ですから誰かが「削除する必要はない、名前を取り除くだけでいい」と言ったら、注意しましょう。その人がまだ合理的に識別できるなら、その線は越えていません。結果が法律を満たすかどうかは法務が判断することです。アーキテクトの仕事は、システムが何をしているのかを正確に言うことです。再び結びつけられるのか、どんなキーが残っているのか、対応表はどこにあるのか？
言葉は正確に使いましょう。それぞれ違う問題を解くからです。暗号化は、権限のない開示からデータを守ります。権限のあるユーザーは復号できます。マスキングは、特定のユーザーや環境に見えるものを変えます。仮名化は、元に戻る方法を残したまま、直接の識別を切り離します。匿名化は、その人を識別する合理的な可能性を取り除きます。データを「個人に関わるもの」から外すのは、最後の一つだけです。
規制は要件になる
Section titled “規制は要件になる ”法務に権限セットを作るよう言われる必要はありません。それは線の私の側の話です。法務は「この種類の個人情報にアクセスできるのは、正当な業務上の必要がある従業員だけ」と言うかもしれません。そこで私が翻訳します。それは誰なのか、その種類をどう特定するのか、アクセスをどう付与するのか、異動したら何が起きるのか、連携はそれを読めるのか、エージェントは、エクスポートできるのか、そして誰が見たかをどう証明するのか？ オーナーがポリシーを決め、アーキテクトがそれを強制する。 法務とコンプライアンスが義務を確定し、データオーナーがビジネスのポリシーを決め、アーキテクトが強制を設計します。
規制から証拠へ：法務が解釈し、オーナーがポリシーを定め、アーキテクトがそれを機能させ、証明できるようにする。
そしてコンプライアンスは製品ではありません。「コンプライアンス：オン」を買うことはできません。暗号化は要件を支えることがあり、監査機能は証拠を提供し、保持のツールはポリシーを実行し、同意のデータは許可された利用を支えます。しかし機能をライセンスしても、アーキテクチャがコンプライアンスを満たすわけではありません。コンプライアンスは、人、ポリシー、プロセス、データ、管理策、証拠という設計全体から生まれます。Salesforceはその一部であって、すべてではありません。そしてポリシーが強制するほど重要なら、証明するほど重要かどうかも問いましょう。3月17日にこのレコードに誰がアクセスしたのか、誰がこの項目を変えたのか、あのエクスポートには何が含まれていたのか？ モジュール6で証拠を扱います。
プライバシーは全体像を変える
Section titled “プライバシーは全体像を変える ”Steve Truckingでは、受取人の個人データは3つのパートナー連携を通じて届きます。Salesforceは配送を動かすためにそれを必要とし、クルーはその一部を、自分の停車地について、その日だけ必要とし、Snowflakeは配送の分析をほしがり、財務は請求するのに十分な情報を必要としますが、クルーが見るものまでは必要としません。そして、ある小売パートナーが別のパートナーの受取人を見ることは決してあってはなりません。プライバシーが矢印を変えます。ある項目はSnowflakeに行かず、分析にはより識別しにくいバージョンが渡り、クルーは自分の停車地だけを見て、下流での保持は業務での保持と違ってきます。プライバシーの要件は全体像の図の隣に置かれているのではありません。図そのものを変えるのです。
規制より長生きする問い
Section titled “規制より長生きする問い ”規制は変わります。ですから機密のデータや規制対象のデータについては、長持ちする問いのセットを持ち歩きましょう。
- それは何か？ 個人、機密、財務、健康、決済、子ども、その他の規制対象のデータか？
- それはどこにあるのか？ すべてのコピー：連携、履歴、分析、アーカイブ、サンドボックス、ログ、AIでの利用。
- なぜそれを使ってよいのか？ どんな目的と法的根拠が当てはまるのか？ 同意は関わるのか？
- 誰がそれを使ってよいのか？ 人、システム、パートナー、連携、エージェント。
- どれくらいの期間保持するのか。 そして終わりに何が起きるのか？
- その人は、それについての権利を行使できるか？ 法律の定めに応じて、アクセス、訂正、削除、ポータビリティ、異議申し立て。
- 何が起きたかを証明できるか？ アクセス、変更、エクスポート、同意、削除、保持。
AIのガバナンスは法律になりつつある
Section titled “AIのガバナンスは法律になりつつある ”AIは、統制されたデータのもう一つの利用者を加えます。AIシステムはこのデータを使ってよいのか、何の目的で、グラウンディングとして、何と組み合わせて、出力で繰り返してよいのか、どこにどれくらいの期間ログを残すのか？ AIのガバナンスは、社内ポリシーから法律へと移りつつあります。欧州連合のAI法（Regulation (EU) 2024/1689 (opens in a new tab)、英語）は、その最初の広範な例です。それが何を求めるかはシステムと用途によります。アーキテクトにとっての方向ははっきりしています。AIはガバナンスの外にいるのではなく、統制されたデータのもう一つの利用者なのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 規制対象のデータや機密データが、全体像のどこで入り、どこにあり、どう移動し、どこにコピーされるか。
- アーキテクトが法律を解釈することなく、法務とコンプライアンスのポリシーを、強制できる要件にどう変えるか。
- 機密データを受け取るそれぞれのシステムが本当にそれを必要としているのか、それとも識別しにくいバージョンで十分なのか。
- 保持、削除、匿名化、仮名化、保護、証拠が、データのライフサイクルをどう形づくるか。
- 重要な管理策が実際に機能したことを示すために、どんな証拠がなければならないか。
規制は、その名前をスライドに載せてもアーキテクチャにはなりません。データがどう集められ、分類され、移動し、保護され、保持され、削除され、証明されるかを変えたとき、アーキテクチャになるのです。
さらに学ぶ
Section titled “さらに学ぶ ”- 各規制の公式の情報源は、上の表にリンクしています（2026-10-14確認）。
- Regulation (EU) 2016/679（GDPR） (opens in a new tab)（英語）：第3条（地理的適用範囲）、第4条第5項（仮名化）、前文第26項（匿名情報）。
- Regulation (EU) 2024/1689（AI法） (opens in a new tab)、EUR-Lex（英語）。