システムで個人情報を扱うときの保護対応｜発注側が押さえる法対応と実装の基本

会員登録、顧客管理、問い合わせフォーム、決済——システムやアプリを動かせば、氏名・連絡先・住所といった個人情報は自然と手元に集まります。便利さの裏で、これらは個人情報保護法という法律の対象であり、扱い方を誤ると信頼の失墜や行政対応につながります。この記事では、発注側が知っておきたい個人情報保護の考え方と、システムで実装すべき対応を、専門知識がなくてもわかるように整理します。あわせて、プライバシーポリシーや同意取得の設計、漏えい時の流れ、外部委託の注意、発注時の確認事項までまとめます。なお、法律の適用や具体的な判断は必ず弁護士など専門家に確認してください。本記事は一般的な考え方の整理にとどめ、断定的な法解釈は避けます。

個人情報とは — システムでよく扱う場面

個人情報とは、生きている個人を特定できる情報のことです。氏名はもちろん、氏名と組み合わさることで誰なのかがわかる住所・電話番号・メールアドレスなども含まれます。さらに、それ単体で個人を識別できる番号のような情報も対象です。「名前さえ伏せれば大丈夫」とは限らず、複数の情報が結びついて個人を特定できれば、それは守るべき情報になります。

システム・アプリでは、次のような場面で個人情報が集まります。どれも日常的な機能で、意識しないうちに保有していることが少なくありません。

よくある場面	集まる情報の例
会員登録・マイページ	氏名・メールアドレス・パスワード・生年月日
顧客管理・予約	氏名・電話番号・住所・来店/取引の履歴
問い合わせフォーム	氏名・連絡先・問い合わせ内容
決済・購入	氏名・住所・購入履歴（カード情報は原則、専門の決済代行に預ける）

とりわけ注意したいのが、思想・信条や病歴・犯罪歴などの特に配慮が必要な情報です。これらは通常の個人情報より慎重な扱いが求められ、取得の場面から見直しが必要になることがあります。自社のシステムがこうした情報に触れる場合は、早い段階で専門家に相談しておくのが安全です。

発注側がまず意識したいのは、「便利だから集める」と「守る責任を負う」は表裏一体だという点です。会員機能を付ければ会員情報を、予約機能を付ければ来店履歴を、フォームを置けば問い合わせ内容を、それぞれ抱えることになります。機能を増やすほど守るべき範囲も広がります。だからこそ、システムを企画する段階で「この機能で何の情報が集まり、それをどう守るのか」まで一緒に考えておくことが、後々の負担とリスクを小さくする近道になります。

個人情報保護法で求められる基本的な考え方

個人情報保護法は細かな条文の集まりですが、発注側がまず押さえたい大きな柱は次の4つです。いずれも「集めて終わり」にせず、目的・約束・守り方・渡し方をはっきりさせる、という発想でつながっています。

柱	かみくだくと
利用目的の特定・通知	何のために使うかを決め、本人にわかるようにする
適正な取得・同意	だましたり無断で集めたりしない。必要な場面では同意を得る
安全管理措置	集めた情報を漏らさない・失わないよう適切に管理する
第三者提供のルール	本人の同意なく勝手に他社へ渡さない（例外の定めはある）

ポイントは、「必要な情報を・決めた目的の範囲で・きちんと守って使う」という一貫した姿勢です。この姿勢さえ据われば、細かなルールの多くは自然と守られる方向に働きます。たとえば「発送のために住所を集めた」なら、その住所を無関係な広告のために使い回すのは目的外です。集める前に「何に使うのか」を言葉にしておくと、後の設計も運用も筋が通ります。なお、外部の会社に処理を任せる委託は「第三者提供」とは扱いが異なるなど、区別のややこしい論点も多いため、具体的な当てはめは専門家の確認が確実です。

システムで実装すべき5つの対策

法律が求める安全管理措置を、システム側で形にしたものが以下の5点です。ここは開発会社の腕の見せどころで、発注側は「これらがきちんと組み込まれているか」を確認できれば十分です。脅威対策全般の基礎はシステム開発のセキュリティ対策もあわせてご覧ください。

• アクセス権限：誰がどの情報を見られるかを役割ごとに絞る。全員が全データを見られる状態は避け、必要な人が必要な範囲だけ触れるようにする。
• 暗号化：通信の暗号化（保存・やり取りの保護）に加え、パスワードなどは元に戻せない形で保存する。端末や保存領域が盗まれても中身を読めないようにする。
• ログ（操作記録）：いつ・誰が・どの情報にアクセスしたかを記録する。不正や漏えいの兆候に早く気づけ、事故時の原因究明にも役立つ。
• 保存期間：使い終わった情報をいつまでも溜め込まない。目的を果たした情報は期限を決めて扱う。
• 削除：不要になった情報や、本人から求められた情報を、確実に消せる仕組みを持つ。

見落とされがちなのが保存期間と削除です。集める仕組みは作っても、消す仕組みを用意していないシステムは意外に多いものです。情報は持っているだけで漏えいのリスクになり、量が増えるほど守るコストも上がります。退会した会員の情報がいつまでも残り続ける、テスト用に入れた実在データが本番に紛れている——こうした「溜め込み」は、事故が起きたときに被害を無用に大きくします。「使わない情報は持たない・残さない」という考え方を、設計段階から開発会社と共有しておくと、リスクそのものを小さくできます。個別開発なら、こうした保存・削除のルールを自社の運用に合わせて作り込めます（顧客管理を自作するケースや会員管理システムも参考になります）。

プライバシーポリシーと同意取得の設計

集める前に本人へ示す約束が**プライバシーポリシー（個人情報保護方針）**です。難しく考えず、次の要素を自社の実態に合わせて書くのが基本形です。テンプレートの丸写しは、書いてある内容と実際の使い方がずれる原因になるため避けます。

記載する要素	中身の例
取得する情報	氏名・連絡先・購入履歴など、実際に集めるもの
利用目的	発送・連絡・本人確認など、使う範囲を具体的に
管理の方法	安全に管理する旨、委託先がある場合はその扱い
第三者提供	渡す相手・目的（渡さないなら渡さないと明記）
開示・訂正・削除の窓口	本人からの求めに応じる連絡先

同意取得も、システムの作り方で誠実さが変わります。フォームの送信ボタンの近くに方針への同意チェックを置く、初期状態でチェックを入れておかない、目的を隠さない——こうした設計は、後から「勝手に集められた」と言われないための備えです。逆に、細かな文字で埋もれさせたり、同意しないと先に進めないのに何に同意したのか分からせなかったりする作りは、たとえ形式が整っていても信頼を損ないます。利用者が「何に同意したか」を自分の言葉で説明できる状態を目指すと、設計の善し悪しを判断しやすくなります。問い合わせや会員登録のフォーム設計では、入力の手間と同意の分かりやすさの両立を意識するとよいでしょう。ただし、どの場面で同意が必須かは事案によって異なるため、文面と取得方法は最終的に専門家の確認を受けることをおすすめします。

漏えいが起きたときの対応の流れ

どれだけ備えても、事故の可能性はゼロにはなりません。大切なのは、起きたときにあわてず正しい順番で動けるかです。一般的な流れは次のとおりです。

1. 止める：被害の拡大を食い止める（該当機能の停止、パスワード変更、原因の遮断など）。
2. 調べる：何の情報が・どれだけ・なぜ漏れたかを確認する（ここでログが役立つ）。
3. 報告する：定められた場合、監督官庁への報告を行う。
4. 知らせる：影響を受ける本人へ、必要に応じて通知する。
5. 再発を防ぐ：原因をふさぎ、体制や設計を見直す。

近年は、一定の漏えいについて報告と本人への通知が義務とされ、対応の遅れは信頼の低下や行政対応につながります。報告の要否・期限・方法は事案ごとに異なるため、実際に起きたら速やかに専門家へ相談するのが原則です。そのうえで、平常時に「誰が指揮を執るか」「連絡先はどこか」「誰に相談するか」を一枚にまとめておくと、いざというとき初動で迷いません。あわせて、事故で失われたデータを戻せるように、バックアップとBCPの備えも一体で考えておくと安心です。

事故の重さは、漏れた情報の中身と量で大きく変わります。よくある失敗を一般化した例で示します（いずれも架空のケースです）。例：退職者のアカウントを放置していたケース。 使われなくなった管理者アカウントが残ったまま乗っ取られ、顧客名簿が外部に流出。権限の棚卸しをしていれば防げた。例：ログを取っていなかったケース。 漏えいの疑いが出たものの、誰がいつアクセスしたかの記録が無く、範囲の特定に時間がかかり、結果として広めに通知せざるを得なかった。いずれも、平常時の地味な備え（権限管理・記録）が、事故時の被害の大きさを左右することを示しています。

クラウド・外部委託を使うときの注意

いまや多くのシステムはクラウド上で動き、機能の一部を外部サービスに任せます。便利な反面、個人情報を他社の手に預ける局面が増えるということでもあります。注意したいのは次の点です。

• 委託先の管理責任：処理を委託しても、元の事業者としての責任がなくなるわけではない。委託先が適切に守れるかを確認し、契約で守り方を定めておく。
• 保管場所と再委託：データがどこに保管されるか、委託先がさらに別の会社へ再委託しないかを把握する。
• 決済・カード情報：カード番号は自社で持たず、専門の決済代行に預けるのが一般的。自社システムに保持するほど、守るべき範囲もリスクも増える。
• アカウント管理：クラウドの管理画面こそ厳重に。権限を絞り、退職者のアカウントを放置しない。

自社運用（オンプレミス）とクラウドのどちらが向くかは、クラウドとオンプレミスの違いで整理しています。どちらを選ぶにせよ、「誰がどこまで責任を負うか」を契約と設計の両面ではっきりさせておくことが、後々のトラブルを防ぎます。委託や責任分界の取り決めは、システム開発の契約の観点でも確認しておくとよいでしょう。

中小企業が最低限やっておきたいこと

「大企業のような体制は組めない」と感じても、土台の数項目を押さえるだけでリスクは大きく下がります。まずここから始めましょう。

1. 持っている個人情報を洗い出す（どのシステムに・何が・どれだけあるかを把握する）。
2. 利用目的を言葉にする（何のために集め、どう使うかをはっきりさせる）。
3. プライバシーポリシーを実態に合わせて用意する（テンプレ丸写しにしない）。
4. アクセス権限を絞る（担当者ごとに、見られる範囲を必要最小限にする）。
5. 不要な情報を溜め込まない（使い終わった情報の保存期間と削除を決める）。
6. 委託先を把握する（外部サービスに何を預けているかを一覧にする）。
7. 漏えい時の連絡先と手順を決めておく（誰が動き、誰に相談するかを一枚に）。

これらは一度に全部そろえる必要はありません。まずは「持っている情報の洗い出し」と「利用目的の明確化」という、お金のかからない棚卸しから着手すれば十分です。土台が見えれば、システム側で何を実装すべきかも自然と定まります。完璧を目指して手つかずのまま放置するより、不完全でも今日から1つ始めることが、結果的にいちばんの近道です。ただし、自社の対応が法的に十分かどうかの最終判断は、専門家に確認するようにしてください。

発注時に開発会社へ確認すべきこと

専門知識がなくても、次を質問できれば十分です。答え方そのものが、その会社が個人情報をどれだけ真剣に扱うかを映します。

• アクセス権限を役割ごとに分けられるか：全員が全データを見られる作りになっていないか。
• 暗号化はどうなっているか：通信とパスワードなど、守り方を具体的に説明できるか。
• ログは残るか：誰がいつ何にアクセスしたかを記録し、後から追えるか。
• 保存期間と削除の仕組みはあるか：不要な情報や本人の求めに応じて消せるか。
• 委託先・保管場所はどこか：外部サービスの範囲と、その守り方を示せるか。
• 漏えい時の対応をどう考えるか：発見・停止・記録の仕組みがあるか。

個人情報の話を避ける・「大丈夫です」だけで具体が出ない会社は要注意です。逆に、良い会社ほど「どんな情報を何に使い、どこまで守りたいか」を先に聞き、それに見合った設計を提案します。あわせて、脆弱性診断のような公開後の点検や、保守契約にどこまで含まれるかも確認しておくと、運用開始後も安心です。なお、実装をいくら整えても法的な最終判断は専門家の領域である点は変わりません。**開発会社（実装）・発注側（方針決定）・専門家（法判断）**の三者で役割を分担する前提で進めるのが現実的です。

D-oneApp のシステム開発は、料金を着手前に総額で確定する体系です（スタンダード一律100万円／プロ一律200万円、追加費用なし）。アクセス権限や暗号化、ログ、保存・削除といった個人情報を守る実装も設計・見積りに織り込むため、「後から個人情報対応の費用が積み増される」心配がありません。成果物であるソースコードの権利もお客様に渡すため、将来的に運用先を変えたいときにも柔軟に対応できます。

まとめ

システムやアプリを動かせば、会員・顧客・問い合わせ・決済を通じて個人情報は自然と集まり、その扱いは個人情報保護法の対象になります。押さえるべきは、利用目的の特定・適正な取得と同意・安全管理措置・第三者提供のルールという4つの柱です。システム側では、アクセス権限・暗号化・ログ・保存期間・削除の5点を実装に組み込み、実態に合ったプライバシーポリシーと誠実な同意取得を設計し、漏えい時に迷わず動ける備えを持つことが肝心です。クラウドや外部委託では「誰がどこまで責任を負うか」を明確にしておきましょう。ただし、法律の適用や具体的な判断は必ず専門家に確認してください。自社に必要な対応の整理や、開発会社への確認の進め方は、無料相談でもご説明します。