個人情報保護法の要点。エンジニアが知っておくべきこと

個人情報保護法は、法務や総務だけの話だと思われがちです。しかし実際には、データベースの設計、ログの取り方、外部APIへの連携、退会処理の実装、そして障害対応の手順まで、エンジニアの判断が法令の要求と直結します。たとえば「ユーザのメールアドレスをログにそのまま出力していた」「テスト環境に本番のユーザデータをコピーしていた」「不正アクセスでデータが流出したが、何を誰に報告すべきか分からず初動が遅れた」。これらはいずれも、設計や運用の段階で法令を意識していれば避けられた、あるいは被害を小さくできた問題です。

この記事は、法律家向けの逐条解説ではありません。エンジニアが日々の設計・実装・運用で「ここは法令が絡む」と気づき、適切な人を巻き込み、最低限の判断ができるようになることを狙います。具体的には、(1)何が「個人情報」「個人データ」に当たるのかという定義、(2)実装と運用で担保すべき安全管理措置、(3)漏えいが起きたときに誰へ何を何日以内に報告するのか、という3点を一次情報に沿って整理します。

なお、法令やガイドラインは改正されます。本記事は執筆時点の個人情報保護委員会（以下、委員会）の公開情報に基づきますが、実務で判断を要する場面では必ず最新のガイドラインと自社の法務・プライバシー担当に確認してください。条文の解釈や個別事案の当てはめは専門家の領域であり、本記事はその手前の「現場の地図」を提供するものです。

早見表: エンジニアが押さえる3つの論点#

まず全体像です。細部に入る前に、用語・守り・事故対応の3つの軸で「現場で何を判断するか」を俯瞰します。

この3軸は順番に効いてきます。範囲を取り違えると守るべき対象を見誤り、守りが甘いと事故が起き、事故対応の知識がないと報告義務違反に至ります。エンジニアはこの3つすべての入口に立っている、と意識してください。

「個人情報」と「個人データ」は何が違うか#

法令は似た用語を使い分けます。委員会の公式FAQによれば、それぞれの定義はおおむね次の通りです。

まず個人情報とは、生存する個人に関する情報であって、氏名・生年月日その他の記述等により特定の個人を識別できるもの、または「個人識別符号」が含まれるものを指します。ここで重要なのは、必ずしも氏名が必要ではないという点です。他の情報と容易に照合でき、それによって特定の個人を識別できるなら、その情報も個人情報に含まれます。たとえば社内で管理番号と氏名の対応表があり、ログにその管理番号が出ていれば、ログ単体では匿名に見えても照合により個人を識別できるため、実質的に個人情報として扱う必要が出てきます。

個人識別符号は、指紋や顔認証データのような身体的特徴をデータ化したもの、あるいはマイナンバーや旅券番号のように個人ごとに割り当てられた符号を指します。これらは単体で特定の個人を識別できるものとして、それ自体が個人情報になります。

次に個人データとは、「個人情報データベース等」を構成する個人情報です。個人情報データベース等とは、コンピュータで検索できるよう体系的に構成したもの、または紙でも一定の規則で整理して容易に検索できるようにしたものを指します。つまり、検索可能な形で整理されてはじめて「個人データ」になります。ばらばらのメモ書きと、ユーザIDで引けるDBレコードでは、後者がより重い義務（安全管理措置や第三者提供の制限など）の対象になります。エンジニアが扱うのは、まさにこのデータベース化された個人データであることが多い点に注意してください。

そして保有個人データとは、個人データのうち、事業者が開示・内容の訂正・追加・削除・利用停止・消去・第三者提供の停止を行う権限を持つものです。本人からの請求に応じる義務は、この保有個人データに対して生じます。ただし権利の中身は一律ではなく、開示は原則として請求に応じる一方、訂正・追加・削除は内容が事実でない場合に、利用停止・消去や第三者提供の停止は法令違反など一定の要件に該当する場合に求められる、という整理になっています。退会機能や「自分のデータをダウンロードする」機能の実装が、この本人の権利と結びつきます。

最初は「DBに名前カラムがあるテーブルだけ気をつければいい」と思っていました。実際に整理してみると、アクセスログのIPとユーザID、問い合わせ履歴、決済の与信情報、退会済みユーザのバックアップまで、個人データはサービス全体に散らばっていました。どこに何があるかを棚卸しすること自体が、設計の見直しになりました。

この用語整理は、後述する安全管理措置と漏えい報告の両方に効いてきます。たとえば漏えい報告の義務は基本的に「個人データ」の漏えい等を対象に判断します。だからこそ、自社のどのデータが個人データに該当するかを把握しておくことが、平時にも有事にも出発点になります。データの棚卸しは、社内ルールづくりとも地続きです。社内方針の整備については

もあわせて参照してください。

安全管理措置を実装と運用に落とす#

個人情報取扱事業者には、取り扱う個人データの安全管理のために必要かつ適切な措置を講じる義務があります。委員会のガイドライン（通則編）は、この安全管理措置を、基本方針の策定に加えて、組織的・人的・物理的・技術的の4区分、さらに外的環境の把握という観点で整理しています。エンジニアの仕事は、このうち主に技術的・物理的な部分の実装と、組織的・人的な仕組みの運用に深く関わります。

それぞれの区分で、現場が何をするのかを具体的に見ていきます。

組織的・人的安全管理措置#

組織的安全管理措置は、責任者の設置、取扱規程の整備、点検・監査の仕組みなど、運用の枠組みを指します。人的安全管理措置は、従業者への教育・監督です。エンジニア視点では、誰が本番データにアクセスできるかの権限設計と棚卸し、アクセス権の付与・剥奪のフロー、退職者アカウントの即時無効化などが該当します。これらは技術で支える部分が大きく、「申請ベースの権限付与」「定期的なアクセス権レビュー」「操作ログの保全」を仕組み化することが、組織的措置の実体になります。

物理的・技術的安全管理措置#

物理的安全管理措置は、機器や記録媒体の管理、持ち出しの制御、廃棄時のデータ消去などです。技術的安全管理措置は、アクセス制御、不正アクセスの防止、通信の暗号化、ソフトウェアの脆弱性対応などを含みます。エンジニアが日々向き合うのはここです。具体的には、保存時・通信時の暗号化、最小権限の徹底、認証の強化、ログの取得と監視、そして脆弱性への継続的な対応が柱になります。

外的環境の把握#

外的環境の把握は、個人データを保管している国の制度やリスクを踏まえて措置を講じる、という観点です。クラウドや外部サービスを使う場合、データがどの国に保管されるか、その国の法制度はどうかを把握しておくことが求められます。海外リージョンのストレージや海外SaaSへデータを預ける構成では、この観点が実務上の論点になります。委託先・再委託先を含めて、データの所在と管理状況を把握しておくことが重要です。

安全管理措置の区分（基本方針の策定、組織的・人的・物理的・技術的安全管理措置、外的環境の把握）と、事業の規模や取り扱う個人データの性質・量に応じて「必要かつ適切な措置」を講じる考え方は、個人情報保護委員会のガイドライン（通則編）で整理されています。具体的に何を行うべきかは、同ガイドラインの別添「講ずべき安全管理措置の内容」を参照してください。

なお、安全管理措置の中身は、事業の規模や扱う個人データの性質・量に応じて変わります。小規模な事業者には負担に配慮した考え方も示されています。大企業と同じ重装備を一律に求めるものではなく、自社のリスクに見合った「必要かつ適切な」措置を選ぶ、という発想が基本です。

漏えいが起きたら誰へ何を報告するか#

ここが、インシデント対応でエンジニアが最も法令と接近する場面です。一定の個人データの漏えい等が発生した場合、事業者には委員会への報告と本人への通知が義務付けられます。「自社で判断して様子を見る」では済まないケースがある、という点をまず理解してください。

報告義務が生じる4類型#

委員会の公開情報によれば、報告義務の対象となるのは、個人の権利利益を害するおそれが大きい次のような事態です。

ここで注意したいのは、「漏えい」だけでなく「滅失」「毀損」も報告対象になりうる点です。外部に出ていなくても、ランサムウェアで暗号化されて復元できなくなった、誤ってデータを削除して復旧できない、といった事態も含まれます。また「1,000人を超える」は実際に漏えいした件数だけでなく、漏えいのおそれがある件数も含めて判断されます。件数が確定しないからといって、報告不要と即断しないことが大切です。

なお、これらの類型に当てはまる場合でも、高度な暗号化その他の個人の権利利益を保護するために必要な措置を講じていた場合には、報告対象から除かれることがあります。たとえば適切に暗号化された状態のデータが漏えいし、復号鍵が別管理で漏えいしていないようなケースです。とはいえ、この除外に当たるかの判断は容易ではないため、実装上の暗号化を理由に安易に「報告不要」と決めつけず、要否は法務・プライバシー担当と確認してください。

速報と確報、そして本人通知#

報告は2段階です。委員会の資料では、報告すべき事態を知った時点から、速やかに（おおむね3〜5日以内）まず分かっている範囲で「速報」を行い、その後に詳細な「確報」を提出する流れが示されています。確報の期限は、原則として事態を知った日から30日以内です。ただし、不正の目的をもって行われたおそれがある漏えい等（不正アクセスや故意の持ち出しなど）の場合は、60日以内とされています。

あわせて、対象となる本人への通知も義務です。事態の状況に応じて速やかに、概要・対象となる項目・原因などを、本人に分かりやすい方法で通知します。本人への連絡が困難な場合は、ホームページでの公表や問い合わせ窓口の設置といった代替措置が認められています。

報告の流れや初動の手順は、平時に決めておかないと有事に機能しません。漏えい発生時の具体的な対応手順については

で掘り下げます。あわせて、フィッシングや認証情報の漏えいが漏えい事案の起点になることも多いため、

あわせて読みたい

フィッシングの手口と対策の基本。個人と組織でできることを徹底解説

のような入口対策と、

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

のようなログ保全の備えが、事故対応の実効性を支えます。

漏えいが疑われたとき、最初に困るのは「結局、何件で、何の情報が出たのか」が分からないことです。ログが足りないと事実確認に時間がかかり、その間に報告期限が迫ります。平時から、誰が報告の旗振りをするか、技術側は何を確認して誰に渡すかを決めておくと、いざというときの初動がまったく変わります。

よくある質問#

まとめ#

個人情報保護法は、法務だけの問題ではなく、設計・実装・運用・事故対応のすべてに関わります。エンジニアが押さえるべきは、(1)個人情報・個人データ・保有個人データの違いと、識別できるかで判断する考え方、(2)組織・人・物理・技術・外的環境の5観点で安全管理措置を点検すること、(3)一定の漏えい等は委員会への報告（速報3〜5日、確報30日または60日）と本人通知が義務であること、の3点です。これらを平時から意識しておくことが、有事の被害と法的リスクの両方を小さくします。

法令対応は、社内ルールの整備と漏えい時の手順整備とセットで効きます。あわせて

と

あわせて読みたい

情報漏えい発生時の対応と公表。委員会への報告義務と本人通知をどう判断するか

も参照してください。本記事は執筆時点の公開情報に基づく一般的な整理であり、個別の判断は最新のガイドラインと自社の法務・専門家に確認してください。