この章は法律相談ではありません。実際にどのような義務が適用されるかは、管轄区域（jurisdiction）、対象となる組織・事業者、データの種類、契約内容、そして個別の状況によって異なります。組織固有の判断が必要な場合は、適切な法務・コンプライアンス担当者に確認してください。
ある日、次のような言葉が、いろいろな人から飛び込んできます。
- 「法律で保存が必要らしい」
- 「削除要求が来た」
- 「legal holdが掛かったらしい」
- 「契約上、削除が必要だ」
それぞれ、もっともらしく聞こえます。
しかし、実際にBackupやArchiveの扱いを変える前に、確認すべきことがあります。
「どのAuthorityが、誰に、どのデータについて、どの条件で、何を要求しているのか。」
この章では、この問いにどう向き合うかを整理していきます。
18.1 Retentionは技術だけでは決められない
Chapter 17では、Archiveのlifecycle managementの一部として、retention（保持）とdisposition（処分）という考え方に触れました。この章では、その先を考えます。
「どれくらい保持するか」「いつ削除してよいか」という問いは、技術的な設計だけで決められるものではありません。法律、規制、裁判所のルール、規制当局のガイダンス、契約、業界慣行、そして設計上の推奨事項が、それぞれ異なる形で関わってくる場合があります。
この章では、Archiveのlifecycle managementの中身そのもの（search/discoveryなど）を改めて扱うことはしません。それはChapter 17ですでに見たとおりです。この章で扱うのは、そのlifecycleに、法律や契約がどのような制約を与え得るかという点です。
18.2 AuthorityとScopeを分ける
まず大切な考え方があります。
Law/Regulation（法律・規制）、Court Rule（裁判所のルール）、Regulator Guidance（規制当局のガイダンス）、Contract（契約）、Industry Practice（業界慣行）、Design Recommendation（設計上の推奨事項）は、それぞれ別のものとして区別しておく必要があります。
これらは、似たような結果をもたらすことがあります。例えば、「このデータは削除してはいけない」という結論に、法律からたどり着くこともあれば、契約からたどり着くこともあります。しかし、結果が似ているからといって、その根拠となっているAuthorityの種類、適用範囲、強制力、例外の有無までが同じになるわけではありません。
この章では、この区別を一貫して保ちます。「契約だから、法律と同じくらい強い」「業界慣行だから、規制と同じように守らなければならない」といった単純化はしません。
18.3 Retention requirementを読むための7項目
「法律で保存が必要」「契約上削除が必要」といった話を聞いたとき、それをそのまま受け入れる前に、次の7つの項目を確認することが役立ちます。
- jurisdiction（どの国・地域の話か）
- applicable actor/entity（誰に適用されるのか）
- data / record category（どのデータ・記録の種類が対象か）
- trigger / condition（どのような条件で発動するのか）
- requirement modality（must なのか、may なのか、代替手段があるのか）
- version / effective date（いつの時点の規定なのか）
- exceptions（例外は何か）
保持期間だけを切り出して「〇〇は△年保存が必要」と語られる場合、これらの項目が欠けていると、実際には誤解を招く場合があります。
この7項目は、この本がここまでの調査を整理した実用的な確認リストであり、特定の法令や規格がこの形式で定めているものではありません。次の節以降で見る具体例も、実際にはこの7項目に沿って整理されています。
18.4 Legal HoldとPrivacy Erasure
ここで、よく聞かれる二つの言葉について整理しておきます。
Legal Holdとは、訴訟などに関連する情報について、保持義務に応じて通常のretentionやdeletionの運用を停止・変更し、必要な情報を保持するための実務上の対応を指す言葉として使われます。
米国の連邦民事訴訟規則（Federal Rules of Civil Procedure）第37条(e)は、訴訟の予測または進行の中で保持されるべきだった電子的に保存された情報（ESI）が、合理的な保持措置が取られなかったために失われ、かつ追加のディスカバリーによって復元・代替できない場合に、裁判所が是正措置や特定の制裁を科し得る条件を定めています。
ただし、ここで注意しておきたいことがあります。この規則は、「情報が保持されるべきだった」ことを前提としていますが、保持義務そのものを独立して生み出す、あるいはその全体を定義するものではありません。また、Legal Holdは「永久に保持し続けること」を意味するものでもありません。あらゆる紛争がLegal Holdを発生させるわけでもありません。この章では、Legal Holdが具体的にいつ始まり、いつ終わるのか、誰がそれを判断するのかといった、一般的な手続きの詳細までは扱いません。
Privacy Erasure（プライバシーに基づく消去）については、EUのGDPR（一般データ保護規則）第17条の例を見ておきます。GDPRの適用範囲内では、第17条(1)の要件のいずれかに該当し、かつ第17条(3)の例外が適用されない場合、管理者は不当な遅滞なく個人データを消去する必要があります。
ここで重要なのは、「削除要求が来たから、すべてのBackupコピーから即座に物理的に削除しなければならない」ということを、この条文だけから導き出すことはできないという点です。第17条(3)には、表現の自由、法的義務、公衆衛生、公共の利益のためのアーカイブ・研究・統計、法的請求への対応といった例外が定められており、これらの例外も、Backupの扱いを考えるうえで無視できない要素です。
18.5 Regulation / Guidance / Contractの具体例
ここまでの考え方を、いくつかの具体例で確認してみます。いずれも、特定の管轄区域・特定の対象者に限定された例であり、一般的なルールとして拡張することはできません。
HIPAA（米国） の例では、対象となるHIPAA covered entityまたはbusiness associateが、対象範囲内の electronic protected health information について、緊急事態などによるシステム損傷に備えたcontingency planningの一環として、取り出し可能な正確なコピーを作成・維持する手順と、データ損失から復元する手順を確立・実施することが求められる場合があります。ただし、これはすべての米国組織や、すべての種類のデータに当てはまるものではなく、一般的なBackup保持ルールでもありません。
SEC Rule 17a-4（米国） の例では、対象範囲内のbroker-dealerが電子的に記録を保存する場合、完全なタイムスタンプ付き監査証跡の方式か、書き換え・消去不能な方式かのいずれかを含む、代替手段が示されています。ここで注意しておきたいのは、この規則がWORM（Write Once Read Many）を一律に義務付けているわけではないという点です。あくまで、対象範囲内の特定の記録に関する、代替手段を含む要件です。
UK ICO（英国情報コミッショナー事務局） のガイダンスの例では、有効な消去要求があった場合でも、即座の上書きが常に可能とは限らないケースについて言及されています。その場合、データを「利用不可能な状態に置く」ことと、既存のBackupサイクル・スケジュールを通じて、いずれそのデータが置き換えられていくことを組み合わせる、という考え方が示されています。これは、英国の規制当局によるガイダンスであり、GDPR本文そのものではなく、Backupが一律に消去要求の対象外になるという意味でもなく、また、復元の際に消去されたデータを復活させてよいという意味でもありません。なお、このガイダンスはData (Use and Access) Actによる変更を受けて現在見直し中であり、今後改訂される可能性があります。
Google CloudのData Processing Addendum（契約） の例では、Agreementにこのアドエンダムが組み込まれている顧客について、契約期間中の削除、または契約終了時の返却・削除に関する取り扱いが定められています。この契約例では、最大180日以内の削除対応、そして既存コピーについては最大30日の復旧期間といった内容が含まれています。ただし、これはこの契約・このバージョンに固有の内容であり、法律ではなく、クラウド業界全体に共通するルールでもなく、Google Cloudのすべての顧客に自動的に当てはまるものでもありません。
18.6 Backup / Archiveへの影響
これらの例を踏まえると、Backup / Archiveの実務にとって重要な点が見えてきます。
まず、特定の規制対象となる電子記録には、単にコピーを保持するだけでなく、それ以上の保存properties（例えば改変不可能性や監査証跡）が求められる場合があります。ただし、これがすべてのArchiveやすべての業種に当てはまるわけではありません（SEC Rule 17a-4の例）。
次に、プライバシーに基づく消去要求は、Backupの扱いに影響を与え得ますが、それは「すべてのBackupコピーから即座に削除する」ことを自動的に意味するわけではありません。UK ICOの例で見たように、既存のBackupサイクルを通じた段階的な対応が、一つの現実的な選択肢として言及されています。
また、契約は、削除・返却・既存コピーの取り扱い・復旧期間について、独自の制約を課すことがあります。ただし、これは契約の当事者・範囲に限定されるものであり、法律でも、業界全体の慣行でもありません。
Archiveというラベルがついているからといって、それが自動的に「記録（record）」である、「証拠（evidence）」である、あるいは「法的に適合している」ということにはなりません。Archiveであることと、法的な要件を満たしていることは、別の問題です。実際にどのような要件が適用されるかを検討する際には、この章で見てきた7項目を確認することが重要な出発点になります。
18.7 要件が衝突するとき
ここまで見てきたように、Retention、Deletion、Legal Hold、Privacyに関する要求、契約上の要求は、それぞれ異なる、時には矛盾する結果をもたらす場合があります。
例えば、ある情報について、契約上は削除が求められている一方で、Legal Holdの対象になっている、という状況も考えられます。あるいは、Immutable（改変不可）な設定で保持しているデータに対して、有効な削除要求が発生する、という状況もあり得ます。
このような場合、どちらが優先されるかを、一般的なルールとして決めることはできません。実際にどの要求が優先されるかは、個別のケースによって異なり、この本ではそれを判断しません。
そのため、この本では、次のような主張は行いません。
- Immutableな設定が、常に優先される
- 削除の要求が、常に優先される
- Legal Holdが、常に他のすべての要求より優先される
- プライバシーに基づく要求が、常に保持義務より優先される
- 契約が、常に優先される
- 「法律 > 契約 > 社内ポリシー」といった、固定された優先順位が存在する
技術的な設計だけでは、どの法的・契約上の義務が優先されるかを決めることはできません。設計上できることは、これらの制約を把握したうえで、Immutabilityやretentionの設定を検討することまでです。
実務上の一つの心がけとして、Retention、Deletion、Restore、Archiveの扱い、Backupのlifecycleを変更する前に、次の項目を記録しておくことが役立ちます。
- 根拠となるAuthority
- 適用範囲（scope）
- 発動条件（trigger）
- 要求内容（requirement）
- 例外（exception）
- 判断を行う担当者（decision owner）
そのうえで、組織固有の適用可能性や、要求同士の衝突についての判断は、適切な法務・コンプライアンス担当者に確認することが望まれます。
18.8 まとめ
この章では、法律・規制・裁判所のルール・規制当局のガイダンス・契約が、Backup / Archiveにどのような制約を与え得るかについて整理しました。
重要なのは、次の点です。
- Law/Regulation、Court Rule、Regulator Guidance、Contract、Industry Practice、Design Recommendationは、それぞれ別のAuthorityの種類として区別する必要がある。似たような結果になっても、それらが同等になるわけではない。
- 「法律で保存が必要」といった話を聞いたときは、jurisdiction、applicable actor/entity、data/record category、trigger/condition、requirement modality、version/effective date、exceptionsの7項目を確認する。
- Legal Holdは永久保持を意味しない。すべての紛争がLegal Holdを発生させるわけでもない。
- プライバシーに基づく削除要求は、すべてのBackupコピーからの即座の削除を自動的に意味しない。
- 契約は独自の削除・保持ルールを課すことがあるが、それは契約の範囲に限定される。
- Archiveというラベルは、それだけで記録性・証拠性・法的適合性を証明しない。
- Retention、Deletion、Legal Hold、Privacy、契約上の要求が衝突する場合、どれが優先されるかを一般的なルールとして決めることはできない。技術的な設計だけでは、この優先順位を決められない。
この章で確認する代表的な観点
ここまでの内容を、簡単な表として整理します。
| Authorityの種類 | 何を制約し得るか | まず確認すべきこと | この章で使った例 |
|---|---|---|---|
| Law / Regulation | 保存・保護・手続きに関する要件 | jurisdiction・対象者・データ種別・条件・例外 | HIPAA、GDPR Article 17 |
| Court Rule | 訴訟に関連した保持・保存義務 | どの手続き規則か、どの条件で発動するか | FRCP 37(e) |
| Regulator Guidance | 実務上の対応方法についての解説 | 法令そのものか、規制当局の解説かの区別 | UK ICOのガイダンス |
| Contract | 削除・返却・復旧期間などの取り決め | どの契約が、誰に、どの範囲で適用されるか | Google Cloud Data Processing Addendum |
| Industry Practice | 一般的に行われている実務上の慣行 | それが法律や契約上の義務ではないことの確認 | （この章では特定の例は扱わない） |
| Design Recommendation | 設計上望ましいとされる考え方 | 権威ある法的根拠ではなく、推奨に過ぎないことの確認 | この章自体の7項目チェックのような整理 |
この表は、Authorityの種類を区別するための、この本での整理であり、優先順位や強制力の序列を示すものではありません。実際にどの要件が適用されるかは、必ず一次情報や専門家に確認する必要があります。
Chapter 18を読み終えた時点で考えてみてください
自分が担当しているシステムやデータについて、次の質問に答えられるでしょうか。
- 「法律で保存が必要」と言われたとき、それを鵜呑みにする前に確認すべき7つの項目は何でしょうか。
- Legal Holdが「永久保持」を意味しないのはなぜでしょうか。
- プライバシーに基づく削除要求が、すべてのBackupコピーの即座の削除を自動的に意味しないのはなぜでしょうか。
- Law/Regulation、Court Rule、Regulator Guidance、Contract、Industry Practice、Design Recommendationを、それぞれ別のものとして区別する必要があるのはなぜでしょうか。
- この章が、一般的な保持期間や、固定された優先順位を示さなかったのはなぜでしょうか。
答えに詰まった項目は、この章で再確認し、必要に応じて法務・コンプライアンス担当者に相談してください。