消去の請求が来てから慌てない。利用停止・消去・代替措置・通知を分けて設計する

編集部の実務提案

まず請求の種類を切り分ける

本人からの請求には種類がある。開示、訂正・追加・削除、利用停止・消去、第三者提供の記録の開示。似ているが、要件も応じる内容も違う。本稿の主題は利用停止等、つまり個人データの利用の停止または消去である。ガイドラインは「消去」の意味を広く捉え、データを削除することに加え、削除に代えて当該本人を識別できないようにすることも含まれると整理している。

利用停止等が認められる事由は法律に列挙されている。目的外利用や不適正な利用、不正な手段による取得、不適切な第三者提供といった法違反の取扱いがあった場合に加え、事業者がその個人データを利用する必要がなくなった場合、漏えい等が発生した場合、本人の権利や正当な利益が害されるおそれがある場合にも、請求の対象になる。受付の段階で事由を特定することが、その後の判断の土台になる。

注意したいのは、請求の入口では本人は法律用語で話してこない、という当たり前の事実である。「やめたい」「消したい」「もう連絡しないでほしい」という言葉の背後に、利用停止なのか、消去なのか、単なる配信停止なのかが混在する。受付では、本人の言葉を制度上の請求に翻訳し、対象と希望を確認する聞き取りの設計が要る。

翻訳を誤ると対応もずれる。配信停止だけで済む話に全面消去で応えれば過剰になり、逆に消去請求に配信停止で応えれば不足になる。請求種別の切り分けは、法務の形式論ではなく、本人の意思に正確に応えるための実務の第一歩である。

また、開示請求と利用停止請求が同時に来ることもある。まず自分のデータの所在を開示で確認し、その結果を見て停止や消去を求める、という段階的な請求である。種別ごとに受付番号と期限管理を分けつつ、同一本人からの関連請求として束ねて見られる体制にしておくと、対応の齟齬が減る。

なお、保有個人データに当たらない情報、たとえば6か月以内に消去する予定の短期保存データなどは、制度上の対象外となる場合があることも、切り分けの知識として押さえておく。対象外であることと、任意で応じることは別の判断であり、後述する通知の場面で丁寧に説明する必要がある。

請求の種類は、対応部署の振り分けにも直結する。開示は情報管理部門、訂正はデータの発生源である業務部門、利用停止は法務と運用の協働、といった具合である。受付の時点で種別を正しく判定できれば、社内のたらい回しが減り、対応の初動が速くなる。種別判定の早さは、そのまま対応日数の短さになる。

出典：[1]

編集部の実務提案

受付と本人確認を先に設計する

請求の受付方法は、事業者があらかじめ定めて公表する事項である。ガイドライン（3-8-7）は、請求を受け付ける方法として、提出先、請求の方式、本人または代理人であることの確認方法、手数料の徴収方法を示している。受付窓口が決まっていない組織では、請求が現場のメールボックスに埋もれ、対応の遅れそのものが問題になる。

本人確認はバランスの設計である。確認が緩ければ、なりすましによる不正な消去や開示を招く。厳しすぎれば、正当な本人の権利行使を妨げる。事業者が定めた方法で本人または代理人であることを確認する、というのが制度の建て付けであり、確認方法は請求の種類とリスクに応じて段階を持たせて設計する。

代理人からの請求への備えも要る。本人が委任した代理人、未成年者や成年被後見人の法定代理人。委任状の確認や法定代理権の確認の手順を、請求が来てから考えるのでは遅い。受付のチェックリストに、代理権の確認資料と確認記録の残し方まで含めておく。

手数料も設計項目である。利用停止等そのものに手数料は通常かからないが、開示等では実費の範囲で手数料を定めることができる。金額と徴収方法を事前に定め、請求時に案内できる状態にしておく。費用の説明がないまま請求すると、別の摩擦を生む。

受付の記録は、その時点から始める。受付日時、請求の種別と対象、本人確認の方法と結果、対応期限。後の判断や通知の根拠はすべてここに遡る。記録のない対応は、監査や紛争の場面で「やったこと」を証明できない。受付票の様式を定型化し、担当者が変わっても同じ記録が残る形にする。

受付チャネルの多様化も課題である。ウェブフォーム、メール、電話、郵送。どの経路から来た請求も一元的に台帳へ集約されなければ、期限管理は破綻する。チャネルごとの一次受付ルールと、台帳への転記タイミングを決めておくことが、複数窓口の前提条件になる。

受付の公表は、ウェブサイトの個人情報の取扱いに関する公表事項に含めるのが一般的である。請求先の住所や窓口、様式の置き場所への導線を、利用者が迷わずたどれる形にする。公表していても見つけられない窓口は、実質的には存在しないのと同じである。利用者視点での導線確認を、公表内容の点検項目に加えたい。

出典：[1]

編集部の実務提案

該当性の判断。事由の確認と保存義務との衝突

請求を受けたら、まず請求が制度上の事由に当たるかを確認する。法違反の取扱いがあったのか、利用する必要がなくなったのか、漏えい等や権利侵害のおそれがあるのか。ガイドラインは、事由がある場合、違反を是正するために必要な限度で、遅滞なく利用停止等を行わなければならないとしている。「遅滞なく」と「必要な限度」の両方が、判断の物差しである。

実務で最も悩ましいのは、法令上の保存義務との衝突である。税務、会計、業法などで保存期間が定められた記録は、請求があっても直ちには消せない。この衝突は判断の放棄ではなく、後述する代替措置や、保存期間満了後の消去といった設計で処理する領域である。保存根拠を記録ごとに特定できるかどうかが、ここで効いてくる。

また、消去の対象範囲の線引きも判断である。本人のデータは、基幹システム、分析基盤、バックアップ、委託先、紙の帳票に散らばっている。請求の対象となる保有個人データの範囲を、データマップに基づいて特定する。全データの消去なのか、特定の利用目的に紐づくデータの停止なのかで、作業の範囲は大きく変わる。

判断には期限の意識も伴う。請求への対応は遅滞なく行うことが求められ、対応しない決定をした場合も含め、本人への通知も遅滞なく行う。社内の稟議や法務確認に時間を要する案件ほど、進捗の台帳管理と、節目での本人への中間連絡の設計が重要になる。沈黙の期間が、本人の不信を最も育てる。

該当しないと判断する場合の根拠整理も、判断の一部である。なぜ事由に当たらないのか、どの事実に基づくのか。通知で理由を聞かれたときに、整理された根拠がなければ説明できない。判断の記録は、対応する側を守るためのものでもある。

判断の権限も決めておく。現場の担当者が独断で可否を決めるのではなく、個人情報の取扱い責任者や法務の確認を経る経路を定める。ただし経路が長いほど遅延する。事由が明確な定型案件は現場で進め、衝突や例外のある案件だけを上げる、といったトリアージの基準を先に作る。

判断の過程では、事実確認の範囲を定めることも実務である。請求者が指摘する取扱いが実際にあったか、システムのログや委託先の記録で裏を取る。この確認を省くと、存在しない違反への対応や、実在する違反の見落としが起きる。事実確認の手順と、確認に使う証跡の種類を、判断チェックリストに明記しておく。

出典：[1]

編集部の実務提案

消去の実装。削除と識別不能化、派生データの扱い

消去の方法は1つではない。ガイドラインが示す通り、データを削除することのほか、当該本人を識別できないようにすることも「消去」に含まれる。統計化や匿名加工のように、個人との結びつきを断つ方法が選択肢になる場面がある。目的は本人の権利を守ることであり、物理的な削除だけが答えではない。

実装では、データの所在ごとに手順が違う。本体のデータベース、検索インデックス、キャッシュ、ログ、分析基盤への複製、機械学習の特徴量。主データだけ消して派生物が残れば、実質的には残存である。平時に用意したデータマップと系譜の情報が、ここでそのまま作業指示書になる。

バックアップの扱いは現実的な論点である。即時の書き換えが難しいバックアップについては、復旧時の再適用手順、つまりリストアした際に消去済みデータを再び消す仕組みや、バックアップ自体の世代管理での自然消滅を、方針として定めておく。方針がないと、消去したはずのデータが復旧で蘇る。

委託先のデータも忘れてはならない。自社の消去が完了しても、委託先に残っていれば請求に応えたことにならない。契約に消去の指示と完了報告の条項を含め、実行時には委託先からの完了確認を証跡として取得する。SaaSの場合は、管理画面の操作とベンダーの証明手段を事前に確認しておく。

利用停止と消去の使い分けも実装設計である。停止は、データは残るが使わない状態であり、再開の可能性や法的保存の必要がある場合に適する。消去は不可逆である。本人の請求の文言と事由に応じて、停止で足りるのか消去が必要なのかを決め、その判断を記録する。やり直しの利かない消去ほど、実行前の確認手順を厚くする。

実行後の検証までが作業である。消去対象の検索で残存がないか、停止対象が業務画面やバッチから参照されていないか。実行担当と検証担当を分け、検証結果を対応記録に添付する。消去は見えなくなる作業だからこそ、消えたことの確認方法を先に設計する。

消去の優先順位付けも実務の工夫である。公開状態にあるデータ、検索可能な状態のデータ、日常的に参照されるデータから先に処理し、参照頻度の低いアーカイブは計画的に処理する。リスクの高い所在から潰していく順序は、対応期間中の本人の不利益を最小化する考え方である。順序の根拠は対応記録に残す。

出典：[1]

編集部の実務提案

困難な場合は代替措置で権利を守る

利用停止や消去が困難な場合の扱いも、制度には用意がある。多額の費用を要する場合など、利用停止や消去を行うことが困難なときは、本人の権利利益を保護するために必要な代替措置を講ずることで足りるとされている。ガイドラインの例示では、保存期間の満了後に消去することを約束し、その旨を公表または通知することなどが挙げられている。

代替措置の要点は、「できない」で終わらせないことである。なぜ困難なのか、その間本人の権利をどう守るのか、いつ最終的に解消されるのか。この3点を設計し、本人へ説明できる形にする。たとえば、保存義務のある期間はアクセスを厳しく制限し、利用を当該目的だけに封じ、期間満了と同時に消去する、といった具体的な姿である。

代替措置は恒久化させない。満了後の消去は、台帳に期限付きのタスクとして登録し、実行を検証する。口約束のまま担当者が替われば、措置は消える。代替措置の台帳は、請求対応の記録と紐づけ、未完了の措置が一覧で見える状態を保つ。

また、困難さの主張は安易に使わない。費用がかかることと、多額の費用を要することは違う。通常の業務負担の範囲であれば、それは困難ではなく実施すべき対応である。判断の基準を内部で言語化しておかないと、現場の負担感で可否がぶれる。

代替措置を講じた場合も、講じなかった部分についての説明責任は残る。本人への通知では、実施したこと、実施しなかったこと、その理由と代替の内容を分けて伝える。伝達の丁寧さが、その後の紛争や監督当局への相談の発生率を左右する。

代替措置の設計は、システム側の事情と向き合う機会でもある。消去が困難な理由がアーキテクチャにあるなら、それは技術的負債の申告である。請求対応の記録に困難の理由を蓄積すれば、次期のシステム刷新で「部分消去可能な設計」を要件化する根拠になる。

代替措置の説明では、専門用語を避ける配慮も要る。「困難」の内実が費用なのか技術なのか、本人の日常の言葉に置き換えて伝える。代替措置は事業者の都合の言い訳と受け取られやすい領域であり、説明の透明さがそのまま受け止められ方を決める。具体的な時期と手段を示すことが、最低限の誠実さである。

出典：[1]

編集部の実務提案

通知と記録。対応したことを伝え、残す

対応が終わったら、本人への通知が要る。ガイドラインは、利用停止等を行ったとき、請求に応じない旨の決定をしたとき、請求された措置と異なる措置を取ったときに、遅滞なく本人へ通知することを求める運びを、法第35条第7項に基づいて整理している。やったことだけでなく、やらなかったことも含めて伝えるのが制度の姿である。

通知の内容は、実施した措置、対象範囲、実施日、問い合わせ先を具体的に書く。定型文だけで済ませず、その請求に即した範囲の特定を含める。本人が「自分の求めたことがどう扱われたか」を読み取れることが、通知の品質である。

記録は、受付から通知までの一連を残す。請求内容、本人確認、判断の根拠、実行の証跡、委託先の完了報告、通知の写し。これらが一式で残っていれば、後の監査、監督当局からの照会、本人の再請求にも一貫して対応できる。記録の保管期間とアクセス権限も、あらかじめ定めておく。

記録は改善にも使う。請求の件数、種別、対応日数、困難だった点。これらを定期的に集計すると、保存期間の設計の不備や、データマップの欠落といった構造的な問題が見える。請求対応はコストではなく、自社のデータ管理の監査結果として読むことができる。

なお、請求に応じない場合や異なる措置を取る場合、その決定に至る経路と承認者を記録することも重要である。対応しない判断ほど、後から検証される。判断の過程を残すことは、組織としての説明可能性を担保する。

通知と記録のタイミングを、案件管理の状態遷移として設計しておくと漏れが減る。受付、確認中、判断済、実行中、通知済、完了という状態を持ち、期限超過のアラートを出す。請求対応を個人のメールボックスの管理から、組織の案件管理へ移す発想である。

通知の手段にも設計が要る。本人が請求に使った経路へ返すのが原則だが、郵送や本人限定の方法が適切な場合もある。通知が届かないこと自体が二次的な問題になるため、送達の確認方法まで含めて決めておく。再請求や追加の問い合わせに備え、通知には案件番号と担当窓口を明記し、継続案件として扱えるようにする。

出典：[1]

編集部の実務提案

平時の備えが請求対応の速度を決める

請求対応の速度と正確さは、請求が来た日の頑張りではなく、平時の備えでほぼ決まる。第一にデータマップである。どのシステムに、どの個人データが、どの目的で、どれだけの期間保持されているか。この地図がなければ、対象の特定だけで日数が溶ける。

第二に保存期間の設計である。利用する必要がなくなったデータが請求の事由になる以上、保存期間を定めて平時に消している組織ほど、請求時の作業量は小さい。請求対応の負担は、保存期間管理の未整備さの遅延請求として現れる。期間の定めと自動消去の仕組みは、最も効果の高い備えである。

第三に手順と訓練である。受付票、判断のトリアージ、消去の作業手順、通知の文面。これらを文書化し、年に一度でも模擬請求で訓練する。実請求は待ってくれない。訓練で見つかる不備は、手順の側で直せるもののリストになる。

第四に、委託先と契約の棚卸しである。委託先の一覧と、消去指示への対応可否、完了報告の形式を平時に確認しておく。請求が来てから委託先の仕様を調べるのでは遅い。SaaSの解約時や移行時のデータ消去の扱いも、この棚卸しの対象に含める。

第五に、経営層への報告の設計である。請求件数と対応状況、困難事例、改善の進捗。個人情報の請求対応は、法務や現場だけの仕事ではなく、データガバナンスの健全性を示す指標として報告されるべきものである。報告の場があることで、平時の備えへの投資判断も通りやすくなる。

備えの到達点は、請求を「例外事象」から「定型業務」に変えることである。定型化された組織では、請求は慌てる理由ではなく、設計通りのフローが回る確認の機会になる。その状態を作ることが、本人にとっても、事業者にとっても、最も確実な保護になる。

出典：[1]