自社が直接攻撃されたわけではなくても、利用しているクラウドサービス、メールサービス、レンタルサーバー、ファイル転送サービスで事故が起きることがあります。
その時に、次のように考えてしまうと対応が遅れます。
「サービス会社の事故だから、自社は関係ない」
「個別連絡が来ていないから大丈夫だろう」
「ニュースを見たが、何を確認すればよいか分からない」
「パスワード変更の案内が来たら、その時だけ対応すればよい」
しかし、クラウドや外部サービスは、自社の業務の一部として使っています。メール、ファイル転送、顧客管理、会計、勤怠、ECサイト、予約受付などで利用している場合、そのサービス上に自社の顧客情報、取引先情報、従業員情報、見積書、契約書、請求書、認証情報が残っていることがあります。
つまり、サービス提供事業者側の事故であっても、自社の顧客対応、取引先対応、パスワード変更、法令上の報告要否確認が必要になる場合があります。
今回は、2026年6月に公表されたKDDIのISP事業者向けメールシステムの事案、NTTPCコミュニケーションズのWebARENA関連事案を例に、利用企業側が最初に確認すべきことを整理します。
利用先の事故は、自社の業務リスクでもある
IPAの「中小企業のためのクラウドサービス安全利用の手引き」では、クラウドサービスでは、情報セキュリティ対策についてサービス提供事業者に委ねる部分が発生し、利用者が直接管理できない部分については、機能だけでなく付随するセキュリティ対策も確認したうえで利用する必要があると説明されています。また、クラウドサービスのセキュリティは、提供事業者と利用者が役割と責任を分担して対策を実施することで維持・向上すると整理されています。
ここで重要なのは、「サービス提供事業者が悪い」「利用者が悪い」という単純な話ではないことです。
クラウドや外部サービスを使う以上、事業者側でしか対応できない部分があります。一方で、利用企業側でしか確認できないこともあります。
たとえば、次のようなことです。
- そのサービスを自社で使っていたか
- どの部署、誰が使っていたか
- どの期間に利用していたか
- どのファイルやデータを保存、送信、アップロードしていたか
- 顧客情報や従業員情報が含まれていたか
- 同じパスワードを他のサービスでも使っていないか
- 取引先や顧客への説明が必要か
- 個人情報保護委員会への報告要否を確認すべきか
これらは、サービス提供事業者の発表だけでは分かりません。
自社側で利用実態を確認する必要があります。
事例1：ISP向けメールシステムの不正アクセス
2026年6月23日、KDDIは、ISP事業者向けに提供するメールシステムで不正アクセスがあり、各ISP事業者が提供する電子メールサービスの情報の一部が外部に漏えいした可能性があると公表しました。KDDIの発表では、2026年6月17日に不正アクセスを確認し、第三者製ソフトウェアの脆弱性が悪用され、メールサービスの利用に必要となるメール関連情報が漏えいした可能性があると説明されています。
対象として公表されたISP事業者およびメールサービスには、STNetのピカラ関連メールサービス、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメールサービス、J:COM NET関連メールサービス、コミュファ光・ビジネスコミュファのメールサービス、@niftyメール、BIGLOBEメールが含まれています。漏えいした可能性のある情報は、メールボックスに紐づくメールアドレス・パスワード最大1,422万件で、解約済みや一定期間利用のない休眠利用者も含まれるとされています。
このような事案で利用企業側が確認すべきことは、「KDDIの事故かどうか」だけではありません。
自社が対象メールサービスを業務で使っていたか、現在使っていなくても過去に使っていたか、退職者や共有メールに残っていないかを確認する必要があります。
特に、古いプロバイダメールやレンタルサーバーのメールは、次の用途で残っていることがあります。
- 代表メール
- 問い合わせメール
- 社長や役員のメール
- 経理、請求、受発注用メール
- レンタルサーバーやドメイン管理の連絡先
- 古いECサイトや予約サイトの登録メール
- 退職者が使っていたメール
- 現在は使っていないが転送だけ残っているメール
KDDIは、メールアドレスおよびパスワードが第三者に不正取得されている可能性があるため、利用者側でメールパスワードの変更が必要になると説明しています。
そのため、自社で対象サービスを使っていた場合は、単に「案内を待つ」のではなく、対象メールの有無、利用者、転送設定、他サービスでのパスワード使い回しを確認することが重要です。
事例2：ファイル転送サービスやサーバーの不正アクセス
2026年6月23日、NTTPCコミュニケーションズは、「WebARENA 大容量ファイル転送機能」の停止について公表しました。同社の発表では、2026年4月29日深夜から外部からの攻撃と思われる通信が断続的に発生し、安全性確保のため当該サーバーへのアクセスを遮断して機能を停止したこと、調査の結果、2026年4月21日から第三者による不正アクセスの痕跡を確認したことが説明されています。
同機能に関して、該当サーバーに格納されていた情報には、認証ログ、契約者がアップロードした電子ファイル、アップロード関連情報、操作ログ、Webサーバーログが含まれていました。アップロードされた電子ファイルは2026年4月19日から2026年4月30日までの期間で4,463件、認証ログにおけるユニークメールアドレスは2019年3月5日から2026年4月30日までの期間で7,446件と公表されています。
同社は、情報漏えいを示す明確な痕跡は確認されていない一方で、その可能性を完全には否定できないと説明しています。また、対象となる顧客には契約IDを記載して順次個別連絡するとし、フィッシング等の不審メールとの見間違い防止のため、送信元や内容を確認するよう案内しています。
また、同日公表された「WebARENA SuiteX 一部サーバー（dc70.etius.jp）」の事案では、第三者による不正アクセスの痕跡、一部顧客領域での不審ファイル設置の痕跡、契約者コンテンツとしてWebコンテンツ、メールコンテンツ、管理者アカウント／パスワード、Webアカウント／パスワード、メールアカウント／パスワードなどが格納されていたことが公表されています。
このような事案では、利用企業側は「漏えいしたと確定していないから何もしない」ではなく、対象期間中に自社が何を保存し、何を送信し、どのアカウントを使っていたかを確認する必要があります。
最初に確認するのは「自社が対象かどうか」
事故の公表を見た時、最初に行うことは、社内で騒ぐことではありません。
まず、自社が対象サービスを使っているかを確認します。
確認する項目は、次のとおりです。
| 確認項目 | 確認内容 |
|---|---|
| サービス名 | 公表されたサービスを自社で使っているか |
| 契約名義 | 自社契約か、親会社・関連会社・委託先契約か |
| 契約ID | 公式案内や個別連絡と照合できる契約番号があるか |
| 管理者 | 誰が管理画面に入れるか |
| 利用部署 | 総務、経理、営業、EC担当、制作会社など |
| 対象期間 | 公表された対象期間中に利用していたか |
| 対象データ | メール、ファイル、Webコンテンツ、個人情報、認証情報など |
| 現在の状態 | 利用中、停止中、過去利用、転送のみ、解約済み |
| 個別連絡 | 事業者から連絡が来ているか |
| 公式発表 | 公式サイト上の発表と一致しているか |
特に注意したいのは、契約名義です。
中小企業では、次のような状態がよくあります。
- 社長個人名義で契約している
- 創業時の担当者名義で契約している
- 制作会社が契約している
- 旧会社名や旧住所のまま契約している
- 関連会社の契約を共用している
- 解約したつもりでもメールだけ残っている
事故発生時に個別連絡が届かない原因になることもあるため、契約情報の更新状況も確認してください。
公式情報とフィッシングを見分ける
サービス事故が公表されると、それに便乗したフィッシングメールが出る可能性があります。
NTTPCの公表でも、対象顧客への個別連絡には契約IDを記載し、フィッシング等の不審なメールとの見間違い防止のため、送信元や内容を確認するよう案内されています。
利用企業側では、次のルールを決めておくとよいです。
- メール本文のリンクだけをクリックしない
- 公式サイトのお知らせから情報を確認する
- 契約ID、サービス名、対象期間を照合する
- 送信元ドメインを確認する
- 添付ファイルがある場合は開く前に確認する
- パスワード入力を求められた場合は、公式管理画面から入り直す
- 不審な場合は、公式窓口に電話または問い合わせフォームで確認する
- 社内で受信した案内メールを勝手に転送しない
- 対応担当者を1人または少人数に決める
事故時は、利用者が不安になっています。
「早急にパスワードを変更してください」「アカウント停止を解除してください」といった文面に反応しやすくなります。
だからこそ、公式情報で確認する習慣が必要です。
対象データを確認する
自社が対象サービスを利用していた可能性がある場合、次に確認するのはデータです。
「サービスを使っていたか」だけでなく、何を預けていたかを確認します。
確認すべきデータは、次のようなものです。
- メールアドレス
- メール本文、添付ファイル
- アップロードした電子ファイル
- ダウンロード用URL
- ダウンロード用パスワード
- Webコンテンツ
- データベース
- 管理者アカウント
- Webアカウント、メールアカウント
- 顧客情報
- 従業員情報
- 見積書、請求書、契約書
- 図面、仕様書、未公開資料
- 取引先から預かった資料
- 認証情報、APIキー、設定ファイル
NTTPCのWebARENA大容量ファイル転送機能の公表では、アップロード関連情報として、日時、IPアドレス、ファイル名、ダウンロード用パスワード、ダウンロード用URL、メッセージが格納されていたとされています。
このような情報は、ファイル本体だけでなく、「誰が、いつ、どのようなファイルを送ったか」を推測できる手掛かりになる場合があります。
自社側では、対象期間中に送信・保存したファイル名、送信先、内容、個人情報の有無、取引先秘密情報の有無を確認してください。
パスワードと認証情報を確認する
事故の対象にメールアドレス、パスワード、アカウント情報が含まれる場合は、パスワード変更を優先します。
ただし、パスワード変更は、対象サービスだけで終わらせてはいけません。
確認すべきことは、次のとおりです。
- 対象サービスのパスワードを変更したか
- 同じパスワードを他サービスでも使っていないか
- 似たパスワードを使っていないか
- 管理者アカウントのパスワードを変更したか
- メール、Web、FTP、SFTP、SSH、DBのパスワードを確認したか
- 退職者や旧委託先のアカウントが残っていないか
- 共有アカウントを使っていないか
- 多要素認証を設定できるか
- APIキー、アプリパスワード、連携トークンが残っていないか
- メール転送設定やフィルタ設定に不審な変更がないか
NTTPCのSuiteX一部サーバー事案では、すでに他サーバー等へ移行済みの場合でも、当該サーバーと同一のパスワードを利用している場合は、メールアカウント、Webアカウント、Webコンテンツのパスワード変更を求めています。
この点は、中小企業にとって重要です。
サーバー移行やサービス切替をしていても、同じパスワードを別サービスで使っていれば、事故の影響が残る可能性があります。
顧客・取引先への影響を確認する
次に、顧客や取引先への影響を確認します。
たとえば、対象サービスに保存・送信していたファイルに次の情報が含まれていた場合、自社だけの問題ではありません。
- 顧客名簿
- 注文情報
- 配送先情報
- 問い合わせ内容
- 契約書
- 見積書
- 請求書
- 従業員情報
- 履歴書
- 給与、勤怠、健康情報
- 取引先から預かった図面、仕様書、秘密資料
ここで必要なのは、すぐに一斉通知を出すことではありません。
まず、事実関係を整理します。
| 確認項目 | 内容 |
|---|---|
| 対象期間 | いつからいつまでの利用が対象か |
| 対象者 | 顧客、取引先、従業員、応募者など |
| 対象件数 | 何人分、何社分、何ファイルか |
| 情報項目 | 氏名、住所、メール、電話番号、口座、カード、マイナンバー等 |
| 漏えい可能性 | 確定、可能性あり、確認中、不明 |
| 二次被害 | 不正ログイン、不審メール、不正利用など |
| 自社対応 | パスワード変更、共有停止、連絡、報告、相談 |
| 相手方対応 | 注意喚起、確認依頼、再送、差し替えなど |
個人情報保護委員会は、漏えい等報告について、発覚したら速やかに報告し、速報は発覚日から3〜5日以内、確報は発覚日から30日以内、不正な目的で行われたおそれがある場合は60日以内と案内しています。
また、報告が必要な場合として、要配慮個人情報が含まれる個人データの漏えい等、不正利用により財産的被害が生じるおそれがある個人データの漏えい等、不正の目的をもって行われたおそれがある行為による個人データの漏えい等、本人の数が1,000人を超える漏えい等が示されています。
そのため、サービス提供事業者の事故であっても、自社が取り扱う個人データに関係する可能性がある場合は、報告要否を個別に確認する必要があります。
「事業者が報告するから自社は不要」と決めつけない
クラウドサービスや委託先で事故が起きた場合、「サービス提供事業者が個人情報保護委員会に報告するから、自社は何もしなくてよい」と考えてしまうことがあります。
しかし、これはケースごとに確認が必要です。
個人情報保護委員会のページには、漏えい等報告フォームの記入例として「委託先事例」や「クラウド事業者による代行報告事例」が掲載されています。
つまり、委託先やクラウド事業者が関係する事故でも、誰がどの立場で報告するのか、代行報告なのか、自社で報告が必要なのかは、契約関係、個人データの管理主体、事故の内容によって判断する必要があります。
特に次の場合は、慎重に確認してください。
- 自社の顧客データをクラウドに保存していた
- 委託先に個人データを渡していた
- ファイル転送サービスで個人データを送っていた
- 自社のECサイトや会員サイトのデータが含まれる
- 従業員情報、応募者情報、健康情報、マイナンバーが含まれる
- 取引先から預かった個人情報が含まれる
- 漏えいの有無が確定していないが、そのおそれがある
報告要否は、法務、個人情報保護責任者、外部専門家、必要に応じて関係機関に確認してください。
不確かなまま「報告不要」と決めることは避けるべきです。
サービス停止時の業務影響も確認する
外部サービスの事故では、情報漏えいだけでなく、サービス停止も問題になります。
NTTPCのWebARENA大容量ファイル転送機能は、公表時点で利用できない状態が継続しており、提供再開は2026年12月頃を目途とすると説明されています。
このような場合、利用企業側では代替手段を考える必要があります。
ただし、急いで次のような対応をすると、別の事故につながります。
- 個人のクラウドストレージを使う
- 無料ファイル転送サービスを社員判断で使う
- メール添付に戻す
- パスワード付きZIPを同じメール経路で送る
- 社外秘ファイルをURL公開設定にする
- 送信記録を残さない
- 取引先ごとに別々の方法で送る
サービス停止時には、次の点を確認してください。
- 代替サービスは会社として承認されているか
- 個人情報や機密情報を送ってよいサービスか
- 送信先を限定できるか
- 有効期限を設定できるか
- 送信後に共有停止できるか
- ログを確認できるか
- 送信記録を残せるか
- 取引先と合意できているか
- 委託契約や社内ルールに反していないか
IPAのクラウドサービス安全利用チェックシートでは、どの業務でクラウドサービスを利用し、どの情報を扱うかを検討して業務の切り分けや運用ルールを明確にすること、取扱う情報の重要度を確認すること、サービス停止やデータ消失・改ざんに備えて重要情報を手元に確保し必要時に使えるようにすることなどが確認項目として示されています。
事故が起きてから代替手段を探すのではなく、平時から「このサービスが止まったら何を使うか」を決めておくことが重要です。
事業者に確認すべき質問
サービス提供事業者や委託先から事故の連絡を受けた場合、感情的に問い詰めるのではなく、事実確認に必要な質問を整理して確認します。
以下は、利用企業側が確認すべき質問の例です。
| 分類 | 確認する質問 |
|---|---|
| 対象確認 | 当社契約は対象ですか。対象契約IDはどれですか。 |
| 対象期間 | いつからいつまでの利用・保存・アクセスが対象ですか。 |
| 対象情報 | 当社に関係する情報として、何が格納されていましたか。 |
| 漏えい可能性 | 漏えいは確定ですか、可能性ですか、調査中ですか。 |
| 不正利用 | 二次被害や不正利用は確認されていますか。 |
| 技術的原因 | どの機能、サーバー、脆弱性、設定が関係していますか。 |
| ログ | 当社分のログ、アップロード履歴、接続履歴は提供可能ですか。 |
| パスワード | どのパスワードを変更すべきですか。再利用時の注意はありますか。 |
| 代替手段 | サービス停止中の推奨代替方法はありますか。 |
| 顧客対応 | 当社顧客への説明に使える文面やFAQはありますか。 |
| 法令対応 | 報告・相談済みの機関、報告主体、代行報告の有無はどうなっていますか。 |
| 再発防止 | 対策完了範囲、再開条件、監視体制はどうなっていますか。 |
| 今後の連絡 | 追加情報はどの窓口、どの方法で連絡されますか。 |
NTTPCの各公表では、外部のセキュリティ専門会社による診断、高リスク脆弱性に迅速に対処する体制、不審アクセスの監視・検知・遮断、経営層主導の継続的改善などが再発防止策として示されています。
利用企業側でも、事業者の再発防止策を確認し、自社の利用継続、代替サービス、契約見直しを判断する材料にしてください。
社内で残すべき対応記録
外部サービスの事故では、社内対応の記録が非常に重要です。
後から、取引先、顧客、監査、保険会社、専門家、関係機関に説明する必要が出ることがあります。
その時に記録がなければ、「対応したつもり」になっていても説明できません。
最低限、次の項目を記録します。
- 事故を知った日時
- 情報源
- 公式発表の内容
- 自社が対象かどうかの確認結果
- 対象契約ID
- 対象期間
- 対象データ
- 個人情報や機密情報の有無
- パスワード変更の実施日時
- 共有停止、アカウント停止、代替手段の実施内容
- 事業者への問い合わせ内容
- 事業者からの回答
- 顧客、取引先、従業員への連絡要否
- 個人情報保護委員会への報告要否の判断
- 未確認事項
- 次回確認日
- 責任者、確認者
この記録は、WordでもExcelでも構いません。
重要なのは、時系列で残すことです。
利用サービス事故対応チェックリスト
以下は、そのまま社内で使える簡易チェックリストです。
利用サービス事故対応チェックリスト
事故を知った日：2026年7月21日
対象サービス：〇〇
確認担当者：〇〇
責任者：〇〇
| No. | 確認項目 | 結果 | 備考 |
|---|---|---|---|
| 1 | 公式サイトで事故情報を確認した | 済・未 | メール本文だけで判断しない |
| 2 | 自社が対象サービスを利用しているか確認した | 済・未 | 契約ID、契約名義も確認 |
| 3 | 対象期間中の利用有無を確認した | 済・未 | 過去利用、休眠、転送も確認 |
| 4 | 対象データを確認した | 済・未 | メール、ファイル、Web、DB等 |
| 5 | 個人情報・機密情報の有無を確認した | 済・未 | 顧客、従業員、取引先 |
| 6 | 対象アカウントのパスワードを変更した | 済・未 | 管理者、メール、Web、FTP等 |
| 7 | 同じパスワードを使っている他サービスを確認した | 済・未 | 再利用があれば変更 |
| 8 | 退職者・委託先・共有アカウントを確認した | 済・未 | 不要なら停止 |
| 9 | ログ、送信履歴、アップロード履歴を確認した | 済・未 | 削除しない |
| 10 | 顧客・取引先への影響を確認した | 済・未 | 必要なら連絡方針を作成 |
| 11 | PPC報告要否を確認した | 済・未 | 個別判断 |
| 12 | 代替サービスを承認済み手段から選んだ | 済・未 | 個人ストレージ利用は禁止 |
| 13 | 事業者への確認質問を整理した | 済・未 | 回答を記録 |
| 14 | 社内対応記録を作成した | 済・未 | 時系列で保存 |
| 15 | 次回確認日を決めた | 済・未 | 追加発表を確認 |
このチェックリストを作っておくと、外部サービス事故が発生した時に、担当者が「何から始めればよいか」で迷いにくくなります。
平時にやっておきたいこと
事故が起きてからサービス一覧を作るのは大変です。
平時から次の情報を整理しておくことをおすすめします。
- 利用中のクラウドサービス一覧
- メールサービス一覧
- レンタルサーバー、ドメイン、DNSの契約一覧
- ファイル転送サービス、オンラインストレージ一覧
- 管理者アカウント一覧
- 契約ID、契約名義、請求先
- 利用部署、利用目的
- 保存している情報の種類
- 個人情報の有無
- 委託先、制作会社、保守会社の連絡先
- 事故時の社内責任者
- 代替手段
- 契約書、利用規約、SLA、サポート窓口
IPAのガイドラインでは、中小企業向けに「中小企業の情報セキュリティ対策ガイドライン第4.0版」、資産管理台帳、クラウドサービス安全利用の手引き、セキュリティインシデント対応の手引きなどが公開されています。
自社の管理表を一から作るのが難しい場合は、こうした公的資料の項目を参考にすると始めやすくなります。
まとめ
取引先や利用中のクラウド、メール、サーバーで事故が起きた時、「自社が攻撃されたわけではないから関係ない」と考えるのは危険です。
外部サービスは、自社業務の一部として使われています。
そのため、事故が起きた場合は、自社が対象か、どの期間に利用していたか、どのデータを保存・送信していたか、パスワード変更が必要か、顧客や取引先への影響があるかを確認する必要があります。
中小企業が最初に確認すべきことは、次の5つです。
- 公式情報で事故内容を確認し、フィッシングに注意する
- 自社が対象サービスを利用しているか、契約IDと対象期間を確認する
- 保存・送信していたデータ、個人情報、機密情報の有無を確認する
- パスワード変更、アカウント整理、同一パスワードの使い回し確認を行う
- 顧客・取引先連絡、PPC報告要否、代替サービス利用を記録付きで判断する
クラウドサービスは便利ですが、利用者が何も管理しなくてよいという意味ではありません。IPAも、クラウドサービスでは事業者に委ねる部分があり、利用者はサービスの機能だけでなくセキュリティ対策も確認したうえで利用する必要があると説明しています。
ライトハウスコンサルタントでは、中小企業向けに、利用クラウド・メール・サーバーの棚卸し、事故時チェックリストの作成、委託先・サービス提供事業者への確認項目整理、個人情報漏えい時の初動対応、顧客向け説明文の作成支援を行っています。まずは、自社で使っている外部サービス一覧を作るところから始めてください。
