auto-deletion-workflow

データ自動削除ワークフロー

概要

データ自動削除ワークフローにより、保存期間の満了時、または GDPR 第 17 条に基づく有効な消去請求を受けた際に、すべてのシステムから個人データが確実に削除されます。大規模な手動削除はミスが発生しやすく、保存制限の原則を一貫して満たせません。このスキルでは、連鎖する依存関係に対応し、参照整合性を維持し、監査に耐える確認ログを生成して、予定された保存期間の満了とオンデマンドの消去請求の両方を満たす、自動削除パイプラインを構築するためのアーキテクチャ、ロジック、運用手順を定義します。

法的根拠

GDPR 第 17 条第 1 項 — 消去権

データ主体は、不当な遅滞なく、自身に関する個人データの消去を管理者に求める権利を有します。また、指定された根拠のいずれかが適用される場合、管理者は不当な遅滞なく個人データを消去する義務を負います。

GDPR 第 5 条第 1 項（e）— 保存制限

個人データは、処理目的に必要な期間を超えて保存してはなりません。自動削除は、この原則を大規模に適用するための主要な技術的措置です。

GDPR 第 25 条第 1 項 — データ保護バイデザイン

管理者は、データ最小化などのデータ保護原則を効果的に実施するための、適切な技術的および組織的措置を講じなければなりません。自動削除は、バイデザインの中核となる管理策です。

GDPR 第 30 条第 1 項（f）— 消去予定時期

処理活動の記録には、可能な場合、データの各カテゴリの消去予定時期を含めなければなりません。自動削除システムは、これらの予定時期を実運用に反映します。

自動削除アーキテクチャ

削除トリガーの種類

トリガーの種類	発生元	SLA	優先度
保存期間の満了	保存スケジュールのメタデータが計算された削除日に到達	満了後 30 日以内	標準
データ主体による消去請求	DSAR ワークフローを通じて検証された第 17 条に基づく請求	請求の検証後、暦日で 30 日以内	高
同意の撤回	同意管理プラットフォームのイベント	30 日以内（ベストプラクティス：72 時間）	高
アカウントの閉鎖	顧客アカウントの終了イベント	保存スケジュールに従う（閉鎖後の保存期間）	標準
目的の達成	処理目的が達成され、さらなる法的根拠がない場合	目的の達成後 30 日以内	標準
リーガルホールドの解除	法務担当者による訴訟保全の解除	解除後 14 日以内	標準

システムアーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│                   DELETION ORCHESTRATOR                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │  Trigger      │  │  Dependency  │  │  Execution       │  │
│  │  Engine       │  │  Resolver    │  │  Engine          │  │
│  │              │  │              │  │                  │  │
│  │ - Scheduled   │  │ - FK mapping │  │ - System agents  │  │
│  │ - Event-driven│  │ - Cascade    │  │ - API calls      │  │
│  │ - On-demand   │  │   rules      │  │ - Direct DB ops  │  │
│  │ - Hold check  │  │ - Orphan     │  │ - File system    │  │
│  │              │  │   handling   │  │   purge          │  │
│  └──────┬───────┘  └──────┬───────┘  └────────┬─────────┘  │
│         │                 │                    │             │
│         └────────┬────────┘                    │             │
│                  ▼                             │             │
│  ┌──────────────────────────┐                 │             │
│  │  Deletion Job Queue      │─────────────────┘             │
│  │  (Priority-ordered)      │                               │
│  └──────────────────────────┘                               │
│                  │                                           │
│                  ▼                                           │
│  ┌──────────────────────────┐  ┌──────────────────────────┐ │
│  │  Confirmation Logger     │  │  Audit Trail Generator   │ │
│  │  - Per-system status     │  │  - Immutable audit log   │ │
│  │  - Completion timestamp  │  │  - Deletion certificate  │ │
│  │  - Verification hash     │  │  - Regulatory report     │ │
│  └──────────────────────────┘  └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

削除ワークフローの手順

ワークフロー 1：保存期間の満了に伴う定期削除

[Daily Retention Scan — 02:00 UTC]
         │
         ▼
[Query all records where calculated_deletion_date <= TODAY + 30 days]
         │
         ▼
[For each record approaching expiry]
   │
   ├── [Check: Active litigation hold?]
   │     ├── Yes ──► [Skip — log hold reference, notify Legal]
   │     └── No ──► Continue
   │
   ├── [Check: Active regulatory investigation?]
   │     ├── Yes ──► [Skip — log investigation reference]
   │     └── No ──► Continue
   │
   ├── [Check: Pending data subject request referencing this data?]
   │     ├── Yes ──► [Coordinate with DSAR workflow]
   │     └── No ──► Continue
   │
   ├── [Check: Retention exception approved?]
   │     ├── Yes ──► [Skip — log exception reference and expiry]
   │     └── No ──► Continue
   │
   ▼
[Add to deletion job queue with priority: STANDARD]
         │
         ▼
[On calculated_deletion_date: Execute deletion]

ワークフロー 2：オンデマンドの消去請求による削除

[Verified Art. 17 Erasure Request Received]
         │
         ▼
[Data Discovery — Identify all instances of data subject's data]
   │
   ├── Primary databases (CRM, ERP, HR system)
   ├── Data warehouse and analytics platforms
   ├── File storage (SharePoint, network drives, cloud storage)
   ├── Email and communication systems
   ├── Backup and archive systems
   ├── Third-party processor systems
   └── Logs and audit trails
         │
         ▼
[Generate Deletion Manifest]
   Reference: DEL-YYYY-NNNN
   Data Subject: [Pseudonymised reference]
   Systems identified: [List with record counts]
   Exceptions identified: [Any Art. 17(3) exceptions]
   Estimated completion: [Date]
         │
         ▼
[DPO Review and Approval]
   ├── Approved ──► [Add to deletion job queue with priority: HIGH]
   └── Exceptions found ──► [Partial deletion — exclude excepted data]
         │
         ▼
[Execute deletion across all identified systems]

ワークフロー 3：連鎖削除のロジック

プライマリレコードを削除する際は、関連システムにある依存レコードも削除する必要があります。連鎖削除リゾルバーは、参照整合性を処理します。

[Primary Record Identified for Deletion]
         │
         ▼
[Load Dependency Map for Record Type]
         │
         ▼
[Resolve Dependencies — Depth-First Traversal]
   │
   ├── [Level 0: Primary record]
   │     Example: Customer record in CRM
   │
   ├── [Level 1: Direct dependents]
   │     Example: Orders, support tickets, consent records
   │
   ├── [Level 2: Secondary dependents]
   │     Example: Order line items, payment records, shipping records
   │
   └── [Level 3+: Tertiary dependents]
         Example: Invoice line items, refund records
         │
         ▼
[For each dependent record]
   │
   ├── [Shared dependency?]
   │     (Record also linked to other primary records not being deleted)
   │     ├── Yes ──► [Nullify foreign key — do NOT delete]
   │     └── No ──► [Add to deletion manifest]
   │
   ├── [Legal retention override?]
   │     (Dependent record has its own statutory retention requirement)
   │     ├── Yes ──► [Anonymize link to primary record, retain dependent]
   │     └── No ──► [Add to deletion manifest]
   │
   └── [Aggregated/statistical record?]
         (Record contributes to aggregated reporting)
         ├── Yes ──► [Anonymize — remove personal identifiers, retain aggregate]
         └── No ──► [Add to deletion manifest]
         │
         ▼
[Execute deletion in reverse order (deepest dependents first)]
   Level 3+ ──► Level 2 ──► Level 1 ──► Level 0

依存関係マップのテンプレート

Orion Data Vault Corp 向けに、以下の依存関係マップが設定されています。

主要エンティティ	従属エンティティ	関係	削除アクション	保持期間の例外
顧客	注文	1:N	カスケード削除（法定保持期間の経過後）	6 年 — HMRC
顧客	サポートチケット	1:N	カスケード削除	3 年 — 時効期間
顧客	同意記録	1:N	カスケード削除	抑制記録を保持
顧客	マーケティング設定	1:1	カスケード削除	オプトアウト情報を抑制リストに保持
顧客	アカウント監査ログ	1:N	匿名化（顧客参照を null 化）	7 年 — 監査上の保持
注文	注文明細	1:N	カスケード削除	注文の保持期間に準拠
注文	支払い記録	1:N	匿名化	6 年 — 財務記録
注文	配送記録	1:N	カスケード削除	注文の保持期間に準拠
注文	請求書	1:N	匿名化	6 年 — 税務記録
従業員	給与記録	1:N	カスケード削除（法定保持期間の経過後）	6 年 — PAYE 規則
従業員	人事評価	1:N	カスケード削除	雇用期間＋6 年
従業員	アクセスログ	1:N	匿名化	2 年 — セキュリティ上の保持

確認ログ

削除確認記録の構造

削除を実行するたびに、不変の確認記録が生成されます。

DELETION CONFIRMATION RECORD — Orion Data Vault Corp
-----------------------------------------------------
Reference: DEL-2026-0142
Trigger: Retention expiry / Art. 17 request / Consent withdrawal
Data Subject Reference: DS-HASH-a3f8c2e1
Request Date: 2026-02-15 (if applicable)
Execution Date: 2026-03-14
Completed Date: 2026-03-14T14:23:07Z

SYSTEMS PROCESSED:
┌─────────────────────────┬──────────┬───────────────┬──────────────────┐
│ System                  │ Records  │ Action        │ Status           │
├─────────────────────────┼──────────┼───────────────┼──────────────────┤
│ CRM (Salesforce)        │ 1        │ Hard delete   │ Confirmed        │
│ ERP (SAP)               │ 47       │ Hard delete   │ Confirmed        │
│ Data Warehouse (BQ)     │ 312      │ Hard delete   │ Confirmed        │
│ Email (Exchange)        │ 23       │ Hard delete   │ Confirmed        │
│ File Storage (S3)       │ 8        │ Hard delete   │ Confirmed        │
│ Backup (Veeam)          │ N/A      │ Flagged       │ Pending (cycle)  │
│ Analytics (Mixpanel)    │ 156      │ Hard delete   │ Confirmed        │
│ Support (Zendesk)       │ 12       │ Hard delete   │ Confirmed        │
│ Audit Log               │ 89       │ Anonymized    │ Confirmed        │
│ Payment (Stripe)        │ 5        │ Anonymized    │ Confirmed        │
└─────────────────────────┴──────────┴───────────────┴──────────────────┘

THIRD-PARTY NOTIFICATIONS (Art. 19):
- Processor A (Analytics SaaS): Notified 2026-03-14, confirmed 2026-03-16
- Processor B (Email service): Notified 2026-03-14, confirmed 2026-03-15
- Processor C (Payment gateway): Notified 2026-03-14, pending

EXCEPTIONS APPLIED:
- Financial records (invoices): Anonymized, retained until 2032-03-14 (6-year statutory period)
- Audit log entries: Anonymized, retained until 2033-03-14 (7-year audit retention)

BACKUP DELETION:
- Backup system: Next full rotation cycle completes 2026-06-12
- Expected complete erasure from backups: 2026-06-12

VERIFICATION:
- Post-deletion scan completed: 2026-03-14T14:45:00Z
- Residual data found: None
- Verification hash: SHA-256:e3b0c44298fc1c149afbf4c8996fb924...

Executed by: Deletion Orchestrator v3.2 (automated)
Reviewed by: [DPO Name] (for Art. 17 requests only)

監査証跡の要件

1. 不変性：削除確認記録は、追記専用の監査ログ（書き込み専用ストレージまたはブロックチェーンにアンカーされたハッシュ）に書き込まれます。
2. 確認記録の保持：削除日から 3 年間（異議が申し立てられた場合にコンプライアンスを証明するのに十分な期間）。
3. ログに個人データを含めない：確認記録では、データ主体を仮名化された識別子のみで参照し、氏名、メールアドレス、その他の直接識別子は使用しません。
4. 検索可能性：記録は、削除参照、データ主体ハッシュ、トリガーの種類、システム、日付範囲で検索できる必要があります。

エラー処理と再試行ロジック

削除失敗の処理

失敗の種類	アクション	再試行	エスカレーション
システムが利用不可	再試行用にキューに登録	1 時間後、4 時間後、24 時間後に 3 回試行	3 回失敗した後、IT 運用チームに警告
権限が拒否された	エラーをログに記録し、手動レビュー対象としてフラグを設定	自動再試行なし	システム管理者にエスカレーション
参照整合性違反	依存関係解決機能に送信	依存関係を再解決して再試行	解決できない場合は DPO にエスカレーション
部分的な削除（一部の記録で失敗）	成功した削除をログに記録し、失敗した削除を再試行	3 回試行	IT + DPO にエスカレーション
サードパーティ処理者から応答がない	7 日後にリマインダーを送信	14 日後にフォローアップ	21 日後に DPO + 法務にエスカレーション
バックアップシステム — アクティブなバックアップから削除できない	次のローテーションサイクルの対象としてフラグを設定	バックアップのローテーションスケジュールを監視	90 日以内に完了しない場合は警告

ロールバックに関する考慮事項

削除は本質的に取り消せません。そのため、次の対応を行います。

1. 削除前のスナップショット：Art. 17 のリクエストでは、削除対象データの一時的な暗号化スナップショットを取得します。エラー訂正ができるよう、削除実行後 72 時間保持します。72 時間後に自動破棄します。
2. 段階的な実行：大規模な保持期間満了による削除（10,000 件超）は、1,000 件ずつバッチで実行し、バッチ間で検証します。
3. ドライランモード：新しい削除ルールはすべて、適用前に 30 日間ドライランモードでテストする必要があります。ドライランでは、実際の削除を実行せずに削除マニフェストと確認記録を生成します。

監視とレポート

主な指標

指標	目標	測定頻度
保持期限切れデータの削除完了率	期限切れから30日以内に99.5%	毎月
第17条の消去請求の完了率	30暦日以内に100%	請求ごと
平均削除実行時間	4時間未満（全システムを対象としたエンドツーエンド）	実行ごと
削除失敗率	0.5%未満	毎月
バックアップ削除完了率	バックアップのローテーションサイクル内に100%	ローテーションごと
サードパーティ処理者の確認率	14日以内に100%	通知ごと

四半期コンプライアンスレポート

自動削除システムは、以下を含む四半期レポートを生成します。

1. トリガーの種類別に削除されたレコードの総数（保持期限切れ、第17条、同意の撤回など）
2. SLA目標に対する削除完了率
3. 適用された例外（法的根拠の内訳を含む）
4. 削除の失敗と解決状況
5. サードパーティ処理者のコンプライアンス率
6. バックアップの削除状況と未処理項目
7. 傾向分析（データ量の増加、システムの対象範囲、パフォーマンス）