本人確認を終えたあと、身分証データはどうなるのか。流出時に責任を負うのは誰か

ディレクトリで本人確認が実際に稼働し始めると、もう大変な部分は終わったように感じられる。アップロード用のウィジェットは機能し、合格率と不合格率も妥当な数字で、重要な広告主はきちんと通過していく。しかしその時点で誰も教えてくれないのが、確認作業によって生み出された大量の書類データをどう扱うかという計画だ。本人確認システムは身分証を取り込んで消滅させるわけではない。顔写真と身分証明書の写真という二つの画像を生成し、どちらも誰かのサーバーのどこかに、誰も意図的に決めたわけではない期間にわたって存在し続けることになる。
これは本人確認そのものに反対する話ではない。その是非についてはすでに法律が結論を出しており、確認を省略することの方がはるかに高くつく失敗だ。ここで問題にしたいのは、緑色のチェックマークが表示された直後の部分である。2025年から2026年にかけて複数の企業を深刻に痛めつけたのはまさにこの部分であり、いずれの企業も本人確認自体を省略していたわけではない。彼らは確認作業自体は正しく行い、その結果生まれたデータをどこかに置いたままにして、最終的にそれを見つけるべきでない人物に見つけられてしまったのだ。
確認に通過しても、書類は消えるわけではない
広告主側から見ると、本人確認の流れは単純だ。自撮り写真を撮り、身分証を撮影し、数秒待てば承認される。しかしその裏側では、実際の画像データという成果物が生成され、アップロードフォームから照合エンジンへと送られ、結果とともに戻ってくる。この成果物を照合完了の瞬間に削除するのか、それとも一日、一か月、あるいは無期限に保存するのかは、設計上の判断だ。そして多くのシステムはデータを保持する方向をデフォルトにしている。なぜなら、決められたスケジュールで削除する機能は誰かが構築し維持しなければならないのに対し、何もしないことは無料だからだ。
このデフォルト設定がどれほどの代償を伴うかが明らかになったのは2025年7月のことだ。デート安全確認アプリTeaで発生した情報漏洩により、約72,000枚の画像が流出し、その中には2024年2月以前に提出された身分証明書と確認用自撮り写真、約13,000枚が含まれていた。Tea自身のプライバシーポリシーには、確認用の写真は使用後すぐに削除すると明記されていた。しかし実際には削除されていなかった。画像は保護されていないクラウドストレージのバケットに置かれたままになっており、それは製品が新しいシステムへ移行した後、誰も空にしに戻らなかった旧システムだった。
ここから得られる教訓はデート系アプリに限った話ではなく、確認処理をウィジェットの裏側で外部委託しているあらゆる事業に共通する仕組みの問題だ。プライバシーポリシーは約束であって、自社のインフラの実態を示すものではない。広告主が身分証をアップロードしてから、バックアップを含めそれに触れたすべてのシステムからそのIDが消えるまでの日数を正確に言えないのであれば、自社のポリシーが実際に何を意味するのかを本当に理解しているとは言えない。理解しているのは、ポリシーに何と書かれているかだけだ。
同じ年に起きた二つ目の事例は、この種の失敗が起こるもう一つの典型的なパターンを示している。機密性の高いデータを専用システムではなく汎用システム経由でやり取りしてしまうというものだ。Discordで2025年10月に発生した情報漏洩は、侵害を受けた外部のカスタマーサポート業者にまでさかのぼる。年齢確認の異議申し立て、アップロードされた身分証明書の写真を含む、が通常の苦情対応と同じチケットシステムを経由して処理されていたためだ。Discordは、氏名、ユーザー名、メールアドレス、一部の請求情報とともに、約70,000点の身分証画像と自撮り写真が流出したことを確認した。同社はその後、書類を一般サポート経由でやり取りする運用を完全に廃止している。
単独の身分証よりも、ディレクトリと紐づいた身分証の方が流出時の被害が大きい理由
身分証明書単体の流出でも、写真に写っている本人にとっては現実の問題だ。しかし、そのデータセットがそれをアダルト掲載サイトの確認済み広告主のものだとラベル付けしている場合、問題の性質はまったく異なる次元のものになる。そのラベル自体が損害だからだ。ラベルは、本人が公表することを選んでいなかった自分の人生に関する事実を付け加えてしまう。この組み合わせこそが、ありふれた情報漏洩の通知を訴訟に、あるいは記録に残っているいくつかの事例では、データを失った企業ではなくデータが流出した本人を標的にした恐喝に変えてしまうのだ。
規制当局はすでに、個々の写真やメッセージとは無関係に、こうした関連付けそのものを機微情報として扱っている。GDPR(EU一般データ保護規則)のもとでは、個人の性生活や性的指向を明らかにするデータは、処理するだけで格段に高い法的ハードルが課される特別カテゴリーのデータに分類される。ノルウェーのデータ保護当局は2021年12月、出会い系アプリGrindrに対して約650万ユーロの制裁金を科し、この決定は2025年の不服申立てでも維持された。理由は、ある人物がGrindrの利用者であるという単純な事実を広告パートナーと共有すること自体が、性的指向を明らかにしうると判断されたためだ。制裁金の適用にはメッセージや写真の流出は一切必要なく、利用者であるという事実そのものが機微情報だったのだ。
同じ論理は、ほぼそのままクラシファイド広告のディレクトリにも当てはまる。流出したデータセットが、自社プラットフォームの確認済み広告主のものだと示す身分証明書は、個人データに加えて、本人が公表に同意していない人生に関する推定事実を伴っている。情報漏洩をめぐるあらゆる責任フレームワークは、この組み合わせを小売業者からのカード番号の流出のような通常の漏洩よりも深刻なものとして扱う。これこそが、インターネットのこの領域における制裁金や訴訟が、多くの事業者が自分には関係ないと思い込んでいる情報漏洩の見出しよりもはるかに高額になる大きな理由である。
実務上、これは自社にとって十分なセキュリティとは何かという基準を変えるべき話であり、実際にファイルを保管しているのがベンダーであっても関係ない。パスワードのデータベースと、身分証明書とプラットフォームの会員資格を紐づけたデータベースとでは、求められる注意義務の水準が同じではなく、事故が起きた後に規制当局も記者も両者を同列には扱わない。何かが起きる前に、後者のカテゴリーには、現在の顧客データ全般に適用しているポリシーよりも高い基準を設けると決めておく価値がある。事故が起きた後というのは、その判断をうまく下せるタイミングではないからだ。
保存期間という罠、流出の有無にかかわらず保持していたこと自体が処罰の対象になる
TeaとDiscordの事例は、いずれも情報漏洩、つまり外部の攻撃者が何らかの行動を起こしたことを伴っている。一方でスペインのデータ保護当局は2026年3月、まったく別の経路から同じ結果に至ることを示した。専門の本人確認・年齢確認プロバイダーの一つであるYotiに対し、いかなる情報漏洩もないまま95万ユーロの制裁金を科したのだ。Yotiが処罰されたのは、単に誰にも求められないままデータを保持し続けていたこと、それ自体に対してだった。
この内訳は詳しく読む価値がある。どの項目も、明らかな不正行為ではなく、悪意のないごく普通の業務慣行を描写しているからだ。50万ユーロは、GDPRの特別カテゴリーに関する規則のもとで生体データがどう処理されていたかに関するものだった。20万ユーロは同意の設計に関するものだった。ユーザーはプライバシーポリシーの画面を一度も開かなくてもクリックして通過でき、チェックボックスを見つけて外さない限り、生体データを社内研究のために再利用されることにデフォルトで同意させられていた。残る25万ユーロは、過剰と判断された保存期間に関するものだった。位置情報データは、登録時にどの年齢ルールを適用するかを判定するという一度きりの役目を終えた後も5年間保持され、生体テンプレートはアカウントが有効である間、そして最後に利用されてからさらに3年間、保持され続けていた。
こうした保存に関する判断は、どれも一見もっともらしい理由を持っていた。ルールの再確認が必要になった場合に備えた位置情報、再訪した広告主を再確認する必要が生じた場合に備えた生体テンプレート、製品改善のための研究アクセス、といった具合だ。しかし、もっともらしく聞こえる理由と、明示された具体的な目的に紐づいた保存期間とは同じものではない。規制当局は、本人確認を正しく行うことを事業の中核に据えていたはずの企業を、この二つを混同したという理由で処罰した。Yotiはこの決定に対して不服申立てを行っており、2026年4月には申立ての審理が終わるまで執行が停止されたと報じられているため、この事例は決着済みの案件ではなく、現在進行中の警告として扱うべきだ。ただし、保存期間は利便性ではなく目的に基づいて設定されなければならないという論理そのものは、不服申立ての対象にはなっていない。
ここから導かれる実務上の教訓は言葉にするのは簡単だが、見落とされやすい。ベンダーとの契約書には、確認作業によって生成されるデータのすべてのカテゴリーについて、明示された目的に紐づいた保存期間を日数で明記させるべきだということだ。もしベンダーがその数字を書面で提示できないなら、ベンダー自身もそれを決めていないということであり、規制当局や、自分の身分証がどこへ行ったのかを尋ねる広告主に対して、両者ともそれを後から正当化することはできなくなる。
契約前に本人確認ベンダーへ実際に確認すべきこと
ほとんどの体制では、本人確認ソフトウェアを実際に運用しているのは自社ではない。それを行うのは専門のベンダーであり、これは正しい分業のあり方だ。実際に偽の掲載を見抜ける本人確認は、責任の重い専門領域であり、小規模なチームがゼロから構築すべき分野ではない。しかし、データ保護法のもとでは、確認を実施すると決めた運営者が通常は管理者(コントローラー)であり続け、ベンダーは処理者(プロセッサー)という位置づけになる。処理者のミスであっても、書類が流出した本人に対する責任は結局のところ管理者にのしかかる。だからこそ、こうした問いを投げかけるべき場所は、何か問題が起きた後に送るサポートチケットではなく、ベンダーとの契約書なのだ。
まず確認すべきは、その確認処理が合否と信頼度スコアだけを返す仕組みなのか、それとも実際の画像データが自社のインフラを一時的にでも通過し、そこに残るのかという点だ。書類を後で使うために保存するのではなく、同一のトランザクション内で照合と削除を完結させる、確認したらすぐ破棄するという設計を基本にしているベンダーであれば、信頼して繰り返し確認しなければならないポリシー上の約束ではなく、アーキテクチャそのものによってこのリスクの大部分を取り除いていることになる。
正確な削除までの期間を日数で、マーケティングページからの引用ではなく契約書に明記する形で求め、バックアップがどう扱われるかも確認すべきだ。稼働中のコピーは予定どおり削除しても、90日分のバックアップを保持しているシステムは、表向きの数字が何であれ、実質的には90日間の保存期間を持っていることになる。そして、まさにこのすき間こそが、Teaの画像が削除されたはずの期限を過ぎても生き残っていた場所だった。
ベンダー自身が情報漏洩を起こした場合、誰が誰に、何時間以内に通知するのかを確認すべきだ。規制当局への報告義務を負うのはベンダーではなく自社である可能性が高く、3週間後に知らされた漏洩について72時間以内の通知期限を守ることはできない。この答えは必要になる前に用意しておくとよい。それは決済プロバイダーが口座を承認する前にどのみち求めてくる資料とほぼ同じであり、一度書き出しておけば両方の目的を果たせる。自社が規制当局に対して負っている期限よりも短い契約上の期限をベンダーに課しておけば、自社の期限が切れる前に対応する時間を確保できる。
最後に確認すべきは、ベンダーが確認作業そのものを超えた目的、モデルの学習、他の顧客と共有する不正検知データベース、社内研究などのために、その画像をどう扱っているかだ。沈黙を答えとして受け入れるのではなく、明確な書面での可否を求めるべきである。デフォルトのオプトインという形を取った沈黙こそが、規制当局が詳しく調べるまでの間、Yotiの研究目的の同意設計をあれほど長く存続させてしまった原因だったからだ。
この四半期に実際にすべきこと
ここまでの話は、確認をおろそかにしていい理由にはならない。むしろ、データが自社とベンダーのシステムからどう出ていくのかについて、これまでどうデータが入ってくるかについて慎重にならざるを得なかったのと同じくらい、意図的であるべき理由だ。次に制裁金や情報漏洩の見出しで痛手を負う運営者は、身分証を一度も確認しなかった者たちではない。確認は正しく行いながら、その後どうなるのかを一度も尋ねなかった者たちだ。
今月まずやるべきことは、現在契約しているベンダーに対し、確認作業が生成するすべてのデータカテゴリーについて、保存スケジュールを書面で、「短期間」や「必要に応じて」といった形容詞ではなく日数で提示するよう求めることだ。もしその数字を提示できないなら、答えられないという事実そのものが重要な発見であり、それはどんなパンフレットよりも雄弁に、自社が抱えているリスクについて物語っている。
サポート担当者、異議申し立ての審査担当者、あるいは自分自身が、専用の確認パイプラインではなくメールや一般的なチケットシステムを通じて身分証の写真を受け取ってしまうようなワークフローがあれば、すべて閉じるべきだ。そのようなワークフローが自社の運用のどこかに存在しているなら、それはほぼ間違いなく最大の弱点であり、この業界における他の多くの改善策と違って、それを閉じるのに必要なのは実行するという決断だけで、コストは一切かからない。
次回の契約更新時には、最大保存期間と情報漏洩発生時の通知期限を書面で盛り込み、ベンダーのポリシーページだけでなく実際の運用状況を確認する予定を、四半期ごとに二回に一度、カレンダーに入れておくべきだ。契約した日に真実だった約束が、一年後も同じように真実であり続ける保証はない。2025年から2026年にかけて制裁金を科されたり情報漏洩を起こしたりした企業の多くは、そのことを自社の見直しからではなく、規制当局やハッカーから知らされる形で思い知ることになった。

