結論を先に置く。顧客接点をSaaSに委ねた会社にとって、そのSaaSのインシデントは「他社のセキュリティ事故」ではなく「自社名義の事故」である。 SMS配信・メール配信・CRM・MAといったサービスが破られたとき、攻撃メッセージは自社の名前で、自社の顧客に届く。運営事業者は紛れもなく被害者だが、メッセージを受け取った側から見れば、送信元は利用企業だ。被害と加害が同じ会社の上で同時に成立する——これが顧客接点SaaSに固有のリスク構造であり、ファイアウォールでもバックアップでも防げない。防げる場所は一つしかない。どのSaaSに、何を預け、どんな契約で使うかという発注側の判断である。
2026年7月14日、法人向けSMS配信サービスを提供する株式会社メディア4uが、SMS配信システムへの不正アクセスを公表した。管理コンソールのアカウント管理情報95,412レコードが流出し、うち22,928件には個人情報に該当し得る情報(担当者名や個人を識別し得るメールアドレス等)が含まれる可能性がある。さらに、特定1社のクライアントアカウントを経由して、不正なSMSが280件送信されたことが確認されている。この280件こそが本記事の主題だ。その1社は何も落ち度を公表されていない被害者でありながら、280人の受信者にとっては「あの会社から変なSMSが来た」の主語になった。
この記事から持ち帰ってほしい打ち手は3つある。第一に、自社が顧客接点を委ねているSaaSを棚卸しし、「乗っ取られたら自社名義で何が起きるか」を書き出すこと。第二に、SaaSの選定・契約の段階で、インシデント時の通知期限・開示範囲・責任分界・費用負担を確認しておくこと。第三に、契約先SaaSが破られた日に誰が顧客へ何を言うかという対応分担を、平時に決めておくことだ。以降、公表された事実の確認から順に組み立てていく。
誰のための記事か
本記事は、セキュリティ技術者ではなく、次のような立場の読者に向けて書いている。
- 予約確認・発送通知・督促・認証コードなどをSMS配信やメール配信のSaaSで顧客に送っている会社の経営者・事業責任者
- CRM・MA・フォームツールなどに顧客の連絡先を預けているが、その預け先の安全性を「有名なサービスだから」以上の根拠で判断したことがない会社
- 情シスが兼任1人、またはIT判断が実質的に経営者と現場任せで、SaaSの契約書・利用約款を誰も読まずに使い始めている会社
- 委託先や利用サービスの事故のたびに「うちは大丈夫か」と不安になるが、確認の手順を持っていない管理部門
逆に、今回の事案の攻撃手法の詳細を知りたい読者には応えられない。後述のとおり、侵入経路は運営会社が理由を示したうえで開示していない。本記事はその非開示を批判するのではなく、「開示されない前提で発注側は何を備えるか」に紙幅を使う。
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
何が起きたか——公式リリース2本の時系列
事実関係は、メディア4uの公式リリース(第1報・第2報)で確認できた範囲のみを記載する。
横にスクロールして確認できます
| 日付 | 出来事 | 情報源 |
|---|---|---|
| 7月14日 | SMS配信システムへの第三者による不正アクセスを公表(第1報)。管理コンソール用のアカウント管理情報一覧(アカウントID、企業名/営業所名、担当者名、都道府県・郵便番号、通知用メールアドレス等)95,412レコードが流出、うち22,928件は個人情報に該当し得る情報を含む可能性。特定1社のクライアントアカウントを経由した不正SMS送信280件を確認。パスワード・パスワードハッシュ・APIキー・認証トークン・決済/請求情報・SMS送信先の電話番号・氏名・送信本文は流出対象に含まれないと公表。親会社の株式会社ファブリカホールディングス(東証スタンダード:4193)からも別途公表が行われた旨を記載 | メディア4u公式(第1報) |
| 7月17日 | 続報を公表(第2報)。脆弱性の修正、管理用認証情報の全件無効化・再発行(タイムライン上は6月24日〜7月13日に予防的措置として実施と記載)、ログイン監視の強化を実施し、パスワードポリシーの強化を予定。利用企業に対しては全契約でのパスワード変更を推奨。侵入経路等の詳細は「当事者保護、調査への影響および他のお客様の保護」の観点から開示を差し控えると明記。個人情報保護委員会と協議中で、整理が確定し次第あらためて報告するとした | メディア4u公式(第2報) |
この時系列から、発注側の目で読み取るべき点は3つある。
第一に、流出したのはエンドユーザーの情報ではなく、利用企業側の情報だという点だ。SMSの送信先である一般消費者の電話番号や氏名は流出対象に含まれないと公表されている。漏れたのは、管理コンソールを使う「利用企業の企業名・担当者名・通知用メールアドレス」——つまり、このSaaSを業務で使っている会社の窓口情報である。これが何を意味するかは次章で掘り下げるが、「エンドユーザーの個人情報は無事だから実害は小さい」という読み方は誤りだ。
第二に、**不正SMS280件は「特定1社のアカウント経由」**である点だ。攻撃者は配信基盤そのものを乗り物にしたのではなく、正規の利用企業のアカウントというかたちで自らを送信者に仕立てた。件数として280件は大規模とは言えない。しかし、悪用の成立条件が「アカウントに入れること」だけだったのなら、規模は攻撃者の意図の問題でしかなく、次の事案で同じ件数にとどまる保証はどこにもない。
第三に、事業者側の強い措置は「管理用」に限られ、利用企業側は「推奨」止まりだという点だ。続報のタイムラインによれば、管理用認証情報の全件無効化・再発行は第1報の公表前(6月24日〜7月13日)に予防的措置として実施済みで、利用企業のアカウントについては強制無効化ではなく「全てのご契約においてパスワードの変更を推奨」という位置づけである。事業者の対応として不合理ではないが、発注側から見れば重要な含意がある——自社アカウントの防御は、事業者の措置では完結しておらず、自社が推奨に従って動いて初めて閉じる。事業者の公表文で「実施済み」と書かれた措置の主語と対象がどこまでか、推奨事項が自社側に残っていないかを読み分けることが、この種の公表文を受け取ったときの発注側の実務になる。
「被害者なのに加害側」——顧客接点SaaSに固有の構図
今回の構図を一般化すると、顧客接点SaaSのインシデントには三層の当事者がいる。SaaS事業者、利用企業、そして利用企業の顧客(メッセージの受信者)だ。事故が起きたとき、この三層の間で「被害」と「責任」の見え方が食い違う。ここを整理しておかないと、発生時の対応をすべて誤る。
利用企業は、法的には被害者で、顧客の体験上は加害側に置かれる。 不正SMSの受信者は、SMSアプリの画面で「いつも通知をくれるあの会社」からのメッセージとして攻撃を受け取る。SMSはメールに比べて開封されやすいとされ、送信元への信頼を前提に読まれる媒体だ。その信頼は利用企業が営業活動で積み上げたものであり、攻撃者はそれをそのまま流用する。受信者が抱く不信の宛先は、名前も知らないSaaS事業者ではなく、画面に表示された利用企業になる。「うちも被害者です」という説明は事実だが、顧客の不信を解消する言葉としてはほとんど機能しない。
流出した「利用企業の窓口情報」は、次の攻撃の素材になる。 企業名・担当者名・通知用メールアドレスの組み合わせは、攻撃者から見れば「このサービスを業務利用している会社の、通知を受け取る担当者」のリストである。ここに「不正アクセスのお詫びとパスワード再設定のお願い」を装ったフィッシングメールを送れば、受信者は実際に当該サービスの利用者であり、実際にインシデントが起きた直後なのだから、開封と入力の確率は平時の比ではない。パスワードやAPIキーそのものが流出していなくても、それを釣り上げるための最適な名簿が流出した——この二段目の攻撃面を想定できるかどうかが、公表文の「非流出」の読み方を分ける。インシデント公表直後の便乗フィッシングは常套手段であり、利用企業の側では「本物の事業者からの案内」と「それを装う攻撃」を見分ける前提(正規ドメインの確認、メール内リンクからの認証情報入力をしない等)を担当者に共有しておく必要がある。
そして、顧客への説明責任は利用企業の側に残る。 SaaS事業者が通知する相手は、契約関係にある利用企業までだ。その先にいる受信者・顧客への説明は、顧客との関係を持つ利用企業にしかできない。仮に預けていた顧客データが漏えいする事案であれば、個人データの取扱いを委託していた委託元として、利用企業自身に個人情報保護委員会への報告や本人通知の義務が生じ得る(今回の事案ではエンドユーザー情報は非流出と公表されているが、構図としては常にこの可能性を抱えている)。つまり、SaaSの利用とは業務の外注であって、責任の外注ではない。この当たり前の原則が、月額数万円の手軽さの中で忘れられている会社は多い。
もう一つ、今回の事案が発注側に突きつけた論点がある。侵入経路の非開示だ。運営会社は「当事者保護、調査への影響および他のお客様の保護」を理由に、詳細の開示を差し控えると明記した。調査継続中の攻撃手法の公開が二次被害を招き得る以上、この判断自体には合理性がある。取引先の障害公表文をどう読むかという一般論はニチレイ事案を題材にした需要側BCPの記事で扱ったので繰り返さない。ここで指摘したいのは別の点だ。公表ベースで詳細が出ないのが通例なのだとしたら、利用企業が自社への影響を判断するための情報は、契約でどこまで引き出せるかによって決まるということである。「原因は何か」「自社のデータとアカウントは対象か」「同じ経路は塞がれたのか」——これらを聞く権利は、約款と契約に書かれていなければ、事故が起きてから頼み込むしかない。侵入経路の非開示という開示姿勢そのものが、「契約で何を開示させるか」を選定時の論点に格上げした、と受け取るべきだ。
手順1: 顧客接点SaaSの棚卸し——「乗っ取られたら自社名義で何が起きるか」
備えの第一歩は、防御の強化ではなく現状把握だ。自社の名義・顧客・データを預けているSaaSを、次の5ステップで棚卸しする。専任の情シスがいなくても、管理部門と各部門の責任者が半日集まれば一巡できる粒度にしてある。
ステップ1: 顧客に「届く」サービスをすべて挙げる。 SMS配信、メール配信、CRM、MA、問い合わせフォーム、チャットツール、予約システム、決済・請求の通知、LINE等の公式アカウント運用ツール。判定基準は「そのサービスが自社の顧客に何かを表示・送信できるか」だ。情報システム部門の管理台帳だけでは足りない。マーケティング部門が独自契約したMA、営業が入れたフォームツールなど、部門判断で始まったサービスは経費精算とクレジットカード明細から洗い出す。
ステップ2: 各サービスに「何を預けているか」を書く。 顧客の電話番号・メールアドレス・氏名・購買履歴・問い合わせ内容。加えて見落とされがちなのが「名義」だ。送信元として表示される社名・サービス名、メールの送信ドメイン、API連携のキー。データと名義の両方が預かり対象である。
ステップ3: 乗っ取りシナリオを1行で書く。 「このサービスの管理画面に攻撃者が入ったら、自社名義で○○ができる」を各サービスについて1行ずつ書く。SMS配信なら「全顧客に自社名でフィッシングSMSを送れる」、MAなら「顧客リストを持ち出し、自社ドメインで偽キャンペーンメールを送れる」。この1行が書けたサービスが、優先的に守るべき顧客接点だ。技術的な分析は要らない。経営者が読んで背筋が伸びる文になっていれば、棚卸しとして機能している。
ステップ4: アカウントの実態を確認する。 管理者権限を持つのは誰か。退職者のアカウントは残っていないか。多要素認証は有効か。そして今回の事案が教えるとおり、サービスからの通知を受け取るメールアドレスはどこか。通知先が退職者の個人アドレスや誰も見ない共有ボックスなら、事業者が緊急告知を出しても自社には届かない。インシデント時の生命線は、この地味な設定である。
ステップ5: 各サービスの緊急時連絡経路と公表ページを控える。 障害・インシデントの告知がどのURLに出るか、緊急時のサポート窓口はどこか。事故の日に検索から探し始めるのではなく、台帳の1列として平時に埋めておく。
この棚卸しは一度作れば終わりではなく、サービスの追加・解約のたびに更新する運用が要る。自社だけで回しきれない場合、棚卸しと評価を外部の定期運用に乗せる選択肢としてセキュリティ運用の伴走サービスのような形態があることも、体制設計の材料にしてほしい。
手順2: SaaS選定・契約時のチェックリスト——事故の日に効く条項
棚卸しで重要度が見えたら、次はそのサービスの契約・約款を「事故の日」を想定して読み直す。以下は、顧客接点SaaSの新規選定・契約更新時に確認すべき8項目である。
横にスクロールして確認できます
| # | 確認項目 | 見るべきポイント |
|---|---|---|
| 1 | インシデント通知の期限 | 検知から何時間/何営業日以内に利用企業へ通知するか。「速やかに」だけの規定は事実上の無期限 |
| 2 | 通知の内容 | 暫定段階でも影響範囲の仮判定を出すか。確定するまで沈黙する建付けになっていないか |
| 3 | 開示範囲 | 自社のデータ・アカウントが対象か否かの個別回答、原因・再発防止策の報告(公表とは別に契約当事者へ)を求められるか |
| 4 | 責任分界 | 事業者側の責任範囲と利用者側の責任(アカウント管理・パスワード等)の境界。境界が曖昧なほど事故後に揉める |
| 5 | 損害賠償の上限 | 多くの約款は賠償額を月額利用料の数か月分等に制限している。顧客対応費用の規模と釣り合うかを認識しておく |
| 6 | 費用負担 | 事業者起因の事故における顧客通知・問い合わせ対応等の費用の扱いに関する定めの有無 |
| 7 | 第三者評価 | ISMS等の認証、脆弱性診断の実施、フォレンジック結果の要旨提供の可否 |
| 8 | データの扱い | 預けたデータの保存範囲・期間、解約時の削除、再委託の有無と通知 |
現実的な注意を2つ添える。
第一に、約款型のSaaSでは個別交渉の余地は小さい。月額数万円のサービスに対して条項の修正を求めても通らないことが多い。だがそれはこのチェックリストが無意味だという意味ではない。交渉できないなら、このリストは「どのサービスを選ぶかの比較軸」として機能する。同じ機能・同じ価格帯の候補が2つあれば、通知期限を約款に明記している方、第三者認証と診断実績を公開している方を選ぶ。条項を直せない発注者にとって、選定こそが最大の契約行為である。
第二に、契約で埋められない穴は運用側のコントロールで補う。預けるデータを必要最小限に絞る(配信に不要な属性を同期しない)、権限の強いAPIキーを発行しない、通知先を必ず複数人が見るアドレスにする、重要度の高い顧客接点は単一サービスに全依存しない。契約と運用は、どちらかで足りなければもう一方で補う関係にある。賠償上限の条項(項目5)を読んで青ざめたなら、答えは「交渉」ではなく「そのサービスに預けるものを減らす」かもしれない。
なお、この8項目はSMS配信に限らず、顧客接点を持つSaaS全般と、システム開発・運用の委託先にもほぼそのまま適用できる。委託先のGitHubアカウントや秘密情報の管理といった開発委託固有の論点は公開リポジトリ経由の秘密情報漏えい対応の記事で別途扱っている。
手順3: 発生時の顧客対応分担——事故の日に決めることを残さない
契約先のSaaSが不正アクセスを公表した日、利用企業の社内で起きるのは技術対応ではなく、判断の渋滞だ。「顧客に言うのか、何を、誰が」「配信は止めるのか」「様子見でいいのか」。これらを事故当日に議論している時点で、初動は負けている。あらかじめ決めておくべきは次の5点である。
1. 起動トリガー。 何をもって自社の対応を開始するか。事業者からの通知、公表ページの掲載、報道、顧客からの「変なSMSが来た」という問い合わせ——最初の一報がどこから来ても同じ手順に入れるよう、トリガーを複線で定義する。今回の事案でも、利用企業が事実を知る経路は事業者の告知だけとは限らなかったはずだ。
2. 判断者と一次対応。 アカウントのパスワード変更・APIキーの再発行・配信の一時停止を、誰の承認で実行するか。特に「配信を止める」判断は、督促や認証コードなど業務に直結する配信ほど重く、現場では決められない。止めた場合の代替手段(別経路での連絡)まで含めて、経営レベルで事前に基準を持つ。
3. 顧客向け文面の雛形。 自社名義の不審なメッセージについて顧客へ注意喚起する文面を、空欄付きの雛形で用意しておく。骨格は3点でよい。「当社が利用する配信サービスで発生した事実」「顧客にお願いしたいこと(不審なメッセージのリンクを開かない・当社がSMSで認証情報を尋ねることはない等)」「次の情報更新の時期」。事故当日にゼロから書く文章は、法務チェックと決裁で半日を失う。雛形があれば、埋めて出すだけになる。
4. 社内の問い合わせ集約。 顧客・取引先からの問い合わせを受ける窓口と、回答してよい内容・してはいけない内容(憶測での原因説明、事業者への責任転嫁)を決めておく。現場の善意の回答が、後から事実と食い違うことが二次被害の典型である。
5. 当局報告・法的対応の判断ライン。 預けていた個人データの漏えいが疑われる場合に、個人情報保護委員会への報告要否を誰が判断するか。委託先経由の漏えいであっても委託元の報告義務が生じ得る以上、「事業者が報告するからうちは不要」と即断してはならない。判断に迷う水準の事案が起きたときに相談する外部の専門家(弁護士・セキュリティ会社)の連絡先を、台帳に載せておく。
この5点は、紙にすればA4で2枚に収まる。だが、あるとないとでは事故当日の景色がまったく違う。手順がなければ「何をすべきか」の議論に半日を使い、手順があれば「手順のどこまで進んだか」の確認で会議が終わる。自社起点のインシデントも含めた初動体制の全体設計は、インシデント対応支援の枠組みで発生前の準備から発生時の対応まで一貫して組み立てられる。
FAQ
Q1. 利用中のSMS配信・メール配信サービスが不正アクセスを公表した。今日、何をすべきか。
順番は4つ。(1)事業者の公表文を確認し、自社のアカウント・データが影響範囲に含まれるかを確認する(不明なら問い合わせる)。(2)当該サービスのパスワードを変更し、APIキーを使っていれば再発行する——事業者が「認証情報は流出していない」と公表していても、コストが小さい以上やらない理由がない(実際、メディア4uも続報で全契約におけるパスワード変更を推奨している)。(3)当該サービスの送信ログを確認し、身に覚えのない配信がないかを見る。(4)担当者に対して、当該サービスを装うフィッシングメールへの警戒(メール内リンクから認証情報を入力しない)を共有する。顧客への注意喚起は、自社名義の不正送信が確認された場合、または事業者の公表内容から顧客への影響が否定できない場合に、本文の雛形の要領で速やかに出す。
Q2. 「パスワードやAPIキー、エンドユーザーの電話番号は流出していない」と公表されている。それなら何もしなくてよいのでは。
非流出の公表は現時点の調査結果であり、多くの公表文はその後の調査で範囲が広がる可能性を留保している。加えて本文で述べたとおり、今回流出が公表されたのは「利用企業の担当者名・通知用メールアドレス」であり、これは認証情報を釣り上げる二段目の攻撃(便乗フィッシング)の名簿として機能する。非流出の公表は「直接の悪用が確認されていない」ことを意味するだけで、「攻撃の材料が渡っていない」ことを意味しない。Q1の(2)〜(4)は実施すべきだ。
Q3. 契約チェックリストは大企業向けではないか。約款は交渉できない。
交渉が目的ではなく、判断が目的だ。約款を直せなくても、(1)候補間の比較軸として使う、(2)穴が分かった状態で預けるデータと権限を絞る、(3)賠償上限と自社の想定損害のギャップを経営として認識しておく——の3つの使い方ができる。「読んだうえで使う」と「読まずに使う」の差は、事故の日に請求書の形で現れる。
Q4. 侵入経路を開示しないベンダーは信用できないのか。
非開示それ自体は不誠実の証拠ではない。調査継続中の手法開示は攻撃者を利し、他の利用企業を危険に晒し得るからだ。ベンダーの実力を測る観点は開示の網羅性ではなく、(1)第一報までの速さと具体性(件数・対象・非対象を数字で示せているか)、(2)是正措置の強度と速度(今回で言えば公表前から予防的に進められていた管理用認証情報の全件無効化・再発行と、3日後の続報)、(3)契約当事者への個別の影響回答に応じるか——の3点で見る。この観点は、事故を起こしたベンダーと契約を続けるかどうかの判断軸にもそのまま使える。
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、自社内の「たぶん大丈夫」で止めず、第三者の目を入れる段階にある。
- 顧客接点SaaSの棚卸しをやろうとしたが、そもそも何を契約しているかが集約されておらず、台帳の初版が作れない
- 「乗っ取られたら自社名義で何が起きるか」の1行が書けたが、その対策として何が過剰で何が不足かを判断できる人が社内にいない
- 利用中のSaaS・委託先の約款を読んだが、責任分界と賠償上限が自社のリスクと釣り合っているか評価できない
- 対応分担の5点を決めようとしたが、配信停止の判断基準や当局報告の要否など、前提知識が要る箇所で止まっている
- 実際にいま、利用サービスのインシデント公表を受けて、顧客への告知要否を今日中に判断しなければならない
GXOは、システム開発会社としてSaaSの構成と契約の両方を読める立場から、顧客接点を含む自社のIT資産・委託先のリスク評価(セキュリティ診断・対策の全体像はこちら)、有事の初動と顧客対応設計を含むインシデント対応支援、平時の棚卸し・台帳運用を継続的に回すセキュリティ運用伴走を提供している。「うちのSMSやメールは、乗っ取られたら顧客に何が届くのか」——この問いに社内で答えが出ないなら、その状態こそが今回の事案から受け取るべき警告だ。お問い合わせから、利用中のサービス名が分かる程度の情報で初回の壁打ちができる。事故の日に最初に露呈するのは技術の穴ではなく、決めていなかったことの多さである。
参考ソース
- SMS配信システムへの不正アクセスに関するお知らせとお詫び(第1報)｜株式会社メディア4u(2026年7月14日)
- SMS配信システムへの不正アクセスに関するお知らせとお詫び(続報)｜株式会社メディア4u(2026年7月17日)
※事実関係は上記公式リリースで確認できた範囲のみを記載した。侵入経路等の詳細は公表されておらず、本記事でも憶測は書いていない。親会社ファブリカホールディングス(東証スタンダード:4193)による適時開示は、第1報に「別途公表」と記載されている事実のみに言及した。棚卸し手順・契約チェックリスト・対応分担はGXOによる一般的な解説であり、同社および特定の利用企業の対応状況を評価したものではない。
