本人確認記録の保存要件と個人情報保護の設計

Q: 本人確認記録は何年保存する必要がありますか？

犯収法上、確認記録は原則として契約終了等の日から7年間の保存義務があります。取引記録も同じく7年です。起算日は確認を行った日ではなく契約が終了した日などであるため、契約終了イベントをシステムが把握できる設計になっていないと削除タイミングを正しく判定できません。

Q: eKYCの方式によって保存するデータは変わりますか？

変わります。写真つき身分証と容貌を送信する画像方式では、身分証画像・顔画像そのものが確認記録の一部になるため機微性の高いデータを7年保持します。マイナンバーカード方式（JPKI）では電子証明書の検証結果・シリアル番号・署名検証記録などが中心で、画像を持たない分だけ保存データの機微性を下げられます。

Q: マイナンバー（12桁の個人番号）は保存してよいですか？

いけません。マイナンバーカードを用いた認証と個人番号そのものの取得・保存は別の行為で、犯収法の本人確認を理由に個人番号を取得・保存することはできません。券面画像を保存する構成では、個人番号が記載された面を撮影させない、または撮影後にマスクする処理を設計に含める必要があります。

Q: 7年保存の義務と個人情報保護法の削除要請はどう両立させますか？

法定保存のためのデータとサービス運営に使うデータを分離し、法定保存側を業務システムから隔離するのが出発点です。その上で確認記録へのアクセス権限と目的を限定して閲覧ログを残し、保存時暗号化を前提にし、期限到来データの自動削除を実装します。画像を持たない方式を選ぶことが最も確実な保護策になる場合もあります。

本人確認は、確認が終わった時点で完了する業務ではありません。犯罪収益移転防止法（犯収法）は、確認した事実を記録として作成し、法定年限のあいだ保存することまでを義務づけています。一方で個人情報保護法は、不要になった個人データを持ち続けないことを求めます。本記事は、この逆向きの2つの要請をどう両立させるかを、システムの要件定義・見積もりの段階で決めるべき論点として整理します。自社開発の設計指針としてだけでなく、eKYCの導入を検討している事業会社の責任者が、ベンダー提案の抜けを見つけられるように構成しました。

この記事の要点

犯収法の確認記録・取引記録は、原則として契約終了等の日から7年間の保存義務があります。記載事項は施行規則で定められており、検査で提示できる形が必要です

保存する中身は本人確認の方式で変わります。画像方式は顔写真・身分証画像という機微データを7年抱え、JPKI方式は保存データの機微性を下げられます

マイナンバー（12桁の個人番号）そのものは取得も保存もできません。カード認証と番号の取得はまったく別の話です

「7年持て」と「不要なら消せ」の両立は、目的分離・アクセス制御・暗号化・削除の自動化で設計します

設計の肝は起算日です。7年の起算は確認日ではなく契約終了等の日なので、「契約がいつ終わったか」をシステムが知らないと削除設計が組めません

保存義務の基本: 確認記録は原則7年

犯収法の対象事業者は、金融機関だけではありません。古物商、宝石貴金属の取扱事業者、不動産関連事業者など、幅広い業種が対象になります。これらの事業者は、取引時確認を行ったら確認記録を作成し、原則として契約終了等の日から7年間保存しなければなりません。取引そのものの記録（取引記録）も同じく7年です。

システム開発の観点でまず押さえたいのは、これが「eKYCの結果画面のスクリーンショットを残しておけばよい」という話ではないという点です。確認記録には、確認した方法・日時・書類（または電子証明書）の情報・確認者といった施行規則で定められた記載事項があり、後日の検査で提示できる形で保存する必要があります。

つまり要件は2段構えです。ひとつは「記載事項をすべて満たす記録が生成されること」、もうひとつは「その記録が7年間、改ざんされず、必要なときに取り出せる状態で保管されること」。前者はアプリケーションの設計、後者はデータ基盤と運用の設計に落ちます。どちらかだけを満たしても義務は果たせません。

7年という期間の重さも、要件定義の段階で共有しておくべきことです。7年はシステムのリプレースを1回はまたぐ長さです。「現行システムで7年持つ」ではなく「次のシステムへ引き継げる形で7年持つ」を前提に、保存形式とエクスポート手段を決めておく必要があります。

何を保存するかは方式で変わる

保存すべきデータの中身は、採用する本人確認の方式によって大きく変わります。ここは方式選定そのものに跳ね返る論点です。

写真つき身分証+容貌の方式（現行ホ方式など。2027年4月に廃止）

送信された画像そのものが確認記録の一部になります。つまり、顔写真と身分証画像という機微性の高いデータを7年間保持する設計が必要になるということです。保存件数は月間の確認件数に比例して積み上がり、7年経つまで減りません。漏えい時の影響も、この保有量がそのまま被害規模になります。

マイナンバーカード方式（現行カ方式・JPKI。2025年6月の改正前は「ワ方式」）

保存するのは電子証明書の検証結果、シリアル番号、署名検証記録などです。券面画像や容貌画像を保持しない分、保存データの機微性を構造的に下げられます。2027年の犯収法改正でIC読み取り・JPKIへ寄せていく流れは、なりすまし耐性の観点だけでなく、保存設計の観点からも合理的です。改正後の方式構成は2027年施行後のeKYC方式一覧に、両方式の比較はeKYCとJPKIの違いに整理しています。

方式を問わない共通の注意

マイナンバー（12桁の個人番号）そのものは、犯収法の本人確認を理由に取得することも保存することもできません。マイナンバーカードを使った認証と、個人番号の取得は、法的にまったく別の行為です。券面画像を保存する構成を採る場合は、個人番号が記載された面を撮影させない、あるいは撮影後にマスクする処理を設計に含めることが必須になります。ここは実装の抜けが監査で真っ先に指摘される箇所です。

方式別の保存負荷の見え方

観点	画像方式（ホ方式など）	マイナンバーカード方式（JPKI）
保存する主なデータ	身分証画像、容貌画像、判定結果	証明書の検証結果、シリアル番号、署名検証記録
機微性	高い（顔画像・券面情報を7年保持）	相対的に低い（画像を持たない）
ストレージの増え方	件数×画像サイズで線形に増加	件数あたりのデータ量が小さい
漏えい時の影響	顔画像・券面情報の流出	影響範囲を限定しやすい
個人番号面の扱い	マスク・撮影抑止の設計が必須	券面画像を扱わなければ論点が発生しない

「保存義務」と「個人情報保護」は逆向きの力

ここに、この領域の設計上の緊張関係があります。犯収法は「7年持て」と言い、個人情報保護法は「利用目的に必要な範囲で、安全に管理し、不要になったら消せ」と言います。矛盾しているように見えますが、両立の原則ははっきりしています。

保存目的を分離する

法定保存のためのデータ（確認記録）と、サービス運営に使うデータ（プロフィール、取引履歴など）を分け、法定保存側を業務システムから隔離します。同じDBに同居させると、業務アプリケーションのあらゆる機能が最重要個人情報への到達経路になってしまいます。区画をどう切るかの具体的な構造はeKYCの証跡設計で扱っています。

アクセスを絞る

確認記録は、日常業務ではまず参照しないデータです。参照が発生するのは検査対応や調査といった例外事象に限られます。この性質を利用して、閲覧できる担当者と目的を限定し、アクセスのたびに記録を残します。「めったに開かない」データだからこそ、開いたこと自体が異常検知の材料になります。

暗号化と鍵管理を前提にする

とくに画像を保持する構成では、保存時暗号化を前提条件として設計します。「暗号化しているか」だけでなく、鍵をどこで管理し、誰が触れるのかまでを決めて初めて意味を持ちます。

削除を自動化する

「7年経ったら消す」を人手の運用手順に委ねてはいけません。7年後にその手順書が読まれている保証はどこにもありません。起算日をデータ自身に持たせ、期限到来で自動的に削除・棚卸しされる仕組みとして実装します。

そもそも持たない選択をする

最も確実な保護策は、機微データを保有しない方式を選ぶことです。JPKI方式を採れば、7年間守り続ける顔画像も券面画像も発生しません。守るコストと漏えいリスクを同時に消せる選択肢として、方式選定の段階で検討する価値があります。

設計の肝は起算日

削除の自動化を実装しようとすると、必ず起算日の問題に突き当たります。

7年の起算は確認日ではなく、契約終了等の日です。ここを取り違えると、削除設計そのものが成立しません。確認日起算だと思って実装すると、まだ契約が継続している顧客の確認記録を法定期間内に消してしまう事故につながります。

実務上の難所は、「契約がいつ終わったか」をシステムが知らないケースが多いことです。解約フローが別システムにある、そもそも明確な終了日の概念がないサービス設計になっている、休眠状態と解約が区別されていない、といった状況はよくあります。この場合、削除バッチを書く前に「契約終了イベントをどう定義し、どこから確認記録側へ伝えるか」を決める必要があります。

要件定義では、次の3点をセットで確定させてください。

契約終了に相当するイベントの定義（解約、期間満了、口座閉鎖など、サービスに応じた具体的な事象）
そのイベントを確認記録側のデータへ反映する経路（イベント連携か、日次のバッチ突合か）
起算日から7年経過を判定して削除する処理と、削除した事実の記録

見積もり・要件定義での落とし穴

ストレージコストの見落とし

画像保存型は、件数×7年で容量が積み上がります。サービス開始直後の容量ではなく、月間確認件数から7年分を試算して見積もりに含めてください。暗号化のオーバーヘッド、バックアップ、遠隔地レプリカまで数えると、当初の見込みの数倍になることもあります。見積書のどこを確認すべきかという観点はシステム開発の見積もりの読み方でも扱っています。

起算日の設計漏れ

前節のとおりです。「7年で削除します」と書かれた提案書を見たら、起算日を何と定義し、その情報をどこから取得するのかを必ず確認してください。ここが空白のまま進むと、削除機能が最後まで実装されないか、実装されても正しく動きません。

ベンダー任せの確認不足

eKYC SaaSを利用する場合、確認記録の保存責任を誰が負うのか（SaaS側か自社か）、解約時にデータをどう引き継ぐのかを契約前に確認する必要があります。SaaS側が7年保存を担う契約であっても、事業者としての法的責任がなくなるわけではありません。解約後に自社が記録を提示できない状態になれば、義務違反は自社に帰属します。

バックアップからの削除漏れ

削除バッチが本体データだけを対象にしていて、バックアップやレプリカに7年前のデータが残っている、というのは典型的な漏れです。削除の範囲定義には、バックアップ・レプリカ・キャッシュ・外部エクスポート先まで含めてください。

発注者向け: 保存要件の確認チェックリスト

本人確認機能を含むシステムを発注する、あるいはeKYC SaaSを選定する立場であれば、提案書・仕様書・契約書で次の点を確認してください。関連する選定観点はeKYCサービスの選び方20項目にもまとめています。

まとめ

犯収法の確認記録・取引記録は原則7年保存です。記載事項は施行規則で定められており、検査で提示できる形が求められます
保存する中身は方式で変わります。画像方式は顔写真・身分証画像という機微データを7年抱え、JPKI方式は保存データの機微性を下げられます
マイナンバー12桁の個人番号は取得も保存もできません。券面画像を扱う設計では個人番号面のマスク・撮影抑止が必須です
犯収法の「7年持て」と個人情報保護法の「不要なら消せ」は、目的分離・アクセス制御・暗号化・削除の自動化で両立させます
設計の肝は起算日です。7年は確認日ではなく契約終了等の日から起算するため、契約終了イベントの定義と連携を先に決めます
見積もりでは7年分のストレージ、削除機能の実装、SaaS利用時の保存責任と解約時の引き継ぎを漏らさず確認します

全体像をつかみたい方はeKYC完全マップ2026を、シリーズの読む順はeKYC・本人確認記事の全体目次を参照してください。

よくある質問

Q. 本人確認記録は何年保存する必要がありますか？

犯収法上、確認記録は原則として契約終了等の日から7年間の保存義務があります。取引記録も同じく7年です。注意すべきは起算日で、確認を行った日ではなく契約が終了した日などから数えます。そのため、契約終了イベントをシステムが把握できる設計になっていないと、削除タイミングを正しく判定できません。

Q. 確認記録には何を残せばよいですか？

確認した方法・日時・書類または電子証明書の情報・確認者など、施行規則で定められた記載事項を満たす必要があります。eKYCの結果画面を保存しておけばよいというものではなく、後日の検査で提示できる形式で、記載事項が揃った記録として保存することが求められます。

Q. eKYCの方式によって保存するデータは変わりますか？

変わります。写真つき身分証と容貌を送信する画像方式では、送られた身分証画像・顔画像そのものが確認記録の一部になるため、機微性の高いデータを7年間保持することになります。マイナンバーカード方式（JPKI）では、電子証明書の検証結果・シリアル番号・署名検証記録などが中心で、画像を持たない分だけ保存データの機微性を下げられます。

Q. マイナンバー（12桁の個人番号）は保存してよいですか？

いけません。マイナンバーカードを用いた認証と、個人番号そのものの取得・保存は別の行為で、犯収法の本人確認を理由に個人番号を取得・保存することはできません。券面画像を保存する構成では、個人番号が記載された面を撮影させない、または撮影後にマスクする処理を設計に含める必要があります。

Q. 7年保存の義務と個人情報保護法の削除要請はどう両立させますか？

法定保存のためのデータとサービス運営に使うデータを分離し、法定保存側を業務システムから隔離するのが出発点です。その上で、確認記録へのアクセス権限と目的を限定して閲覧ログを残し、保存時暗号化を前提にし、期限到来データの自動削除を実装します。そもそも画像を持たない方式を選ぶことが、最も確実な保護策になる場合もあります。

Q. 7年経過後の削除は手動運用でもよいですか？

推奨できません。7年後に運用手順書どおりの作業が行われる保証はなく、担当者もシステムも入れ替わっている可能性が高いためです。起算日をデータ自身に持たせ、期限到来で自動的に削除・棚卸しされる仕組みとして実装してください。削除範囲にバックアップ・レプリカ・キャッシュを含めることも忘れないでください。

Q. eKYC SaaSを使えば保存義務はベンダーが果たしてくれますか？

契約内容によりますが、事業者としての法的責任がなくなるわけではありません。確認記録の保存を誰が担うのか、解約時にデータをどう引き継ぐのか、検査時にどう提示するのかを契約前に確認してください。解約後に自社が記録を提示できない状態になれば、義務違反は自社に帰属します。

主な参考資料: 警察庁犯罪収益移転防止法の概要(JAFIC)、e-Gov 犯罪による収益の移転防止に関する法律、個人情報保護委員会個人情報保護法ガイドライン

TodoONada株式会社は、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。確認記録の保存設計、起算日を含む削除の自動化、既存システムの保存要件監査といったご相談にも対応しており、犯収法など業種ごとの本人確認要件の整理から、方式選定・開発・運用までワンストップで支援します。デジタル庁「デジタル認証アプリ」の利用申請・審査対応の伴走も可能です。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜です。まずはマイナンバーシステム導入支援からご相談ください。

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。