新規事業の個人情報とシステム設計｜設計前に確認する点
個人情報を扱う新規事業や、業法（特定の事業を規制する法律）が関わる新規事業では、設計に入ってから「この情報は取得できなかった」「この確認手順が必要だった」と分かると、画面もデータベースも作り直しになりやすくなります。この記事では、システム設計の前に確認しておきたい5つの点を整理します。あわせて、確認した内容を設計の条件に置き換える考え方と、プロトタイプ段階での扱い方も紹介します。
なお、この記事は一般的な情報の整理であり、法的助言ではありません。法令やガイドラインは改正されることがあるため、実際の判断は弁護士などの専門家と、個人情報保護委員会や所管官庁の公式情報で確認することを前提にしてください。
設計の前に確認しておきたい理由
個人情報や業法への対応は、あとから足しやすい機能ではありません。氏名や住所をどの画面で取るか、どのテーブルに保存するか、誰が閲覧できるか、いつ消すか。こうした決めごとの一つひとつが、画面、データベース、権限、ログ、外部サービスとの連携に染み込んでいきます。
たとえば、同意を取る画面を後から挟む場合を考えます。同意の履歴を残すにはデータの持ち方から変える必要があります。外部の分析ツールを後から入れると、利用者の情報が外部へ送られるため、利用者への説明の方法も見直しになります。1か所の修正に見えても、実際は設計全体に影響が及びます。
新規事業には、もう一つ事情があります。事業の仮説が固まっていない段階では、「とりあえず取れる情報は取っておこう」という発想になりがちです。しかし、使い道が決まっていない個人情報を集めると、管理の負担と漏えい時のリスクだけが先に増えます。
そのため、設計の前に次の2点を確認しておくことを勧めます。
- 事業そのものにどんな法令が関わるか（業法の有無）
- どんな情報を、何のために、どこまで扱うか（個人情報の範囲）
この2点が見えていれば、設計は「何を作るか」に集中できます。
設計前に確認したい5つのこと
1. 扱う情報を棚卸しする
最初に、事業で扱う情報を書き出します。「会員の情報」とひとまとめにせず、項目単位で分けるのがポイントです。
- 氏名、住所、電話番号、メールアドレスなどの基本情報
- 生年月日や性別などの属性情報
- 本人確認書類の画像や番号
- 位置情報や行動履歴
- 健康状態や病歴など、取り扱いに特に配慮が必要な情報
- 決済に関わる情報
個人情報保護法には「要配慮個人情報」という区分があります。人種、信条、病歴、犯罪の経歴など、不当な差別や偏見につながるおそれがある情報で、取得には原則として本人の同意が必要です。事業の性質上こうした情報に触れるなら、設計の最初に洗い出しておく必要があります。
棚卸しでは、各項目に「なぜ必要か」を一言添えます。答えられない項目は、最初のバージョンでは取らない判断もあり得ます。必要な情報だけを持つ設計は、事故のときの影響範囲を小さくします。データの持ち方の考え方は、新規事業のデータ設計｜最初に決めたい5つの持ち方でも整理しています。
2. 利用目的と同意の取り方を決める
個人情報保護法では、個人情報を取り扱うときに利用目的をできる限り特定し、取得時に本人へ通知または公表することが求められます。目的の範囲を超えて使う場合は、原則として本人の同意が必要です。
これは法務だけの話ではなく、画面の設計に直結します。
- 登録画面のどこに、利用目的やプライバシーポリシーへの案内を置くか
- 同意が必要な項目と、そうでない項目をどう分けるか
- 同意した日時や内容の履歴を、どのデータとして残すか
- 同意の撤回や、利用停止の依頼を受けたときの操作をどうするか
新規事業では、事業が育つにつれて利用目的が増えます。最初に書いた目的の範囲を超えてデータを使いたくなる場面は、珍しくありません。「将来、別のサービスに使うかもしれない」という見通しがあるなら、目的の書き方を専門家と相談したうえで、同意の履歴を残せる設計にしておくと、後の対応がしやすくなります。
3. 業法や許認可が関わるかを確認する
個人情報とは別に、事業そのものに規制がかかる場合があります。業法は事業ごとに異なり、システムの仕様がそのまま要件になることもあります。いくつか例を挙げます。ただし、該当するかどうかは事業の内容や提供の仕方で変わります。
| 事業の領域（例） | 関わる可能性のある法令の例 | 設計に影響しやすい点 |
|---|---|---|
| お金を預かる・送る・貸す | 資金決済法、貸金業法、犯罪収益移転防止法など | 本人確認の方法、取引記録の保存 |
| 医療・健康に関わる | 医師法、医療法、医薬品医療機器等法など | 医療情報の安全管理、表示内容の制限 |
| 人材紹介・求人 | 職業安定法など | 求職者情報の取り扱い、保管と削除 |
| 中古品の売買 | 古物営業法など | 取引相手の確認、取引記録の保存 |
| 通信販売・定期購入 | 特定商取引法など | 事業者情報や条件の表示、申込み画面の作り |
この表は網羅的なものではなく、「こういう観点で確認する」ための例です。許認可が必要なのか、すでに許認可を持つ事業者と組む形にするのか、で設計は大きく変わります。ここがあいまいなまま画面を作り込むと、後で業務フローごと変えることになりかねません。
業法の確認は、システム側だけで判断しないことが大切です。所管官庁の公式情報や、弁護士・行政書士といった専門家の見解をもとに、「このサービスの形で提供できるのか」を先に確かめます。そのうえで、システムに求められる条件を言葉にします。事業の形とシステムは切り離せないため、新規事業のシステム設計とビジネスモデルの作り方の観点とあわせて考えると整理しやすくなります。
4. 預け先・委託先・外部サービスを洗い出す
個人情報は、自社のシステムの中だけに留まるとは限りません。クラウドのサーバー、メール配信、アクセス解析、決済、チャットサポート、AIの機能。外部のサービスを使うたびに、利用者の情報が自社の外へ出ていく可能性があります。
確認したいのは、次のような点です。
- 個人情報の取り扱いを外部に任せる場合、委託先を適切に監督できているか（個人情報保護法は委託先の監督を求めています）
- 外部サービスへ情報を渡すことが、「委託」なのか「第三者提供」なのか（扱いが異なり、第三者提供は原則として本人の同意が必要です）
- サーバーや委託先が海外にある場合、外国にある第三者への提供に関するルールが関わらないか
- アクセス解析や広告のツールで、利用者の端末の情報が外部へ送信されないか（Cookieなどの情報を扱うルールや、電気通信事業法の外部送信に関する規律が関わる場合があります）
決済については、カード情報などを自社で保持しない設計にするのが一般的な考え方です。外部サービスに任せるか自作するかの分け方は、新規事業の決済システム開発｜外部サービスと自作の分け方で扱っています。
AIの機能を組み込む場合や、開発にAIを使う場合も同じです。個人情報や機密情報をAIへ入力してよいか、入力した情報がどう扱われるかを確かめておきます。開発側の観点は生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアにまとめています。
5. 事故が起きたときの動きを決めておく
どれだけ備えても、事故の可能性をゼロにはできません。個人情報の漏えいなどが起きたとき、一定の場合には個人情報保護委員会への報告と、本人への通知が義務づけられています。何が対象になるかは、公式のガイドラインで確認します。
ここで大切なのは、「事故のとき何を調べるか」をシステム側があらかじめ用意しておくことです。
- 誰が、いつ、どの情報にアクセスしたかを後から追えるか（アクセスログ）
- 影響を受けた利用者を特定し、連絡できるか
- 利用者から削除や開示を求められたとき、どの画面や手順で対応するか
- 問題を見つけた担当者が、誰にどう連絡するか
ログが残っていなければ、何が漏れたのか分からないまま、対応が長引いてしまいます。ログの項目と保存期間は、後から足すより最初に決めておくほうが手戻りが少なくなります。セキュリティ全般の確認点はAI生成コードのセキュリティ｜確認点と人の役割も参考になります。
確認した内容を設計の条件に置き換える
ここまでの確認結果は、そのままでは設計者に伝わりません。「個人情報に気をつける」ではなく、設計の条件として書き換えます。たとえば次のように置き換えます。
| 確認した内容 | 設計の条件の例 |
|---|---|
| 要配慮個人情報は最初は取らない | 入力項目に含めない。将来取る場合は別画面と同意の仕組みを追加する |
| 同意の履歴を残す | 同意の日時・文面のバージョン・対象の利用者を保存するテーブルを持つ |
| 担当者ごとに見られる範囲を分ける | 役割ごとの権限と、閲覧・変更のログを設ける |
| 利用者の削除依頼に対応する | 削除や匿名化を、操作できる機能として用意する |
| 外部サービスに情報を渡す | 渡す項目を必要最小限にし、連携先の一覧を管理する |
| 本人確認が必要な事業 | 確認方法と、記録の保存期間を仕様に含める |
置き換えるときのコツは、法令の細かい条文を設計者が読み込む形にしないことです。専門家が確認した「事業として守る事項」を、設計の条件として短い文章にして渡します。この形にしておくと、後から要件を見直すときも、何のための条件なのかが追えます。要件をどう言葉にするかは、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。
また、設計の決めごとを文書として残しておくことも大切です。担当者が替わっても、なぜこの権限にしたのか、なぜこの項目は取らないのかが分かる状態にしておきます。AI設計書の自動生成は可能？後から困らない残し方では、設計の根拠を残す考え方に触れています。
管理画面は、個人情報が最も集まりやすい場所の一つです。誰が何を見て操作できるかが、そのまま事故のリスクにつながります。最初に作る範囲を見極める視点は、新規事業の管理画面開発｜最初に作る範囲の見極め方で扱っています。
プロトタイプの段階で個人情報をどう扱うか
「設計の前に確認する」というと、すべてが決まるまで何も作れないように聞こえるかもしれません。ただ、新規事業では、実物を見ながら確かめたいことが多くあります。個人情報や業法が関わる場合でも、段階を分ければ両立できます。
ダミーデータで画面と流れを確かめる
プロトタイプの段階では、実在の個人情報を使わず、ダミーのデータで画面と業務の流れを確かめる進め方が基本になります。登録、確認、承認、通知といった流れが事業として成り立つかは、ダミーのデータでも十分に確かめられます。実際の利用者の情報を入れなくても、「この画面で本当に進められるか」「この確認手順は現場で回るか」という判断はできます。
テスト用のデータは、本番のデータを流用しないことも基本です。開発用の環境と本番の環境を分け、本物の個人情報が開発環境に入り込まない仕組みにしておきます。
実際の利用者の情報を入れるタイミングを区切る
実在の利用者に使ってもらう段階、つまりクローズドβなどでは、本物の個人情報が入ります。この段階に進む前に、次の点を揃えておきたいところです。
- 利用目的の通知と同意の取り方が、画面に反映されている
- 権限とログが、最低限の形で動いている
- 外部サービスの利用が、確認済みの範囲に収まっている
- 事故が起きたときの連絡先と手順が決まっている
公開の範囲を絞る考え方は、新規事業のクローズドβ｜進め方と公開範囲の決め方で整理しています。人数を絞るだけでなく、「どの情報を、どこまで入れるか」を段階的に増やしていくと、確認の負担も管理しやすくなります。
作ってみて分かることを、確認に戻す
プロトタイプを動かすと、設計前には見えなかった論点が出てきます。「この項目は実は不要だった」「この確認手順は現場に負担が大きい」といった発見です。それを法務や専門家の確認に戻し、条件を更新していきます。確認とプロトタイプを行き来することで、事業の形と法令対応の両方を現実に近づけられます。
専門家に相談するときの準備
個人情報や業法の確認は、弁護士や行政書士などの専門家と進めるのが安心です。事業の内容によっては、社会保険労務士や、業界に詳しいコンサルタントも関わります。相談の効率を上げるには、システム側の情報を整理して持っていくことが有効です。
- 事業の概要（誰に、何を、どう提供するか）
- 扱う情報の一覧（棚卸しの結果）
- 情報の流れが分かる簡単な図（どこで取得し、どこに保存し、どこへ渡すか）
- 画面のイメージや、プロトタイプの画面
- 使う予定の外部サービスの一覧
言葉だけの説明より、画面や図があるほうが、専門家も具体的に確認できます。システムの担当者と専門家が同じ資料を見て話せる状態にしておくと、認識の食い違いも減ります。
システム開発を外部に依頼する場合は、構想や事業アイデアといった機密情報も渡すことになります。秘密保持の取り決めについては、システム開発のNDA｜秘密保持で決める8つの項目が参考になります。
まとめ
個人情報や業法が関わる新規事業で、システム設計の前に確認しておきたいのは、次の5つです。
- 扱う情報を項目単位で棚卸しし、必要なものだけに絞る
- 利用目的と同意の取り方を決め、画面とデータの持ち方に反映する
- 業法や許認可が関わるかを、専門家とともに確認する
- 預け先・委託先・外部サービスを洗い出し、情報の流れを把握する
- 事故が起きたときの記録と連絡の手順を、設計に含めておく
確認した内容は「個人情報に気をつける」といった心構えではなく、設計の条件として短く書き換えておくと、設計者にも専門家にも伝わりやすくなります。プロトタイプの段階ではダミーのデータで流れを確かめ、実在の利用者の情報を入れる段階の前に、同意や権限、ログを揃える。この順番を意識すると、確認と開発を無理なく並行できます。
私たちJustFitは、先に動くプロトタイプを約1ヶ月で用意し、実物を見てから契約を判断できる進め方の受託開発サービスです。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。個人情報や業法が関わる構想でも、画面やデータの持ち方を実物を見ながらすり合わせていくことで、事業の形を具体的にしていけます。進め方の詳細は、JustFitのサービス紹介をご覧ください。