顧客管理システム、会員管理システム、予約システム、人材管理システムなどを開発すると、多くの場合で氏名・住所・電話番号・メールアドレスなどの個人情報を扱います。
このようなWebシステムを設計するときは、単純に「データベースへ保存できればよい」という考え方では不十分です。
重要なのは、
- そもそも何を保存するのか
- 誰が閲覧できるのか
- 画面にどこまで表示するのか
- データをどのように保護するのか
- 誰が閲覧・変更したかを追跡できるか
- 退会・契約終了後にいつ削除するのか
まで含めて設計することです。
特に個人情報を扱うWebシステムでは、開発後にセキュリティ対策を追加するよりも、要件定義や基本設計の段階から個人情報の扱いを整理しておく方が安全で、後からの改修も減らせます。
この記事では、個人情報を扱うWebシステムを設計するときに確認したいポイントを、実際の業務システムを想定しながら解説します。
個人情報を扱うWebシステムでは最初に「情報の流れ」を整理する
個人情報のセキュリティ対策というと、
- 暗号化
- ファイアウォール
- WAF
- MFA
などの技術に注目しがちです。
しかし、最初に整理すべきなのは「どの個人情報が、どこから入り、どこへ保存され、誰が利用するのか」です。
例えば会員管理システムなら、
会員
↓
Webフォームから登録
↓
Webアプリケーション
↓
データベースへ保存
↓
管理画面から担当者が閲覧
↓
必要に応じてCSV出力
という流れがあります。
この場合、個人情報はデータベースだけに存在するわけではありません。
- Webブラウザ
- アプリケーションサーバー
- データベース
- ログ
- バックアップ
- CSVファイル
- メール
- 外部API
など、複数の場所を通る可能性があります。
そのため、「データベースを暗号化したから安全」と考えるのではなく、個人情報が通る経路全体を確認する必要があります。
個人情報を扱うWebシステムで整理したい8つの設計ポイント
個人情報を扱うWebシステムでは、少なくとも次の8つを検討しておくとよいでしょう。
- 保存する個人情報
- データベースへの保存方法
- 通信経路
- 画面への表示方法
- アクセス権限
- 操作ログ・監査ログ
- データの保存期間と削除
- バックアップ・外部サービスへの連携
それぞれ詳しく見ていきます。
1．必要な個人情報だけを保存する
最も重要な考え方の一つが、
「取得できる情報を保存する」
のではなく、
「業務に必要な情報だけを保存する」
ことです。
例えば予約管理システムを作るとします。
予約受付に必要なのが、
- 氏名
- メールアドレス
- 電話番号
- 予約日時
だけであれば、住所や生年月日まで取得する必要があるのかを検討します。
個人情報は増えるほど管理対象も増える
保存する項目が増えると、それだけ管理する情報も増えます。
例えば、
「念のため住所も登録してもらおう」
という理由だけで住所を収集すると、その後は住所についても、
- 閲覧権限
- CSV出力
- ログ
- バックアップ
- 削除
- 漏えい対策
を考える必要があります。
Webシステムを設計するときは、各項目について、
「この情報は何の業務に必要なのか」
を説明できる状態にしておくことが重要です。
2．データベースへの保存方法を設計する
個人情報の多くはデータベースへ保存されます。
例えば顧客管理システムでは、
顧客テーブル
- 顧客ID
- 氏名
- メールアドレス
- 電話番号
- 住所
- 担当者
- 登録日時
- 更新日時
などを保存します。
ここで重要なのが、すべてのデータを同じように扱わないことです。
パスワードはそのまま保存しない
ログイン機能を持つWebシステムでは、パスワードの扱いに特に注意が必要です。
パスワードをそのままデータベースへ保存する設計は避け、適切なパスワードハッシュを利用することが基本です。
つまり、
パスワード
↓
適切なハッシュ処理
↓
ハッシュ値を保存
という構成にします。
利用者がログインするときも、入力されたパスワードを同じ方法で検証します。
個人情報の暗号化も検討する
扱う情報やリスクに応じて、保存データの暗号化を検討します。
例えば、
- 住所
- 電話番号
- 生年月日
- その他重要な個人情報
などです。
ただし、「すべてのカラムを暗号化すればよい」という単純な話でもありません。
暗号化すると、
- 検索
- 並び替え
- 集計
- インデックス
- 外部システム連携
が難しくなる場合があります。
そのため、
「どの情報を暗号化するか」
「その情報を検索する必要があるか」
「暗号鍵をどこで管理するか」
まで含めた設計が必要です。
3．通信経路を保護する
個人情報は保存時だけでなく、通信中にも扱われます。
例えばユーザーが会員登録フォームへ入力した場合、
ブラウザ
↓
インターネット
↓
Webサーバー
↓
アプリケーション
↓
データベース
という流れで情報が移動します。
WebシステムではHTTPSを利用し、通信内容を保護することが基本です。
また、システム構成によっては、
Webアプリ
↓
API
↓
データベース
Webアプリ
↓
外部SaaS
Webアプリ
↓
AI API
などの通信もあります。
個人情報を外部サービスへ送信する場合は、
「どの情報をどこへ送っているのか」
を把握できるようにしておくことが重要です。
4．画面に表示する個人情報を必要最小限にする
データベースに保存している情報を、すべて管理画面へ表示する必要はありません。
例えば顧客一覧画面で、
| 氏名 | メール | 電話番号 | 住所 | 生年月日 |
|---|
とすべて表示する必要があるでしょうか。
日常業務で必要なのが、
| 顧客名 | 担当者 | ステータス |
|---|
だけなら、一覧では最低限の情報だけを表示し、詳細画面を開いた場合だけ個人情報を表示する方法があります。
マスキングも検討する
用途によっては、
090-****-1234
t*@example.com
のように、一部をマスキングして表示する方法もあります。
例えばコールセンターで、
「本人確認をした後だけ詳細情報を表示する」
という設計も考えられます。
個人情報を扱う画面では、
「保存しているから表示する」
のではなく、
「業務上、その画面で本当に必要か」
という観点で設計します。
5．誰が閲覧・編集できるか権限を設計する
個人情報を扱うWebシステムで非常に重要なのがアクセス権限です。
例えば人材管理システムを考えてみましょう。
利用者には、
- 一般社員
- 上司
- 人事担当者
- 人事管理者
- システム管理者
などが存在します。
すべてのユーザーが同じ情報を閲覧できる設計では問題になる場合があります。
例えば、
一般社員
自分自身の情報のみ閲覧
上司
所属チームの必要な情報のみ閲覧
人事担当者
業務上必要な従業員情報を閲覧・編集
システム管理者
システム設定を管理
というように役割ごとに権限を分けます。
この考え方をRBAC（Role-Based Access Control：ロールベースアクセス制御）と呼びます。
「管理者なら全部見られる」でよいとは限らない
システム開発では、
admin
user
という2種類だけで権限を作ってしまうことがあります。
しかし個人情報を扱う業務システムでは、それでは粗すぎる場合があります。
例えば、
営業管理者
→ 顧客情報を閲覧
経理担当者
→ 請求情報を閲覧
人事担当者
→ 従業員情報を閲覧
システム管理者
→ システム設定はできるが、人事情報は閲覧不要
というケースもあります。
「管理者」という一つの権限にすべてを集めるのではなく、業務上必要なアクセス範囲を整理することが重要です。
画面だけではなくAPIでも権限チェックする
Webシステムの権限制御で注意したいのが、
「画面からボタンを消しただけ」
という設計です。
例えば一般ユーザーには顧客削除ボタンを表示しないとしても、
API自体に権限チェックがなければ、別の方法で削除処理を実行できてしまう可能性があります。
そのため、
画面
↓
API
↓
データベース
という各処理の中で、サーバー側でも権限を確認する必要があります。
6．操作ログ・監査ログを設計する
個人情報を扱うシステムでは、
「誰が何をしたか」
を確認できるようにすることも重要です。
例えば次のような操作です。
- ログイン
- 顧客情報の閲覧
- 個人情報の変更
- データ削除
- CSV出力
- 権限変更
- 管理者操作
特に重要な操作では、
- ユーザーID
- 操作日時
- 操作内容
- 対象データ
- 成功・失敗
などを記録しておく方法があります。
ログに個人情報を書きすぎない
一方で、ログを詳しく残せばよいわけでもありません。
例えばアプリケーションログに、
「山田太郎、住所○○、電話番号○○を登録しました」
と個人情報をそのまま出力してしまうと、ログファイル自体が新たな個人情報の保存場所になります。
そのため、
顧客ID：12345を更新
のように、個人情報そのものを可能な限りログへ含めずに追跡できる設計も検討します。
7．個人情報をいつまで保存するか決める
システム開発時に忘れられやすいのが削除設計です。
例えば、
「退会したユーザーの情報をどうするのか」
を考えます。
退会
↓
アカウントを無効化
↓
一定期間保存
↓
削除または匿名化
など、業務や必要性に応じてルールを決めます。
システムにはデータ登録機能だけでなく、
- 削除
- 無効化
- 匿名化
- 保存期間管理
も必要になる場合があります。
論理削除と物理削除を使い分ける
Webシステムでは、データをすぐにデータベースから消さず、
deleted_at
のような項目を設定して、画面上では削除済みとして扱う「論理削除」が使われることがあります。
一方、データそのものをデータベースから削除する方法が「物理削除」です。
個人情報では、
「画面から消えている＝データが削除されている」
とは限りません。
そのため、
- いつ論理削除するか
- いつ物理削除するか
- バックアップにはいつまで残るか
まで整理することが重要です。
8．バックアップにも個人情報が含まれることを忘れない
データベースを削除しても、バックアップに個人情報が残っている場合があります。
例えば、
本番データベース
↓
毎日バックアップ
↓
30日間保存
というシステムであれば、本番データを削除しても一定期間はバックアップに残る可能性があります。
そのため個人情報の保存期間を考えるときは、
- 本番DB
- バックアップ
- CSV
- 添付ファイル
- ログ
- 外部サービス
まで含めて確認します。
CSV出力は個人情報流出の経路になりやすい
業務システムでは、
「顧客一覧をCSVでダウンロードしたい」
という要望がよくあります。
便利な機能ですが、CSVとしてダウンロードすると、システム側のアクセス制御から離れてしまいます。
例えば、
顧客情報CSVをダウンロード
↓
PCのデスクトップへ保存
↓
メール添付
↓
別の社員へ転送
といったことが可能になります。
そのためCSV出力では、
- 誰がダウンロードできるか
- どの項目を出力できるか
- 出力操作をログに残すか
- 大量出力を許可するか
を検討します。
場合によっては、
通常ユーザー
→ CSV不可
管理者
→ CSV可能
などの制御も必要です。
検索画面にも個人情報特有の注意点がある
顧客管理システムでは、
- 氏名
- 電話番号
- メールアドレス
などで検索できると便利です。
しかし検索機能を作ると、個人情報へアクセスできる範囲も広がります。
例えば、
電話番号の一部だけ入力
↓
該当する顧客を大量表示
という仕様になっていると、必要以上の情報へアクセスできる可能性があります。
検索条件、表示件数、利用権限なども含めて設計することが重要です。
添付ファイルの扱いにも注意する
業務システムでは、データベースだけでなくファイルにも個人情報が含まれます。
例えば、
- 本人確認書類
- 契約書
- 履歴書
- 申込書
- 診断書
- 顧客提出資料
などです。
ファイルを扱う場合は、
- 保存先
- 閲覧権限
- ダウンロード権限
- URLの有効期限
- 削除方法
- バックアップ
などを検討します。
単純に公開URLを発行し、
URLを知っていれば誰でも閲覧できる
という状態にならないよう注意が必要です。
開発・テスト環境へ本番の個人情報をコピーしない
Webシステム開発では、本番データを使ってテストしたくなることがあります。
例えば、
「実際のデータならバグを再現しやすい」
という理由です。
しかし本番の個人情報をそのまま開発環境へコピーすると、個人情報を扱う場所が増えてしまいます。
本番環境
＋
ステージング環境
＋
開発環境
＋
開発者PC
という状態になる可能性があります。
テストには、
- ダミーデータ
- 匿名化したデータ
- マスキングしたデータ
を使用する方法を検討します。
外部API・AIへ個人情報を送信するときも確認する
近年はWebシステムから、
- 生成AI
- OCR
- メール配信サービス
- CRM
- 決済サービス
- 分析サービス
などへデータを送信するケースも増えています。
例えば問い合わせ管理システムで、
問い合わせ内容
↓
生成AI
↓
回答案を生成
という機能を実装するとします。
問い合わせ内容に、
- 氏名
- メールアドレス
- 住所
- 契約情報
などが含まれている可能性があります。
そのため外部APIを利用するときは、
「どのデータを送信しているのか」
を整理する必要があります。
場合によっては、
個人情報を除外
↓
必要な文章だけ送信
↓
AI処理
↓
結果をシステムへ戻す
という設計も考えられます。
認証と権限管理は分けて考える
個人情報を扱うWebシステムでは、
「ログインできる＝すべての情報を閲覧できる」
という設計にしないことが重要です。
認証は、
「誰なのか」
を確認する仕組みです。
一方、認可・権限管理は、
「何をしてよいのか」
を判断する仕組みです。
例えば、
山田さんとしてログイン
↓
営業担当者であることを確認
↓
自分の担当顧客のみ閲覧可能
という流れです。
SSOやMFAを導入して認証を強化しても、権限設計が不十分であれば必要以上の情報を閲覧できる可能性があります。
認証と権限は別々に設計しましょう。
個人情報を扱うWebシステムの画面設計例
例えば顧客管理システムなら、次のように画面を分ける方法があります。
顧客一覧
表示する情報：
- 顧客番号
- 顧客名
- 担当者
- ステータス
顧客詳細
権限があるユーザーのみ表示：
- 電話番号
- メールアドレス
- 住所
- 契約情報
顧客編集
さらに権限を限定：
- 個人情報変更
- 契約情報変更
管理画面
管理者のみ：
- ユーザー管理
- 権限設定
- CSV出力
- 操作ログ
このように、
一覧
↓
詳細
↓
編集
↓
管理
の段階に応じて権限を細かく設定すると、必要以上の個人情報表示を防ぎやすくなります。
【コピペ用】個人情報を扱うWebシステムの設計チェックリスト
個人情報を扱うシステムを検討している場合は、次の項目を整理してみてください。
管理する情報
- 氏名：
- メールアドレス：
- 電話番号：
- 住所：
- 生年月日：
- その他の個人情報：
- 添付ファイル：
情報を利用する人
- 一般ユーザー：
- 担当者：
- 管理者：
- 外部ユーザー：
- システム管理者：
権限
- 閲覧可能な情報：
- 編集可能な情報：
- 削除可能な情報：
- CSV出力可能なユーザー：
- 添付ファイルをダウンロードできるユーザー：
データ保護
- HTTPS：
- パスワードハッシュ：
- データ暗号化：
- MFA：
- アクセス制御：
- バックアップ：
ログ
- ログイン履歴：
- 個人情報変更履歴：
- 削除履歴：
- CSV出力履歴：
- 権限変更履歴：
データ削除
- 退会時の処理：
- 契約終了時の処理：
- 保存期間：
- 物理削除の時期：
- バックアップ保持期間：
外部連携
- メールサービス：
- 決済サービス：
- CRM：
- AI API：
- その他の外部サービス：
このチェックリストを整理すると、個人情報に関する要件をシステム開発会社へ伝えやすくなります。
個人情報を扱うWebシステムでよくある設計ミス
とりあえず全部保存する
将来使うかもしれないという理由だけで個人情報を増やすと、管理する対象も増えます。
取得目的と必要性を整理することが重要です。
ログインできれば安全だと考える
認証だけでは十分ではありません。
ログイン後に、
「誰がどの情報を閲覧できるか」
を制御する必要があります。
管理者権限が強すぎる
一つの管理者ロールですべての個人情報へアクセスできる設計は、業務によっては過剰な権限になります。
職務に応じて権限を分離することを検討します。
CSV出力を誰でも利用できる
システム内部ではアクセス制御できていても、CSVとして一括ダウンロードされると管理が難しくなります。
CSV出力は独立した権限として設計する方法があります。
個人情報をログへ残してしまう
デバッグ目的でリクエスト内容を丸ごとログへ出すと、氏名・住所・電話番号などがログに保存される可能性があります。
ログに何を記録するかも設計対象です。
削除方法を決めていない
登録・更新機能は要件定義されているものの、
「退会後のデータをどうするか」
が決まっていないケースがあります。
保存期間や削除方法も開発前に整理しておきましょう。
個人情報を扱うWebシステムに関するよくある質問
個人情報はデータベースへ保存してもよいですか？
Webシステムでは個人情報をデータベースへ保存すること自体は一般的ですが、必要性、利用目的、アクセス権限、セキュリティ対策、保存期間などを整理して設計する必要があります。
扱う情報や事業内容によって求められる対応も異なるため、法令や社内規程については必要に応じて専門家へ確認してください。
個人情報はすべて暗号化した方がよいですか？
一律にすべて暗号化すればよいとは限りません。
暗号化すると検索や集計が難しくなる場合もあります。
情報の重要度、利用方法、検索要件などを整理して設計します。
なお、ログインパスワードについては暗号化して復号できる状態で保存するのではなく、適切なパスワードハッシュを利用することが基本です。
個人情報を扱う場合はMFAが必要ですか？
システムの利用者、扱う情報、アクセス環境などによって判断します。
特に管理者アカウントや重要な個人情報へアクセスできるユーザーについては、MFAを含めた認証強化を検討する価値があります。
CSVダウンロードは禁止した方がよいですか？
必ずしも禁止する必要はありません。
業務上CSVが必要なケースもあります。
ただし、
- 出力権限
- 出力項目
- 操作ログ
- 一括出力件数
などを整理した方がよいでしょう。
個人情報の閲覧履歴は残した方がよいですか？
扱う情報や業務によります。
特に重要な個人情報を扱うシステムでは、誰が閲覧・変更・出力したのか追跡できる仕組みを検討します。
ただし、ログそのものに不要な個人情報を記録しないよう注意が必要です。
開発会社へ何を伝えればよいですか？
最低限、
- どの個人情報を扱うのか
- 誰が利用するのか
- 誰が何を閲覧できるのか
- CSV出力が必要か
- 外部サービスへデータを送るか
- 退会・契約終了後にどうするか
を整理すると、要件定義を進めやすくなります。
セキュリティは「機能一覧」と同じ段階で整理する
Webシステム開発では、
- 顧客登録
- 顧客検索
- CSV出力
- メール送信
などの機能を先に決め、セキュリティについては開発後半で考えてしまうことがあります。
しかし個人情報を扱うシステムでは、
「誰が使うか」
「誰が見られるか」
「何を保存するか」
が画面やデータベース設計そのものに影響します。
そのため、
業務整理
↓
個人情報の整理
↓
権限整理
↓
機能整理
↓
画面設計
↓
データベース設計
↓
システム開発
という流れで検討する方が合理的です。
hiro-dev-labでは個人情報を扱うWebシステムの要求整理から相談できます
個人情報を扱うWebシステムでは、プログラムを書く前の設計が重要です。
例えば顧客管理システムでも、
「顧客情報を登録できるようにしたい」
という要求だけでは十分ではありません。
実際には、
- どの情報を保存するか
- 誰が登録するか
- 誰が閲覧するか
- 誰が編集するか
- CSV出力を許可するか
- 操作履歴を残すか
- 退会後どう処理するか
まで整理する必要があります。
hiro-dev-labでは、
- 業務ヒアリング
- As-Is（現在の業務）の整理
- To-Be（システム導入後の業務）の整理
- 要求整理
- 要件定義
- 権限設計
- 画面一覧の整理
- データ項目の整理
- プロトタイプ作成
- Webシステム設計・開発
- API連携
- AI・業務自動化
などから相談できます。
「個人情報を扱う予定だが、どこまで対策すればよいか分からない」
「顧客管理システムを作りたいが、権限設計が決まっていない」
「現在Excelで管理している個人情報をWebシステムへ移行したい」
という段階でも、まず現在の業務と情報の流れを整理することから検討できます。
まとめ
個人情報を扱うWebシステムでは、単にデータを安全なサーバーへ保存するだけでは十分ではありません。
重要なのは、
- 必要な個人情報だけを取得する
- 保存方法を整理する
- 通信経路を保護する
- 画面表示を必要最小限にする
- ユーザーごとの権限を設計する
- 操作ログを適切に記録する
- 保存期間と削除方法を決める
- バックアップや外部連携まで確認する
という考え方です。
特に、
「誰が、どの個人情報を、何のために利用するのか」
を明確にすると、必要なセキュリティ対策を整理しやすくなります。
個人情報保護を後付けのセキュリティ機能として考えるのではなく、業務フロー、画面、データベース、権限、ログまで含めたWebシステム全体の設計として考えることが重要です。