はじめに
2026年11月2日、家電量販店のノジマは、ECサイト「ノジマオンライン」と中古スマホ買取サイトの会員管理システムが第三者による不正アクセスを受け、会員情報約700万件が外部に漏えいしたと発表しました。この秋は、公式アプリや会員サイトからの大規模な漏えいが続いています。
今回の発表で目を引くのは、「クレジットカード情報は保持していない」と明記されている点です。決済情報を自社で持たない仕組みにしていたため、カード情報は漏えいの対象になりませんでした。一方で、氏名や住所、生年月日といった情報は漏えいしています。
退会者のデータまで漏えいの対象になった事例は、アットコスメ不正アクセスの記事で取り上げました。今回はそこから視点を変えて、「そもそも会員DBに何を持つか」を発注側がどう決め、どう減らしていくかを、コンサルタントの視点で考えます。
何が起きたのか
ノジマの発表（2026年11月2日）と報道をもとに整理すると、概要は次のとおりです。
- 検知：2026年11月1日、「ノジマオンライン」の会員管理システムへの第三者からの不正アクセスを検知・確認した
- 漏えい：社内調査の結果、同じ11月1日に個人情報が外部に漏えいしたことを確認した
- 対象サイト：ノジマオンライン（EC専門サイト）と中古スマホ買取サイトの2つ
- 件数：約700万件。退会した人は含まれていないと説明している
- 項目：氏名（漢字・カナ）、生年月日、性別、郵便番号、住所、電話番号、ログインID、暗号化されたパスワード、メールアドレス
- カード情報：決済情報の非保持化に対応しており、2つのサイトではクレジットカード情報を保持していない
- 対応：外部からのアクセスの遮断と監視の強化、警察への相談、個人情報保護委員会などへの報告準備、2サイトの一時休止
- 今後：不正利用や二次被害の有無は調査中。サイトの再開時期は、安全性が確認でき次第知らせるとしている
侵入の経路や原因は、11月5日時点で確認できた範囲では公表されていません。今後、続報で内容が変わる可能性があるため、最新情報は同社の発表を確認してください。
なぜ会員DBには「必要以上のデータ」がたまるのか
今回カード情報が守られたのは、決済代行会社にカード情報を預け、自社では持たない仕組みにしていたからです。EC事業者には割賦販売法でカード情報の適切な管理が求められており、多くの事業者が「非保持化」を進めてきました。持っていないデータは、侵入されても漏れません。
ところが、カード以外の項目では、同じ発想がなかなか広がりません。背景には3つの事情があります。
1つ目は、「いつか使うかもしれない」で項目が増えることです。 会員登録の画面に生年月日や性別の欄があるのは、マーケティングで使えそうだからという理由が多いでしょう。しかし実際に施策で使われているかを確かめる場面は、ほとんどありません。
2つ目は、データの「持ち主」がはっきりしないことです。 会員DBはシステム部門が管理し、項目を増やしたいのは事業部門です。項目を減らす判断を誰がするのかが決まっていないため、一度入れた項目はそのまま残り続けます。
3つ目は、サイトごとに会員基盤を分けないことです。 今回はECサイトと買取サイトの2つが対象になりました。会員基盤を共通にすると、会員はIDを1つで使えて便利です。一方で、1回の侵入で複数のサービスの会員情報がまとめて危険にさらされます。
コンサルタントならこう考える：保持データを減らす4つの仕組み
ニュースでは「不審なメールに注意」という利用者向けの呼びかけが中心です。発注側として考えたいのは、事故が起きる前に「漏れて困るデータの量」そのものを減らしておくことです。
1. 項目ごとに「使い道」と「持ち主」を台帳にする
まず、会員DBの項目を一覧にし、項目ごとに「何の業務・施策で使っているか」「その項目の責任者（データオーナー）は誰か」を書き込みます。使い道が書けない項目は、削除の候補です。
ポイントは、項目を足すときも、残すときも、データオーナーの承認を通すことです。年に1回、台帳を見直す場を設け、「この1年で使わなかった項目」を洗い出します。システム部門だけで判断せず、事業部門に「使っていないなら消す」と決めてもらう流れにするのがコツです。
2. 保存期間と削除を「要件」として発注する
退会者や長く使われていない会員のデータを、いつまで持つのかを決めておきます。ここで大切なのは、ルールを決めるだけでなく、削除する機能をシステムの要件に入れることです。
会員サイトの開発や改修をベンダーに頼むとき、RFPや要件定義書に「退会から○日後に個人情報を削除する」「休眠会員は○年で削除または匿名化する」といった要件と、その確認方法を書きます。削除の仕組みは後回しにされやすく、要件にないと作られません。保守契約にも、削除が実際に動いているかの定期報告を入れておくと安心です。
3. カードで成功した「非保持化」を他の項目にも広げる
カード情報を決済代行会社に任せたのと同じ発想で、ほかの項目も「持たない」「粗くして持つ」方法を検討します。たとえば次のような考え方です。
- 年代別の案内しかしないなら、生年月日ではなく年代だけを持つ
- 地域別の施策なら、住所全体ではなく都道府県だけを分析用のデータに持つ
- 配送のために住所が必要でも、マーケティング用のデータベースには写さない
すべての項目を減らせるわけではありません。ECで商品を届けるには住所や電話番号が必要です。それでも、「業務に必要な場所にだけ置く」「分析用には粗くした写しを使う」だけで、1回の侵入で漏れる範囲は小さくなります。
4. 共通の会員基盤は「止め方」まで設計する
複数のサイトで会員基盤を共通にするなら、設計の段階で「どこかが侵入されたとき、何が一緒に止まるか」を確認しておきます。今回のように2サイトを同時に休止すると、そのサイト経由の販売と買取がどちらも止まります。
設計レビューでは、次の2点を確かめましょう。
- サービスごとに、会員基盤のどの項目を参照しているか（不要な項目まで見えていないか）
- 侵入を見つけたときに、どの単位でサイトを止められるか。再開するときに、誰が何を確認して判断するか
再開の判断基準を事前に決めておかないと、休止が長引き、事業への影響が大きくなります。「止める基準」と同じくらい「再開する基準」を先に決めておくことが、情シスやDX担当者の役割です。
明日からできる3つのこと
1. 自社の会員DBの項目を一覧にし、項目ごとに「使い道」と「データオーナー」を書く。書けない項目に印をつける
2. 退会者・休眠会員のデータの保存期間を確認し、削除の仕組みが実際に動いているかをベンダーに確かめる
3. 次に会員サイトを改修するときのRFPに、「保持項目の最小化」と「削除機能」を要件として入れる
まとめ
ノジマオンラインの事案では、約700万件の会員情報が漏えいしました。一方で、カード情報は「持っていなかった」ために漏えいしませんでした。侵入を完全に防ぐことは難しくても、漏れて困るデータを減らしておくことはできます。項目ごとの使い道と持ち主を決め、保存期間と削除を要件に入れ、持たなくてよいものは持たない。その積み重ねが、万が一のときの被害を小さくします。
参考
- 株式会社ノジマ「ノジマオンラインの不正アクセスに伴う個人情報漏えいに関するお詫びとお知らせ」（2026年11月2日）
- NHKニュース「ノジマ 不正アクセスで約700万件の個人情報漏えい」（2026年11月2日）
- 日本経済新聞「ノジマ、ECサイトなどに不正アクセス 顧客情報700万件流出」（2026年11月2日）
- ビジネス+IT「ノジマ、会員700万件の個人情報が漏えい 住所・電話番号も対象、自分は大丈夫か」（2026年11月2日）
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント