使っているクラウドサービスで情報漏えいが起きたら？利用企業は何をすべきか

2026年10月28日

情報漏えいの発表が続いています。2026年10月には、Web サイトを作るクラウドサービスの Studio と、コミュニティサイトを作る Commune が相次いで不正アクセスを受け、それぞれを使っていた企業が漏えいのおそれを発表しました。自社で契約して使っているサービスの側で漏えいが起きたとき、利用企業は何をすればよいのでしょうか。ProFab でも利用していたクラウドサービスでインシデントが発生したことをきっかけに、最近の2つの事例と個人情報保護法の決まり、個人情報保護委員会のガイドラインが定める措置を整理しました。結論から言うと、漏えいが自社ではなくクラウドサービスの側で起きた場合でも、個人情報保護委員会への報告と本人への通知が求められます。インシデントはいつ起きてもおかしくないので、利用企業の側で備えておくことが必要だと考えています。

区分	漏えいしたおそれがある情報
アカウント	ユーザー名、メールアドレス、ハッシュ化（元に戻せない形に変換）したパスワード
サイトの中身	デザインエディタと CMS（記事などを管理する機能）の内容
フォーム	送信内容。ゴミ箱に入れた回答、テスト送信、画面の表示上限を超えた分も含む。添付ファイルは名前のみ
設定	Google reCAPTCHA（スパム対策）の設定、Webhook（外部への通知）の URL、ライブプレビュー（公開前の確認用ページ）の URL
認証情報	外部サービスの API キー、パスワード保護ページのパスワード、Google スプレッドシート連携の認証情報など

区分	漏えいした情報
会員の基本情報	メールアドレス、表示名、自己紹介、非公開グループの所属など。メールアドレスを含むのは約12.6万人
コミュニティごとに登録させていた項目	利用企業によって異なる。氏名・生年月日・住所、企業名・役職、年代・性別など
パスワード	144人のパスワードが、本人の操作によらず仮パスワードに変えられた。パスワードそのものの漏えいは確認されていない

利用企業に求められる報告と本人通知

報告と本人通知の決まり

個人情報保護法は、個人データの漏えいが一定の条件に当たるとき、個人情報保護委員会（以下、個情委）への報告と本人への通知を義務にしています（法26条）。条件は次の4つで、どれか1つに当たれば対象です。漏えいが確定していなくても、「おそれ」の段階から対象になります。

報告の対象になる漏えい	例
要配慮個人情報（病歴・障害・犯罪歴など）を含む	患者の診療情報を入れた USB メモリの紛失、従業員の健康診断の結果の漏えい
不正に使われると財産的な被害が出るおそれがある	EC サイトからのクレジットカード番号の漏えい、送金や決済ができるサービスの ID とパスワードの漏えい
不正の目的による（おそれを含む）	不正アクセス、ランサムウェアによる暗号化、従業員による持ち出し、サイトの入力ページの改ざん
本人の数が1,000人を超える	システムの設定ミスで、1,000人を超える個人データがインターネット上から見られる状態になった

（出典: 個人情報保護法施行規則第7条、例は個情委ガイドライン通則編 3-5-3-1 の事例から）

クラウドサービスへの不正アクセスで問題になるのは3つ目です。この類型には人数の下限がありません。1人分の漏えいでも、外部からの攻撃によるものなら報告の対象です。さらに、データベースに入れる前のフォームの送信内容も対象に含まれます（個情委ガイドライン通則編 3-5-3-1）。

報告は、速報と確報の2段階で出します。速報は、漏えいを把握してから概ね3〜5日以内が目安で、その時点で分かっていることを中心に書きます。確報は、把握した日から30日以内、不正の目的による場合は60日以内に、すべての項目をそろえて出します。期限の起点は、社内のどこかの部署が把握した時点です。

報告	期限	書くこと
速報	把握してから速やかに（目安は3〜5日以内）	9項目のうち、その時点で分かっているもの
確報	把握した日から30日以内（不正の目的なら60日以内）	9項目すべて（概要、漏えいした項目、本人の数、原因、二次被害、本人への対応、公表の状況、再発防止策、その他）
本人通知	状況に応じて速やかに	概要、漏えいした項目、原因、二次被害、その他の5項目

（出典: 個人情報保護法施行規則第8条・第10条、個情委ガイドライン通則編 3-5-3-3〜3-5-4-5）

本人への通知は、メールや郵送など方法を問いません。連絡先が分からないなど、通知が難しい場合は、事案を公表するか、本人が自分のデータが含まれているかを問い合わせられる窓口を設けることで代用できます。なお、2026年7月に公布された改正個人情報保護法では、本人への通知の代わりに公表などで済ませられる範囲が広がる予定です。まだ施行されていないので、現時点では現行のルールが当てはまります（個情委「令和8年改正個人情報保護法について」）。

クラウドサービスでの事案における報告主体

クラウドサービスの側で起きた漏えいでも、利用企業は個情委への報告義務を負います。個情委の Q&A も、不正の目的による漏えいの例として、自社が使っている「入力フォーム作成ツールの提供事業者」や「ストレージサービスの提供事業者」への攻撃を挙げています（個情委「ガイドラインに関するQ&A」 6-16）。

提供元にも報告義務があるかどうかは、提供元が利用企業のデータを預かって扱う立場か、置き場所を貸すだけの立場かで分かれます。

提供元の立場	当てはまる例	報告の仕方
データを預かって扱う（委託）	保守のために、提供元がデータの中身を見たり調べたりできる	利用企業と提供元の両方に義務がある。連名で1通にできる。提供元が利用企業に知らせた場合は、利用企業だけが出す
データの置き場所を貸すだけ	契約で中身を扱わないと決め、提供元のアクセスも技術的に制限している	義務は利用企業だけにある。提供元に代行してもらうことはできる

（出典: 個情委「ガイドラインに関するQ&A」 6-22・7-53、個情委ガイドライン通則編 3-5-3-2）

どちらに当たるかは、契約の文言だけでなく実態で決まります。個情委は2024年3月、利用規約で保守のためにデータを調べられるとし、保守用の ID で実際にアクセスできた提供元を、委託に当たると判断しています（個情委の注意喚起）。

事例1（Studio）は、フォームの送信内容を「運営者からの委託を受けて」保管していると説明し、連名での報告を選べるとしました（Studio「フォーム機能をご利用のお客様へ」）。事例2（Commune）では、報告は利用企業が行い、コミューンは必要な情報を提供するとしています（コミューンの発表）。どちらの場合も、連名で出せるのは個情委への報告だけで、本人への通知は利用企業が行います。

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

提供元から漏えいの連絡を受けたら、利用企業は4つの段階で対応を進めます。まず社内に報告して被害が広がるのを止め、次に事実関係と影響範囲を調べます。その結果をもとに個情委への報告と本人への通知を行い、最後に再発防止策を決めます。以下は、冒頭で触れた ProFab の対応で取った手順を、ほかのクラウドサービスにも当てはまる形にまとめたものです。

段階	目安	やること	主に担う人
1 社内への報告と被害の拡大防止	通知を受けた日	漏えいは起きたものとして扱うと決め、管理部門に第一報を入れる。流出したおそれのあるパスワードや外部連携の認証情報を使えなくする	運用部門
2 事実関係の調査と影響範囲の特定	速報の前まで	提供元の発表と自社の記録を集め、預けていたデータを書き出して数える	運用部門
3 個情委への報告と本人への通知	速報は3〜5日以内、確報は30日または60日以内	報告と本人通知の要否を判断して実施する	管理部門
4 再発防止策の検討と実施	落ち着いたあと	同じことが起きても被害が小さく済む使い方に改め、止めた機能を再開する条件を決める	両者で合意

1 社内への報告と被害の拡大防止

最初に決めるのは、漏えいは「起きたもの」として扱うことです。提供元の発表が「おそれ」の段階でも、報告の対象になるためです。速報の目安の3〜5日は、通知を受けた日から数えます。残りの段階は、この期限に間に合うように進めます。

次に、役割を分けます。何がどれだけ漏れたかを調べられるのは、そのツールを利用している運用部門です。報告と本人通知の要否は、法務や情報セキュリティなど、会社として判断できる管理部門が決めます。運用部門は、その日のうちに管理部門へ第一報を入れます。第一報には、提供元から知らされた事実、影響を受けた自社のサービス、これから取る対応、判断してほしいことをまとめます。

あわせて、被害が広がらないようにします。提供元が脆弱性を直しても、すでに読み出された情報を使った攻撃を受けるリスクは残ります。パスワードはハッシュ化されていても解読されるおそれがあり、クラウドサービスをほかのサービスとつなぐための API キーや連携の許可（以下、外部連携の認証情報）は、読み出されればそのまま使えます。何を使えなくするかは、提供元の発表にある漏えいしたおそれのある項目と、提供元が呼びかけている対応を出発点にします。主な対象は次の3つです。

対象	やること
ログイン	パスワードでログインしている場合は変更し、同じパスワードをほかで使っていればそちらも変える。全端末からログアウトさせ、多要素認証を設定する
外部連携の認証情報	API キーを作り直す。表計算ソフトやチャットツールなどとの連携を解除し、連携先のサービスの側でも許可を取り消す
アカウントと設定	知らないメンバーや管理者が増えていないか、権限や通知先・転送先の設定が書き換えられていないかを確かめる

見落としやすいのは、外部連携の認証情報です。ログインのパスワードを変えても無効にならないので、クラウドサービスの側で連携を解除し、連携先の側でも許可を取り消して、はじめて使えなくなります。

提供元の安全が確かめられるまで、そのサービスでデータを集めるのを止めることも考えます。止めている間、自動返信などを手作業でどう補うかも、あわせて決めておきます。

2 事実関係の調査と影響範囲の特定

原因の究明は、侵入されたシステムを持つ提供元が行います。利用企業の側では、まずクラウドサービスの操作やログインの記録（ログ）を書き出します。ログには保存期間があり、消えると影響範囲を特定できなくなるためです。あわせて、提供元からの通知の原文と続報、自社で取った対応と作業した画面の記録を集め、時系列にまとめておきます。確報で原因と再発防止策を書くときの材料になります。

そのうえで、報告にも本人通知にも要る、何が、何人分、いつからいつまで漏れたおそれがあるのかを調べます。手順は3つです。

手順	やること	注意する点
書き出す	クラウドサービスに預けていたデータを全件書き出す	削除済み（ゴミ箱）やテストのデータも対象になる。画面に見えている分だけで数えない
数える	件数、人数、期間、項目に分けて数える	基準は社内の管理表より、提供元から書き出したデータに置く。社内の表に載っていない古い分が残っていることがある
中身を確かめる	自由記述の欄に、要配慮個人情報や財産的被害につながる情報、取引先の機密が含まれていないかを確かめる	キーワードで機械的に絞り、引っかかったものを目で確かめる

中身を確かめるのは、報告の4類型のどれに当たるかを判断するためです。問い合わせのような自由記述の欄には、取引先の技術的な相談など、個人情報とは別に守秘の観点で扱いを考えるべき内容が入っていることもあります。

3 個情委への報告と本人への通知

調べた結果をもとに、管理部門が報告と本人通知の要否を決めます。不正アクセスによる漏えいは4類型の「不正の目的」に当たるので、人数にかかわらず報告と本人通知の対象です。提供元と連名で出せる場合も、自社で出す場合も、運用部門は報告書の材料と本人への通知文のたたき台を用意します。通知文では次の点に気を付けます。

気を付ける点	理由
宛名を「会員の方」「お問い合わせいただいた方」と決めつけず、「メールアドレス等の登録・送信の記録がある方」とする	本人の知らないうちに、第三者がアドレスを入力している場合がある
提供元や自社を装うメールへの注意を書き、パスワードなどを尋ねることはないと明記する	漏えいした氏名とアドレスを使ったなりすましメールが、最も起こりやすい二次被害のため
1通ずつ個別に送り、送った記録を残す	宛先に複数のアドレスを並べると、通知そのものが新たな漏えいになる

4 再発防止策の検討と実施

提供元の脆弱性そのものは、利用企業には防げません。利用企業にできるのは、漏れにくくすることと、漏れても被害が小さく済むようにしておくことです。再発防止策は、漏えいが起きたサービスだけでなく、同じようにデータを預けているほかのクラウドサービスにも当てはめます。インシデントが起きていないサービスでも、使い方が同じなら同じ被害が起こりうるためです。まず、クラウドサービスの使い方を見直します。

見直す点	中身	理由
データを溜めない	フォームの回答や問い合わせの内容、会員ではない人の連絡先など、通知メールや社内のシステムで受け取れば済むデータは、クラウドサービスの側に残さない。保存しない設定にするか、定期的に完全に削除する。テスト送信やゴミ箱の分も消す。会員登録で集める項目は、使い道のあるものに絞る	漏れるのは、提供元の側に残っていたデータと、登録させていた項目だけ。事例2（Commune）では、コミュニティごとに登録させていた氏名や住所も漏えいした
連携を絞る	使っていない連携を解除し、不要な API キーを削除する。連携に使うアカウントは専用のものに絞り、表計算ソフトなら書き込み先のシートだけに権限を与える。どのサービスにどの認証情報を登録したかを一覧にし、定期的に作り直す	外部連携の認証情報は、パスワードを変えても使える状態で残る
アカウントを減らす	退職者や異動者、制作を頼んだ外部の担当者など、使っていないアカウントを削除する。管理者の権限は必要な人だけに絞る。ログインは多要素認証をかけたものに限る	事例1（Studio）では、ログインのパスワードも漏えいの対象になった
異変に気付く	管理画面のログイン履歴、メンバーの追加、データの一括書き出しの記録を、月に1回など決まった頻度で見る。提供元のお知らせを受け取れるようにしておく	事例1（Studio）では、不正アクセスから提供元が気付くまで約2週間かかった

次に、個人データの保管先を台帳にまとめます。台帳には、サービスごとに、保管しているデータの種類、件数の目安、保管を始めた時期、連携してデータを送っている先を書きます。顧客管理などほかのサービスに取り込んだ複製や、今は使っていないサービスに残っている古いデータも対象です。台帳があれば、漏えいが起きたときに調べる範囲をすぐに決められます。

台帳には、サービスごとの削除の手順と、削除後にデータが残る期間も書き添えます。多くのクラウドサービスは、削除したデータをしばらく復元できる状態で保持します。ProFab が確かめたサービスでは、通常の削除から30〜90日はデータが残り、すぐに消すには「完全に削除」の操作か提供元への依頼が必要でした。

体制と契約も、起きる前に確かめておけます。誰が判断し、誰が手を動かし、提供元とは誰が連絡を取るのかを文書にしておけば、通知を受けた日に役割を決める時間を、調査に充てられます。契約で、提供元が個人データを「取り扱う」ことになっているかを確かめておけば、提供元の案内を待たずに報告の出し方を決められます。

最後に、止めた機能を再開するときの条件を決めます。たとえば、社内のセキュリティ担当の確認を受けること、機密情報を書き込まないよう注意書きを添えること、集めたデータをクラウドサービスの側に溜めない設定にできるかを確かめることです。

まとめ

使っているクラウドサービスで漏えいが起きても、個情委への報告と本人への通知は利用企業に求められます。通知を受けた日に社内への報告と被害の拡大防止を済ませ、速報の期限までに影響範囲を特定する。この流れを事前に決めておくことが、利用企業にできる備えです。

提供元の側で起きる漏えいが続くなか、クラウドサービスの設定や運用で守りを固めるだけでなく、個人データをクラウドサービスに預けず、社内の基盤に移すという選択肢も出てきているように感じています。この流れについては、別の記事で書きたいと思います。

ProFab では、こうしたセキュリティインシデントも考慮して、DX や AI の活用を想定したコンプライアンスの見直しや、社内ガイドラインの策定などを支援しています。使っているクラウドサービスでのデータの管理や、起きたときの備えを見直したい方は、お問い合わせからご連絡ください。

執筆者

川村　浩太

慶應義塾大学卒業後、総合化学メーカーを経てデロイトトーマツコンサルティングに在籍。新規事業立ち上げ、M&A、経営管理、業務改善などのプロジェクトに関与。マーケティング企業を経て、株式会社ProFabを設立。ProFabでは経営コンサルティングと生成導入支援事業を運営。

TechTechでは、技術、ビジネス、サービス、規制に関する最新ニュースと、各種ツールの実務的な活用方法について、初心者でも理解できる明瞭な発信を心掛ける。日本ディープラーニング協会の実施するG検定資格を保有。