顧客データの削除をどこまで確認するか。画面から消えた後の設計

顧客データの削除を設計するとき、管理画面から顧客名が消えた状態だけを「削除完了」とするのは早すぎます。僕なら、本体、添付、検索用データ、バックアップを別々の対象として確認し、各対象に削除方法と完了条件を置きます。画面から見えなくなった時点で確認できるのは、利用者向けの表示が止まったことです。保存先全体の処理状況は、別に確かめる必要があります。

経営者が決める範囲は、どの状態まで到達すれば顧客へ「削除済み」と説明するのか、一部が失敗したときに誰が再開するのか、古いバックアップを復元したときに削除済みデータを戻さないか、という業務上の条件です。データベースの細かな命令は、その条件を実現する手段として開発担当者が詰めます。ただし、バックアップをどの時点で物理的に消せるかは採用製品によって違います。この違いを残したまま、ひとつの完了条件へまとめられるかが設計の要点です。

顧客データの削除設計は、画面ではなく保存先から始める

顧客レコードを起点にすると、削除対象をひとまとまりに見てしまいがちです。実際には、氏名や連絡先を持つ本体、アップロードされたファイル、検索を速くするために複製されたデータが別々の保存先で動くことがあります。バックアップには、日常の読み書きから離れた復旧用のコピーが保持されます。

保存先ごとに扱いが違うことは、特定製品の公式資料からも確認できます。2026年9月21日時点で、Google Cloudのデータ削除に関する公式資料は、日常の読み書きに使う稼働系と、障害復旧用のコピーを保持するバックアップ系を分けて説明しています。Google Cloud固有の仕様なので、自社サービスへのそのままの転用はできません。自社では「顧客という一件」を、実際にデータが存在する複数の保存先へ分解して洗い出します。

ここで「どのデータベースを使っているか」だけを聞いても足りません。顧客の識別子を手がかりに、本体から参照される添付は何か、別の検索基盤へ複製される項目は何か、どのバックアップに含まれるかを開発担当者に図か文章で示してもらいます。技術用語をすべて理解する必要はありません。削除対象の入口と出口を一人が説明できる状態が必要です。

この整理が経営会議と開発現場の間で止まるなら、経営と技術をつなぐ人がいないと、会議は決まらないで扱っているように、論点を経営判断へ翻訳する担当を先に決めるほうが進みます。削除命令を書く人と、完了条件を承認する人は同じでなくても構いません。

四つの対象を分けた削除確認表の記入例

削除確認表では、一件の削除依頼に対して、本体、添付、検索用データ、バックアップの四行を用意します。各行に持たせるのは、対象識別子、削除方法、完了条件、確認方法、未完了時の扱いです。顧客名だけを作業キーにせず、各保存先で同じ対象を追える識別子を置くことが重要です。

本体の行では、業務画面が参照する顧客レコードを対象にします。削除方法には、実際に消去するのか、まず利用停止状態にして後続処理を待つのかを自社仕様として書きます。完了条件は、本体を通常の参照方法で取得できず、その顧客を起点に新しい添付や検索用データが作られない状態です。「削除処理を受け付けた」は進捗として記録し、確認方法には対象識別子での再取得と後続処理の結果を残します。

添付の行では、契約書、画像、出力ファイルなど、本体から参照されるファイルを対象にします。保存場所とファイル側の識別子を確認表へ残し、本体の参照だけを切った状態と、添付ファイル自体の削除が終わった状態を分けます。削除に失敗した添付がある場合は、本体の行だけを完了にして全体を閉じません。再実行の担当と、確認できない間のアクセス制限を未完了時の扱いとして決めます。

検索用データの行では、検索基盤に複製された顧客情報を対象にします。2026年9月21日時点のElasticsearchのdelete by query公式仕様では、対象を検索してまとまりごとに削除し、処理結果に削除成功件数、失敗、競合などが返ります。再試行の上限に達して処理が止まる場合もあり、APIの受付時点では未完了が残り得ます。また、検索結果への反映に関係するrefreshの既定値はfalseです。Elasticsearch以外を使う場合は、その製品の公式仕様にある失敗の返し方と反映時点へ読み替えます。

したがって検索用データの完了条件は、処理応答を確認し、反映後に対象識別子で検索して結果がないことです。削除件数だけを合格条件にすると、そもそも対象件数の想定が違った場合を見落とします。期待した対象と処理結果を照合し、失敗や競合が残れば、その行は未完了として再開できるようにします。

バックアップの行は、ほかの三行と同じ日に物理消去できる前提を置きません。削除後に作られる新しいバックアップへ対象が入らないこと、削除前のバックアップがいつ、どの条件で失効するか、復元する場合に削除記録をどう再適用するかを書きます。完了条件は採用製品と自社の運用に合わせて定義し、分からない場合は「バックアップも削除済み」と言い換えず、未確認の条件として残します。

この四行があると、本体だけ終わった状態を「顧客には非表示、削除作業は継続中」と表現できます。経営者が見るべきなのは技術処理の細部より、どの行が未完了で、顧客への説明と復旧手順に何が影響するかです。

バックアップは削除期限より、復元時の再混入を確認する

バックアップには、稼働系とは異なる時間軸があります。2026年9月21日時点のGoogle Cloud公式資料では、稼働系から削除されたデータはその後バックアップへコピーされない一方、削除前に作成されたバックアップは所定の周期に従って期限切れになるため、削除の反映には遅れがあると説明されています。この説明から分かるのはGoogle Cloudでの扱いです。自社が契約・設定しているサービスについて、古いコピーの失効条件を個別に確認します。

もっと見落としやすいのは復元です。障害対応で削除前のバックアップを戻せば、その中に削除済みの顧客データが含まれる可能性を運用上の論点にしなければなりません。そこで削除台帳には、顧客を各保存先で追う識別子と、四行ごとの完了状態を残します。復元手順には、サービスを通常運用へ戻す前に削除台帳を再適用し、本体と添付を処理し、検索用データを作り直すか削除し、各行の確認をやり直す工程を組み込みます。

古いバックアップ自体に触れられない製品でも、復元後の稼働系へ削除記録を反映する手順は設計できます。この方法は、バックアップを改変できるという主張を含みません。一方、削除台帳が復元対象と同じバックアップにしか存在しなければ、どの顧客を再削除すべきか判別できません。台帳をどこに保持し、復旧担当がどう取得するかまでが確認対象です。

逆にSaaSを解約してデータを外へ出す場面では、ファイルを開けることと、添付・履歴・参照関係を使って業務を戻せることの違いを確認します。削除も書き出しも、元の画面が使えなくなった後に業務の意味を再現できるかが境界になります。

法的にいつ削除義務が生じるか、どの保存が許されるかは、個別事情を踏まえて専門家が判断する領域です。技術責任者は、専門家や経営者が決めた削除方針を各保存先の処理と復元手順へ落とし、実行結果を説明できる状態を担います。

全行がそろうまで、非表示と削除完了を分ける

複数の保存先を順に処理するときは、途中失敗が起こり得る前提で運用するほうが堅実です。2026年9月21日時点で、MicrosoftのCompensating Transactionパターンは、複数データストアにまたがる処理について、途中から再開できる進捗記録、再試行しても不整合を増やさない各処理、元の処理から補償処理までを関連づけた監査を示しています。同パターンは削除専用の製品仕様ではありませんが、四対象の削除ジョブを設計する際の根拠になります。

実務では、一部が失敗したら、完了済みの行を識別して未完了の行から再開します。同じ対象へ処理を再実行しても、別のデータを消したり、消したはずの情報を作り直したりしないことを開発担当者に確認します。確認表には対象別の進捗、失敗理由、最後に確認した結果を残し、後任者でも作業を続けられるようにします。

運用開始前に経営者が承認する条件は明快です。四対象の洗い出しが済み、各行の完了条件と確認担当が決まり、未完了時の顧客向け状態が決まり、復元手順に削除台帳の再適用が入っていることです。技術責任者がこの条件を説明できなければ、画面から消える機能はあっても、顧客データの削除設計はまだ完成していません。

判断の担当が曖昧な場合は、CTO代行を入れた後の意思決定を確かめる方法も役割分担の整理に使えます。削除の実装を開発会社へ任せても、完了条件を誰が承認し、失敗時に誰が継続を指示するかは自社側に残る判断です。

最初に一件の削除依頼を選び、四行の確認表へ実際の保存先と担当者を書いてみてください。空欄になった行は、画面から消えた後をまだ説明できない場所です。その空欄を技術責任者と埋め、復元しても再混入しないと確認できた時点を、自社の「削除完了」にします。