【ITニュース解説】The Deletion Layer — Or, "We Deleted It" and "We Lost It" Are the Same Sentence Until You Can Prove Which One Happened

現代のシステム開発において、「データを削除した」と自信を持って主張することは、実際には非常に難しい問題である。データが「削除された」状態と「紛失された」状態は、外部から見るとほとんど区別できないため、システム障害やセキュリティ監査、顧客からの問い合わせの際に「データは今どこにあるのか？」という質問に明確に答えられない状況が多々発生する。

多くの開発チームは、自らが管理するシステム上からデータが削除されたと信じて「削除しました」と回答する。しかし、現代のシステムではデータは一つの場所に集中しているわけではない。データベース、バックアップ、キャッシュ、レプリカ、検索インデックス、分析用のデータウェアハウス、機械学習モデルに利用される派生データなど、多岐にわたる場所に分散して存在しているため、一つのシステム上での削除が、データ全体の完全な削除を意味するわけではない。

このような状況は、システムの設計が不適切だったわけではない。長年にわたって多様な問題解決のために機能が追加され、システムが複雑化した結果、データが自然と分散するようになったのが実情である。「削除した」という意図的な行為と「紛失した」という偶発的な出来事は、外部から見ればどちらも「データが存在しない」という同じ結果しか示さない。この二つを区別できる唯一の証拠は、削除が行われる「前に」作成された記録だが、多くのチームはそのような記録を残していない。

データベースでデータを「削除する」という操作は、一般的にはそのデータへの参照（ポインタ）を解除し、そのデータが使っていた領域を「空き」としてマークする行為である。この時点では、物理的なデータそのものがすぐに消滅するわけではない。データは、データベースのページ内に残っていたり、変更履歴ログに存在したり、他のデータベースへのレプリカに残っていたりする。さらに、夜間のバックアップテープ、クラウドのコールドストレージ、キャッシュ、検索インデックス、過去に取り込まれた分析用データ、あるいは数値の羅列に変換された埋め込みデータストアなど、実に様々な場所に残り続ける可能性がある。

これらのデータが保管されている場所は、それぞれ独自のタイミングでデータを処理する。そのため、「このデータが完全に削除されるのはいつか？」という質問への正確な答えは、特定の日付ではなく、「プライマリデータベース、レプリカ、バックアップ、キャッシュ、派生データストア、そして外部ベンダーに存在する全てのコピーにおいて削除が完了する最も遅い時期」となる。多くのチームが「30日後に削除します」と回答するのは、多くの場合、最も早く削除が完了する部分（例えばアプリケーションの本番データベース）のことであり、バックアップなど、最も遅い部分での削除完了を指しているわけではない。アプリケーション上からデータが数秒で消えても、バックアップテープ上には数ヶ月間残り続けることがある。これは、「削除された」と「完全に破壊された」という言葉が持つ意味の違いであり、この違いこそが根本的な問題なのだ。

外部から見たデータの消失には、「ポリシーに基づく削除」「保持期間切れによる自動消去」、そして「システム障害や移行による紛失」の三つの形がある。これらのどれもが最終的には「データがない」という結果をもたらすため、単にデータがないという状況だけでは、どのケースが発生したのかを証明できない。意図的に適切にデータを削除したチームでさえ、その証拠がなければ、「紛失した」チームと同じ立場に立たされ、紛争において不利になることが多い。

この問題を解決するには、「より多くのデータを保持する」ことではない。ほとんどの法規制では無制限のデータ保持は認められておらず、セキュリティリスクも増大し、顧客への約束とも矛盾する。真の解決策は、「削除」という行為自体を、後からその事実を証明できる「イベント」として記録することにある。

データの削除は、まるで証明書の失効プロセスと似ている。証明書を失効させた場合、問題は「誰がまだその証明書を信頼しているか、そしていつまでか」となる。同様に、データを削除した場合も「どのコピーがまだそのデータを保持しているか、そしていつまでか」が問われる。情報の伝達遅延や、システム全体での把握の難しさといった点で共通の課題がある。

この類似性は解決策にもつながる。まず、削除を行う「前に」、どこにデータが保存されているかをすべて特定し、列挙する必要がある。次に、削除を各システムに「意図的に伝播」させる。キャッシュの有効期限（TTL）のような自動メカニズムに任せるだけでは不確実性が残る。そして、システムの末端（エッジ）で「検証」を行う。単にAPIがエラーを返すかどうかではなく、派生データストアへの問い合わせが実際にゼロ件を返すことを確認する。この検証は、削除処理とは独立したシステムによって、削除側の前提に依存しない形で行われるべきだ。

「この特定の記録をどのシステムが保持していたか、そのうちどのシステムがゼロであることを確認したか、そしてそれがいつ確認されたか」という質問に正確に答えられるチームは、残念ながらごく少数である。

そこで提案されるのが「削除レシート」の作成だ。これは、削除処理が実行される「前に」、削除イベントごとに作成される記録である。削除レシートには、以下の項目を含める。

• 削除対象（What）: 削除対象のデータ本体を保持する代わりに、そのデータのハッシュ値（一方向の暗号化された指紋）を記録する。これにより、データを識別しつつプライバシーを守れる。
• 削除場所（Where）: データが格納されていた全てのストアの名前を具体的に列挙する。これにより、「削除しました」という漠然とした主張を、具体的な場所を挙げた証明可能な主張に変える。
• 削除日時（When）: UTC時刻で記録し、その削除の根拠となったポリシーの基準も併記する。これにより、削除が計画的かつポリシーに基づいていることを証明できる。
• 削除方法（Method）: 行の削除、暗号によるデータ破壊、媒体の物理的破壊など、削除の強度を示す具体的な方法を記載する。
• 検証（Verification）: 削除後に実行したクエリと、その結果、およびタイムスタンプを記録する。これは「本当に削除されたか」を証明する最も重要な証拠となる。
• 承認者と理由（Who / why）: 削除を承認した人物や、適用されたポリシーの条項を記録する。これにより、削除が個人的な判断ではなく、組織的な決定に基づいていることを示す。

この削除レシートにおいて、データのハッシュ値は非常に重要な役割を果たす。ハッシュ値は、元のデータを読み取ったり、再構築したり、悪用したりすることはできない。しかし、将来的にそのデータが発見された場合に、それが削除されたはずのデータと同一であることを比較によって証明できるのだ。これは、「このデータはかつて存在し、このハッシュ値を持つデータとして私たちが管理していたが、削除された」という事実を証明するための、最小限のデータ保持である。つまり、「何も残っていない」ことを証明するために、必要最小限の痕跡を保持する、という考え方だ。

ここで一つ、受け入れがたい現実がある。それは、「何らかの記録を残さなければ、削除を証明することはできない」という点だ。削除を証明するための記録自体も、ある種のデータである。「私たちは何も保持しません」という姿勢ではなく、「私たちは、残りのデータがなくなったことを証明できる最小限のものを保持します」と正直に述べ、その事実を記録しておくことで、将来的にその記録が発見された際に、それが意図的な行為であり見落としではないことを説明できるようになる。

削除が特に困難になるケースもいくつかある。 一つ目は「バックアップ」だ。プライマリデータベースからデータを削除しても、バックアップチェーンには影響しない。多くのバックアップシステムは、セット全体を書き換えずに個別のレコードだけを削除することはできない。この場合、そのレコードが将来復元されないようにマークし、バックアップセットが期限切れになる日付を削除レシートに記載するべきだ。つまり、「削除しました」ではなく、「本番環境からは直ちに削除されましたが、当該バックアップセットが期限切れとなる2027年3月1日以降に復元不可能になります」という具体的な表現が、法的に防御可能な説明となる。 二つ目は「派生データ」だ。集計データや機械学習モデルの埋め込みデータなどは、元のレコードを直接含まず、行ごとに削除できない場合が多い。これらの派生データが個人データとみなされない理由を明確に説明できるか、あるいはできないかで対応が変わる。もし個人データとみなされるなら、削除の範囲に問題が生じ、技術的な解決だけでは不十分となる。どちらのケースであるかを文書で明記する必要がある。 三つ目は「法的保持（Legal Hold）」だ。これは、「削除を停止できる」という能力があるだけでなく、「削除を停止できることが証明されている」という要件である。スケジュールに基づいて自動で削除を行うポリシーは、それを一時的に中断できるメカニズムが実際に機能すると証明されている場合にのみ安全だ。テストされていない中断機能は、テストされていないバックアップと同じで、単なる「信じ込み」であり、実証された「能力」ではない。

より実践的なアプローチとして、例えば「金曜日の午後」に試せる手順がある。まず、顧客に削除を約束している特定のデータクラス（例：閉鎖されたアカウント情報）を一つ選ぶ。そのデータクラスのサンプルデータを一つエクスポートし、ファイル名に日付を付けてハッシュ値を計算し、そのハッシュ値をデータがあった場所の記録として保存する。次に、そのデータのコピーを保持していると「確信している」だけでなく、「具体的に名前を挙げられる」全てのデータストアをリストアップし、その数を記録する。自分が管理できるストアからはデータを削除し、管理できないストアについては、そのコピーがいつ期限切れになるかを正確な日付とともに削除レシートに記録する。派生データストアに対してクエリを実行し、その結果を記録する。もしクエリを実行できないなら、それ自体が重要な発見点となる。最後に、バックアップの有効期限をカレンダーに登録する。その日付こそが、「データが完全に削除された」という主張が真実となる日である。

この作業は、一つのデータクラスにつき半日程度で完了するだろう。その成果として得られるのは、「この記録は本番環境からこの日付に削除されました。バックアップ内のコピーはこの日付に期限切れとなります。そして、その両方を証明するハッシュ値はこれです」という、誰に検証されても自信を持って答えられる説明だ。

最後に、不安になるかもしれないが、非常に重要な点がある。データの削除ポリシーは、迅速な削除から利益を得る部門（ビジネス部門など）によって作成され、証拠の保持から利益を得る部門（法務部門やセキュリティ部門など）によって実施されることが多い。これらの部門は通常、組織内で別々に存在し、めったに直接会うことがないため、結果として、慎重であるべき場所では迅速に、迅速であるべき場所では遅いという、矛盾したポリシーができあがってしまう。

この非対称性も重要だ。あなたを告発する側は、ほとんどの場合、データ保持期間の制限を持たないが、あなたのシステムはほとんどの場合、保持期間の制限がある。これは、紛争が発生した際に、残存する記録が訴える側の主張に有利になることを意味する。このような非対称性を是正できる唯一の手段は、証明可能な削除を行うことである。それは、何も問題がない通常の日に行われる、地道で退屈な作業だが、将来的なリスクから組織を守るために不可欠なのだ。誰も問題視していないときに作成した記録こそが、いざという時にあなたを救う唯一の証拠となる。