政府は2026年10月8日、全国の企業で不正アクセスによる個人情報漏えいが相次いでいることを受け、関係省庁会議を同日午後に開くと発表したと共同通信が報じました。
古川俊治サイバー安全保障担当相、国家サイバー統括室(NCO)の飯田陽一内閣サイバー官、経済産業省や総務省などの担当者が出席し、今後の対応方針を協議するとされています。
国内では9月末以降、タイムズカー、佐川急便、焼肉きんぐ、MrMax、大和証券の委託先、大阪公立大学などで大規模な不正アクセスやランサムウェア被害が相次ぎ、10月7日にはIDCフロンティアの「IDCFクラウド」がランサムウェア攻撃を受け、495の企業・自治体へ影響が広がりました。
一方、古川大臣は10月6日の記者会見で、国民に対して「パスワードの使い回しをやめる」「多要素認証を利用する」「不審なメールやSMSに注意する」という3点を要請し、「自分の情報は自分で守る」と呼び掛けました。
個人側の対策が二次被害を減らすうえで有効なのは間違いありません。しかし、直近で相次いでいる大規模事案の多くは、利用者のパスワード使い回しを起点にしたものとは確認されていません。
クラウド基盤へのランサムウェア攻撃、Webシステムへの侵入、ソフトウェア機能の不正利用、既知脆弱性、APIへの攻撃、委託先システムの侵害などが問題になっている中で、「自分の情報は自分で守る」を前面に出すだけでは、被害原因と対策の主体を取り違えるおそれがあります。
政府の関係省庁会議と直近のインシデントのサマリー
- 政府は10月8日午後、不正アクセスと情報漏えいの多発を受け関係省庁会議を開催予定
- 古川俊治サイバー安全保障担当相、NCO、経産省、総務省などが参加すると報じられている
- 10月6日の古川大臣会見では、パスワード使い回し防止、多要素認証、フィッシング対策を国民へ要請
- 古川大臣は「自分の情報は自分で守る」と呼び掛けた
- 同会見では企業側にも基本的な安全対策を求め、NCOを中心に関係省庁・被害企業と連携する方針にも言及
- IDCFクラウドはランサムウェア攻撃を受け、495の企業・自治体に影響
- 焼肉きんぐ公式アプリでは1,078万8,963件の会員情報漏えいを確認
- タイムズカーでは約660万アカウントの情報取得、約160万アカウントで本人確認書類の漏えいを確認
- MrMaxでは最大173万5,154人の会員情報が流出
- 大和証券では委託先への不正アクセスにより約11万人の顧客情報が漏えいした可能性
- 大阪公立大学ではランサムウェア攻撃で約500台のサーバーが停止し、バックアップの多くも暗号化
- JPCERT/CCは10月8日、既知脆弱性の探索、APIへの不正操作、Metabase脆弱性悪用など複数の攻撃類型を注意喚起
- 個人情報保護委員会も10月7日、大規模漏えいを受け事業者側の安全管理措置の点検を求めた
政府、10月8日午後に関係省庁会議
共同通信によると、政府は10月8日、不正アクセスによる個人情報漏えいが全国で相次いでいることを受け、同日午後に関係省庁会議を開催します。
出席者として、
- 古川俊治サイバー安全保障担当相
- 国家サイバー統括室(NCO)の飯田陽一内閣サイバー官
- 経済産業省
- 総務省
などが挙げられています。
10月8日13時台までに、会議結果や具体的な追加対策を示す政府の公式資料は確認されていません。
政府が今後どこまで事業者側の技術対策、委託先管理、脆弱性対応、クラウド障害へのBCPまで踏み込むかが焦点になります。
古川大臣「自分の情報は自分で守る」
古川大臣は10月6日の記者会見で、企業や行政機関を狙った不正アクセスが相次ぎ、大量の個人情報が流出しているとして、国民へ次の3つの対策を呼び掛けました。
- パスワードの使い回しをやめる
- 多要素認証を利用する
- 不審なメールやSMSのリンクを開かない
会見では、情報漏えい後のなりすまし、不正送金、詐欺などの二次被害を防ぐための対策として説明しています。
古川大臣はその上で、
「自分の情報は自分で守る」
という意識を持つよう求めました。
この発言に対してはSNS上で、企業への不正アクセスで流出した情報についてまで利用者側へ責任を負わせるように聞こえるとの批判が出ています。
以下に記載している直近事案の原因を見ると、利用者がパスワードを変えていても防げなかった可能性が高い事案が多数あります。
タイムズカー―約660万アカウント、本人確認書類まで漏えい
タイムズカーでは、Webシステムへの不正アクセスによって約660万アカウントの情報が第三者に取得されました。
さらに約160万アカウントでは、
- 運転免許証画像
- 現住所確認書類
- 学生証
- 家族確認書類
などの本人確認書類も漏えいしています。
タイムズカーへの不正アクセスで問題になっているのは、サービス側に保存された個人情報や本人確認書類です。
利用者が異なるパスワードを設定していたとしても、事業者側システムに保存された免許証画像の流出を利用者自身が防ぐことはできません。
大和証券―攻撃されたのは委託先「i-ask」
大和証券は10月5日、問い合わせ管理などに利用していたスカラコミュニケーションズのサーバーが不正アクセスを受け、約11万人の顧客情報が漏えいした可能性があると公表しました。
大和証券本体のシステムではなく、外部委託先のFAQ・問い合わせシステム「i-ask」が侵害された事案です。
約11万人について、
- 氏名
- メールアドレス
- 口座番号
- 問い合わせ関連情報
などが影響を受けた可能性があります。
利用者が証券口座でMFAを利用していたとしても、委託先に保存された問い合わせデータの漏えいを防げるわけではありません。
詳細は大和証券、委託先への不正アクセスで約11万人に影響と、スカラコミュニケーションズ「i-ask」への不正アクセスで整理しています。
佐川急便―荷物の送り主・届け先は自分で情報を預けていない場合もある
佐川急便では「お荷物問い合わせサービス」への不正アクセスにより、9月30日から遡る約100日分の荷物について、
- 送り主
- 届け先
- 氏名
- 住所
- 電話番号
などが外部へ流出した可能性があります。
「スマートクラブ」の会員でなくても、誰かから荷物を送られたことで届け先情報が佐川急便のシステムに保存されていた可能性があります。
このようなデータは、本人がパスワードを強化するだけでは守れません。
佐川急便「お荷物問い合わせサービス」への不正アクセスでは、会員サービス利用者以外にも影響が及ぶ構造を整理しています。
JPCERT/CCが示した原因は「利用者のパスワード」だけではない
10月8日、JPCERT/CCも「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」を公表しました。
JPCERT/CCが実際に報告を受けている攻撃手法には、
- 複数製品の既知脆弱性を探索・悪用
- 環境設定ファイルやバックアップファイルの窃取
- スマートフォンアプリを解析してAPIエンドポイントやキーを特定
- 内部APIによるユーザー権限変更
- 不正アカウント作成
- 不正な認証トークンへの応答確認
- NoSQLインジェクション
- 別システムから窃取したAPIキーの悪用
- MetabaseのSQLインジェクション脆弱性CVE-2026-72898の悪用
などがあります。
これらは企業・サービス運営者側が、
- パッチを適用する
- APIごとに認可を実装する
- レート制限を設ける
- 不要な管理機能をインターネットへ公開しない
- APIトークンを最小権限にする
- 不要なデータを削除する
ことで対処すべき領域です。
詳細はJPCERT/CCが公表した国内不正アクセスの攻撃手法で整理しています。
個人情報保護委員会も事業者側へ点検を要求
個人情報保護委員会も10月7日、大規模な個人データ漏えい事案が相次いでいるとして注意喚起を公表しました。
同委員会が求めているのは、個人に対するパスワード変更だけではありません。
個人情報を保有する事業者に対して、安全管理措置や不正アクセス対策の点検を求めています。
10月7日の個人情報保護委員会、10月8日のJPCERT/CC、そして政府の関係省庁会議という流れを見ると、問題の中心は企業・組織側のシステム防御、脆弱性管理、データ管理、委託先管理にもあります。
個人対策は「侵入防止」ではなく「二次被害軽減」と整理すべき
パスワードの使い回しをやめること、多要素認証を使うこと、不審なメールを開かないことは、どれも有効な対策です。
ただし、今回のような企業システムへの侵入が相次ぐ局面では、その役割を正確に説明する必要があります。
個人側の対策で減らせるのは主に、
- 漏えいした認証情報を別サービスで悪用される
- 漏えい情報を使ったフィッシングにだまされる
- アカウントを乗っ取られる
- なりすまし詐欺の二次被害を受ける
といったリスクです。
一方、
- 企業のWebサーバーに脆弱性がある
- APIの認可が不十分
- クラウド基盤がランサムウェア攻撃を受ける
- 委託先が侵害される
- 退会済み利用者のデータを必要以上に保持している
- バックアップが本番と同一障害領域にある
といった問題を、利用者がパスワードを変更して解決することはできません。
「利用者が注意してください」で終わらせない対策が必要
政府が今後の対策を示すのであれば、国民への注意喚起と同時に、サービス提供事業者へ何を求めるのかを具体化する必要があります。
例えば、
- MFAを利用者の任意設定ではなく標準化・デフォルト化する
- パスキーなどフィッシング耐性の高い認証方式を普及させる
- Web・APIの脆弱性管理を継続する
- 管理APIをインターネットへ直接公開しない
- 大量データ取得や異常なAPI操作を検知する
- 退会者を含む不要な個人情報を削除する
- 委託先・再委託先までセキュリティ管理を確認する
- SaaSやクラウドの基盤依存を把握する
- 本番とは異なる障害領域へバックアップする
- 漏えい後に利用者へ迅速・具体的に通知する
といった対策です。
利用者へ「MFAを設定してください」と求めるのであれば、企業側には「MFAを提供し、容易に有効化できる設計にする」責任があります。
パスワードを使い回さないよう求めるのであれば、事業者側もパスワードだけに依存しない認証設計、異常ログイン検知、レート制限、リスクベース認証などを実装する必要があります。
「自分の情報は自分で守る」には限界がある
利用者が自分で管理できる情報は限定されています。
一度企業へ提供した、
- 住所
- 電話番号
- 運転免許証画像
- 問い合わせ履歴
- 過去の契約情報
- 荷物の届け先情報
を、利用者自身が企業のデータベースから守ることはできません。
どのクラウドへ保存するか、何年間保管するか、どの委託先へ渡すか、どのAPIからアクセス可能にするかを決めるのはサービス提供側です。
「自分の情報は自分で守る」というメッセージは、フィッシングやパスワード再利用への注意としては正しい一方、企業側で発生した大規模漏えいへの説明として使用すると、責任の所在を曖昧にします。
個人が注意することと、企業・政府が安全なサービス基盤を作ることは、どちらか一方を選ぶ話ではありません。
今回の関係省庁会議では、国民への自己防衛要請だけでなく、直近のインシデントで繰り返されているWeb、API、脆弱性、クラウド、委託先、データ保持の問題に対し、事業者側へどのような具体策を求めるのかが問われます。








