GDPRとデータ基盤設計――削除要請対応・同意管理のアーキテクチャ

GDPR対応のデータ基盤設計で最も重要なのは、「削除要請を受けた瞬間に、個人データがどのテーブル・どのカラムに点在しているかを即座に特定できる仕組み」と、「同意ステータスの変更がリアルタイムで下流システムに伝播する設計」の二つです。この二つを後付けで実装しようとすると、基盤を半分作り直すはめになります。GDPRは罰則が厳しく、最大で全世界売上高の4%という数字が独り歩きしていますが、本当に恐ろしいのは金額ではなく、対応不能な基盤を運用し続けるという技術的負債そのものです。

本記事では、データエンジニアとDPO(Data Protection Officer)が連携してGDPR対応のデータ基盤を設計するための具体的なアーキテクチャを、削除要請フロー・同意管理・保持期間管理・越境移転の四つの観点から解説します。SQL例とチェックリストも用意しましたので、自社基盤の監査にもご活用ください。

GDPRの基本とデータ基盤への要件

GDPR(General Data Protection Regulation、一般データ保護規則)は2018年5月に発効したEUの個人データ保護規則で、EU居住者の個人データを扱うすべての事業者に適用されます。日本企業であっても、EUからのアクセスがあるECサイトを運営していたり、EU拠点の従業員データを本社で集約していたりすれば対象となります。「うちはEUに進出していないから関係ない」と油断していると、越境データ分析の案件が一つ走った瞬間に対象になっていた、というケースは珍しくありません。

データ基盤設計の観点からGDPRが要求する主な権利は、アクセス権(第15条)、訂正権(第16条)、削除権(第17条)、処理制限権(第18条)、データポータビリティ権(第20条)、異議権(第21条)の六つです。これらの権利を「個別対応可能な粒度」で実装するには、データリネージ、マスタ管理、削除APIの三点セットが必要となります。個人情報保護法とあわせた包括的な設計については、D-06(個人情報保護法対応)もご参照ください。

GDPR条文	権利名	データ基盤への要件
第15条	アクセス権	ユーザーIDで個人データを全レイヤーから抽出可能
第17条	削除権	ソース→DWH→マート→BIの全層で削除/匿名化
第20条	ポータビリティ権	機械可読形式(JSON/CSV)でのエクスポート機能
第21条	異議権	処理目的別の同意フラグと停止APIの実装

削除要請(Right to Erasure)対応のアーキテクチャ

削除要請対応は、GDPR対応の中で最も技術的難易度が高い領域です。理由は単純で、データ基盤は「コピーを増やすこと」で分析価値を生み出す構造になっているため、削除は全層にわたる逆方向の伝播を要求するからです。ソースDBの一行を消しても、DWHのスナップショット、マートの集計、BIのキャッシュ、機械学習の学習データにまで個人データは散らばっています。

実装パターンは大きく三つあります。物理削除、ソフトデリート(論理削除)、匿名化(仮名化・ハッシュ化)です。現実的にはソフトデリート+下流マート再構築の組み合わせが主流で、削除フラグを立てた後に日次バッチで物理削除と匿名化が走る設計になります。A-10(データリネージ)で個人データの所在を特定できる状態にしておくことが前提条件です。

-- ソフトデリート実装例(Snowflake)
UPDATE raw.users
SET deleted_at = CURRENT_TIMESTAMP(),
    email = SHA2(email, 256),
    full_name = 'DELETED_USER_' || user_id,
    phone = NULL
WHERE user_id = :erasure_request_user_id
  AND deleted_at IS NULL;

上記SQLを実行しただけでは下流マートに古いデータが残るため、dbtモデルの再実行やStreamによるCDC伝播が必要になります。削除フローの全体像は次のようになります。

【削除要請フロー】

[削除要請受付] --> [本人確認] --> [リネージ検索]
                                      |
                                      v
                          [削除対象テーブル一覧生成]
                                      |
        +-----------------------------+-----------------------------+
        |                             |                             |
        v                             v                             v
  [ソースDB更新]              [DWH匿名化実行]              [BIキャッシュ削除]
        |                             |                             |
        +-----------------------------+-----------------------------+
                                      |
                                      v
                          [下流マート再ビルド] --> [完了報告]

※ 30日以内の対応が原則。リネージが整備されていない場合、この工程は人力となり期限超過リスクが急増する。

同意管理(Consent Management)の設計

同意管理は、CMP(Consent Management Platform)と呼ばれる専用ツールとデータ基盤を連携させる設計が一般的です。重要なのは、同意ステータスを「処理目的ごと」に管理することです。GDPRは「マーケティング目的」「分析目的」「パーソナライズ目的」などを個別に同意・撤回できる必要があります。一括で「分析に使ってよいですか」と聞いて一括でオプトアウトさせる設計は、規制違反と見なされます。

同意ステータスはバージョン管理し、過去のある時点でどの同意が有効だったかを再現できる必要があります。これは後から「この時点のデータを使って分析したのは不正処理だ」と主張された際に、同意があった証拠を提示するために不可欠です。D-08(権限管理)の設計と組み合わせて、同意ステータスをビューレベルで反映する構造にするのが理想形です。

カラム名	型	説明
consent_id	STRING	同意レコードの一意キー
user_id	STRING	ユーザーID(個人識別子)
purpose	STRING	処理目的(marketing/analytics/personalization等)
status	STRING	granted/withdrawn/expired
granted_at	TIMESTAMP	同意取得日時
withdrawn_at	TIMESTAMP	同意撤回日時(NULL可)
legal_basis	STRING	法的根拠(consent/contract/legitimate_interest)
version	INT	同意バージョン(文言改訂時にインクリメント)
source	STRING	取得経路(web/mobile/offline)

データ最小化・保持期間管理

GDPR第5条はデータ最小化原則を定めており、「処理目的に必要な最小限のデータのみを」「必要な期間のみ」保持することを要求します。データ基盤では「とりあえず全部取得して、使い道は後で考える」という収集方針が長年一般的でしたが、この考え方はGDPR下では通用しません。テーブル単位・カラム単位で保持期間を定義し、超過したデータは自動的に削除または匿名化する仕組みが必要です。

実装としては、各テーブルのメタデータに保持期間を登録し、日次ジョブで保持期間を超過したレコードを検出・処理するパイプラインが王道です。dbtのpost-hookやAirflowのスケジュールタスクで実装できます。ログ系テーブルは90日、取引履歴は7年、マーケティング行動履歴は2年、といった形で目的別に設定します。

-- 保持期間超過データの自動削除(BigQuery)
DELETE FROM `project.dataset.user_events`
WHERE event_timestamp < TIMESTAMP_SUB(
  CURRENT_TIMESTAMP(), INTERVAL 90 DAY
)
AND user_id NOT IN (
  SELECT user_id FROM `project.dataset.legal_hold_users`
);

上記の例では、90日を超えた行動ログを削除しつつ、訴訟などで削除が禁止されている「リーガルホールド」対象ユーザーは除外しています。保持期間管理とリーガルホールドの両立は忘れられがちなポイントですが、訴訟中にデータを自動削除してしまうと別のコンプライアンス問題(証拠隠滅)を引き起こします。

越境データ移転への対応

GDPRは「EU域外への個人データ移転」を原則禁止とし、例外として十分性認定・標準契約条項(SCC)・拘束的企業準則(BCR)などの法的枠組みを要求します。日本は2019年に十分性認定を受けているため、日本へのデータ移転は比較的スムーズですが、米国は2023年のData Privacy Framework発効後も依然として注意が必要です。データ基盤の物理配置を決める際に、この規制は避けて通れません。

実務では、EU居住者データを扱う分析基盤をEUリージョンに配置し、日本側のグローバル基盤とは集約済み・匿名化済みデータのみでやり取りする「EUファースト構成」が推奨されます。F-15(グローバルデータ基盤)で詳しく解説していますが、AWS・GCP・Azureそれぞれにリージョン別のサービス境界があり、選択を誤るとコストもガバナンスも崩壊します。

リージョン	移転可否	対応方針	代表サービス
EU域内	自由	原則EU域内に基盤を配置	Snowflake EU, BigQuery EU
日本	十分性認定あり	追加契約なしで移転可能	Snowflake JP, BigQuery Tokyo
米国	DPF認定枠で可	DPF非参加企業にはSCC必須	DPF認定ベンダー限定
その他	原則SCC	標準契約条項+移転影響評価	ケースバイケース

GDPR対応チェックリスト

以下のチェックリストは、データ基盤のGDPR対応状況を自己診断するためのものです。すべて「はい」と答えられる基盤は国内でも少数派ですので、現状把握の出発点としてご活用ください。D-14(コンプライアンス対応)ではより包括的な監査フレームワークを解説しています。

項目	確認内容	優先度
リネージ	user_idを起点に個人データの所在を追跡可能か	高
削除API	30日以内に全レイヤーで削除完了可能か	高
同意管理	目的別の同意ステータスをビューで反映しているか	高
保持期間	テーブル単位で保持期間を定義・自動執行しているか	中
越境移転	EU居住者データの物理配置を把握しているか	中
監査ログ	個人データへのアクセスログを1年以上保持しているか	中

まとめ

GDPR対応のデータ基盤設計は、法務要件と技術要件を同時に満たす稀有な領域です。削除要請を「面倒な事務作業」ではなく「基盤の健全性を測るストレステスト」と捉え直すと、自然とリネージ・同意管理・保持期間管理の三点が整備され、結果としてデータガバナンス全体の成熟度が上がります。罰金を回避するための守りの投資ではなく、データ活用の持続可能性を高める攻めの投資と考えるのが、現代的なアプローチです。

よくある質問

Q. GDPRの削除要請にはどう対応すべきですか?

データリネージで個人データの所在を特定し、ソース→DWH→マート→BIの全レイヤーで削除または匿名化を実行するパイプラインを構築します。30日以内の完了が原則のため、手動対応では間に合いません。ソフトデリート+日次バッチでの下流伝播が現実的な実装パターンです。

Q. GDPR対応でデータレイクは使えますか?

使えますが、削除要請への対応が課題となります。従来のParquetファイルは更新困難ですが、Apache Icebergのposition deleteやDelta Lakeのdelete文で特定レコードの削除が可能になりました。トランザクショナルレイクハウスを採用すれば、レイクの柔軟性を保ちつつGDPR対応が両立できます。

Q. 日本企業にGDPRは関係ありますか?

EU居住者のデータを扱う場合は関係します。ECサイトでEUからのアクセスがある場合や、EU拠点の従業員データを本社で集約している場合、グローバル顧客のサポート履歴を分析している場合などはすべて対象です。「EU進出していないから無関係」と決めつけるのは危険で、現代のSaaSビジネスでは多くの企業が無自覚にGDPR適用範囲に入っています。