コンテンツにスキップ

個人情報保護の基本:システムを作る人が知っておきたいルール

Section titled “個人情報保護の基本:システムを作る人が知っておきたいルール”

なぜシステムを作る人が理解する必要があるのか

Section titled “なぜシステムを作る人が理解する必要があるのか”

会員登録、オンライン取引、問い合わせ、採用、従業員管理など、多くのシステムは個人情報を扱います。個人情報の保護は、法律に沿って実装すべきシステムの要件です。

情報が漏えいすると、本人が詐欺やなりすましなどの被害に遭うおそれがあります。企業にも調査・復旧・説明の負担が生じ、顧客や取引先の信頼を失います。

何を、何のために取得し、誰が利用し、どこに保存し、いつ削除するのか。 これを設計段階で決めることが、個人情報保護の出発点です。

本記事は、民間事業者がシステムを設計・運用する際の基本を整理しています。法律上のルールと、そのルールを実現するための設計例を分けて説明します。

個人情報保護法は、個人情報の有用性に配慮しながら、個人の権利や利益を守るための法律です。正式名称は「個人情報の保護に関する法律」です。

事業者には、利用目的の明確化、安全な管理、第三者提供の制限、本人からの請求への対応などが求められます。大企業だけの法律ではなく、個人情報データベース等を事業に利用する中小企業や個人事業主にも適用されます。

「安全に保存する」だけでなく、「本人に説明した目的で使う」「必要な同意を得る」「本人の権利に対応する」ことも必要です。

参考:個人情報保護委員会・ガイドライン(通則編)

個人情報とは、生存する個人に関する情報で、特定の個人を識別できるもの、または個人識別符号を含むものです。他の情報と容易に照合して本人を識別できる場合も含まれます。

情報 個人情報として考えるポイント
氏名 本人の氏名は個人情報に該当する
住所 氏名や顧客情報との組合せなどで本人を識別できる場合に該当する
電話番号 顧客台帳などと容易に照合して本人が分かる場合も該当する
生年月日 氏名などとの組合せで本人を識別できる場合に該当する
メールアドレス 単独で本人が分かる場合や、登録情報と容易に照合できる場合に該当する
パスポート番号 法令で定める個人識別符号に該当し、番号だけでも個人情報になる
顔認証データ 本人を識別できるよう顔の特徴を変換した所定のデータは、個人識別符号に該当する

個人識別符号には、公的な番号のほか、本人を識別するために身体の特徴を変換した顔・指紋などの認証データがあります。顔写真そのものも、本人を識別できれば個人情報です。

氏名を顧客IDに置き換えても、顧客台帳と容易に照合できるなら個人情報です。暗号化した情報や公開済みの情報も、それだけで保護対象から外れるわけではありません。

参考:政府広報オンライン・個人情報保護法の解説、通則編・定義

要配慮個人情報は、不当な差別や偏見などの不利益が生じないよう、特に配慮が必要な個人情報です。

例として、人種、信条、社会的身分、病歴、犯罪の経歴、犯罪被害の事実、障害に関する情報、健康診断の結果、診療・調剤に関する情報などがあります。

取得には原則として本人の同意が必要で、オプトアウトによる第三者提供も認められません。オプトアウトとは、所定の条件を満たした上で、本人から停止の求めがあるまで提供する仕組みです。

「重要・機密だから要配慮個人情報になる」という分類ではありません。例えば、口座残高やパスポート番号は重要な情報ですが、それだけで要配慮個人情報になるわけではありません。実務では、法律上の分類と漏えいした場合の被害の大きさを両方考えます。

参考:個人情報保護委員会・要配慮個人情報のFAQ

個人情報データベース等・個人データ・保有個人データの違い

Section titled “個人情報データベース等・個人データ・保有個人データの違い”

この区別によって、適用されるルールが変わります。

用語 意味 例
個人情報 本人を識別できる情報など 氏名が書かれた申込書
個人情報データベース等 特定の個人情報を検索できるよう体系的に整理した情報の集合 顧客DB、検索できる顧客一覧Excel、索引付きの紙の顧客台帳
個人データ 個人情報データベース等を構成する個人情報 顧客DBに登録された一人分の情報
保有個人データ 事業者が開示・訂正・利用停止・消去などを行う権限を持つ個人データ。法定の除外あり 自社が管理し、開示等に対応できる顧客情報

「データベース」はRDSやPostgreSQLだけを指す言葉ではありません。Excelや紙の台帳も該当し得ます。また、DBから出力したCSVや帳票も個人データになり得ます。

保有個人データは、単に自社サーバーに保存されているデータという意味ではありません。委託先が保管していても、開示等の権限が委託元にある場合は、委託元の保有個人データになり得ます。

参考:通則編・2-4、2-6、2-7

取得・利用するときの基本ルール

Section titled “取得・利用するときの基本ルール”

利用目的を具体的に定め、その範囲で適正に取得・利用することが基本です。

利用目的は原則として本人への通知または公表が必要です。Webフォームなどで本人から直接書面・電子的な記録により取得する場合は、原則として事前に利用目的を明示します。

通常の個人情報の取得に、常に本人同意が必要なわけではありません。一方、要配慮個人情報の取得や、定めた利用目的の達成に必要な範囲を超える利用には、原則として同意が必要です。違法・不当な行為を助長するような利用も禁止されています。

以下は実装・運用の例です。

設計項目 具体例
取得項目 問い合わせ対応だけなら、生年月日や本人確認書類まで求めない
利用目的の表示 入力フォームで、返信・本人確認などの用途を説明する
同意の記録 必要な同意について、日時、対象、説明文の版を保存する
用途の変更 問い合わせ情報を広告配信に使う際、元の目的で認められるか確認する
外部連携 入力情報を解析・広告・AIサービスに送る処理もデータフローに含める

参考:通則編・利用目的、取得

保管・管理するときの基本ルール

Section titled “保管・管理するときの基本ルール”

個人データには、漏えい・滅失・毀損を防ぐための必要かつ適切な安全管理措置が必要です。従業者や委託先の監督も求められます。利用目的に必要な範囲で正確・最新に保ち、利用する必要がなくなったときは遅滞なく消去するよう努めます。

システムと運用で実現する対策例

Section titled “システムと運用で実現する対策例”

以下の手段がすべて一律に法律で指定されているわけではありません。データの性質、量、業務、被害の大きさに応じて選びます。

分類 対策例
組織・責任 管理責任者、取扱手順、事故の連絡先、定期点検を定める
人・教育 従業者への教育、秘密保持、退職時の権限削除を行う
物理的な保護 端末・媒体の持出し制限、施錠、書類や媒体の適切な廃棄を行う
アクセス制御 職務別に最小限の権限を与え、管理者認証を強化する
通信・保存 TLS、保存時の暗号化、鍵のアクセス制限を設計する
ログ・監視 閲覧・変更・CSV出力を記録し、大量取得などを検知する
開発・テスト 本番データを安易に複製せず、テスト用の架空データを使う
保存期間 データごとに期間を定め、バックアップや出力ファイルも削除計画に含める
外国での取扱い 関係する外国の制度を把握し、アクセス元や再委託先も確認する

アプリのDBだけでなく、ログ、監視ツール、メール、添付ファイル、バックアップにも個人情報が入ることがあります。特にログへ本人確認書類やフォームの全内容を出力する実装は避けます。

参考:通則編・安全管理措置

第三者に提供するときの基本ルール

Section titled “第三者に提供するときの基本ルール”

個人データを第三者に提供するときは、原則として事前に本人の同意が必要です(第27条)。法令に基づく提供などには例外があります。

第三者提供は、ファイルを渡す場合だけではありません。外部の会社がデータを利用できるよう閲覧権限やAPIアクセスを与える場合も該当し得ます。第三者提供や受領については、法定の確認・記録義務が適用されるかも確認します。

判断の軸は、自社の業務を代行するために使うのか、相手が独自の目的で使うのかです。

項目 業務委託に伴う提供 委託に該当しない第三者提供
目的 委託元の利用目的の達成に必要な業務を代行する 提供先が独自の目的で利用する
例 顧客へのメール送信、本人確認、配送の代行 他社が自社商品の営業に使うため顧客リストを受け取る
国内での同意 第27条では第三者に該当せず、第三者提供の同意は原則不要 原則必要。法定の例外あり
委託元の責任 委託先を必要かつ適切に監督する 委託先監督としての義務とは別に、提供の適法性を確認する

例えば、メール配信会社が指定された顧客に報告書を送るだけなら、業務委託になり得ます。その顧客情報を配信会社自身の広告に使わせる場合は、委託の範囲を超えます。契約の名前だけでなく、実際の利用目的と取扱いを確認します。

委託では、安全管理措置、目的外利用の禁止、再委託、事故時の通知、契約終了後の返却・削除などを契約と運用で管理します。同意不要でも、管理責任がなくなるわけではありません。

また、グループ会社も別法人であれば、同じグループという理由だけでは第三者提供の制限を免れません。業務委託や、法定事項を事前に通知するなどの要件を満たす共同利用に当たるかを確認します。

参考:通則編・第三者提供、第三者提供時の確認・記録義務編

外国にある第三者への提供は、なぜ別に説明されるのか

Section titled “外国にある第三者への提供は、なぜ別に説明されるのか”

外国への提供には、外国の制度や提供先の保護措置を踏まえた追加のルールがあります(第28条)。国内で同意不要となる業務委託でも、この規定が適用される外国への提供では原則として同意が必要です。

ケース 同意の考え方
国内の委託先への提供 委託の要件を満たせば、第三者提供の同意は原則不要
第28条が適用される外国の相手への提供・委託 原則として外国への提供を認める本人同意が必要
委員会が日本と同等水準と認めた外国の相手への提供 第28条の同意は不要。第27条に従い、委託か通常の第三者提供かを判断する
日本法に相当する措置を継続的に講じる所定の体制を整えた相手への提供 第28条の同意は不要。第27条に従うほか、相当措置の継続確保等が必要

第28条に基づく同意を得る場合は、原則として提供先の外国名、その国の個人情報保護制度、提供先の保護措置について事前に情報を提供します。法令に基づく提供などには例外があります。

第27条と第28条の同意を必ず二重に取るという意味ではありません。第28条が適用される場合は、その規定に沿った外国提供同意を取得します。

参考:外国にある第三者への提供編

AWSやメール配信サービスを利用する場合

Section titled “AWSやメール配信サービスを利用する場合”

外国企業のサービスを使うことや外国のサーバーに保存することだけで、直ちに外国への第三者提供になるわけではありません。

クラウド事業者が個人データを取り扱わないことが契約と適切なアクセス制御などで確保されている場合は、個人データの提供に該当しない扱いがあります。この場合でも、利用企業自身の安全管理措置は必要です。

サービス選定時には次を確認します。

  1. 誰がデータを取り扱うか。契約先だけでなく、サポート担当や再委託先も確認する。
  2. 保存場所とアクセス元はどこか。
  3. 委託業務の範囲だけで利用するか。独自の広告や学習などへの利用はあるか。
  4. 第三者提供・委託・外国への提供のどのルールが適用されるか。
  5. 同意または例外の条件をどう満たし、その状態をどう維持するか。

AWSやSendGridなども、サービス名だけで一律に判断せず、利用機能・契約・実際の取扱いに基づいて評価します。

参考:クラウド利用のFAQ(Q7-53)、外国サーバーへの保存のFAQ(Q12-3)、外的環境の把握のFAQ(Q10-25)

漏えい等が発生したときの基本ルール

Section titled “漏えい等が発生したときの基本ルール”

「漏えい等」は、外部への流出だけでなく、データを失う「滅失」、内容が壊れる「毀損」も含みます。

次のような法定の報告対象事態では、発生のおそれがある場合も含め、個人情報保護委員会等への報告と本人への通知が必要です。

報告対象となる事態 例
要配慮個人情報を含む 健康診断結果の漏えい
財産的被害が生じるおそれがある 不正決済につながるカード情報の漏えい
不正な目的による漏えい等のおそれがある サイバー攻撃や従業員による持出し
本人の数が1,000人を超える 大規模な顧客データ流出

速報は速やかに行い、目安は認知後おおむね3~5日以内です。確報は原則30日以内、不正な目的による事態は60日以内です。本人への通知も状況に応じて速やかに行います。通知が困難で、本人の権利利益を保護するための代替措置を取る場合など、法定の例外があります。

実務では、担当部署への連絡、被害拡大の防止、証拠保全、影響範囲の調査、報告・通知、再発防止を進めます。報告の要否を判断するためにも、誰の、どの情報が、どこまで影響を受けたか追跡できる設計が必要です。

参考:漏えい等報告・本人通知、通則編・漏えい等の報告

本人からの開示・訂正・利用停止等への対応

Section titled “本人からの開示・訂正・利用停止等への対応”

保有個人データについては、法定の条件に従って、本人からの開示、訂正、利用停止・消去などの請求に対応します。利用目的や受付手続、問い合わせ先なども、本人が知り得る状態にしておきます。

システムでは、本人確認、対象データの検索・抽出、変更・停止処理、対応記録を準備します。退会時にすべて即時削除する設計ではなく、法令上の保存義務がある記録との関係も整理します。

参考:通則編・保有個人データ

プライバシーマーク(Pマーク)とは

Section titled “プライバシーマーク(Pマーク)とは”

プライバシーマークは、個人情報を適切に保護する体制を整備した事業者を評価し、マークの使用を認める制度です。JIPDECが運営し、JIS Q 15001に準拠した構築・運用指針に基づいて審査します。

対象は、個人情報保護マネジメントシステム(PMS)という、方針・責任体制・手順・教育・点検・改善の仕組みです。原則として法人単位で付与され、有効期間は2年です。

個人情報保護法 Pマーク
法律上、守るべきルール 個人情報保護の体制と運用を評価する制度
適用対象の事業者は遵守する必要がある 取得は任意。取引条件で求められる場合はある
Pマーク未取得でも遵守が必要 取得後も継続的な運用・改善が必要

Pマークは、特定のシステムで情報漏えいが起きないことを保証するものではありません。また、「個人情報保護士認定試験」は個人の知識を認定する試験であり、事業者に付与されるPマークとは別の制度です。

参考:JIPDEC・プライバシーマーク制度の概要

システムの要件として最初に整理すること

Section titled “システムの要件として最初に整理すること”

以下は、設計書に落とし込むための確認項目の例です。

確認項目 要件として決めること
データの一覧 取得する項目、要配慮個人情報の有無、ログ・帳票・バックアップへの複製
目的と説明 項目ごとの利用目的、入力画面の説明、必要な同意と記録
権限 閲覧・変更・削除・出力できる利用者と管理者
外部への流れ 送信先、委託先、再委託先、国、提供の法的な根拠
保存と削除 保存期間、法定保存、退会後の処理、バックアップの扱い
本人の権利 開示・訂正・利用停止等の受付と対応手順
事故対応 検知、連絡、証拠保全、影響調査、報告・通知の責任者

金融・医療などでは分野別のガイドラインも確認します。マイナンバーを含む情報には、番号法による追加の制限もあります。

個人情報保護をセキュリティ要件、画面仕様、データ設計、外部サービス契約、運用手順に反映することで、開発後に対応漏れが見つかることを防げます。

確認日:2026年10月9日。法律・ガイドラインの改正時は、適用される規定と施行日を確認してください。