個人情報を扱うWebシステムで、将来にわたって漏えいしないと保証することはできません。だからこそ、侵入を防ぐ対策に加えて、保存する情報を減らし、取得できる範囲を狭め、異常を見つけたら止める設計が必要です。完璧さを約束するより、失敗したときにどこまで影響するかを説明できるシステムを選びます。
このガイドは、会員サイト、予約サービス、顧客管理、本人確認を伴うサービスを構築・選定する事業者向けです。2026年10月1日時点の一次資料を踏まえ、発注担当者が設計・契約・受入れで確認する項目を整理します。特定企業の未公表の侵入経路や内部設計を推定する記事ではありません。
「完璧ではない」を、対策を諦める理由にしない
認証、画面表示、API、管理者の操作、バックアップ、委託先との連携には、それぞれ情報へ到達する経路があります。ソフトウェアの不具合だけでなく、設定ミス、端末やアカウントの侵害、内部不正も考える必要があります。限定した前提で安全性を検証できても、その前提を超える将来の運用まで保証できるわけではありません。
目標は、侵入の可能性と侵入後の被害を両方減らすことです。「1回に100件まで取得できるから最大100件しか漏れない」とは言えません。繰り返し取得、複数アカウント、DBやバックアップへの直接アクセスがあれば、画面の上限を超える可能性があります。
最初に、集める情報と残す理由を決める
構築前に、業務責任者と情報管理担当者が次の一覧を作ります。「便利だから残す」ではなく、誰の何の仕事に必要かを説明できることを条件にします。
| データ | 確認すること | 減らす・分ける例 |
|---|---|---|
| 氏名・住所・連絡先 | 利用目的、必須項目、担当者、保存期間 | 予約番号だけで処理できる画面では氏名を出さない |
| 本人確認書類の画像 | 画像保存の法令・契約・業務上の根拠、確認後に必要な記録 | 保存義務等を確認したうえで、確認結果・日時・方法など必要な記録を残し、不要な原画像は削除する |
| 退会・申込未完了の情報 | 退会後や中断後に残す理由、削除期限 | 一定の保存が必要な記録と、不要な途中入力・一時画像を分ける |
| ログ・バックアップ・作業用コピー | 本文や認証情報の混入、保存場所、削除期限 | ログの情報を最小化し、開発・検証では架空データを使う |
「確認済み」という印だけで足りる業務もあれば、法令や契約上、記録の保存が必要な業務もあります。本人確認が終わったら無条件に原画像を消す、という共通ルールにはしません。必要性と保存期限を先に確認し、例外の承認者も決めます。個人情報保護委員会の通則編ガイドラインも参照してください。
削除は本番DBだけでは完了しません。画像保管庫、複製、検索用データ、一時ファイル、委託先、バックアップを一覧にします。バックアップからすぐに個別削除できない場合は、アクセスを制限し、保持期限と復元時の再削除手順を定めます。「退会したので全部消えた」と、仕組みで保証できない説明をしないことも必要です。
分離するのは、データの置き場所だけではない
一般的な構成例は、公開Web、業務処理、個人情報の保管、鍵の管理を分ける形です。下の流れは設計を話し合うための例であり、これを採用すれば安全が保証されるという構成図ではありません。
利用者・担当者 ↓ 本人確認と操作権限の検査 Web／業務API → 業務DB（予約番号・処理状態など） ↓ 許可された目的・対象・項目だけを要求 個人情報アクセス用サービス → 非公開の個人情報保管庫 ↓ 許可された処理だけ 鍵管理サービス（復号権限・利用記録） 各層の操作記録 → 独立した監視先 → 通知・一時停止・調査
たとえば架空の予約サービスなら、通常の予約一覧は予約番号と状態だけにし、連絡が必要な担当者だけが担当予約の連絡先を参照します。本人確認画像を扱う処理は別の権限にします。予約用アカウントが画像保管庫を全件読み出せるなら、DBを別サーバーに置いただけでは十分な分離になりません。
分離の効果は、片方を侵害されても他方へ同じ権限で進めないことにあります。接続用の認証情報、管理者、バックアップへの権限まで共通なら、まとめて影響を受ける可能性があります。小規模なシステムでも、アカウント・保管領域・権限を分けるところから始められます。
大量取得を難しくする5つの設計
1．ログイン後も、対象ごとに権限を確認する
ログインは相手を確認する認証です。その人がその顧客・書類・項目を見てよいかを決めるのが認可です。画面のボタンを隠すだけでなく、サーバーで毎回検査し、許可されていない操作は拒否します。利用者IDを変更した要求、別部署のデータ、画像URLへの直接アクセスも対象です。OWASPは最小権限、既定で拒否、要求ごとの権限検査を推奨しています。OWASP：認可
2．一括取得を通常操作から分ける
CSV出力、全件検索、画像の一括ダウンロードには、通常閲覧とは別の権限を設けます。必要な一括処理は、目的・対象範囲・項目を限定し、承認、有効期限、出力先、削除期限を記録します。画面・APIの1回の件数だけでなく、一定時間の累積件数や通信量、アカウントをまたぐ異常も見ます。
制限のしきい値は通常業務を測って決めます。低すぎれば正規の処理を止め、高すぎれば大量取得を見逃します。低速で続く取得や特権アカウントの操作も監視し、単なるページ分割を流出防止策と呼ばないようにします。OWASP：REST APIの安全対策
3．暗号化と、復号できる権限を分ける
通信中と保存中の暗号化は必要な対策です。ただし、正常なアプリが読めるデータは、そのアプリの権限を奪った相手にも読まれる可能性があります。暗号鍵をデータと同じ設定ファイルへ置かず、鍵管理サービス等で復号の権限・用途・記録を管理します。鍵の更新や緊急時の失効、復旧も試します。OWASP：保存データの暗号化
別IDへの置換も、対応表や復号の権限が同時に奪われれば保護が崩れます。「暗号化済み」「トークン化済み」という製品説明だけで判断せず、誰が何件分を元の情報へ戻せるかを確認します。
4．本人確認画像とバックアップを公開経路から外す
画像は非公開の保管先に置き、閲覧のたびに権限を確認します。URLを知っているだけで誰でも見られる設計にしません。有効期限付きURLを使う場合も、転送・共有される可能性を考え、期限と発行対象を限定します。バックアップは独立した権限で保護し、管理画面、分析ツール、開発環境にも同じ情報が残っていないか確認します。
5．記録を残すだけでなく、止めるまでを決める
誰が、いつ、どの処理で、どの範囲へ、どれだけアクセスしたかを記録し、担当者へ通知します。ログにパスワード、認証トークン、本人確認画像、個人情報の本文をそのまま保存して、新たな漏えい元を作らないようにします。記録の閲覧権限や改ざんへの対策も必要です。OWASP：ログ設計
異常通知の宛先、夜間の当番、一括出力や画像閲覧を止める権限、再開の承認者を決めます。自動停止は被害を抑えられる反面、誤検知で業務を止める可能性があります。止める範囲を限定し、調査と解除の手順を事前に試しておきます。
WordPressやSaaSを使う場合の選び方
お知らせを発信するWordPressと、免許証画像を大量に扱う本人確認システムでは、必要な保護が違います。WordPressを使うなら、公開コンテンツと機微な業務情報の責任範囲を分けます。一般公開用のメディア領域へ本人確認画像を置く運用は避け、保管・閲覧・削除を制御できる専用の仕組みを検討します。
| 選択肢 | 向く条件 | 確認する負担・限界 |
|---|---|---|
| 情報を取得しない、入力項目を減らす | 業務目的を少ない情報で達成できる | 本人確認・契約・問い合わせ対応に不足しないか、業務側が判断する |
| 既存SaaS・本人確認サービスを使う | 機能や運用が自社の要件に合う | 委託先・再委託先、保存期間、削除、ログ、事故通知、費用支援。外注しても自社の説明責任が消えるわけではない |
| 自社システムで分離して構築する | 独自の権限・保存・業務連携が必要 | 設計、鍵管理、監視、更新、復旧訓練を継続できる人と予算が必要 |
見積りは初期費用だけで比較せず、保管・通信・ログ・鍵管理・監視・定期診断・更新・問い合わせ対応・移行と削除まで含めます。料金や上限は契約プランによって違うため、想定する件数と業務を示して見積りを取ります。認証マークや監査報告も判断材料ですが、対象範囲や時点を確認し、自社の使い方まで安全だと読み替えないことが必要です。
発注・契約時に書面で答えてもらうこと
- 通常のWebアカウント、管理者、保守担当、連携用アカウントは、それぞれ何を何件取得できるか。
- 本人確認画像の保存理由と期限は何か。退会者・未完了申込み・一時ファイルにも削除が適用されるか。
- CSV、API、画像URL、DB、バックアップのどの経路でも、権限の制限が効くか。
- 鍵の管理者とデータの管理者は誰か。緊急時に権限を失効しても復旧できるか。
- 異常を何で検知し、誰が何分・何時間以内に対応する契約か。夜間・休日も対象か。
- 事故時の第一報、調査、対象者の特定、本人通知、費用負担は誰が行うか。
- 解約時に取り出せるデータと、削除される範囲・期限・確認方法は何か。
技術担当者だけで契約を確定せず、業務責任者、情報管理担当者、必要に応じて法務が確認します。供給者が回答できない項目は「対応済み」にせず、制約と代替策を契約・運用手順に残します。
漏えい後の報告・本人通知まで、導入前に準備する
2026年10月4日追記。Legalscapeの解説「個人情報漏洩が起こるとどうなる？」は、従業員のミス・内部不正・外部攻撃という原因、信用や賠償への影響、報告と本人通知、技術と人の両面の対策を整理しています。構築・選定では、これらを「事故時に誰が何を実行できるか」という条件に置き換えると役立ちます。以下の法的な基準は、個人情報保護委員会の一次資料で確認しています。
報告の要否を、件数だけで判断しない
民間事業者の個人データについて、報告対象となるのは、漏えい・滅失・毀損、またはそのおそれがあり、次のいずれかに該当する場合です。高度な暗号化等による除外の適用は、具体的な保護状態を確認して判断します。
- 病歴などの要配慮個人情報が含まれる。
- 不正利用による財産的被害のおそれがある。
- 不正目的の行為によるおそれがある。取得予定で個人データとして扱う予定の個人情報も含まれる。
- 対象となる本人の数が1,000人を超える。
「1,000件以上」という基準ではなく、本人の人数で判断します。人数が少なくても、他の類型に当たれば報告対象です。根拠は個人情報保護委員会の漏えい等対応案内です。行政機関等やマイナンバーの取扱いには別の基準もあるため、この民間事業者向けの整理をそのまま適用しないでください。
調査完了を待たず、報告と通知を進められるか
速報は報告対象事態を知った後、速やかに行います。概ね3～5日以内は目安であり、待ってよい期間ではありません。確報は原則30日以内、不正目的の行為によるおそれがある類型では60日以内です。社内では、いずれかの部署が知った時点を記録し、担当役員への報告日から数え直さないようにします。
本人への通知も状況に応じて速やかに行い、全項目の解明まで一律に保留しません。通知が困難な場合の代替措置には条件があり、Webで公表するだけで常に足りるわけではありません。委託先から委託元への通知による報告義務の例外もあるため、担当と連絡経路を契約時に確認します。詳しくは通則編ガイドラインの3-5（漏えい等の報告等）を参照してください。
選定条件にするのは、機能名より実行できる手順
| 確認する業務 | 構築・選定時に求める説明や証拠 |
|---|---|
| 対象者と漏えい項目の特定 | 対象期間・本人・情報項目を調べられる記録と、調査担当者へ安全に提供する手順。調査用に個人情報を無制限に複製しない |
| 被害拡大の防止と証拠保全 | 接続や権限を止める担当、ログの保全方法、外部調査会社への連絡先。原因調査に必要な記録を消さない初動手順 |
| 報告・本人通知・問い合わせ対応 | 判断責任者、委託先の第一報期限、休日の連絡先、通知文面の承認手順。確定情報と調査中の事項を分け、続報を届ける運用 |
| 誤操作と内部不正への対策 | 誤送信や公開設定ミスを想定した訓練、持出し制限、異動・退職時の権限削除。研修や守秘義務書面だけに頼らない仕組み |
| 事故対応の費用 | 調査、通知、相談窓口、復旧、利用者支援の予算と負担区分。保険や契約の対象・免責・上限を確認する |
漏えいが起きただけで一律の刑罰や定額の賠償が決まるわけではありません。法的責任は事案ごとに確認します。その一方で、責任が確定するまで何も準備しない運用では、利用者への支援が遅れます。発注者は、調査・通知・相談対応を模擬事故で一度実行し、担当者が不在でも引き継げる状態を受入れ条件にしてください。
架空データで小さく試し、受入れ条件を確認する
実在する顧客情報や免許証画像を持ち込まず、完全な架空データを使った検証環境から始めます。発注者が試験範囲を承認し、実施者・記録先・中止条件を決めます。第三者の本番サービスへ無断で大量アクセスする試験は行いません。
| 試すこと | 受入れ時に残す証拠 |
|---|---|
| 別利用者・別部署の情報へのアクセス | 画面とAPIの双方で拒否され、権限のない画像も取得できない記録 |
| 通常上限を超える連続取得・一括出力 | 合意した条件で制限・通知・停止が働き、正規業務への影響も説明できる結果 |
| 退会・期限満了後の削除 | 対象範囲から削除され、バックアップ復元時にも再削除が行われる結果 |
| 連携アカウントや鍵の失効 | 失効後のアクセスが止まり、承認された手順で復旧できる記録 |
| 夜間の事故を想定した訓練 | 通知から担当者の応答、一時停止、証拠保全、連絡までの実測時間 |
拒否されるべき操作が通る、削除対象が残る、通知に誰も応答しない場合は、本番導入前に修正して再確認します。検証の合格は試した条件での結果です。試験で100件に止まったとしても、あらゆる攻撃で100件以内に収まる保証にはなりません。
運用開始後も、保存量と権限と対応時間を見直す
更新・脆弱性への対応、多要素認証、不要アカウントの削除など、侵入を防ぐ基本対策は継続します。そのうえで、保存期限を超えた情報の件数、全件出力できるアカウント数、異常から担当者の応答・停止までの時間を記録します。業務量や機能が増えたら、権限と取得制限も見直します。
事故が起きた場合の利用者支援も設計の一部です。対象者の特定、漏えい項目の通知、予防策の案内、費用支援の判断までを、開発会社任せにせず事業者の業務として準備します。
まずは一つの業務を選び、「何を保存しているか」「誰が全件を取り出せるか」「異常時に誰が止めるか」を確認してください。持つ量を減らし、届く範囲を狭め、止めるまでの時間を短くする。その積み重ねが、大量流出しにくいシステムにつながります。
関連リンク
- 個人情報漏えい後の対策費は誰が負担するべきか――被害が出る前の補償という考え方：事故後の利用者支援と、予防費用の負担を検討する。
- API・API連携：データを受け渡す窓口と、連携時に確認する条件を理解する。
関連する用語・実践記事
- 情報セキュリティ：漏えい・改ざん・消失を防ぐ情報セキュリティの全体像を確認する。
- アクセス制御（権限管理）：データごとの閲覧・編集・削除権限と、異動時の見直しを確認する。
- 個人情報：取得目的、保存期間、削除、委託先など、扱う情報の基本を確認する。
- 情報漏洩のリスクと回避方法――取扱い・権限・送信のルール：誤送信、共有リンク、持出しなどを含む取扱い・権限・送信の実務ルールを作る。
- Webサイトもセキュリティを考えなければならない理由――改ざん・漏洩・停止を防ぐ運用：CMSの更新、管理者、バックアップ、異常時の連絡を保守運用として確認する。
関連する記事：個人情報を集める責任は、謝罪だけで果たせるのか
関連する記事：相次ぐ情報漏洩から考える、委託先まで含めた情報管理