So-net 258万件の個人情報漏えいから考える｜退会者データと「預けた顧客情報」を発注側はどう管理するか

はじめに
何が起きたのか
なぜこうした漏えいは起きるのか
発注側が自社で整えておきたい仕組み
まとめ
参考

はじめに

ソニーネットワークコミュニケーションズは2026年10月27日、インターネット接続サービス「So-net」の会員データベースが不正アクセスを受け、合計約258万件の個人情報が漏えいしたと発表しました。漏えいした中には、すでに退会した元会員の情報や、NTTドコモの「ドコモ光」で提供されているプロバイダーサービスの利用者情報も含まれています。

原因は調査中とされており、侵入経路はまだ分かっていません。それでも、この事案には発注側の担当者が自社に持ち帰って考えるべき論点がいくつもあります。「退会した人のデータを、いつまで持っているのか」「他社に預けた顧客情報は、どこにあり、どう守られているのか」です。

この記事では、事案の概要を整理したうえで、こうした漏えいが組織で起きやすい理由と、発注側を支援するコンサルタントとして自社で整えておきたい仕組みを考えます。

何が起きたのか

ソニーネットワークコミュニケーションズの公式発表（2026年10月27日）をもとに整理すると、経緯は次のとおりです。

10月19日：So-net会員データベースに外部から不正アクセスを受ける
10月23日：不正アクセスを確認し、対象サーバーを停止して攻撃元からの通信を遮断
10月24日：調査の結果、個人情報の漏えいを確認し、項目と件数を把握
10月27日：漏えいが確認されたメールアドレスのパスワードを初期化し、公表

漏えいした情報の内訳は、おおむね次のとおりです。

So-net会員情報：約214万件（現会員約187万件、2026年3月以降に退会した元会員約27万件）
plala（Sコース）会員情報：約44万件（現会員・元会員の合計）
項目：氏名、電話番号、メールアドレス、ユーザーID、生年月日、性別、インターネット接続用ID
一部のメールサービスのメールアドレスとそのパスワード：約5万4千件
銀行口座情報：16件、パスワード再設定用の通知書情報：7件

会員情報のパスワードやクレジットカード情報の漏えいはないとされています。また、2026年2月末までに退会した人の情報は漏えいしていないと説明されています。

plala（Sコース）は、TBS NEWS DIGの報道によれば、NTTドコモの委託を受けて提供されているサービスです。つまりドコモから見れば、自社サービスの利用者情報が、委託先のシステムから漏えいしたことになります。

なぜこうした漏えいは起きるのか

侵入経路が分かっていない以上、今回の原因を推測で語ることは避けます。ここでは一般論として、大規模な漏えいにつながりやすい組織側の事情を整理します。

一つ目は、データが「たまる」方向にしか動かないことです。システムには登録や更新の機能は丁寧に作られますが、「消す」機能は後回しになりがちです。退会処理をしても、データベース上は「退会済み」のフラグが立つだけ、という設計は珍しくありません。保持期限のルールがあっても、実際に削除するバッチが作られていなければ、データは残り続けます。

二つ目は、一つのデータベースに多くの情報が集まることです。会員情報、メールサービスの情報、決済情報が、運用の都合で近い場所に置かれていると、一か所への侵入で被害が一気に広がります。

三つ目は、委託の連鎖で「誰が守るのか」がぼやけることです。サービスの提供を他社に任せると、発注側は「専門の会社に任せているから大丈夫」と考え、委託先は「契約の範囲で対応している」と考える。その間にある、データの持ち方や監視の水準といった論点が、どちらからも確認されないまま残ってしまいます。

四つ目は、検知まで時間がかかることです。今回は不正アクセスから確認まで4日でした。この期間が長いか短いかはここでは評価しませんが、一般に、異常な大量アクセスに気づく仕組みがなければ、発覚は利用者からの問い合わせや外部からの指摘を待つことになります。

発注側が自社で整えておきたい仕組み

ここからは、事業会社の情シスやDX担当として、自社や委託先で同じことを起こさないために何を整えるべきかを、コンサルタントの視点で整理します。

1. 「持たないデータは漏れない」を設計のルールにする

最も確実な対策は、そもそも不要なデータを持たないことです。今回、2月末までに退会した人の情報は漏えいしなかったと説明されています。保持の期間や仕組みの詳細は公表されていませんが、データを持ち続けている範囲が、そのまま漏えいしうる範囲になることはよく分かります。

自社で取り組むなら、次の順番がおすすめです。

保持期限を決める：法令や会計・問い合わせ対応の必要性から、「退会後○か月」「最終利用から○年」といった期限を、データの種類ごとに決める
削除を機能として作る：期限を過ぎたデータを消す（または個人を特定できない形に加工する）処理を、システムの要件として明記する
削除の実行を確認する：月次や四半期で削除件数を報告させ、実際に消えていることを確かめる

ポイントは、削除を「運用でやるもの」ではなく「要件として作るもの」にすることです。要件定義書に書かれていない機能は、まず作られません。新規開発や刷新の際には、発注側から削除要件を明示的に出すことが大切です。

2. 委託先に預けたデータの「所在台帳」を作る

今回のように、自社の顧客情報が委託先のシステムで漏えいするケースは珍しくありません。発注側として最低限やっておきたいのが、どの委託先に、どの顧客情報を、何件くらい預けているかを一覧にした台帳を作ることです。

委託先名とサービス名
預けている情報の項目（氏名、連絡先、口座情報など）と概算件数
保管場所（委託先の自社基盤か、さらに別のクラウドか）
退会・解約時にデータが消えるタイミング

この台帳があれば、委託先で事故が起きたときに、自社の顧客がどれだけ影響を受けるかをすぐに見積もれます。逆に台帳がないと、委託先からの報告を待つしかなく、自社の顧客への説明が遅れます。

3. 契約で「データの持ち方」と「事故時の約束」を決める

委託契約や利用規約の確認では、価格や機能だけでなく、次の点を押さえておきたいところです。

保持と削除：契約終了時や利用者の退会時に、データをいつまでに削除するか。削除したことを証明してもらえるか
保護の水準：パスワードなどの認証情報をどのように保管しているか。重要な情報を他の情報と分けて管理しているか
事故時の報告：不正アクセスに気づいてから何時間以内に発注側へ連絡するか。影響範囲の調査結果をどこまで共有するか
監査と報告：年に一度、セキュリティ対策の状況を報告してもらえるか。必要に応じて確認に入れるか

大手の事業者が相手だと、個別の条件交渉は難しいこともあります。それでも、質問して回答を記録に残すことには意味があります。回答があいまいな項目は、自社側のリスクとして経営層に報告し、受け入れるかどうかを判断してもらう材料になります。

4. 「気づく仕組み」を要件に入れる

大量の個人情報が外に持ち出されるとき、多くの場合、データベースへのアクセスやネットワークの通信量に普段と違う動きが出ます。こうした異常に気づくには、ログを取るだけでなく、誰かが見て、異常なときに通知が飛ぶ状態にしておく必要があります。

発注側としては、システムの構築や保守を委託する際に、次のような項目を要件や契約に入れておくとよいでしょう。

個人情報を扱うデータベースへのアクセスログを、一定期間保存すること
大量の検索や出力など、普段と違う操作を検知して通知すること
検知から発注側への報告までの時間の目安

監視には費用がかかるため、予算の段階で削られやすい項目です。だからこそ、「検知が遅れた場合に何が起きるか」を、今回のような事例を引き合いに出して説明し、予算を確保しておくことが大切です。

5. 漏えい時の「顧客への連絡」を委託先と分担しておく

委託先で事故が起きたとき、顧客への連絡を誰が行うのかは意外と決まっていません。委託先が直接連絡するのか、発注側が自社の名前で連絡するのか。問い合わせ窓口はどちらが持つのか。

これが決まっていないと、顧客は両方から連絡を受けたり、どこに問い合わせればよいか分からなくなったりします。事故時の連絡手順については、GMO「お名前.com デスクトップクラウド」の事案を取り上げた記事や、メール配信SaaS「ブラストメール」の事案を取り上げた記事でも整理しています。

まとめ

So-netの事案は、原因こそ調査中ですが、退会者を含む大量の会員情報や、委託を受けて提供していたサービスの利用者情報まで一度に漏えいした点で、多くの組織にとって他人事ではありません。発注側として取り組みたいのは、退会者データの保持期限と削除を要件として作ること、委託先に預けた顧客情報の所在台帳を作ること、契約でデータの持ち方と事故時の約束を確認すること、そして異常に気づく仕組みと顧客への連絡分担を決めておくことです。「持たないデータは漏れない」「どこにあるか分からないデータは守れない」。この二つを出発点に、自社のデータの持ち方を一度見直してみてください。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。