eKYCの証跡設計。PII Vaultと監査ログ

Q: eKYCで取得した画像や個人情報はどう保存すべきですか？

性質の異なるデータを1つのDBに混ぜず、業務DB（セッション状態と参照IDのみ）、PII Vault（個人情報の実体）、Evidence Store（確認の証拠）、監査ログ（アクセスの記録）の4区画に分けるのが基本です。業務DBには個人情報の実体を持たせないことで、漏えい時の影響範囲と内部不正の機会を最小化できます。

Q: eKYCの監査ログには何を記録すべきですか？

処理の証跡（確認セッションの状態遷移・判定の入力と結果・外部プロバイダの応答）と、閲覧の証跡（誰がどの画像・属性を表示したか）の2種類を区別して記録します。閲覧の証跡は内部不正対策の本丸で、これがないと審査担当者が全ユーザーの画像を無記録で見られる状態になります。

Q: 本人確認記録の保存期限が過ぎたデータはどう削除すべきですか？

データ分類ごとの保持期間表を固定し、期限到来データを削除する定期バッチを用意します。削除範囲にはバックアップ・レプリカ・キャッシュまで含め、削除した事実の記録（削除証跡）を監査ログに残します。訴訟・調査対応で保全が必要なデータを除外するリーガルホールドの仕組みも必要です。

Q: eKYCのSaaSを使う場合もデータ設計の確認は必要ですか？

必要です。保存・削除の実務がベンダー側に移っても事業者としての責任はなくなりません。データの保存期間、削除手順、削除証明の提供有無、閲覧ログの取得範囲は契約前に確認すべき項目です。

eKYC（オンライン本人確認）のシステムには、券面画像・顔画像・確認記録という、事業者が扱うデータの中でも最も重い個人情報が集まります。本記事は、これらを「業務DB・PII Vault・Evidence Store・監査ログ」の4区画に分けて守るデータ設計を解説します。自社開発の設計指針としてだけでなく、eKYCシステムを発注する事業会社の責任者が「ベンダーのデータ管理をどの観点で確認すべきか」を判断できるように構成しています。確認日: 2026年8月23日。

なお、法令上の保存要件（何を7年残すか）は本人確認記録の保存要件と個人情報保護の設計が扱っており、本記事はその要件を実現するシステム側の構造を担当します。

この記事の要点

本人確認データには「日常業務で毎日使うデータ」と「めったに開かないが7年守る証跡データ」が混在します。性質が正反対のこの2群を1つのDBに置いた時点で、設計は行き詰まります

分割の基本形は4区画です。業務DB（参照頻度高）、PII Vault（個人情報の金庫）、Evidence Store（確認の証拠）、監査ログ（誰が何をしたか）

暗号化は「やっているか」ではなく「鍵をどう分けているか」が本題です。エンベロープ方式と権限分離が実務の標準です

「保存する設計」と同じ重さで「消す設計」が必要です。期限到来データの削除と、削除した事実の証跡までが一式です

データを分ける理由: アクセス頻度と保護要件が正反対

eKYCで発生するデータを性質で仕分けると、両極端な2つのグループに分かれます。

業務で毎日触るもの: 確認ステータス、審査キュー、ユーザーとの紐付け
めったに触らないが長期間守るもの: 券面画像、容貌画像、IC読み取り結果、確認記録

前者に求められるのは可用性と検索性、後者に求められるのは機密性と完全性です。要件が正反対のデータを1つのDBに同居させると、アプリケーションの全機能が最重要個人情報への到達経路になります。漏えい時の影響範囲も、内部不正の機会も、監査での説明コストも、すべて最大化してしまいます。

4区画分割の基本形

区画	入れるもの	アクセス特性
業務DB	セッション状態、審査ステータス、PII Vaultへの参照ID	アプリから高頻度。個人情報の実体は持たない
PII Vault	氏名・住所等の属性、顔画像・特徴量	専用API経由のみ。目的を付けたアクセス制御
Evidence Store	券面画像、IC検証結果、判定時の入力一式（確認の証拠）	原則追記のみ（WORM的運用）。読み出しは例外事象
監査ログ	誰が・いつ・どのデータに・なぜアクセスしたか	追記のみ。改ざん検知付き

ポイントは、業務DBには「vault:12345」のような参照IDだけを置き、個人情報の実体はVault側へ隔離することです。これにより、業務DBが漏えいしても個人情報の実体は漏れず、Vaultへのアクセスは全件が監査ログに残る、という多層構造が成立します。

Evidence Storeに入る「判定時の入力一式」は、確認セッションの状態機械の遷移と対応させて保存します。「どの入力に基づいてapprovedに遷移したのか」を後から再現できることが、証跡としての価値だからです。

暗号化の設計: エンベロープ方式と鍵の分離

保存時暗号化は「実施しているか」の一言で済ませられがちですが、本題は「鍵をどう分けているか」です。実務の標準はエンベロープ暗号化で、データごとのデータ鍵（DEK）で暗号化し、そのDEKをKMSのマスター鍵（KEK）で暗号化して保管します。設計で決めるのは次の3点です。

鍵の分離単位: 少なくとも区画ごと（PII VaultとEvidence Storeで別鍵）に分けます。マルチテナント構成であればテナントごとに分けると、契約終了時の対応が「鍵の破棄」で完結します
ローテーション: KEKの定期ローテーションと、その際の再ラップ（DEKの再暗号化）手順を決めておきます
権限の分離: アプリケーションの実行権限とKMSの鍵管理権限を別の主体に分けます。アプリが侵害されても鍵ポリシーは変更できない状態を作ります

注意すべきは、顔画像から生成する特徴量（テンプレート）の扱いです。個人情報保護委員会のガイドラインQ&Aは、保護措置を施したテンプレートについても漏えい時の扱いを具体的に示しており、「特徴量だから画像より軽く扱ってよい」という整理は通用しません。特徴量も個人情報として、画像と同じ枠組みで保護対象に含めます。

監査ログの2本立て: 処理の証跡と閲覧の証跡

監査ログは、性質の異なる2種類を区別して設計します。

処理の証跡: 確認セッションの状態遷移、判定の入力と結果、外部プロバイダの応答。壊れないeKYC APIの設計で扱った状態機械の遷移ログが、そのまま土台になります
閲覧の証跡: 手動審査や問い合わせ対応で、誰がどの画像・属性を表示したか。内部不正（覗き見）対策の本丸であり、審査画面の表示そのものをログに残します

閲覧証跡が整備されていると、手動審査の運用設計（最小権限、二重承認、審査対象の割当て）が実効性を持ちます。逆にここが欠けていると、「審査担当者は全ユーザーの画像を無記録で閲覧できる」状態になり、内部統制としても監査対応としても説明が立ちません。

消す設計: 削除バッチと削除証跡までが一式

保存要件には必ず期限があります。期限を過ぎた個人情報を持ち続けることは、リスクの在庫を積み増しているのと同じです。「消す設計」として最初から仕様に含めるべきは次の4つです。

保持期間表の固定: データ分類ごとに保持期間を最初に決めます。法定7年の確認記録、社内規程で決める画像の保持期間、セッションの一時データ、それぞれ根拠と期限を表にします
削除バッチ: 期限到来データを削除する定期処理を用意します。削除範囲にはバックアップ・レプリカ・キャッシュまで含めます。「本体だけ消して7年前のバックアップに残っていた」が典型的な漏れです
削除証跡（削除certificate）: いつ・何を・どの根拠で削除したかを監査ログに残し、「消したことを証明できる」状態にします
例外の扱い: 訴訟・調査対応で保全（リーガルホールド）がかかったデータを削除バッチから除外する仕組みを組み込みます

外部のeKYC SaaSを利用する場合、この「消す設計」はベンダー側にも同じように必要です。保存期間・削除手順・削除証明の提供有無は、契約前に確認すべき項目です（eKYCサービスの選び方20項目の項目15・16に対応します）。

発注者向け: データ管理の確認チェックリスト

eKYCシステムの開発を委託する、あるいはSaaSを選定する立場であれば、提案書・仕様書・契約書で次の点を確認してください。

個人情報の実体と業務データが分離された構成か（業務DBに券面画像が直置きされていないか）
券面画像・IC検証結果などの証跡が追記型（改ざんできない運用）で保存されるか
保存時暗号化の鍵管理方式（エンベロープ暗号化・鍵の分離単位・ローテーション）が説明されているか
顔画像の特徴量（テンプレート）も個人情報として保護対象に含まれているか
審査担当者の閲覧ログ（誰がどの画像を見たか）が取得されるか
データ分類ごとの保持期間表が提示されているか
削除バッチの範囲にバックアップ・レプリカが含まれているか
削除証明（いつ・何を消したかの記録）が提供されるか

まとめ

eKYCのデータは業務DB・PII Vault・Evidence Store・監査ログの4区画に分け、業務DBには参照IDだけを置きます
暗号化はエンベロープ方式を標準とし、区画・テナント単位の鍵分離とアプリ/鍵管理の権限分離まで設計します
顔画像の特徴量も個人情報です。「テンプレートだから軽い」という整理は個人情報保護委員会のQ&Aに照らして通用しません
監査ログは「処理の証跡」と「閲覧の証跡」の2本立てです。手動審査の覗き見対策には閲覧証跡が不可欠です
保持期間表・削除バッチ・削除証跡・リーガルホールドまで含めた「消す設計」を、開発の最初から仕様に入れます
SaaS利用時も同じ観点が必要です。保存期間・削除手順・削除証明は契約前の確認事項です

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

よくある質問

Q. eKYCで取得した画像や個人情報はどう保存すべきですか？

性質の異なるデータを1つのDBに混ぜず、4区画に分けるのが基本です。業務DB（セッション状態と参照IDのみ）、PII Vault（氏名・住所・顔画像などの実体）、Evidence Store（券面画像・IC検証結果などの確認の証拠）、監査ログ（アクセスの記録）に分割し、業務DBには個人情報の実体を持たせません。これにより漏えい時の影響範囲と内部不正の機会を最小化できます。

Q. PII Vaultとは何ですか？

個人情報（PII）の実体を隔離して保管する専用の区画です。氏名・住所などの属性や顔画像・特徴量を格納し、アクセスは専用API経由のみに限定して、目的を付けたアクセス制御と全件の監査ログを課します。業務DBには「vault:12345」のような参照IDだけを置くことで、業務DBが漏えいしても個人情報の実体は漏れない多層構造を作ります。

Q. 顔画像の特徴量（テンプレート）も個人情報として扱う必要がありますか？

あります。個人情報保護委員会のガイドラインQ&Aは、保護措置を施した特徴量についても漏えい時の扱いを具体的に示しており、「特徴量だから画像より軽い」という整理は通用しません。顔画像本体と同じ枠組みで暗号化・アクセス制御・監査の対象に含める必要があります。

Q. eKYCの監査ログには何を記録すべきですか？

2種類を区別して記録します。1つは処理の証跡で、確認セッションの状態遷移・判定の入力と結果・外部プロバイダの応答です。もう1つは閲覧の証跡で、手動審査や問い合わせ対応で誰がどの画像・属性を表示したかです。閲覧の証跡は内部不正（覗き見）対策の本丸で、これがないと審査担当者が全ユーザーの画像を無記録で見られる状態になります。

Q. 本人確認記録の保存期限が過ぎたデータはどう削除すべきですか？

データ分類ごとの保持期間表を最初に固定し、期限到来データを削除する定期バッチを用意します。削除範囲にはバックアップ・レプリカ・キャッシュまで含めることが重要です。加えて、いつ・何を・どの根拠で削除したかの記録（削除証跡）を監査ログに残し、訴訟・調査対応で保全が必要なデータを削除から除外するリーガルホールドの仕組みも組み込みます。

Q. eKYCのSaaSを使う場合もデータ設計の確認は必要ですか？

必要です。保存・削除の実務がベンダー側に移っても、事業者としての責任はなくなりません。データの保存期間、削除手順、削除証明の提供有無、閲覧ログの取得範囲は契約前に確認すべき項目です。ベンダー選定の観点全体はeKYCサービスの選び方20項目と併せて確認してください。

主な参考資料: 個人情報保護委員会個人情報の保護に関する法律についてのガイドラインQ&A、警察庁犯罪収益移転防止法の改正資料一覧、NIST SP 800-63-4

TodoONada株式会社は、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。本記事の4区画分割・鍵管理・監査ログ設計は、当社が本人確認基盤を構築する際に実際に用いている考え方です。犯収法など業種ごとの本人確認要件の整理から、方式選定・開発・運用までワンストップで支援し、既存システムのデータ設計・鍵管理・監査対応のレビューも承ります。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜です。まずはマイナンバーシステム導入支援からご相談ください。

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

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

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

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