2026年9月から10月にかけて、国内では情報漏洩・不正アクセスの公表が記録的なペースで続いています。民間の調査会社によれば、2026年1〜9月に初報が公表された情報漏洩事案はすでに454件に上り、10月13日時点の通算では485件と、2025年の年間件数をすでに上回ったと報じられています。
ブックオフ（最大643万件）、スカイチケット（約1464万件）、第一興商（約872万件）、ミスターマックス（約173万件）、ディップ「バイトル」（最大388万件）、コミューン基盤経由でのヤマハ・スズキ・パナソニック等への波及、IDCFクラウドのランサムウェア攻撃によるJR各社への波及――。個別のニュースとして見ると別々の事件ですが、横断して見ると、企業が見直すべき共通の論点がいくつも浮かび上がります。
この記事では、直近の情報漏洩ラッシュから見えてきた、企業が今すぐ見直すべき7つのセキュリティ対策を整理します。
① 委託先・外部基盤の管理――「自社は攻撃されていない」は安心材料にならない
IDCFクラウドへのランサムウェア攻撃は、JR東日本・JR九州・JR東海など、直接の契約者ではない大手企業にまで情報漏洩の可能性を波及させました。コミューン基盤への不正アクセスも、ヤマハ・スズキ・ヤマハ発動機・パナソニック・LINEヤフー・Sansanなど、名の知れた複数企業を巻き込んでいます。第一興商の事案も、委託先のそのまた委託先の端末感染が発端でした。
詳しい構造分析は、こちらのコラムで整理しています。
→ 一つの侵入が何十社にも波及する――サプライチェーン経由の情報漏洩が急増する理由
見直すポイント：自社がどの外部SaaS・クラウド基盤・委託先に顧客情報やコミュニティー運営を委託しているかを棚卸しし、再委託の有無まで確認する。委託先・基盤側で事故が起きた場合の連絡体制もあらかじめ整えておく。
② 退職者アカウントとパスワードの使い回し――基本中の基本が今も最大の弱点
デンマークの中央個人登録簿から約880万人分の個人情報が流出した事案では、侵入の足掛かりになったのは、照会サービスを提供する小規模IT企業の管理者アカウントに使われていたパスワード「123456」でした。元従業員から漏えいした認証情報が使われたとみられています。カインドオル（トレジャー・ファクトリーグループ）の事案でも、二段階認証が設定されていないスタッフアカウントがフィッシングの標的になりました。
見直すポイント：退職者・休眠アカウントを速やかに無効化する。管理者アカウントを含む重要アカウントには多要素認証を必須化し、単純なパスワードや使い回しを排除する。
③ バックエンドAPIの認可設計――「アプリは問題ない」で終わらせない
NICTは2026年10月13日、公開されているスマートフォンアプリを解析してバックエンドサーバを狙う「A2B攻撃（App-to-Backend Attack）」を特定し、注意喚起を公表しました。アプリ自体に脆弱性がなくても、裏側のサーバのアクセス権限確認や入力検証に不備があれば、情報漏洩につながり得るという指摘です。
→ NICTが命名した「A2B攻撃」とは何か――相次ぐ情報漏洩の「共通の入り口」を読み解く
見直すポイント：自社アプリが利用するAPIについて、IDOR／BOLA（アクセス権限不備）、SSRF、RCE、SQLインジェクションを重点的に点検する。アプリの画面テストだけでなく、裏側のサーバ設計まで含めて診断する。
④ 外部委託ツール・SaaSの脆弱性管理――「自社開発ではない部分」こそ盲点
キャッシュレスサービス「IDARE」の事案では、自社開発のシステムではなく、カスタマーサポート業務に使っていた外部ソフトウェアの脆弱性が悪用され、約13万人分の情報が漏洩しました。自社が開発・管理していないツールだからといって、点検対象から外してよいわけではありません。
見直すポイント：自社で導入している外部ソフトウェア・SaaSの一覧を作成し、ベンダーのセキュリティアップデート適用状況を定期的に確認する体制を持つ。
⑤ バックアップの隔離――ランサムウェアは「復旧手段」まで狙う
IDCFクラウドの事案では、影響を受けた契約者の約7割でバックアップデータごと暗号化・消去されており、通常の復旧手順が機能しない事態となりました。ランサムウェア攻撃は、本番データだけでなく復旧の生命線であるバックアップそのものを標的にするケースが増えています。
→ ランサムウェアが狙う「バックアップ破壊」 復旧経路を守るために見直すべき点
見直すポイント：バックアップを本番環境・同一認証情報から論理的・物理的に分離する（オフライン化、イミュータブル化）。定期的に実際の復元テストを行う。
⑥ フィッシング耐性のある認証――「見た目で信じない」仕組み化
日本エネルギー経済研究所（フィッシングでM365アカウント侵害、パスポート情報13件確定）、小田原エンジニアリング（なりすましメールで取引先に金銭被害）、カインドオルなど、フィッシングを起点とした事案が繰り返し発生しています。メールの見た目が自然であればあるほど、人間の注意力だけでは見抜けません。
見直すポイント：「メールのリンクから重要サービスへログインしない」を全社ルール化する。入金・送金指示は、メール以外の経路（電話等）で必ず再確認する運用を徹底する。
⑦ AIによる攻撃の高速化を前提にした監視体制
韓国の金融機関を狙った一連の攻撃では、自律型の侵入テストツールとAIエージェントが組み合わされた痕跡が確認され、被害は16社・約10万件にまで拡大しました。国内の不正アクセス急増についても、識者から「AIエージェントによる自動化が背景にあるのではないか」との指摘が出ています。
→ 攻撃にも防御にも偽情報にも――AIが顔を出し始めたセキュリティの現場
見直すポイント：短時間での大量アクセス・大量照会を検知できる監視体制を整える。攻撃の自動化によって「スピードで押し切られる」ことを前提に、検知から遮断までの時間を短縮する。
よくある質問
Q. なぜ2026年秋に情報漏洩の公表がこれほど増えているのですか？
単一の原因ではなく、複数の要因が重なっていると考えられます。クラウド・SaaS化による攻撃対象の集約（1つの基盤侵害が多数の企業に波及）、AIを用いた攻撃の自動化・高速化、そして公開アプリの解析からバックエンドを狙う新手法（A2B攻撃）の広がりなどが指摘されています。
Q. 中小企業でもすぐに着手できる対策はありますか？
優先度が高いのは、退職者・休眠アカウントの無効化と、重要アカウントへの多要素認証の設定です。費用をかけずに着手でき、デンマークの事案のような「単純なパスワードの放置」を防ぐ効果があります。あわせて、委託先・利用中の外部サービスの棚卸しも、資料を集めるだけであれば自社内で始められます。
Q. 自社が直接攻撃されていなくても、対応が必要になることはありますか？
あります。IDCFクラウドやコミューンの事案が示すように、自社が利用している外部基盤・SaaSが攻撃を受けた場合、自社が直接の被害者でなくても、顧客への説明や対応が必要になります。委託先・利用サービスが事故を起こした場合の対応フローを、平時から決めておくことが重要です。
まとめ：チェックリスト
- 委託先・利用中の外部SaaS／クラウド基盤を棚卸しし、再委託の有無まで確認したか
- 退職者・休眠アカウントを無効化し、重要アカウントに多要素認証を設定したか
- 自社アプリのバックエンドAPIについて、アクセス権限不備（IDOR／BOLA）を点検したか
- 自社で使う外部ソフトウェア・SaaSのアップデート状況を定期確認しているか
- バックアップを本番環境から分離し、実際に復元できることを確認したか
- 「メールのリンクからログインしない」「入金指示は別経路で確認」を全社ルール化したか
- 短時間での大量アクセス・大量照会を検知できる監視体制があるか
情報漏洩のニュースが相次ぐと、「自社は大丈夫か」という不安が先に立ちがちです。しかし本当に重要なのは、個別のニュースに一喜一憂することではなく、ここに挙げた7つの論点のうち、自社がまだ手を付けていないものから一つずつ着手することです。