「うちは小さい会社だから、個人情報保護法はあまり関係ないだろう」と考えていないでしょうか。実は、これはよくある誤解です。個人情報保護法は、会社の規模にかかわらず、すべての事業者に適用されます。特に、社内の業務基盤を新しく構築したり、既存の仕組みを改修したりするタイミングは、法令対応を組み込むよい機会です。
こうした対策を十分に整えないまま開発を進めると、後から修正するためのコストが膨らんだり、取引先や監査で指摘を受けたりする可能性があります。本記事では、総務業務とシステム担当を兼務している方でも「何から着手すべきか」が分かるように、法令の要点と開発への反映方法を順を追って解説します。
どのような情報が対象になるのか
対象となるのは、生存する個人を特定できる情報です。氏名、住所、電話番号、メールアドレスはもちろん、顔写真や動画、マイナンバーなども含まれます。また、それ単体では特定できなくても、他の情報と組み合わせることで個人が分かるものも対象です。たとえば、「会社名＋部署名＋役職」の組み合わせで特定の人物が絞り込める場合がこれに当たります。
業務上では、顧客情報、取引先の担当者情報、従業員情報などが該当します。紙の帳票だけでなく、Excelファイル、データベース、クラウド上のストレージに保管されているものも例外ではありません。
中小企業でも対応が必要になる理由
2022年4月施行の改正法では、それまで適用除外とされていた「5,000件以下の取り扱いに限る小規模事業者」への特例が廃止されました。これにより、取り扱う件数にかかわらず、すべての事業者に義務が課されています。
また、ビジネスの観点からも無視できません。大手企業が中小企業に開発や業務を委託する際、情報管理体制を確認するケースが増えています。対応が不十分な場合、取引継続の見直しにつながるおそれもあります。
システム開発で特に影響が大きいポイント
法令の中でも、開発に直接関わる主な論点は4つあります。情報取得時の同意や案内の設計、誰がどの情報にアクセスできるかという権限管理、いつ誰が何をしたかを残す操作履歴の記録、そして不要になったデータをいつどのように削除するかという保管期限の設計です。これらは設計段階で織り込まないと、後から追加するのが難しくなります。
法令の内容をシステム要件に落とし込む考え方
法令の要件を開発に反映させるには、「法律が求めていること」を「システムでどう実現するか」に置き換える作業が欠かせません。この整理が不十分だと、開発会社に仕様を正確に伝えられず、想定と異なる仕上がりになることがあります。
取得時の同意や通知をどう設計するか
情報を取得する際は、利用目的を本人に通知または公表し、必要に応じて同意を得ることが求められます。画面上では、入力フォームに利用目的を明示し、「同意する」などのチェックボックスを設ける対応が一般的です。
重要なのは、同意を取得した事実と日時をシステム側に記録しておくことです。「いつ、どの内容に同意したか」を後から確認できれば、問い合わせがあった場合にも迅速に対応できます。また、病歴・障害・犯罪歴などの要配慮個人情報は、通常より厳しい基準があり、取得には原則として明示的な同意が必要です。
必要な人だけが見られる権限管理を整える
アクセス権限の管理は、設計の中でも特に重要です。全員がすべてのデータを参照できる状態はリスクが高く、法的にも問題になり得ます。
具体的には、役職や業務内容に応じて、閲覧・編集・削除できる範囲を制限する仕組みが必要です。たとえば、営業担当者は担当顧客のデータのみ閲覧可能にし、人事情報は人事部門だけが参照できるように設定するといった形です。退職者や異動者のアカウント削除、権限変更のルールもあわせて決めておきましょう。
操作履歴を残して確認できるようにする
誰がいつどのデータにアクセスし、どのような操作をしたかを記録する仕組みを、一般にログ管理と呼びます。万が一、情報漏えいが発生した場合、この記録がなければ原因の特定も対応も難しくなります。
記録しておきたい内容は、ログイン・ログアウトの日時、閲覧・ダウンロード・変更・削除の操作、管理者による設定変更などです。ログは改ざんされにくい形で保存し、1〜3年を目安に保管することが望まれます。
保管期間と削除方法をあらかじめ決める
利用目的を終えた情報は、速やかに削除または匿名化することが求められます。開発段階でデータの保管期間を決め、期限が来たら自動で削除する、あるいは担当者に通知が届く仕組みを組み込んでおくと、運用負担を大きく減らせます。
削除方法も重要です。データベース上で「削除」とフラグを立てるだけで、実際にはデータが残る構造になっていないか、開発会社に必ず確認しておきましょう。
プライバシーポリシーと実際の運用を一致させる
プライバシーポリシーとは、自社がどのように情報を取り扱うかを示す文書です。ウェブサイトや画面上に掲載するだけでなく、実際の運用と内容が一致していることが重要です。
利用目的をわかりやすく整理する
「お客様の情報はサービス提供のために利用します」という曖昧な表現では、不十分となる場合があります。実際にどのような目的で、どの機能が、どの情報を使うのかを具体的に記載することが大切です。たとえば「ご注文内容の管理、配送の手配、アフターサービスの連絡のために利用します」と目的を並べる形は、利用者にとって分かりやすく、法的にも適切です。
画面表示や入力フォームの案内とずれをなくす
プライバシーポリシーには「メールマガジンは送らない」と書いてある一方で、登録フォームではメールマガジン送付にチェックが入っている、といった矛盾があると、それ自体が法令違反になり得ます。開発段階で、ポリシーの記載内容と画面上の案内、チェックボックスの設定が一致しているかを確認する工程を必ず設けましょう。
開発前に確認しておきたい社内文書
開発を依頼する前に、社内で用意しておきたい文書があります。現在運用中のプライバシーポリシー、社内の個人情報取扱規程、そして今回の開発で扱う情報の一覧と利用目的の3点です。これらを整理してから開発会社に依頼すると、要件の認識ずれを防ぎやすくなります。
外部委託や共同利用を行うときの注意点
開発では、依頼先に自社の顧客データや従業員データを渡す場面が生じます。また、完成した環境の運用をSaaSや外部の運用会社に委託するケースも少なくありません。こうした場合、法令では委託元である自社が、委託先の管理状況に責任を持つとされています。
委託先との契約で確認すべき事項
委託先との契約書に、情報の取り扱いに関する規定が含まれているか確認しましょう。具体的には、委託先が情報を目的外に利用しないこと、再委託する場合は事前承認を得ること、漏えいが発生した場合は速やかに報告することなどが盛り込まれているかがポイントです。これらが書かれていない場合は、覚書や特約として追加を検討してください。
委託先の管理状況をどう確かめるか
契約書を交わすだけでなく、委託先の管理体制を定期的に確認することも欠かせません。毎年現地確認を行うのが難しい場合は、プライバシーマークやISMS認証の取得状況が、一定の管理水準を判断する目安になります。いずれも第三者機関による審査を経た認証制度です。
情報漏えい時の報告と対応の流れを決める
2022年の法改正により、一定の条件を満たす漏えいが発生した場合、個人情報保護委員会への報告と本人への通知が義務化されました。委託先を含めてインシデントが発生した際に、誰がどのように動くかを、あらかじめ文書で定めておくことが重要です。
共同利用で明確にしておくべき内容
複数の会社が同じ情報を共同で利用する場合、たとえばグループ会社間で顧客情報を共有するようなケースでは、共同利用の内容をプライバシーポリシーなどで公表する必要があります。公表すべき内容は、共同利用する情報の項目、利用する会社の範囲、利用目的、管理責任を持つ会社名の4点です。
クラウド利用や海外でのデータ管理に備える
近年は、データをクラウド上に保管するケースが一般的です。クラウドを利用する場合でも、法令上の責任は自社にある点を忘れてはいけません。
クラウドサービス選定時の確認項目
サービスを選ぶ際は、データがどの国のサーバーに保管されるかを確認しましょう。国内サーバーを利用しているサービスであれば比較的管理しやすい一方、グローバル展開しているサービスでは海外サーバーに保管される場合があります。また、事業者の規約に、利用目的、第三者提供、保管期間などが明記されているかも確認ポイントです。
データを国外で扱う場合に見ておくべき点
情報を国外に移転する、つまり海外サーバーに保存したり海外拠点に送ったりする場合には、法律上の要件があります。本人の同意を得ること、日本と同水準の保護制度を持つ国・地域であること、または適切な契約などによって保護水準を確保することが求められます。海外拠点がある場合や、海外ベンダーのツールを利用している場合は、開発会社や専門家に相談しながら確認しておくと安心です。
提供先や保管場所の説明ができる状態にする
取引先や監査から「この情報はどこに保存されていますか」「誰が閲覧できますか」と尋ねられたとき、すぐに答えられる状態が理想です。そのためには、どのサーバーにどの情報があるかを示す構成図と、誰から誰に情報が渡るかを示すデータフロー図を整備しておくと役立ちます。
社内体制と文書を整えて運用に落とし込む
適切な設計ができても、運用する体制や文書が整っていなければ、法令対応は実務として機能しません。
担当者の役割と承認の流れを決める
情報を扱う業務について、誰が担当し、誰が承認するかを明文化しましょう。たとえば「顧客データの第三者提供は部長以上が承認する」「新しい委託先との契約は総務担当と経営者が確認する」といった流れを定めておくことで、担当者が迷わずに動けます。
取扱記録や手順書を残す
どのような情報を、どの目的で、どの業務基盤で扱っているかを整理した「個人情報取扱台帳」を作成しておきましょう。また、委託先への情報提供や開示請求への対応など、頻度は高くないものの重要な手続きについては、手順書を用意しておくと担当者が変わった場合でも対応しやすくなります。
社内教育で最低限共有したい内容
全社員に最低限理解してもらいたいのは、どの情報が法令の対象に当たるか、漏えいが起きたまたは疑われる場合に誰へどう報告するか、そして業務上知り得た情報を業務外で利用したり持ち出したりしてはならないことの3点です。年に1回程度、短時間でも確認の機会を設けることで、意識の維持につながります。
定期的な見直しと点検の進め方
法令は改正されることがありますし、業務内容が変われば扱う情報の種類も変わります。少なくとも年に1回、取り扱う情報の種類や件数に変化がないか、プライバシーポリシーの内容が実態と一致しているか、委託先の管理状況に変化がないか、アクセス権限に不要なものが残っていないかを点検する場を設けることをお勧めします。
監査や取引先への説明に備えて資料をまとめる
大手企業と取引している場合、情報管理体制についてアンケートや調査票への回答を求められることがあります。また、将来的に外部監査を受ける可能性もあります。そのような場面を見据えて、説明資料を整えておくことは非常に重要です。
説明資料に入れておきたい項目
用意しておきたいのは、扱う情報の種類と件数の概要、管理体制としての担当者・責任者の役割、セキュリティ対策の概要、委託先の一覧と管理状況、そしてインシデント発生時の対応手順です。
システム構成と管理方法を簡潔に示す
技術的な知識がない相手に説明する場合でも、「どこに何の情報があり、誰がアクセスできるか」を示した図があると伝わりやすくなります。開発会社に依頼して構成図を作成し、更新してもらうことを習慣にしておくと、説明の場で活用しやすくなります。
質問を受けやすい点を先回りして整理する
監査や取引先からよく聞かれるのは、「漏えい防止のためにどのような対策をしているか」「委託先をどのように選定・管理しているか」「従業員への教育をどのように行っているか」といった点です。こうした質問への回答を事前に整理しておくと、落ち着いて対応できます。
中小企業が迷いやすい実務上の疑問
どこまでシステムで対応すればよいのか
「完璧を目指すとコストが際限なくかかる」という声は少なくありません。現実的な進め方としては、リスクの高い情報から優先して対応する方針が有効です。取り扱い件数が多い顧客情報や、機密性の高い従業員情報から着手し、段階的に対応範囲を広げていく方法を開発会社と相談してみてください。
既存システムを改修するときの進め方
ゼロから構築する場合と異なり、既存環境の改修では現状把握が最初のステップです。現在の環境にどのようなデータが保存されているか、アクセス権限は適切か、ログは取得されているかを洗い出したうえで、不足している部分を補う改修を進める流れが一般的です。現状把握から改修完了まで、3〜6か月程度を見込むのが現実的でしょう。
自社だけで判断が難しい場合の相談先
法律の解釈や具体的な対応方法に迷った場合は、個人情報保護委員会のウェブサイトに掲載されている相談窓口や参考資料が役立ちます。また、弁護士や社会保険労務士、中小企業診断士への相談も有効です。開発面については、依頼先やITコンサルタントに、法令対応を含めて要件を整理したいと相談することで、実務的な助言が得られることがあります。
まず着手したい3つの対応
ここまでの内容を実際の行動につなげるために、まず取り組みたい3つのステップを整理します。
ステップ1：扱う個人情報と利用目的を整理する
どの部署が、どのような情報を、何の目的で、どのツールやファイルで扱っているかを一覧にします。この作業は外部に委託するよりも、実務をよく理解している社内担当者が主導するほうが効果的です。A4用紙1〜2枚程度の表から始めても十分です。
ステップ2：必要な管理機能を要件として明確にする
ステップ1で整理した内容をもとに、開発する環境に必要な機能を要件として文書化します。たとえば、アクセス権限の設定、操作履歴の記録、データ削除の仕組みなどです。「何を保護したいか」「誰に見せてはいけないか」という観点で記載すると、開発会社にも伝えやすくなります。
ステップ3：委託先と社内運用の確認資料をそろえる
開発会社や運用委託先との契約書に、情報の取り扱いに関する条項があるかを確認し、なければ追加を依頼します。同時に、社内の担当者、承認の流れ、インシデント対応手順をまとめた文書も用意しておきましょう。
よくある質問
Q1：Webサイトに問い合わせフォームを設置するだけでも対応が必要ですか？
はい、フォームで氏名やメールアドレスを収集する場合は対応が必要です。フォームの近くに利用目的を明示し、プライバシーポリシーへのリンクを設置することが基本対応となります。
Q2：取り扱う従業員が数名しかいない場合でも、規程や手順書は必要ですか？
件数や人数にかかわらず、法令の適用は受けます。ただし、規程や手順書は大がかりなものでなくても構いません。「誰が責任者か」「漏えいが起きたときにどうするか」が最低限分かる形でまとめておくことが重要です。
Q3：従業員に説明する義務はありますか？
法律上、明示的に教育を義務づける規定があるわけではありませんが、管理体制を整える義務の一環として、実務上は教育の実施が重要です。漏えいが発生した際に、教育していなかったという状況は、管理責任の観点から不利になり得ます。
Q4：開発を外注した場合、要件に法令対応を含めなくてもよいですか？
いいえ、含める必要があります。開発会社は、基本的に指示された内容に沿って構築します。法令対応の要件を明示しないと、セキュリティや権限管理が不十分な環境になるリスクがあります。「個人情報保護法に対応した仕様にしたい」と伝えたうえで、具体的な要件を共有することが重要です。
Q5：対応が不十分だった場合、どのようなリスクがありますか？
個人情報保護委員会からの指導・勧告・命令を受ける可能性があり、悪質な場合は罰則の対象になることもあります。ただし、それ以上に大きいのは、漏えいが起きた場合の信頼への影響です。顧客や取引先からの信頼を失うことで、事業への打撃が長期化する可能性があります。
まとめ
個人情報保護法への対応は、大企業だけの課題ではありません。中小企業が開発を進める際にも、設計段階から組み込むことが欠かせないテーマです。法令の要件を要件定義に落とし込み、委託先の管理を確認し、社内の体制と文書を整えることで、リスクを大きく減らせます。
「どこから着手すればよいか分からない」という場合は、まず自社が扱っている情報の洗い出しから始めてみてください。そこから見えてきた課題をもとに、開発会社や専門家と一緒に対応策を検討していくことが、現実的で効果的な進め方です。
個別の状況に応じて整理や要件化を進めたい場合は、専門家や開発パートナーに早めに相談することをお勧めします。
