はじめに
2026年10月21日、クラウド型のメール配信サービス「ブラストメール」が、不正アクセスのため緊急停止しました。運営元の発表では、全契約者の情報と、一部契約者の配信先リストが外部に持ち出されたとされています。その後、利用していた官公庁や自治体、企業から「当方のメールマガジン配信先情報が漏えいした可能性がある」という公表が相次いでいます。
自社で作ったシステムが攻撃されたわけではありません。それでも、メールマガジンの読者や会員から見れば、漏えいしたのは「あなたの会社に登録した情報」です。この記事では、事案の概要を整理したうえで、委託先SaaSの事故がなぜ自社の備えから漏れやすいのか、そして発注側として普段から何を仕組みにしておくべきかを、コンサルタントの視点で考えます。
何が起きたのか
運営元の株式会社ラクス（子会社の株式会社ラクスライトクラウドが提供）の第2報（2026年10月21日）と、利用組織の公表をもとに整理すると、概要は次のとおりです。
- 停止：2026年10月21日0時30分から、サービスを緊急停止。再開時期は未定
- 内容：第三者がAPI用のサーバー2台に侵入し、販売管理システムとサービスのデータベースから情報を持ち出したことを確認
- 対象：全契約者の販売管理情報（会社名、担当者名、電話番号、メールアドレス、契約・支払履歴など）と、一部契約者のメール配信先リスト。クレジットカード番号は保持していないと説明
- 原因：侵入経路や件数の詳細は調査中
- 影響：環境省（10月23日公表）をはじめ、自治体や企業が、メールマガジンの配信先情報が漏えいした可能性や配信停止を相次いで公表
環境省の発表では、管理画面とAPIが止まり、メール配信そのものもできなくなっていることが示されています。つまり今回は「情報が漏れたかもしれない」と「お知らせが送れない」の2つが同時に起きています。なお、件数や侵入経路は今後の続報で変わる可能性があるため、最新情報は運営元の発表を確認してください。
なぜ「委託先SaaSの事故」は備えから漏れやすいのか
私が発注側の支援で多くの会社を見てきた経験では、SaaSの事故に弱い会社には共通する構造があります。
1つ目は、SaaSが「システム」として扱われていないことです。 メール配信、アンケート、フォーム、イベント受付などのツールは、広報やマーケティング、各事業部が部門の予算で契約していることが多く、情シスが把握していないケースが珍しくありません。基幹システムなら台帳も保守契約もあるのに、名簿を何万件も預けている配信ツールは誰の管理下にもない、ということが起こります。
2つ目は、「クラウドだから運営会社が守ってくれる」という思い込みです。 個人情報の取り扱いを外部に任せていても、本人に対して責任を負うのは情報を集めた自社です。委託先で事故が起きれば、報告や本人への連絡が必要かを判断し、問い合わせに答えるのは自社の仕事になります。
3つ目は、預けているデータが増え続けることです。 配信リストは足すことはあっても、消すことはあまりありません。数年前のイベント参加者や退会済みの会員まで残っている、という状態は珍しくありません。事故が起きたとき、そもそも何を預けていたのかを答えられない会社も少なくないのです。
コンサルタントならこう考える：発注側が整えるべき5つの仕組み
ニュースでは「パスワードの変更」「不審メールへの注意」といった利用者向けの対策が多く紹介されます。それも大事ですが、発注側の担当者として考えたいのは、次に同じことが起きたときに慌てないための仕組みです。
1. SaaS台帳に「預けているデータ」まで書く
まず、全社で使っているSaaSを洗い出し、台帳にします。ポイントは、サービス名と契約部門だけでなく、「誰の情報を、どの項目で、およそ何件預けているか」まで書くことです。今回のような事故が起きたとき、最初に聞かれるのは「うちは使っていたか」「何件影響するか」です。この2つに1時間で答えられるかどうかで、初動の速さが大きく変わります。
洗い出しには、経理の支払データ（カードやクラウド利用料の明細）を見るのが近道です。部門へのアンケートだけでは、少額の契約は漏れやすくなります。
2. 預けるデータを最小にし、定期的に消す
漏れて困る情報は、そもそも預けないのが一番の対策です。メールマガジンならメールアドレスだけで足りることが多く、氏名や所属、住所まで登録する必要があるかは見直す余地があります。あわせて、「最後に配信してから2年以上たったリストは消す」「イベント参加者のリストは開催後◯か月で消す」といった保存期間のルールを決め、年に1回は棚卸しをします。
3. 選定・契約のときに確認する項目を決めておく
SaaSは約款で契約することが多く、個別に交渉できる余地は小さいのが現実です。だからこそ、申し込む前に確認する項目を社内で決めておくことが大切です。たとえば次のような項目です。
- 事故が起きたとき、どの手段で何時間以内に利用者へ連絡するか
- 解約したとき、データがいつ消えるか（消えた証明が出せるか）
- 第三者認証の取得状況や、セキュリティの説明資料（チェックシート）があるか
- 管理画面のアクセスログや操作ログを利用者が確認できるか
- 多要素認証やアクセス元の制限を利用者側で設定できるか
部門が申し込む前に情シスがこの項目を確認する、という簡単な手続きを作るだけでも、管理されないSaaSは大きく減ります。
4. 止まったときの代わりの手段を用意しておく
今回の事案で見落とされがちなのが、「送れなくなる」という影響です。自治体なら防災や行政のお知らせ、企業なら障害や手続きの連絡にメール配信SaaSを使っているケースもあるはずです。マーケティング用のメールなら数日止まっても大きな問題にはなりませんが、障害の連絡、防災、決済や手続きのお知らせといった止まると困る連絡をSaaSに任せている場合は、別の手段を決めておく必要があります。別のサービスとの併用、Webサイトでの告知、SMSなどです。業務の重要度によって必要な備えは変わるため、台帳に「止まったときの影響」も1行書いておくと判断しやすくなります。
5. 委託先で事故が起きたときの初動手順を決めておく
自社の事故対応の手順はあっても、「委託先で事故が起きたとき」の手順がない会社は多いです。最低限、次のことを決めておきましょう。
- 委託先からの連絡や報道を受けたとき、誰に集めるか（窓口）
- 影響の範囲を誰が確認するか（台帳を見る人、委託先に問い合わせる人）
- 個人情報保護委員会への報告や本人への連絡が必要か、誰が判断するか
- 自社のWebサイトでの公表文と、問い合わせ対応の準備をどうするか
今回も、利用組織の多くが数日のうちに公表しています。事前に手順と文面のひな形があれば、慌てて対応してミスをするリスクを下げられます。
明日からできる3つのこと
全部を一度にやるのは大変なので、まずは次の3つから始めることをおすすめします。
1. 経理の支払明細から、名簿を預けているSaaS（メール配信、フォーム、アンケート、イベント受付など）を洗い出す
2. その中で件数が多いもの、止まると困るものを上位3つ選び、預けている項目と件数、代わりの連絡手段を確認する
3. 「委託先で事故が起きたら誰に連絡するか」を1枚の紙にまとめ、関係部門に共有する
まとめ
今回の事案は、自社が直接攻撃されたわけではないのに、自社の名簿が漏えいしたかもしれないという、委託先SaaSならではの事故でした。SaaSは便利で、部門の判断で手軽に使えるからこそ、管理の目が届きにくくなります。大切なのは、預けているデータを台帳で把握すること、預けるデータを最小にすること、申し込む前の確認項目を決めること、止まったときの代わりの手段を用意すること、そして委託先の事故の初動手順を決めておくことです。「預けた情報も自社の情報」という前提で、発注側として仕組みを整えておきましょう。
参考
- 【第2報】当社子会社が提供する「ブラストメール」における不正アクセスによる情報漏えいおよびサービス停止について（株式会社ラクス）
- 環境省 報道発表資料（2026年10月23日）
- メール配信サービスの契約者情報全て漏えい 横浜市やJR四国などに影響 ラクス子会社に不正アクセス（ITmedia NEWS）
- ブラストメールに不正アクセス、全契約者の顧客情報を外部持ち出し（セキュリティ対策Lab）
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント