2026年の情報流出ケースブック：国内企業9事案を時系列で、自社の点検に変える

原則として確認された発生期間を軸に並べます。侵入開始が不明な事案は検知日または公表日を位置の目安にし、表で区別しました。したがって、全事案の厳密な侵入開始順を示すものではありません。ムーンスターは3月の検知と、後に示された5月の漏えい可能性の高い期間を分けています。skyticketは3経路を1回の記事で扱います。

例えばマイナビの3月31日付第三報は、異常検知を2025年12月5日、情報流出の可能性の確認を2026年1月16日としています。そのため本連載の「2026年に発生した」と扱う本文ケースには入れていません。さくらインターネットの9月10日付第三報には、販売管理システムへの不正アクセスを2023年4月以降～2026年3月としている部分があります。複数年にまたがる事案を単一の2026年事件として数えないため、こちらも初回9事案からは分けました。マイナビ第三報、さくらインターネット第三報

年度途中の選定であり、1～2月に事件がなかったという意味ではありません。公開資料の具体性、規模、被害を減らすために得られる学びを基準に選びました。新しい事案の追加時にも、発生・検知・公表の日付を分けます。

各社の発表を足して「日本全体で何億人流出」と計算することもできません。同じ人が複数サービスを使い、ひとつの事案の続報でも集計方法が変わるためです。二次被害の未確認は、情報流出がなかったことの証明ではありません。

「どうしたら防げたか」は反省を押し付ける見出しではありません。外部の読者には当時の制約や全設定は見えません。企業が公表した対応と編集部の一般的な対策案を分け、対策があれば必ず防げたという結論にはしません。

• 開発担当：CAMPFIREとマネーフォワードを読み、秘密情報と個人情報がコードの外へどう複製されるかを確認する。
• EC・予約サービス担当：ショップサーブ、skyticket、ソースネクストを読み、管理権限、予約情報の認可、旧ログを確認する。
• 情シス・運用担当：メディカ出版とタイムズカーを読み、認証の例外、ログの欠落、保持し続ける画像を確認する。
• 情報共有・顧客窓口担当：Gyazoとムーンスターを読み、派生データの機密性と、問い合わせから被害を把握する経路を確認する。

本連載の指示文は、事案の特徴を自社点検へ変換するために編集部が作成した教材です。被害企業の非公開環境を検査した結果でも、プロンプトの有効性を実測した結果でもありません。LLMへ渡すのは社内規程で認められた資料だけとし、秘密や実際の顧客データを除きます。

• 根拠にした資料と該当箇所があるか。存在しない設定やCVEを作っていないか。
• 「未確認」と「問題なし」を区別しているか。
• 推奨変更の業務影響を担当者が把握しているか。
• 自社の検証環境と合成データで、拒否すべき操作が拒否されるか。
• 修正後も監視・保持期限・例外の管理が続くか。

事故を振り返るケースブックとは別に、脆弱性ウォッチ：影響判断から修正確認までを始めます。初回は判断の手順と、curlのHTTP/2アップロードに関する重大な脆弱性です。脆弱性があることと、それが実際の情報流出原因になったことは別の事実として扱います。

この記事と各ケースの確認日は2026年10月21日です。出典は各社の公式発表を中心に記載し、事実が変わる続報では元の数値・解釈を訂正できる構成にしています。公表済みの範囲を超える攻撃者の主張や、流出データの実物は根拠として使っていません。