2026年9月から10月にかけて、企業が使うSaaSへの不正アクセスが相次ぎました。Webサイト制作のStudio、コミュニティのCommune、問い合わせ管理のi-ask、メール配信のサービスなどで、そのサービスを使う企業の顧客や会員の情報が漏えいした、またはそのおそれがあると公表されています。
自社のシステムが攻撃されたわけではなくても、預けていた顧客の情報が漏れれば、利用企業として対応が必要になります。個人情報保護委員会への報告や、本人への通知の義務を負うのは、多くの場合、利用企業の側です。
本記事では、SaaSから情報が漏えいしたときに利用企業がやることを、個人情報保護委員会の資料をもとに整理します。記載の内容は、2026年10月時点の情報に基づきます。法律の判断は事案によって変わるため、実際の対応では弁護士などの専門家にも相談してください。
2026年秋に公表された主な事案
2026年9月から10月にかけて、企業が顧客や会員の情報を預けるSaaSで、次のような事案が公表されました。件数は、各社の発表の時点のものです。
| サービス（提供会社） | 種類 | 公表 | 発表の内容 |
|---|---|---|---|
| Commune（コミューン） | コミュニティ | 10月9日 | 非公開のコミュニティの招待リンクを不正に取得され、管理者になりすまして会員の情報を取得された。漏えいした会員は推計約30.7万人（コミューン（別タブで開く）） |
| i-ask（スカラコミュニケーションズ） | FAQ・問い合わせの管理 | 10月6日 | 管理サイトに不正にログインされ、同じサーバーを使う利用企業最大5社の問い合わせの情報（延べ最大約71万件）が対象になった。利用企業の大和証券、シチズン時計なども公表した（スカラコミュニケーションズ（別タブで開く）（10月7日時点の保存）、大和証券（別タブで開く）、シチズン時計（別タブで開く）） |
| SpeeCAN RAIDEN ほか（アルカディア） | 防災情報の配信 | 10月13日 | ファイルサーバーの脆弱性から、設定ファイルにあったログイン用の秘密の鍵を盗まれ、ログインされた。メールアドレスは最大約313万件（推定）。本来は契約者が行う個人情報保護委員会などへの報告を、同社が代わりに行うとした（アルカディア（別タブで開く）、経過の報告（別タブで開く）） |
| Studio（Studio） | Webサイトの制作 | 10月16日 | 一部の機能の脆弱性を悪用され、全利用者のアカウントの情報と、サイトのフォームに送られた内容、外部のサービスのAPIのキーなどが、外部から取得できる状態だった（Studio（別タブで開く）） |
| クロネコ代金後払い（ヤマト運輸） | EC事業者向けの後払いの決済 | 10月16日（第4報） | 購入者の情報約526万件、加盟店の情報約4,100件などを持ち出された（ヤマト運輸（別タブで開く）） |
| メール配信サービス（ユミルリンク） | メールの配信 | 10月19日 | プログラムの脆弱性から、同社のサポートの担当者の認証情報を取られ、5つのシステムからメールアドレスを含む情報、延べ約900万件（試算）を出力された（ユミルリンク（別タブで開く）） |
フォーム、問い合わせの管理、メールの配信、決済など、マーケティングやCSで日常的に使う種類のSaaSが並んでいます。自社が直接攻撃されていなくても、使っているSaaSを通して顧客の情報が漏れることがあります。
漏えいしたとき、報告するのは誰か
SaaSで漏えいが起きたとき、個人情報保護委員会への報告と本人への通知の義務を負うのは誰かは、SaaSの事業者が預かったデータを「取り扱う」ことになっているかで変わります。ただし、どちらの場合も、利用企業は報告と通知の当事者になります。
| SaaSの事業者 | 法律上の位置づけ | 報告・通知の義務 |
|---|---|---|
| 個人データを取り扱う（保守や調査でデータを見られる、など） | 利用企業からの「委託先」 | 利用企業と事業者の両方が負う。事業者は、利用企業に知らせれば義務を免れる。利用企業には、委託先を監督する義務もある |
| 個人データを取り扱わない（契約で取り扱わないと定め、アクセスを制御している） | 委託ではない | 利用企業が負う。報告を事業者に任せることはできる |
前者は個人情報保護委員会のガイドライン（通則編）（別タブで開く）、後者はガイドラインのQ&AのQ6-22（別タブで開く）とQ7-53（別タブで開く）で示されています。
2024年3月には、社会保険労務士向けのSaaSの事業者が、保守のためのIDで利用者のデータにアクセスできたことなどから、利用者から個人データの取扱いの委託を受けていたと判断された例があります。このとき個人情報保護委員会は、利用者の多くに委託している認識が薄く、委託先の監督が十分でなかった可能性があると指摘しました（個人情報保護委員会（別タブで開く））。
SaaSを使っていても、顧客の情報の責任は利用企業に残ると考えておきます。
報告と通知が必要になる場合
報告と本人への通知が必要になるのは、個人データの漏えい（またはそのおそれ）のうち、次の4つのどれかに当たる場合です（個人情報保護委員会（別タブで開く））。
- 要配慮個人情報（病歴など）が含まれる
- 財産的な被害が生じるおそれがある（クレジットカードの番号など）
- 不正の目的で行われたおそれがある
- 本人の数が1,000人を超える
不正アクセスによる漏えいは、多くの場合、3に当たります。3には人数の下限がないため、問い合わせフォームに届いた数件の情報でも、報告の対象になりえます。
「おそれ」も対象です。SaaSの事業者が「実際に取得された事実は確認できていないが、取得されたものとみなして対応する」としている場合も、報告が必要かを検討します。
期限
| 期限 | |
|---|---|
| 速報 | 速やかに（目安は、漏えいを知ってからおおむね3〜5日以内） |
| 確報 | 30日以内。不正の目的によるおそれがある場合は60日以内 |
| 本人への通知 | 状況に応じて速やかに |
速報の目安は、個人情報保護委員会のガイドライン（通則編）（別タブで開く）に示されています。
連名で報告できる場合
Studioの件では、委員会と協議した結果、利用企業は自分で報告するか、Studioが取りまとめて連名で報告するかを選べるとされました。連名で報告する場合は、この件に限り、速報の目安を過ぎても遅れとして扱わないとされています（Studio（別タブで開く））。
ただし、連名の報告に含まれるのは委員会への報告だけです。本人への通知は、利用企業が自分で行います。
利用企業がやること
SaaSの事業者から漏えいの連絡を受けたら、次の順に進めます。
1. 影響を確かめる
事業者の発表と個別の連絡から、次のことを確かめます。
- 自社のどのアカウント、どのプロジェクト（サイトやコミュニティ）が対象か
- 漏れた（おそれがある）データの項目。フォームの回答、会員の情報、添付ファイルなど
- 対象の期間と、対象になる件数
使わなくなったプロジェクトや、キャンペーンが終わったLPも対象になることがあります。Studioの件では、ゴミ箱に移しただけで完全に削除していないフォームの回答や、テストの送信も対象とされました。
2. 認証情報を切り替える
SaaSに預けていたのは、顧客の情報だけではありません。ほかのサービスとつなぐためのAPIのキーやトークンも、漏れた可能性があります。Studioは、利用者に次の対応を求めています（Webhookとスプレッドシートは、おすすめとしての案内）。
- SaaSにログインするパスワードの変更。同じパスワードをほかで使っていれば、そちらも変える
- 外部のサービス（microCMS、Notionなど）との連携に使うAPIのキーの再発行
- Googleスプレッドシートとの連携の解除と、つなぎ直し（Studioは接続用の鍵を更新済みで、念のための対応）
- Webhookの通知先のURLの切り替え
- パスワードで保護したページのパスワードの変更
APIのキーは、新しいキーを発行して設定を差し替えてから、古いキーを止めます。先に古いキーを止めると、連携が止まります。あわせて、漏えいの期間より後に、つないだサービスで覚えのない使われ方がないかも確かめます。
3. 個人情報保護委員会に報告する
報告の対象に当たるかを判断し、速報を出します。連名で報告する仕組みがある場合は、自分で報告するか、連名にするかを決めます。報告は、個人情報保護委員会のWebサイトから行えます。ただし、金融など、報告の受付を各省庁に任せている業種は、その省庁に報告します（個人情報保護委員会（別タブで開く））。
4. 本人に通知する
本人に、漏えいの概要、漏れた項目、原因などを、分かりやすい方法で知らせます。メールの送信や文書の郵送が例として挙げられています。
連絡先が分からないなど、本人への通知が難しい場合は、Webサイトでの公表や、問い合わせの窓口を設けることで代えられます（個人情報保護委員会（別タブで開く））。Studioは、営業目的の問い合わせやスパムでも、氏名やメールアドレスなどが含まれていれば、原則として通知が必要としています。
5. 二次被害を防ぐ
漏れたメールアドレスに、事業者や自社を装ったメールが届くおそれがあります。本人への通知や公表の中で、パスワードや認証情報をメールで尋ねることはない、と伝えておきます。
6. 預け方を見直す
落ち着いたら、同じことが起きたときに被害を小さくする方法を考えます。次の節で説明します。
平時に備えておくこと
どのSaaSに、何を預けているかを一覧にする
漏えいの連絡を受けてから、どのプロジェクトで何を集めていたかを調べ始めると、速報の期限に間に合いません。次のことを一覧にしておきます。
- SaaSの名前と、使っている部署・担当者
- 預けている個人情報の項目（氏名、メールアドレス、電話番号など）
- ほかのサービスとの連携と、そのAPIのキー
- 事業者が個人データを取り扱う契約か（委託か）
マーケティングの部門は、フォーム、MA、LP、ウェビナー、コミュニティなど、多くのSaaSで顧客の情報を集めます。情報システムの部門が把握していないSaaSがないかも確かめます。
SaaSに残さない
フォームの回答は、SaaSのダッシュボードに残さず、CRMなどの決まった置き場所に送る設定にできることがあります。Studioの件でも、「フォームの結果をStudioに保存」を無効にしていた間の回答は、漏えいの対象外とされました。
集めた個人情報の置き場所を少なくするほど、漏えいしたときに確かめる範囲も小さくなります。
APIのキーの権限を絞る
SaaSにつなぐAPIのキーは、必要な操作だけができるものにします。読み取りだけで足りるなら、書き込みの権限を持たせません。キーが漏れたときに、つないだ先のデータまで書き換えられるのを防ぐためです。
まとめ
- 2026年秋の事案：Webサイト制作のStudio、コミュニティのCommune、問い合わせ管理のi-askなど、企業が使うSaaSへの不正アクセスで、利用企業の顧客の情報が漏えい、またはそのおそれがあると公表された
- 報告の当事者：SaaSの事業者が委託先かどうかにかかわらず、利用企業は個人情報保護委員会への報告と、本人への通知の当事者になる
- 期限：不正アクセスによる個人データの漏えいは、人数にかかわらず報告の対象になりえる。速報は速やかに（目安はおおむね3〜5日以内）、確報は60日以内
- やること：影響を確かめる、認証情報を切り替える、報告する、本人に通知する、二次被害を防ぐ、預け方を見直す
- 平時の備え：どのSaaSに何を預けているかを一覧にし、SaaSに残す個人情報を減らし、APIのキーの権限を絞る
顧客の情報が、フォーム、MA、CRM、広告など、いくつものSaaSに分かれて置かれていると、漏えいしたときに影響を確かめるだけで時間がかかります。どこにどのデータがあり、誰が見られるのかを把握しておくことが、分析のためにも、守るためにも役に立ちます。
株式会社INVOXは、データ基盤の構築、データ分析の支援、AIエージェントの開発を行っています。広告やGA4、CRMのデータをBigQueryに統合する際に、データの置き場所と権限の設計から支援しています。
BIツールを狙った不正アクセスと、データ基盤で見直す点は、「Metabaseの脆弱性と、BIツールからの情報漏えいを防ぐために見直すこと（別タブで開く）」で解説しています。
「顧客の情報がどのSaaSにあるかを整理したい」「データ基盤の権限の設計を相談したい」といった課題をお持ちでしたら、お問い合わせください。
