「情報漏洩急増」のニュース、他人事ですか？顧客情報を守るために今すぐ塞ぐべき12の穴

情報確認日：2026年10月21日。本記事は一般的な実務整理です。個別の法的義務や事故対応は、最新の公式案内、契約、組織の担当者・専門家に確認してください。

目次を開く

1. いま何が起きている？2026年10月の情報漏洩ニュースと公式発表
2. 情報漏洩対策とは？攻撃防止だけでは足りない理由
3. 最初に作るべき「情報の流れ」の台帳
4. 認証・権限でできること｜入口と操作範囲を絞る
5. SaaS・端末・メールの利用条件を整える
6. AI・自動化・委託先に対する具体的な対策
7. 検知・バックアップで被害の拡大を抑える
8. 事故が疑われたときの初動対応
9. 個人情報の漏えい等報告・本人通知で確認すること
10. マーケティング部門の活用例｜点検を通常業務に組み込む
11. 30日で進める導入手順と、見落としを減らす点検表
12. 対策ツールを比較し、費用をどう配分するか
13. よくある質問
14. まとめ｜「気をつける」から、確認できる仕組みへ
15. 参考資料・出典

いま何が起きている？2026年10月の情報漏洩ニュースと公式発表

SNSで見かける情報について、拡散量やトレンド順位ではなく、当事者・専門機関の発表で確認できる内容を整理します。以下は2026年10月21日の確認時点の情報です。公表日と発生日は同じではなく、調査の進展で内容が変わる場合があります。Xの投稿数やトレンド入りは本記事では測定していません。

NEC｜委託先の認証情報を経由した被害を10月20日に公表

NECの2026年10月20日発表によると、開発・保守の委託先が9月下旬に攻撃を受け、盗まれた正規アカウントが顧客システムへの不正アクセスに悪用されました。共有クラウド内のファイルについて、個人情報やシステム関連情報を含む漏えいも確認したとしています。詳細は調査中です。

ここから自社の点検へつなげたいのは、委託先が使う端末・認証・共有領域です。ただし、後述する対策をしていれば本件を必ず防げたと結論づけるものではありません。

Studio｜不正アクセスを確認、データ取得の可能性に備えて案内

Studioの公式案内では、9月30日〜10月1日の不正アクセスを確認し、10月13〜14日に脆弱性修正と経路遮断を実施したとしています。第三者による実際のデータ取得は確認できていない一方、取得された前提で対応を進めています。第一報は10月16日、確認した案内の最終更新は10月18日です。

利用企業は、対象の機能・情報と必要な操作を個別案内および最新の公式情報で確認してください。すべての利用者で同じ被害が確定したという意味ではありません。自社の問い合わせフォーム、外部連携、保存データまで確認対象にすることが実務上の論点です。

専門機関も、直近の国内事案について注意喚起している

JPCERT/CCの10月8日公開・9日更新の注意喚起は、2026年9月前後の国内組織で不正アクセスによる漏えい被害が相次いでいる状況を示しています。SNSでの話題だけを根拠にするのではなく、こうした専門機関の情報を確認して行動することが重要です。

情報漏洩対策とは？攻撃防止だけでは足りない理由

情報漏洩対策とは、情報を意図しない相手へ渡さないための予防と、異常の発見、被害拡大の抑制、復旧、再発防止を組み合わせる取り組みです。ウイルス対策ソフトを入れる、研修を実施する、といった単独の対策だけでは範囲が足りません。

「急増」を裏づける調査と、別の統計を混同しない

ＭＭ総研が2026年10月14日に公表した調査では、2026年1〜9月のサイバー攻撃による情報漏えい事案は454件、前年同期比49％増としています。漏えいの可能性を含む、国内の企業・団体のWebサイトや報道で公表された事案が対象で、組織・サービス名を照合し重複を除き、初報の月に計上しています。

この調査の対象と期間では、増加を事実として説明できます。一方、未公表事案を含む国内の全漏洩を数えたものではなく、誤送信などを含むすべての原因を同じ条件で集計した数字でもありません。

個人情報保護委員会の令和7年度年次報告では、2025年4月1日から2026年3月31日の漏えい等事案に関する報告の処理件数は17,139件、前年度は19,056件です。こちらは前年度より減少していますが、対象期間も集計対象もＭＭ総研とは異なります。片方の数字で、もう片方の増減を否定することはできません。

一方で、同委員会は2026年10月7日の大規模漏えい等事案を踏まえた注意喚起を公表しています。数字の増減だけで安全だと判断せず、現在の自社の情報の扱いを点検することが大切です。報告件数と実被害の全体を混同しない姿勢は、社内への説明にも必要です。

マーケティング部門にも情報の出口がある

情報システム部門だけが、すべての共有や送信を把握しているとは限りません。営業リストをCSVで渡す、代理店へ広告権限を付ける、AIへレポートを入力する、といった日常業務にも出口があります。担当部署を問わず、扱う情報と接続先を把握してください。

• 顧客情報：氏名、メールアドレス、商談内容、問い合わせ履歴。
• 事業情報：売上、予算、未公開の価格、サービス開発の資料。
• アクセス手段：管理者権限、APIキー、接続アプリ、共有端末。

本記事の12施策は、製品を導入すれば完全に漏洩を防げるという意味ではありません。既存の設定と運用を組み合わせ、何が未対応かを明確にするための実務案です。

最初に作るべき「情報の流れ」の台帳

対策を増やす前に、どこで取得し、どこへ保存し、誰へ渡すかを整理します。IPAの中小企業の情報セキュリティ対策ガイドラインには、資産管理やクラウド、事故対応に関する資料も用意されています。自社の規模に合う形で台帳を作るところから始められます。

施策1｜データ・アカウント・接続先を棚卸しする

台帳には、サービス名だけでなく、扱うデータ、管理者、外部共有、終了条件を残します。最初から全社を完璧に調べるのではなく、顧客情報と管理者権限を扱う業務から確認します。以下は架空のマーケティング部門の記入例です。

担当例は業務責任者、技術確認は管理者です。完了条件は、主要データの保存先と外部提供先に不明なものがない状態です。サービス追加、担当変更、契約終了の際に更新する仕組みにしてください。棚卸しを年一回だけ行っても、その間の連携追加は残り続けます。

台帳に残す最小項目

業務名／サービス名／責任者／管理者
扱う情報の種類／利用目的／保存先
アクセスできる人と外部組織
AI・アプリ・APIへの接続
共有リンクの条件／保存期間／契約終了時の処理
最終確認日／未対応事項／次の担当者

「契約しているから安全」「担当者が知っているはず」で終わらせず、他の担当者も確認できる記録にします。取引先の契約や規程がある場合は、それに従うことが前提です。

認証・権限でできること｜入口と操作範囲を絞る

アカウントを守ることと、ログイン後にできる操作を絞ることは別です。強い認証だけでは、広すぎる権限や外部共有は解決しません。認証、役割、終了時の処理をセットで点検してください。

施策2｜重要アカウントの多要素認証を確認する

メール、ファイル保管、顧客管理、広告管理、CMSの管理者などから優先して確認します。多要素認証は、パスワード以外の要素も使う仕組みです。対応環境ではフィッシング耐性のある認証も検討しますが、認証があればすべての侵害を防げるとは考えません。NISTの認証に関する資料も、方式の違いを理解する参考になります。

管理者は、設定済みの人数だけでなく、対象アカウントのうち何件が未設定かを確認します。例外アカウントを残すなら、理由、代替策、解消期限を記録してください。復旧手段を担当者個人だけに依存させないことも重要です。

• 管理者と一般利用者を分けて集計する。
• 不要な古い認証経路や利用者を確認する。
• 復旧方法と、担当者不在時の連絡経路を決める。

施策3｜権限を役割別に分け、退職・契約終了と連動させる

外部担当者へ管理者権限を付ける前に、その仕事に必要な操作を確認します。閲覧、編集、公開、利用者追加、請求管理は、同じ権限としてまとめない方が点検しやすくなります。サービスが提供する役割の範囲で最小限にします。

退職・異動・委託終了の際は、ログインアカウントだけでなく、共有先、外部アプリ、API、端末、資料の保管先も確認します。パスワード変更だけで、既存のセッションや接続アプリがすべて無効になるとは限りません。実際のサービス仕様に従って、必要な取り消しと再確認を行います。

SaaS・端末・メールの利用条件を整える

個人の注意力だけに依存せず、通常の操作で必要以上に外へ出ない状態を目指します。設定を変更する際は、サービスの管理者と調整し、業務を止めないための例外手順も用意してください。

施策4｜共有リンクと外部公開を定期的に点検する

重要な資料は、対象者を指定した共有を基本に検討します。必要に応じて有効期限、編集可否、再共有、ダウンロードの条件も確認します。ただし、制限しても画面撮影や手動転記まで完全に防げるわけではありません。

リンクを送る前には、別の権限を持つ確認用アカウントなど、承認された方法で見え方を確かめます。本人のアカウントで開けることは、受け手の権限が正しい証拠ではありません。公開前の確認対象には、シートの別タブ、コメント、画像、埋め込み資料も含めます。

• 「リンクを知っている全員」などの公開範囲を確認する。
• 目的が終了した共有と、古い提案資料を点検する。
• 個人用クラウドへのコピーを放置しない。

施策5｜端末の更新・暗号化・ロック・管理状態を確認する

業務端末では、OSやアプリの更新、画面ロック、ストレージの保護、端末管理の対象かを確認します。BYODなど私物端末の利用がある場合は、業務情報をどこへ保存してよいか、紛失や契約終了時にどう処理するかを決めます。

端末の暗号化は、盗難・紛失時のリスク低減に役立つ一方、ログイン済みの端末上で不正操作された場合まで解決するわけではありません。バックアップや復旧キーの管理も含めて、管理者が確認できる状態にします。導入済みという申告だけでなく、管理画面や記録で確認します。

施策6｜公開機器・VPN・CMS・拡張機能の更新を管理する

インターネットへ公開している機器やサービスは、何が存在するかを把握し、保守担当を決めます。更新情報の収集、適用判断、動作確認、適用後の確認を一つの流れにしてください。古い機器やサポート終了製品は、継続利用の理由と移行計画が必要です。

WordPressなら、本体だけでなくテーマ、プラグイン、管理者、バックアップ、外部接続を確認します。更新を闇雲に実行して本番サイトを止めないよう、復旧手順と検証環境も検討します。ブラウザ拡張機能も、メールや顧客管理の画面へアクセスするものがないか確認します。

施策7｜メールとファイル送信を、確認できる手順にする

宛先、添付、公開範囲、送信目的を確認し、重要な送信には必要に応じて承認を組み込みます。社外へ渡す項目を必要最小限にする方が、誤送信した場合の影響も抑えやすくなります。添付ファイルへパスワードを付けるだけで安全と判断しないでください。

AI・自動化・委託先に対する具体的な対策

AIを使うことで、資料の読み取り、外部ツールへの接続、公開までが短い流れでつながる場合があります。便利さを保つためにも、入力、アクセス、実行、出力を分けて管理します。一律に禁止するだけでは、利用状況が見えなくなる可能性があります。

施策8｜AIへ入力してよい情報を三段階で分ける

個人情報保護委員会は生成AIサービス利用に関する注意喚起を公表しています。個人データを入力する場合の扱いやサービスの条件を確認し、単に「学習に使われない」と聞いたことだけで入力可否を決めないことが重要です。

次の表は、社内ルールを作るための設計例です。契約・法令・顧客との約束を確認したうえで調整してください。氏名を消しただけの情報を、十分に匿名化できたと判断するものではありません。

サービス選定時は、学習利用だけでなく、保存期間、共有、管理者の権限、外部連携、削除、利用契約も確認します。具体的なサービスを使う際の整理は、ChatGPTの業務利用ルールと、Geminiの法人利用時の確認事項も参照できます。現在の条件は各公式情報で再確認してください。

施策9｜API・連携アプリ・AIエージェントの権限を絞る

APIキーをチャットや公開コードへ貼らず、承認された保管方法で管理します。自動化に必要な操作だけを許可し、不要になった接続を解除します。読み取りと書き込み、検証環境と本番環境を分けることも検討してください。

AIが読むメール、Webページ、ファイルには、外部の人が書いた指示が含まれ得ます。OWASPのプロンプトインジェクションに関する資料も参考に、外部コンテンツを実行権限の根拠にしない設計が必要です。AIへの「外部送信しない」という文章だけに依存せず、接続権限と承認を制限します。

• 参照してよい保存先と、出力してよい宛先を決める。
• 公開、送信、削除、購入などを承認対象にする。
• 自動化の実行記録と、停止する方法を用意する。

AIエージェントのセキュリティと、MCPサーバーの権限設計は、この論点を詳しく扱う関連記事です。本記事は自社環境を実際に診断した結果ではありません。

施策10｜委託先・代理店・再委託先まで終了条件を決める

委託先には、渡す情報、利用目的、権限、保存先、再委託、事故時の連絡、契約終了時の返却・削除を確認します。「有名な会社だから」「契約書があるから」で、実際の運用確認を省かないでください。

例えば広告代理店への委託終了では、広告管理の利用者だけでなく、顧客リスト、計測、ファイル共有、レポート配信、API接続も対象にします。削除したという連絡を受け取るだけでなく、自社側の管理画面で確認できる部分を点検します。契約上の確認方法は担当者や専門家と相談してください。

検知・バックアップで被害の拡大を抑える

侵入を完全に防ぐことだけを前提にしないためには、異常に気づく仕組みと、業務を戻すための準備が必要です。ただし、復元できることと、漏洩していないことは別です。この違いを経営層にも共有してください。

施策11｜ログ・通知・連絡先を「見られる状態」にする

重要なサービスについて、不審なサインイン、管理者追加、外部共有、大量取得などを、利用できる監視機能で確認します。対象の操作、保管期間、閲覧担当、通知先を決め、通知を出すだけで終わらせないことが大切です。

通知先が退職者になっている、管理者が一人しかいない、記録が短期間で消える、といった状態も点検します。一方で、ログには個人情報や認証に関わる情報が含まれる場合があるため、全社員や外部AIへ無制限に共有しないでください。

施策12｜バックアップと復元テストを分けて確認する

データの種類ごとに、保存先、頻度、管理者、世代、復旧方法を決めます。通常の利用アカウントが侵害された場合でも、バックアップまで同時に破壊されない構成を検討します。具体的な方式は、環境と管理者の判断に合わせてください。

完了条件は「保存に成功した」という通知だけではありません。許可されたテスト環境などで、必要なファイルやシステムを復元できるか、どの程度時間がかかるかを確かめます。顧客情報が外へ出た場合は、復元しても外部に渡った情報を回収できるとは限りません。

事故が疑われたときの初動対応

「漏洩が確定するまで待つ」のではなく、疑いを認識した時点で社内の対応担当へ連絡します。初動の時間配分は事故によって異なります。以下は平時に役割を決めるための整理で、どの事故にも一律の操作を指示するものではありません。

一般担当者が先に伝えること

発見した日時／発見者／連絡できる方法
何を見て異常だと考えたか
関係するサービス、端末、ファイル
漏洩が疑われる情報の種類
すでに行った操作と、その時刻
分かっている事実／まだ確認できていないこと

パスワード、APIキー、漏洩が疑われる個人データそのものを、広い社内チャットへ貼らないでください。必要な証拠の保存と、共有する範囲は対応担当と調整します。疑わしいメールを全社へ転送する行為も、被害や情報の拡散につながり得ます。

管理者・対応担当が行う判断

JPCERT/CCの侵入型ランサムウェア対応FAQでは、被害拡大を防ぐための隔離や専門家への相談が説明されています。実際の環境では、隔離の方法、業務への影響、証拠保全を調整してください。闇雲な再起動、初期化、ファイル削除で記録を失わないよう、対応担当へつなぎます。

• 被害拡大を抑えるために止める接続・共有を判断する。
• ログ、時刻、変更履歴、関連する連絡を保全する。
• 認証情報、セッション、接続アプリの無効化等を検討する。
• 影響範囲と、まだ分からない範囲を整理する。
• 社内責任者、専門家、取引先、関係機関への連絡を判断する。

連絡の順番を決めておく

被害の全容が分からない段階で、「漏洩はありません」と断言しないでください。確認できたこと、調査中のこと、次に案内する予定を分けます。AIに対外説明の文章を作らせる場合でも、実際の個人情報や未確認の原因を安易に入力せず、責任者が内容を確認します。

個人情報の漏えい等報告・本人通知で確認すること

報告が必要かどうかは、情報の種類、事態、業種、委託関係などで確認が必要です。すべての誤送信を一律に同じ期限で扱う説明や、「小さな事故だから不要」という自己判断は避けてください。

法定の報告対象かを早期に確認する

個人情報保護委員会の漏えい等対応の案内では、要配慮個人情報、財産的被害のおそれ、不正な目的によるおそれ、1,000人を超える個人データなどに関する報告対象が説明されています。おそれの段階も含むため、確定前でも対象となり得る点を担当者へ確認します。

報告対象の事態では、速報は速やかに、目安として概ね3〜5日以内、確報は原則30日以内、不正の目的によるおそれがある場合は60日以内と案内されています。これは任意に待ってよい猶予期間という意味ではありません。起算点や報告先、本人通知等は、公式案内と個別事案に沿って判断してください。

未判明事項と追加報告を管理する

件数や原因が未確定の場合は、分かっている情報と未判明事項を分けます。「調査が終わらないから連絡しない」とせず、必要な対応を確認します。具体的な解釈は個人情報保護法ガイドライン・通則編や担当窓口・専門家に確認してください。

顧客との契約や業法等に、別の連絡・報告条件がある場合もあります。本記事だけで判断を完結させず、関係する担当者が確認することが必要です。なお、本記事は法令上の個別判断を代行するものではありません。

マーケティング部門の活用例｜点検を通常業務に組み込む

ここからは架空の設計例です。実際に漏洩を防止できたという検証結果や、特定企業の事故を再現したものではありません。人数が少ない組織でも、仕事が始まる・変わる・終わるタイミングに確認を組み込めます。

広告レポートをAIで分析する場合

最初に、分析の目的と必要な項目を決めます。個別の氏名やメールアドレスが不要なら、許可された集計データだけで分析できないか検討します。顧客名を置き換えても、少数の属性や自由記述から相手が推測される場合があるため、単純な名前の削除だけで安全と判断しません。

次に、承認されたAIサービス、契約、保存や外部連携の条件を確認します。出力は集計元と照合し、社外へ渡す前に個人情報や別案件が混ざっていないか点検します。分析精度の確認と、情報の扱いの確認を別々の完了条件にしてください。

• 入力前：必要な項目と、入力許可を確認する。
• 実行時：接続先、権限、外部送信の有無を確認する。
• 出力後：数値の整合性と公開範囲を人が確認する。

委託先へ制作を依頼する場合

契約開始時に閲覧先と編集先を分け、案件フォルダー単位で必要な範囲だけを共有します。別案件の資料が同じフォルダーに残っている場合は、共有前に分離します。途中で担当者が変わる際も、利用者を追加するだけでなく、前任者の権限が不要になっていないか確認します。

納品時には、公開物の確認に加え、共有リンク、外部アプリ、原稿や顧客素材の返却・削除を点検します。毎回新しい研修を行うより、契約開始・変更・終了のチェック欄へ組み込む方が、確認を忘れにくくなります。実施率や残存権限を測定し、運用できているかを振り返ってください。

30日で進める導入手順と、見落としを減らす点検表

一度に全製品を買い替えるより、重要な情報とアカウントから順に整えます。以下の期間と頻度は編集部の計画例であり、法定の期間や、すべての企業に適切な基準ではありません。現在の事故対応が必要な場合は、この予定より対応を優先します。

今日・一週間・一カ月で分ける

責任者は、実施した作業の数だけでなく、未対応の項目と次の期限を確認します。担当者へ「セキュリティを強化して」とだけ依頼せず、対象、操作、完了条件を決めてください。

定期点検で見る指標

• 重要アカウントの多要素認証：対象数、未設定数、例外。
• 終了した担当者・委託先：停止の所要時間と残存権限。
• 共有リンク：所有者不明、目的終了、広すぎる公開範囲。
• AI・アプリ連携：未承認サービス、不要な接続、過大な権限。
• 復元・初動訓練：実行した日、失敗箇所、改善担当。

頻度の例として、重要な通知は業務日ごと、権限や共有は月ごと、契約変更時には都度確認するなどが考えられます。これは編集部の運用例です。環境のリスクと負担に合わせて調整してください。

対策ツールを比較し、費用をどう配分するか

研修、端末保護、認証、監視、バックアップには異なる役割があります。どれか一つを購入してすべて解決するものではありません。まず既存契約で使える機能と設定を確認し、足りない部分を見積もります。

費用は利用料だけでなく運用まで含める

本記事では、企業ごとの端末数や支援範囲が不明なまま、全国共通の料金相場を置きません。同じ見積もり条件をそろえ、何が含まれ、誰が運用するかを比較してください。高度な検知製品を入れても、通知を見る人が決まらなければ運用上の空白が残ります。

架空の事故で、連絡と判断が機能するかを試す

実在の顧客データや危険な添付ファイルを使わず、架空の共有・誤送信・不審な認証要求などで練習します。知識テストの点数だけでなく、「気づいた人が、必要な情報を、正しい相手へ伝えられるか」を見ます。

架空シナリオ：顧客リストを含む資料の共有範囲を誤った可能性がある。
確認すること：誰に連絡するか、何を止めるか、何を記録するか。
禁止すること：実際の顧客情報を訓練へ流用しない。
振り返り：迷った判断、連絡漏れ、権限不足を改善項目にする。

一人でAIを活用した業務の広げ方は、メディア運営の実務事例でも紹介しています。ただし、実行範囲が広がることと、すべての処理が安全だと証明されたことは別です。効率化と同時に、権限と確認工程も設計してください。

よくある質問

情報漏洩は最新年度も増えていますか？

ＭＭ総研の公表事案調査では、2026年1〜9月のサイバー攻撃による漏洩事案（可能性を含む）は454件、前年同期比49％増です。一方、個人情報保護委員会の令和7年度の報告処理件数は前年度より減少しています。対象・期間が異なるため、同じ統計として扱えません。

最初にやるべき施策は何ですか？

重要情報の保存先と管理者を整理し、メール・ファイル保管・管理者アカウントの認証、不要な権限、緊急連絡先から確認してください。進行中の事故が疑われる場合は、通常の点検より事故対応を優先します。

生成AIを学習オフにすれば安全ですか？

学習利用だけで判断しないでください。入力許可、保存、共有、契約、管理者、外部連携、出力先も確認します。個人情報や顧客情報の入力可否は、社内ルールと関係する条件に基づいて判断してください。

バックアップがあれば情報漏洩も解決できますか？

バックアップは復旧のための対策であり、すでに外部へ渡った情報を取り消すものではありません。漏洩の予防、発見、被害拡大の抑制、対外対応と分けて備える必要があります。

小規模な会社でも委託先の確認が必要ですか？

自社の規模だけで判断せず、渡す情報、アクセス権限、利用目的、契約、再委託、終了時の返却・削除を確認してください。具体的な義務や確認方法は、担当者や専門家と相談します。

事故の報告は原因が分かってからでよいですか？

全容が判明するまで放置しないでください。報告対象や期限、本人通知、契約上の連絡を早期に確認し、その時点で分かる情報と未確認事項を分けて対応します。公式案内と個別事案に沿った判断が必要です。

まとめ｜「気をつける」から、確認できる仕組みへ

情報漏洩対策は、「気をつける」という宣言だけでは完了しません。データの流れを把握し、認証、権限、共有、端末、AI、委託先、監視、復旧をつなげて運用します。

まずは重要な情報と管理者から確認し、未対応事項、担当者、期限を記録してください。「対策しているつもり」ではなく、設定と記録で確認できる状態を作ることが、実務で続けられる対策の出発点です。

参考資料・出典

• NEC：委託先への不正アクセスに起因する情報漏えい等の公表（2026年10月20日）
• Studio：不正アクセスに関するご案内
• JPCERT/CC：直近で相次いでいる国内組織における不正アクセスに関する注意喚起
• ＭＭ総研：国内サイバー攻撃による情報漏えい動向調査（2026年10月14日）
• 個人情報保護委員会：令和7年度年次報告
• 個人情報保護委員会：2026年10月の大規模漏えい等事案に関する注意喚起
• IPA：中小企業の情報セキュリティ対策ガイドライン
• 個人情報保護委員会：生成AIサービス利用に関する注意喚起
• NIST：認証方式に関する資料
• OWASP：Prompt Injection
• JPCERT/CC：侵入型ランサムウェア攻撃を受けたら読むFAQ
• 個人情報保護委員会：漏えい等の対応とお役立ち資料
• 個人情報保護委員会：個人情報保護法ガイドライン・通則編