企業のセキュリティインシデントは増加の一途をたどっており、大企業から中小企業まで、様々な規模の企業が被害を受けています。ランサムウェア攻撃、情報漏洩、システム障害など、サイバー攻撃の手口は多様化し、高度化しています。
特に懸念されるのは、セキュリティ対策が進んでいると思われている大企業でも、甚大な被害を受けているという点です。これは、セキュリティ対策の有無だけではなく、その実装方法や運用体制に課題があることを示唆しています。
本記事では、2026年に実際に発生した6つのセキュリティインシデント事例を取り上げます。各事例から学べる教訓を紐解き、企業が今すぐ実施すべき対策と、セキュリティ強化の方針について詳しく見ていきましょう。
マネーフォワードのインシデント事例
マネーフォワードは、2026年5月にGitHubへの不正アクセスを受け、開発・システム管理に利用していたリポジトリ上の情報が外部に流出した可能性があることを公表しました。開発環境における機密情報の管理不備が、被害につながった事例です。
インシデント概要
2026年5月1日、マネーフォワードは、同社グループがソフトウェア開発およびシステム管理に利用していたGitHubへの不正アクセスを公表しました。第三者がリポジトリにアクセスし、ソースコードを含む情報をコピーした可能性があるとされています。本件は、GitHubの認証情報に関連する不正利用を起点として、リポジトリ内の情報が閲覧・複製された事案です。
流出した可能性のある情報には、マネーフォワードビジネスカード関連の一部情報や、顧客・従業員の個人データが含まれる可能性があるとされています。調査の進展により、対象となるデータ範囲について追加の確認が行われました。
根本的な問題点として、リポジトリ内に個人情報や認証情報に関わる情報が含まれていたことが挙げられます。開発・運用環境における情報管理の厳格化が求められる事例です。
重要な点として、本番データベースへの不正アクセスや、本番環境からの大規模な情報漏えいは確認されていないとされています。被害は主に開発・管理系の領域にとどまったと整理できます。
被害と企業への影響
事象発生後、マネーフォワードは安全性確認のため、銀行口座連携機能を一時的に停止しました。この対応は、利用者に一時的な不便を与えましたが、金融機関との安全確認を優先したものです。発表後は関連報道も相次ぎ、株価にも短期的な影響が見られました。
ユーザー側の反応としては、「なぜGitHub上に個人情報や認証情報が含まれていたのか」という運用面への疑問や、銀行連携停止による不便、今後の補償はどうなるのかといった不安が中心でした。
特に重要なのは、金融サービス事業者としての信頼性への影響です。開発環境の管理不備は、事業者の信用に直結し得るため、再発防止策の実効性が強く問われます。
ただし、顧客情報を格納する本番データベースへの不正侵入や、本番環境からの情報流出は確認されていないため、被害は限定的だったとも言えます。
学べる教訓
このインシデントから学べる最大の教訓は、ソースコードの管理環境（GitHub）が企業のセキュリティにおいて本番環境と同等に強固な守りを求められる時代になったということです。マネーフォワードのケースは、ハードコードされたシークレットとテストに紛れ込んだ本番データの組み合わせが、セキュリティを侵害するという典型例を示しています。
対策として、マネーフォワードは業務端末のセキュリティ統制強化、通信統制基盤の導入、開発環境における個人情報ハンドリングルールの厳格化、開発環境のリアルタイム監視を導入しました。シークレット・スキャニング機能や、テスト・データセット匿名化ポリシーの導入は、わずかな実装コストで同類のインシデントを高い確率で予防できます。
日経新聞のインシデント事例
日本経済新聞社は、2025年9月に社内で利用していたコラボレーションツールへの不正アクセス被害を公表しました。メディア企業としての信用や、取材・業務情報の管理体制が問われるインシデントでした。
インシデント概要
日本経済新聞社は、社員が業務で使用していた個人所有のパソコンがウイルスに感染し、社内ツールの認証情報が流出したことをきっかけに、社員アカウントへの不正ログインが発生したと説明しています。これにより、社員や取引先など計1万7368人分の個人情報やチャット履歴が漏えいした可能性があると公表されました。
本件は、単一の端末侵害が、社内で広く使われるコラボレーションツールの不正利用につながった事例です。流出した可能性のある情報には、Slackに登録されていた氏名、メールアドレス、チャット履歴などが含まれていました。
ただし、取材先や取材に関する情報の漏えいは確認されていないとされています。報道機関として特に重要な情報については、被害が及ばなかった点が示されています。
被害と企業への影響
日経は被害把握後、パスワード変更などの対策を実施しました。社内ツールのアカウント保護と、認証情報の管理強化が改めて課題となった事案です。
また、報道・著述目的の個人情報は、個人情報保護法上の一部の報告義務の対象外となる場合がありますが、日経は事案の重要性と透明性を踏まえ、個人情報保護委員会に任意で報告しました。この対応は、企業としての説明責任を重視したものといえます。
この事案は、多くの組織でコアシステムに比べてコラボレーションツールの監視が手薄になりやすいことを示しました。社員や取引先のメールアドレス、チャット履歴が漏えいすれば、迷惑メールや標的型攻撃に悪用されるリスクもあります。
さらに、社員の個人所有パソコンを起点とする侵害だった点から、エンドポイント管理の重要性も浮き彫りになりました。大手メディア企業であっても、端末と認証情報の管理が不十分であれば、社内全体のセキュリティに影響し得ることを示した事例です。
学べる教訓
このインシデントから学べる最大の教訓は、SaaSとBYOD（個人端末の業務使用）が前提となった現代のサイバー空間において、「端末」「SaaS・ID」「バックアップ／ログ」を三位一体で設計することの重要性です。
実際、Slack や Teams、Microsoft 365 などの SaaS から情報が漏れるインシデントでは、認証情報を窃取した後、情報窃取型マルウェア（インフォスティーラー）を仕込むケースが非常に多くなっています。企業は、エンドポイント保護の強化、多要素認証の導入、定期的な監視ログ分析などの多層防御を構築する必要があります。
メディア企業だけでなく、全ての組織が同様のリスクに直面していることを認識する必要があるでしょう。
PRTIMESのインシデント事例
PR TIMESは、2025年4月に管理者画面を含むサーバーへの不正アクセス被害を公表しました。多くの企業やメディアが利用するプラットフォームで発生した事案であり、SaaS事業者としての責任や、情報管理体制の重要性が問われました。
インシデント概要
PR TIMESは2025年5月7日、プレスリリース配信サービス「PR TIMES」において、2025年4月24日から第三者によるサーバー内部への不正アクセスとサイバー攻撃が行われていたことを公表しました。4月25日には、同サービスのサーバー上で不審なファイルが見つかり、調査の結果、個人情報や発表前のプレスリリース情報を中心とする保有情報が漏えいした可能性があると判断されました。
漏えいした可能性のある個人情報は最大90万1,603件に及び、企業ユーザー、メディアユーザー、個人ユーザー、インポートリストの情報が含まれていました。さらに、1,182社1,682件の発表予定日時が設定されていたプレスリリース発表前情報も流出した可能性があります。
被害と企業への影響
攻撃は複数段階で行われ、4月27日深夜から4月28日早朝にかけて、攻撃者が設置した不審なプロセスを通じた追加の攻撃も確認されました。調査ではバックドアの存在も確認されており、初期侵入後に攻撃が継続していた可能性があります。
PR TIMESは、上場企業の多くが利用する配信基盤であり、月間のプレスリリース配信件数も多いことから、本件の影響は利用企業だけでなく、報道機関や一般利用者にも及ぶ可能性がありました。
同社は対応として、不正侵入経路を遮断し、当該プロセスを停止させました。また、個人情報保護委員会や日本情報経済社会推進協会に速報を行い、警察にも被害申告を実施しています。
ただし、流出した可能性のある情報には、銀行口座番号やクレジットカード情報といった決済関連情報は含まれていなかったとされています。被害の種類としては、決済情報よりも、個人情報や公開前情報の漏えいリスクが中心でした。
学べる教訓
このインシデントから学べる最大の教訓は、リモートワーク環境の構築に伴い、IPアドレスの許可リストが拡大されていたが、追加の経緯が不明なIPアドレスが存在していたという、アクセス管理の厳格性の欠如です。セキュリティ対策と利便性のバランスを取ることは重要ですが、その過程で管理体制が曖昧になってはいけません。
特に注目すべきは、社内管理の共有アカウントが使用されていたという点です。認証の個別化が実施されていれば、不正アクセス者を特定・追跡しやすくなっていた可能性があります。
さらに重要な教訓は、SaaSプラットフォーム企業を導入する際、組織はセキュリティ部門だけでなく、事業部門もサイバーリスクを理解し、その事業リスクがどこまで許容できるかを判断する必要があるということです。プラットフォーム提供企業のセキュリティ対策を把握し、継続的に監視することが利用企業の責任でもあります。
アスクルのインシデント事例
アスクルは、2025年10月にランサムウェア攻撃による大規模なシステム障害を受けました。法人向け・個人向け通販や購買支援サービスに影響が及び、サプライチェーン全体のリスクを示す事案となりました。
インシデント概要
2025年10月19日、アスクル株式会社はランサムウェア攻撃によるシステム障害を確認し、法人向け通販「ASKUL」、個人向け通販「LOHACO」、購買支援サービス「ソロエルアリーナ」の受注・出荷業務を停止しました。侵入経路としては、業務委託先に付与していた管理者アカウントのIDとパスワードが不正に利用されたことが確認されています。攻撃により、物流システムと社内システムの一部が暗号化され、顧客のお問い合わせ情報や商品仕入れ先情報が流出した可能性があるとされました。
物流センターの複数システムが暗号化され、バックアップも影響を受けたため、一部システムの復旧には時間を要しました。復旧対応は、被害範囲の確認と段階的な再開を前提に進められました。
被害と企業への影響
今回の攻撃により、多数の企業、医療機関、学校などで備品調達に支障が出て、流通ネットワーク全体に混乱が広がりました。取引先や委託先のECサイトにも影響が及び、受注・出荷停止が連鎖するなど、サプライチェーン全体への波及が目立ちました。無印良品やロフトなど、他社のEC事業にも影響が及んだと報じられています。
アスクルは、復旧対応や物流配送基盤の維持に伴う費用、将来の損害に備えた引当金などを計上し、業績面でも大きな影響を受けました。物流システムの復旧には数か月を要し、段階的に「ソロエルアリーナ」「ASKUL」「LOHACO」の受注が再開されました。
さらに深刻だったのは、バックアップデータにも被害が及び、復旧にあたって新たな環境構築が必要になった点です。バックアップの堅牢性や、侵入後の横展開を前提にした対策の重要性が改めて浮き彫りになりました。
学べる教訓
このインシデントから学べる最大の教訓は、「境界の外」に潜む侵入口に対する警戒が不足していたということです。委託先や弱い認証が攻撃者の最も好む入口になる「境界外部化」リスクが露呈しました。
具体的には、業務委託先に自社システムへのアクセス権限を付与する際に考慮すべきポイントとして、そもそも自社のシステムにアクセス権限を付与する必要性があるのか、業務端末は自社が貸与するのか委託先が用意するのか、それぞれにおけるセキュリティポリシー、アクセス権限の棚卸周期などが重要です。
アスクルでは、攻撃後の対策として、自社・委託先を含むすべてのリモートアクセスに多要素認証を適用し、管理者権限の運用ルールを見直して権限管理を強化しました。 さらに重要な教訓は、ランサムウェア攻撃を想定したバックアップ環境の構築が不可欠であるということです。アスクルのケースでは、バックアップデータ自体が暗号化・削除されたため、復旧に極めて長期間を要しました。
フクヨシのインシデント事例
フクヨシは、2025年10月に海外グループ会社経由の不正アクセスを受け、個人情報漏えいが発生しました。本社だけでなくグループ全体でのセキュリティ統制の重要性を示す事例です。
インシデント概要
2025年10月、株式会社フクヨシの海外グループ会社のサーバーが第三者による不正アクセスを受けました。この不正アクセスを起点として、国内の個人情報を含むデータが漏えいしたことが判明しました。海外拠点を起点とした侵入であり、グループ企業間の接続を通じて社内ネットワークへ影響が及んだ事案です。
海外グループ会社が侵入経路となった点は、グローバルに事業を展開する企業におけるリスクを示しています。本社の対策が一定水準にあっても、グループ会社全体でセキュリティレベルが揃っていないと、そこが弱点になり得ます。
被害と企業への影響
フクヨシの不正アクセスでは、最大1万5,829名分の個人情報が漏えいしたとされています。この事案は、単なる個人情報流出にとどまらず、海外拠点を起点とするサプライチェーン上のリスクが現実化した点に特徴があります。
企業への影響としては、顧客や関係者の信頼低下がまず挙げられます。個人情報の流出は、被害者への通知や関係当局への報告など、法令対応も伴うため、対応負荷が大きくなります。
また、グループ全体のセキュリティ体制を見直す必要も生じます。海外拠点の監査、ネットワークの再設計、接続権限の整理など、運用面での再構築が求められます。
さらに、複数拠点にまたがるインシデントは復旧コストも高くなります。事業継続計画の見直しを含め、グループ横断での対策強化が必要になる事例です。
学べる教訓
フクヨシのインシデントから最も重要な教訓は、本社だけでなく、国内外の子会社や関連会社を含めたグループ全体のセキュリティガバナンスを強化する必要があるということです。
具体的には、各拠点のセキュリティレベルを可視化し、統一されたポリシーを適用することが重要です。海外拠点は、言語、法制度、運用文化の違いから、セキュリティ対策が後手に回りやすい傾向があります。しかし、その「弱い部分」こそが攻撃者に最初に狙われるポイントになります。
さらに重要な教訓として、グループ内でのインシデント発生時の情報共有・連携体制を構築しておく必要があります。海外拠点で異常が検知された際に、本社が即座に対応できるよう、24時間体制での監視、報告ルール、初動対応の流れを事前に定めておくことは、被害を最小化する上で不可欠です。
すかいらーくのインシデント事例
すかいらーくは、2025年5月に公式テイクアウトサイトが不正アクセスを受け、クレジットカード情報が漏えいした可能性がある事案を公表しました。初期対応の遅れも含め、ECサイトにおける脆弱性管理とインシデント対応の重要性が問われた事例です。
インシデント概要
2025年5月3日ごろから5月7日にかけて、株式会社すかいらーくホールディングスが運営するテイクアウトサイトに対して、第三者による不正アクセスが発生しました。
当初はシステム障害として対応されましたが、その後の調査で不正アクセスの可能性が判明し、専門調査会社による調査が行われました。
攻撃者は、システムの一部に存在していた脆弱性を悪用して侵入したとされています。不正アクセスは、5月3日と5月4日以降の複数の期間にわたって行われたことが確認されています。
被害と企業への影響
2025年7月30日、すかいらーくホールディングスは最終調査結果を公表し、2025年4月30日から5月7日までの間にテイクアウトサイトで新規にクレジットカードを登録した利用者2,270名分のカード情報が漏えいした可能性があると明らかにしました。漏えいの可能性がある情報には、氏名、性別、生年月日、電話番号、メールアドレス、クレジットカード番号、有効期限、セキュリティコードなどが含まれていました。
影響としては、まずクレジットカード情報が外部に持ち出された可能性があるため、不正利用リスクへの継続的な対応が必要になりました。すかいらーくはカード会社と連携し、監視や対応を進めています。
また、テイクアウトサイトは一時的に停止され、サービス再開まで時間を要しました。利用者の利便性が損なわれたほか、復旧と安全確認のための追加対応も必要になりました。
さらに、障害発生後の初期判断や報告のタイミングが課題として残りました。原因が不明な段階では、不正アクセスの可能性を前提に慎重に対応する必要があることが示された事例です。
学べる教訓
すかいらーくのインシデントから最も重要な教訓は、初期対応における判断の速さと正確性の重要性です。
5月3日の段階でサービス障害が検知された際に、当初はプログラム不良と判断されました。これが致命的な判断ミスでした。障害の原因が不明な段階では、プログラム不良か不正アクセスかを即座に判別することは困難ですが、その後の対応に大きな影響を与えます。
実際のインシデント対応フローとしては、原因が明確でない段階では、不正アクセスの可能性を想定した慎重な対応が求められます。単にサイトを再開するのではなく、複数の重要なステップが不可欠です。
まず、初期対応の標準化として、サイト再開前に外部セキュリティ専門家による緊急調査を実施し、不正アクセスの有無を確認すべきでした。次に、システムの一部の脆弱性を悪用した不正アクセスが原因でした。既知の脆弱性に対する定期的なパッチ適用と脆弱性診断の実施が重要です。
さらに、最終調査完了から報告までに2.5ヶ月を要したことは、被害者への対応遅延につながります。初期報告（24時間以内）、暫定報告（72時間以内）、最終報告（30日以内）というタイムラインを設定し、ステークホルダーへの迅速な情報提供を徹底することが、信用回復の第一歩となります。
6つのインシデント事例から学べる共通の教訓
前述の6つのセキュリティインシデント事例（マネーフォワード、日経新聞、PRTIMES、アスクル、フクヨシ、すかいらーく）を分析すると、単なる個別の対応で終わらない、組織全体のセキュリティ戦略の再構築が急務であることが見えてきます。
ここでは、これらの事例から導かれる共通の課題、企業規模別の対策の違い、および今後求められるセキュリティ戦略について考察します。
セキュリティ対策における共通の課題
6つの事例を通しての共通の課題は「認証情報の漏洩と悪用」です。GitHub認証情報、Slack認証情報、管理者アカウント、委託先アカウントなど、いずれも認証情報窃取が侵入経路となっています。
特に注目すべきは、多要素認証（MFA）が「例外的に適用されていない」「未導入」というケースが複数見られることです。ポリシーが存在していても、委託先や海外拠点で形骸化しているパターンが目立ちます。
また、アスクルではバックアップ自体が暗号化・削除され、すかいらーくでは初期対応での判断誤りが被害を拡大させました。さらに、アスクル・フクヨシ・日経新聞すべてが「委託先」「グループ会社」「私物PC」といった直接管理外からの侵入を許しており、サプライチェーン経由の脆弱性が最も危険であることが浮き彫りになっています。
企業規模別に見える対策の違い
大規模企業（マネーフォワード、アスクル、フクヨシ）は復旧能力と情報開示では優れていますが、グループ全体での統一的なセキュリティガバナンスが欠落しています。フクヨシは海外拠点のセキュリティレベルが低く、アスクルは委託先での例外的なMFA未適用がありました。
メディア企業（日経新聞、PRTIMES）は顧客情報や取材情報の流出が経営に直結し、テレワーク環境下でのエンドポイント管理が課題です。
小～中規模ECサイト（すかいらーく）は脆弱性診断が後回しになりがちで、インシデント対応の専門チームを持たないため、初期判断誤りが起きやすい傾向があります。
共通する課題は、規模を問わず、セキュリティ投資が後手対応になっていることです。短期的な事業成果を優先し、セキュリティをコストと見なす傾向が強いことが見えてきます。
今後の企業に求められるセキュリティ戦略
今後の企業のセキュリティ戦略は、技術的対策と組織的ガバナンスの両輪で進める必要があります。
まず重要なのは、ポリシー策定から実行・監査までの一貫したセキュリティガバナンスを構築することです。グループ企業・委託先に同一水準を強制し、定期的に監査する仕組みが必須となります。
次に、3-2-1ルール（3つのコピー、2つのメディア、1つはオフサイト）に基づくバックアップ戦略を再構築し、ランサムウェア対策としてイミュータブルバックアップの導入を検討すべきでしょう。
加えて、VPN接続であってもすべてのアクセスにMFAを適用するゼロトラスト戦略への移行も急務です。併せて、常設CSIRT（Computer Security Incident Response Team）による迅速な初期対応体制を構築することで、インシデント検知から対応まで的確に対処できる組織体制を整備する必要があります。
まとめ｜インシデント事例を教訓に自社のセキュリティを強化しよう
セキュリティインシデントは、大企業だけでなく、あらゆる企業に起こり得る経営リスクです。今回紹介した6つの事例では、認証情報の管理不足や委託先・グループ会社の脆弱性、初動対応の遅れなど、一見小さな課題が重大な被害へと発展していました。
重要なのは、インシデントが発生してから対策を講じるのではなく、日頃から多要素認証（MFA）の導入やアクセス権限の見直し、バックアップ体制の強化、委託先を含めたセキュリティガバナンスの整備など、予防を前提とした取り組みを進めることです。また、万が一被害を受けた場合でも、迅速に状況を把握し、適切な情報開示と復旧対応を行える体制を整えておくことが、被害の最小化と企業の信頼維持につながります。
サイバー攻撃の手口は今後も高度化・巧妙化していくと考えられます。今回の事例を自社には関係ないと考えるのではなく、自社のセキュリティ対策を見直すきっかけとして活用し、継続的な改善を進めていくことが重要です。
