社内のアプリやWebシステムで、顧客情報が「URLを知っていれば誰でも見られる状態」になっていたと分かった。設定はもう直したけれど、お客様に知らせるべきなのか、知らせるならどう書けばいいのか分からない。個人情報の漏えい対応で、経営者や情シス兼任の担当者が最も手が止まりやすいのがこの場面です。
「顧客情報が見られる状態だったことを、お客様に知らせるべきか、どう書けばいいのか分からない…」
先に結論をお伝えします。「実際に見られたか分からない」状態でも、個人情報保護法では「漏えいのおそれ」として、お客様(本人)への通知が必要になる場合があります。判断の分かれ目は、①どんな情報か、②何人分か、③不正なアクセスの疑いがあるか、④実際に見られたかをログで確かめられるか、の4つです。知らせると決めたら、お知らせ文には「何が起きたか」「どの情報か」「原因」「二次被害のおそれ」「お客様にお願いしたいことと問い合わせ先」の5つを書きます。
この記事では、個人情報の漏えい通知を「出すか・出さないか」の判断の材料と、お知らせ文の書き方を、発注者の立場で順番に解説します。チェックリストと開発会社への質問例も添えています。
※ 本記事は2026年11月時点の一般的な考え方の紹介です。個別の事案で報告・通知が必要かどうかは、個人情報保護委員会の窓口や弁護士などの専門家に確認してください。
「見られる状態だった」だけでも通知が必要になることがある理由
「誰も見ていないなら、知らせなくていいのでは」と考えるのは自然なことです。ただ、個人情報保護法の考え方では、「見られた」と確定していなくても対応が必要になる場面があります。
「漏えい」には設定ミスで見られる状態になったことも含まれる
個人情報保護委員会のガイドラインでは、個人データ(=データベースなどで整理された個人情報)の「漏えい」の例として、誤送信と並んで、システムの設定ミスでインターネット上から見られる状態になったことが挙げられています。一方で、第三者に見られる前にすべて回収できた場合は、漏えいに当たらないとされています。
📰 出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」3-5
つまり、分かれ目は「誰にも見られていないことを確かめられるか」です。アクセスログ(=いつ・どこから見られたかの記録)が残っていて、社外からのアクセスが無いと確かめられれば、判断は変わってきます。逆にログが無い・足りない場合は、「漏えいのおそれ」がある前提で考えることになります。
法律で報告と通知が義務になる4つの場合
2022年4月に施行された改正個人情報保護法では、次のいずれかに当たる漏えい等(そのおそれを含む)が起きたとき、個人情報保護委員会への報告と、本人への通知が義務になりました。
| 報告・通知が必要になる場合 | 例 |
|---|---|
| 要配慮個人情報が含まれる | 病歴、健康診断の結果など |
| 財産的な被害が生じるおそれがある | クレジットカード番号、ネットバンキングのIDとパスワード |
| 不正な目的によるおそれがある | 外部からの不正アクセス、従業員による持ち出し |
| 本人の数が1,000人を超える | 顧客名簿の全件 など |
📰 出典:個人情報保護委員会「漏えい等の対応とお役立ち資料」
委員会への報告には期限があり、発覚した日から概ね3〜5日以内に速報、30日以内(不正な目的によるおそれがある場合は60日以内)に確報を出すとされています。お客様への通知は「当該事態の状況に応じて速やかに」とされていて、すべての事実が分かるまで待つ必要はありません。
開発会社が原因でも、知らせる責任は発注者側にある
見落とされやすいのが、責任の所在です。システムの開発や運用を開発会社に任せていて(法律上は「委託」)、設定ミスが開発会社側で起きた場合でも、委員会への報告とお客様への通知は、原則として個人データを預かっている発注者(委託元)が行います。開発会社は、発注者に必要な事項を伝えることで、自身の報告義務を果たす形になります。
開発会社を責めるより先に、「事実を調べて、早く正確に伝えてもらう」ことに協力をお願いするのが、結果的に早く終わる進め方です。
知らせるかを判断する4つの確認
ここからは、通知するかどうかを決めるために、発注者が確認することを順に見ていきます。設定を直した直後から始めましょう。
確認1:見られる状態だった情報の「中身」
まず、どんな項目が含まれていたかを一覧にします。氏名と会社名だけなのか、電話番号や住所まで入っていたのか。病歴などの要配慮個人情報や、クレジットカード番号・パスワードが含まれていたかは、義務になるかどうかに直接関わります。
確認2:何人分か
件数を数えます。1,000人を超えるかどうかが1つの基準です。テスト用に入れたデータや、重複している行を除いた「本人の数」で数えます。
確認3:不正なアクセスの疑いがあるか
アクセスログに、社外からの見慣れないアクセスや、大量に読み出した記録が無いかを開発会社に確認してもらいます。不正な目的によるおそれがあると判断されると、件数が少なくても報告の対象になります。
確認4:「誰にも見られていない」とログで確かめられるか
見られる状態だった期間すべてについて、アクセスログが残っているかを確かめます。ホスティング(=システムを置いて公開するサービス)によっては、ログの保存期間が短いことがあります。ログが途中で切れている場合は、「その期間は見られていないと言い切れない」ことになります。
この4つが分かったら、個人情報保護委員会の相談窓口や弁護士に、事実をまとめて相談するのが確実です。義務に当たらない場合でも、お客様との信頼関係を考えて自主的に知らせるという判断もあります。
お知らせ文に書く5つの項目
通知すると決めたら、文面を作ります。ガイドラインでは、本人に通知する事項として、概要・個人データの項目・原因・二次被害やそのおそれの有無と内容・その他参考となる事項が挙げられています。これに沿って、次の5つを書くと抜けが出にくくなります。
| 項目 | 書く内容 | 書き方のポイント |
|---|---|---|
| 1. 何が起きたか(概要) | いつからいつまで、どんな状態だったか、いつ気づいて止めたか | 日付を具体的に。「一時的に」などのあいまいな表現で済ませない |
| 2. どの情報か(項目) | 氏名・メールアドレス・電話番号など | 含まれていない項目(カード番号は含まれない等)も書くと安心につながる |
| 3. 原因 | システムの設定の誤り など | 担当者個人や開発会社の名前は出さない |
| 4. 二次被害のおそれ | 現時点で確認できている被害の有無、考えられる影響 | 分かっていないことは「調査中」と書き、断定しない |
| 5. お願いと問い合わせ先 | 不審なメールや電話への注意、問い合わせ窓口と受付時間 | 本人が「自分は対象か」を確かめられる窓口を用意する |
お知らせ文のひな形
次のような流れで書くと、伝えるべきことが揃います(一般的な形の例です。実際の文面は専門家の確認を受けてください)。
件名:お客様情報の取り扱いに関するお詫びとお知らせ
(1)概要
当社が利用している〇〇のシステムにおいて、〇年〇月〇日から〇月〇日までの間、
設定の誤りにより、お客様の情報が外部から閲覧できる状態になっていました。
〇月〇日に判明し、同日中に閲覧できない設定へ修正しました。
(2)対象となる情報
氏名、メールアドレス、電話番号(クレジットカード情報は含まれておりません)
(3)原因
システムの公開範囲の設定に誤りがありました。
(4)現在の状況
現時点で、外部の第三者による閲覧や、情報の不正な利用は確認されておりません。
引き続き調査を行っています。
(5)お客様へのお願いとお問い合わせ先
当社を名乗る不審なメールや電話にご注意ください。
お問い合わせ窓口:〇〇(受付時間 平日〇時〜〇時)
連絡先が分からないお客様がいるとき
メールアドレスや住所が無く、直接知らせられないお客様がいる場合、ガイドラインでは代わりの対応として、事案の公表(自社のWebサイトへの掲載など)や、本人が自分が対象かどうかを確かめられる問い合わせ窓口の設置が挙げられています。
通知でやりがちな失敗
- 原因がすべて分かるまで待ってしまう:調査が長引くと、通知が遅れて不信感につながります。分かっている範囲で先に知らせ、続報を出す形でも構いません
- 「被害はありません」と言い切る:ログで確かめられていないのに断定すると、後で見られていたと分かったときに説明がつかなくなります
- 社内の担当者や開発会社を名指しする:お客様にとって必要なのは「何が起きて、何をすればいいか」です。誰のせいかは書きません
- 問い合わせ窓口を用意せずに送る:通知を送った直後に問い合わせが集中します。対応する人と想定問答を先に決めておきましょう
- 開発会社との事実確認がずれたまま出す:期間や件数が開発会社の調査結果と食い違うと、訂正が必要になります
ランサムウェアなどの攻撃を受けた場合の連絡の順番は、次の記事で解説しています。


発注者がやること チェックリスト
- ☐ 見られる状態だった期間(いつから・いつまで)を記録した
- ☐ 含まれていた項目と、本人の数を一覧にした
- ☐ 要配慮個人情報・カード番号・パスワードが含まれていないか確かめた
- ☐ アクセスログが期間すべてについて残っているか、開発会社に確認した
- ☐ 報告・通知が必要かを、個人情報保護委員会の窓口や弁護士に相談した
- ☐ 報告の期限(速報は概ね3〜5日以内)を社内で共有した
- ☐ お知らせ文の5つの項目を揃え、開発会社の調査結果と数字を合わせた
- ☐ 問い合わせ窓口と担当者、想定問答を用意した
開発会社への質問例
- 「見られる状態だった期間について、アクセスログはすべて残っていますか。社外からのアクセスがあったかを調べていただけますか」
- 「その期間に、データがまとめて読み出された記録はありますか」
- 「対象になった情報の項目と件数を、重複を除いて出していただけますか」
- 「お客様へのお知らせに書く『原因』と『修正した内容』を、専門用語を使わずに説明する文案をいただけますか」
- 「同じ設定ミスが他の画面やシステムで起きていないか、点検していただけますか。費用と日数はどのくらいですか」
顧客情報が入ったアプリを見つけたときの後始末の全体の流れは、次の記事にまとめています。


まとめ:「見られたか分からない」ときこそ、早く・正確に
顧客情報が見られる状態だったと分かったら、次の順番で進めましょう。
- 情報の中身・人数・不正アクセスの疑い・ログの有無の4つを確かめる
- 報告と通知が必要かを、期限を意識して専門家に相談する
- お知らせ文には、概要・項目・原因・二次被害のおそれ・お願いと問い合わせ先の5つを書く
- 分からないことは断定せず、続報で補う
お客様に知らせるのは勇気がいることですが、早く正確に伝えることが、結果的に信頼を守ることにつながります。開発会社とは責任の押し付け合いではなく、事実を揃えるパートナーとして協力して進めましょう。
あわせて読みたい関連記事













