保存期間を過ぎた個人情報を破棄する

目標

保存期間表と保存命令をデータとして置き、期間が過ぎた個人情報を予行と実際の破棄に分けて消します。破棄証跡を残し、消された人の情報が本当に読めないこと、バックアップに何が残ったかまで確認します。

なぜ重要なのか

個人情報は、消さなくても事故、誤って消しても事故です。保有期間が過ぎたら遅滞なく破棄しなければなりませんが、紛争や監督機関の要求で保存命令がかかった案件は、期間が過ぎても消してはいけません。2つのルールがぶつかる場所を人の判断に任せると、毎回違うように処理されるので、判定を再計算できるデータにしておきます。特に、起算日1つで結果がまるごと変わります。請求の3年を事故日から数えるか終了日から数えるかによって、まだ保存すべき資料が数十件消えることがあり、その事故は消されたあとにしか現れません。採点ツールは、書き出された一覧を信用しません。契約・請求・ルールの表から直接計算し直して突き合わせ、破棄のあとには、バックアップから取り戻した連絡先が、バックアップ外のファイルにまだ残っていないかを調べます。

ステップ

/root/retention/gen_retention.pyを作成して実行し、/root/retention/ins.dbと書類・バックアップを作ります。契約120件、請求240件、個人情報360行、ルール4行、保存命令12件です。
起算日を旧バージョンのルールに変えると、さらに消される案件を/root/retention/basis_gap.csvに、5つの数字を/root/retention/basis.txtに書きます。
基準日時点で保存期間が過ぎた案件を、/root/retention/due.csvに書きます。保存命令はまだ見ません。
保存命令で除かれる案件を/root/retention/hold_excluded.csvに、最終対象を/root/retention/due_final.csvに書きます。
/root/retention/purge_plan.jsonに予行計画を出します。このステップでは何も消しません。
/root/retention/purge.pyを作成して実行し、計画どおりに消して、purge_logに履歴を残します。
/root/retention/purge_evidence.jsonに破棄証跡を出します。
バックアップに残った複製を/root/retention/backup_residual.csvに、報告書を/root/retention/retention_report.mdに書きます。

参考

判定ルール: 破棄対象は기산일 + 보존연수 <= sys_param.asof(プレースホルダーは起算日と保存年数です)の案件です。起算日が空の案件(まだ終了していない請求)は対象ではありません。
年単位の加減はdate.replace(year=...)で行います。2月29日は、その年になければ28日に下げます。
最終対象は、破棄対象からlegal_holdにかかった案件を除いたものです。
破棄は、subject表の行の削除と、その請求の書類ファイルの削除と、purge_logへの登録です。バックアップには手を付けません。
purge_logの列はsubject_type, subject_id, rule_kind, basis_date, expiry_date, purged_at, doc_pathで、最初の2列が主キーです。rule_kindはpolicyまたはclaim、doc_pathは契約なら空です。
ルールの計算を1か所にまとめておけば、ステップ3からステップ8まで、書き直さずに済みます。
基準日の確認: sqlite3 -readonly /root/retention/ins.db "SELECT * FROM sys_param;"
よくある間違いは、起算日が空の案件をずっと昔として処理すること、保存命令を期間判定より先に見ること、表の行だけを消して書類ファイルを残すこと、バックアップまで消してしまうことです。
このラボの人名・連絡先・住所はすべて合成です。保存年数のうち、法定の時効でない値は合成の社内規程であり、本文にそう書かれています。

契約と請求のスナップショットを作る

/root/retention/gen_retention.pyを作成して実行し、/root/retention/ins.dbと/root/retention/docs/、/root/retention/backup/2026-08-31/docs/を作ってください。契約120件、請求240件、個人情報360行、ルール4行、保存命令12件です。

表は6つです。請求の9件に1件ほどは終了日が空でなければならず(まだ終わっていない案件)、ルール表には、現在のルール(policy・claim)と旧バージョンのルール(policy_alt・claim_alt)が一緒に入ります。書類は請求ごとに1枚ずつ作り、バックアップのディレクトリにそのままコピーします。

起算日を変えると何が変わるか

旧バージョンのルール(policy_alt・claim_alt)では破棄対象だが、現在のルールではまだ対象でない案件を/root/retention/basis_gap.csvにsubject_type,subject_id,primary_expiry,alt_expiryとして書き、/root/retention/basis.txtにdue_policy=、due_claim=、due_policy_alt=、due_claim_alt=、extra_under_alt=を書いてください。

満了日は、起算日に年数を足した日です。timedelta(days=365*n)を使うとうるう年でずれるので、date.replace(year=...)を使ってください。起算日が空の案件は満了日がないので、primary_expiryの欄を空欄にします。

期間が過ぎた案件を抜き出す

基準日(sys_param.asof)時点で保存期間が過ぎた案件を、/root/retention/due.csvにsubject_type,subject_id,rule_kind,basis_date,expiry_dateとして、subject_type・subject_idの昇順で書いてください。保存命令はまだ見ません。

現在のルールは、契約がcontract_end基準で5年、請求がclaim_closed基準で3年です。終了日が空の請求は、時効が始まっていないので対象ではありません。空の日付をずっと昔で埋めると、進行中の請求がまるごと消えます。

保存命令がかかった案件を除く

破棄対象のうちlegal_holdにかかった案件を/root/retention/hold_excluded.csvにsubject_type,subject_id,hold_id,reasonとして、残りの最終対象を/root/retention/due_final.csvにdue.csvと同じヘッダーで書いてください。

保存命令は、期間判定のあとに適用します。順序を変えると、命令はかかっているがまだ期間が過ぎていない案件まで除外一覧に入り、数字がぼやけます。reasonは、legal_hold表に書かれた文言をそのまま使います。

消す前にまず計画を出す

/root/retention/purge_plan.jsonに、mode(dry-run)、executed(false)、asof、counts(policy・claim・files)、subjects(subject_type・subject_id・expiry_date)、files(消す書類のパス)を入れた予行計画を出してください。このステップでは何も消しません。

計画と実行を、同じコードの1つのフラグで分けると、いつかそのフラグが誤って入ります。計画をファイルとして出し、実行はそのファイルを読むようにすれば、人が確認する場所ができます。書類のパスは請求にだけあります。

計画どおりに実際に消す

/root/retention/purge.pyを作成して実行し、計画に書かれた対象のsubject行と書類ファイルを消して、purge_logに履歴を残してください。バックアップには手を付けません。

計画ファイルだけを信じて消すと、計画を作ったあとにかかった保存命令を見逃します。実行の直前にもう一度判定を行い、計画と違えば止めてください。表の行とファイルは一緒に処理する必要があり、purged_atは日付と時刻です。

破棄証跡を出し、復元できないことを確認する

/root/retention/purge_evidence.jsonにasof、purged(policy・claim)、files_removed、held_kept、pii_rows_left_for_purged、doc_files_left_for_purged、backup_copies_leftを書いてください。数字は、現在の状態を直接数えて出た値である必要があります。

証跡は文言ではなく、計算です。残っていてはいけない2つの数字(個人情報の行、書類ファイル)は0でなければならず、バックアップの複製数は0ではないはずです。その差が、ステップ8のテーマです。

バックアップに残った複製を明らかにして報告書を書く

消したのにバックアップに複製が残った案件を/root/retention/backup_residual.csvにsubject_type,subject_id,backup_pathとして書き、/root/retention/retention_report.mdに、## 무엇을 지웠나、## 기산일을 어떻게 정했나、## 보존 명령、## 남은 사본、## 재발 방지の5つの節を書いてください(見出しは順に、韓国語で「何を消したか」「起算日をどう決めたか」「保存命令」「残った複製」「再発防止」を意味する語です)。

バックアップのパスは、実際にファイルがあるものだけを書きます。報告書には、破棄件数、請求3年の根拠条文、どの日を起算日にしたか、保存命令で残した件数、バックアップに残った複製の話を、数字とともに入れてください。