@cosme会員約300万人分の情報漏えい｜2か月で3件の公表から考える、個人データを「入口別」ではなく「流れ」で守る仕組み

はじめに
何が起きたのか
なぜ個人データは「想定外の場所」から漏れるのか
発注側が自社で整えておきたい仕組み
まとめ
参考

はじめに

2026年11月2日、化粧品の口コミサイト「@cosme（アットコスメ）」を運営するアイスタイルが、第三者による不正アクセスにより、@cosme共通IDの会員情報の一部、約300万人分が外部に漏えいしたと発表しました。氏名や住所に加えて、肌質や髪質といった情報も対象に含まれています。

同社は2026年9月に、社内でのファイルの受け渡しに使った外部サービスの設定不備による漏えいの可能性を、10月には委託先のメール配信システムへの不正アクセスに関するお知らせを公表しています。3件は原因も経路も異なり、同社も互いの関連は示していません。ただ、発注側の目で見ると、「個人データの出口は1つではない」ことがよく分かる並びです。

この記事では、事案の概要を整理したうえで、個人データの守り方を侵入経路ごとではなく「データの流れ」全体で考える仕組みについて、発注側支援の立場から解説します。

何が起きたのか

アイスタイルの発表（2026年11月2日）と報道によると、概要は次のとおりです。

2026年10月28日、第三者による@cosmeへの不正アクセスにより、@cosme共通IDの会員情報の一部が外部に漏えいしたことを確認した
対象は約300万人。項目はユーザーID（ログインには使わない自動発番のID）、ニックネーム、氏名（漢字・カナ）、郵便番号、住所、電話番号、メールアドレス、性別、生年月日、肌質、髪質
現時点の確認では、ログイン用パスワードとクレジットカード情報は含まれていない
不正アクセスの時点で会員だった人は、その後に退会していても対象になる。退会者には、プライバシーポリシーに基づき退会後も一定期間保管している情報をもとに連絡する
対象者への個別連絡は11月6日に完了する予定で、案内メールは「cosme.net」ドメインから送る。メールでパスワードやクレジットカード情報の入力を求めることはないとしている
個人情報保護委員会に報告済み。第三者のセキュリティ専門会社と原因と影響範囲を調査中で、発表時点では不正利用や二次被害は確認されていない

侵入の日時や手口は、発表時点では明らかにされていません。

同社が直近で公表した別の2件は次のとおりです。

9月16日公表：9月2日、社員が個人情報を含むファイルを外部のファイル転送サービスで受け渡した際、公開設定の不備により、URLを知っていれば誰でもアクセスできる状態が約20分間続いた（メールアドレスなど、10,997人分。漏えいの「可能性」としての公表）
10月23日公表：一部のメール配信に使っていた委託先（ユミルリンク）の「Cuenote FC」が不正アクセスを受けた件で、同社の利用環境にも外部からの不審なアクセスの痕跡があると連絡を受け、調査が終わるまで利用を段階的に停止した（漏えいの有無や件数は、同お知らせでは示されていない）

なぜ個人データは「想定外の場所」から漏れるのか

ここからは特定の会社の話ではなく、会員サービスを持つ企業に一般的に起きやすい構造を整理します。

会員データは本番DBの外にも散らばる

会員情報の本体はサービスのデータベースにあります。しかし実際の業務では、メールマガジン配信のために配信システムへ、分析や施策の検討のために分析基盤や表計算ファイルへ、問い合わせ対応のためにコールセンターのシステムへと、データは何度も複製されます。セキュリティ対策は本番システムに集中しがちで、複製先は「一時的なもの」「委託先が管理しているもの」として後回しになります。

共通IDに情報が集まるほど、1回の事故が大きくなる

複数のサービスを1つのIDで使えるようにすると、利用者は便利になり、事業側は顧客を横断的に理解できます。その反面、ID基盤には各サービスで集めた属性が集まり、事故が起きたときに失うものも大きくなります。今回の肌質・髪質のように、法律上の「要配慮個人情報」には当たらなくても、氏名や住所と結び付くと本人にとって知られたくない情報になり得るものも含まれます。

対策が「事故が起きた入口」単位で終わる

事故が起きると、その入口に対策が打たれます。ファイル転送の事故ならファイル転送のルールを、メール配信の事故なら配信委託先の管理を見直します。それ自体は正しいのですが、入口ごとに対策していると、まだ事故が起きていない別の入口は手付かずのまま残ります。

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

発注側支援のコンサルタントとして、同じことを自社で起こさないために整えておきたい仕組みを5つに整理します。ポイントは、個人データが「どこから入り、どこにコピーされ、どこから出ていくか」を一枚の地図で管理することです。

1. 個人データの「流れ図」と台帳を作る

最初にやるべきことは、会員データの流れを図にすることです。本番DBを中心に、次のような複製先・受け渡し先を洗い出します。

外部のSaaS（メール配信、MA、CRM、アンケート、問い合わせ管理など）
分析基盤、データウェアハウス、BIツール
社内の共有フォルダやファイル転送サービスでの受け渡し
委託先・再委託先が持つ作業用のコピー

それぞれについて、渡している項目、件数、保管期間、管理責任者（自社の誰か、委託先のどこか）を台帳にします。ここで「誰が責任者か分からない」複製先が見つかれば、それが最優先の対策対象です。

2. 「連絡に使うデータ」と「分析に使うデータ」を分けて持つ

肌質や髪質、購買履歴のような属性・嗜好のデータは、主に分析やおすすめに使います。この用途に、氏名や住所、電話番号は通常いりません。そこで、分析用のデータは会員IDとは別の仮のIDで管理し、氏名や連絡先とは別の場所に置く設計にします（仮名化）。こうしておけば、分析側からデータが漏れても、それだけでは個人を特定しにくくなります。

新しいシステムを発注するときは、要件定義の段階で「項目ごとの用途」と「どのシステムが氏名と結び付けて持つか」を決め、提案依頼書（RFP）にも書いておきます。後から分けるのは大変なので、最初の設計で決めるのが一番安上がりです。

3. 共通IDに渡す属性は「各サービスに必要な最小限」にする

共通ID基盤を持つ企業は、ID基盤と各サービスの間でどの属性を共有しているかを確認します。各サービスが本当に必要としている項目だけを渡し、使っていない連携は止めます。ID基盤側には「属性を追加するときは、用途と保管期間を情報システム部門が承認する」というルールを置くと、データが知らないうちに集まることを防げます。

退会者のデータをいつまで、どの形で残すかも同じ台帳で管理します。保存項目と期間の絞り方については、クラブツーリズムの事案を取り上げた記事で「持たない・残さない」ルールとして整理しています。

4. 事故の再発防止策は「同じ型の入口すべて」に横展開する

自社や他社で事故が起きたときは、その入口だけでなく、流れ図の中で同じ型の入口すべてを点検します。たとえば、ファイル転送の設定ミスが起きたら、ファイル転送サービスだけでなく、共有リンクを発行できるすべてのクラウドストレージを点検します。委託先のSaaSで事故が起きたら、同じように会員データを預けているすべての外部サービスについて、預けているデータの量と、異常があったときの報告ルートを確認します。

他社の事故も、自社の流れ図に当てはめて「うちならどこが該当するか」を確認する材料になります。月に一度、情報システム部門で直近の事故報道を流れ図に当てはめる場を持つだけでも、点検の抜けは大きく減ります。

5. 委託先との契約で「データを返す・消す」まで決める

外部サービスや委託先に会員データを渡すときは、契約や発注書で次の点を決めておきます。

預けるデータの項目と件数の上限、保管期間
契約終了時やキャンペーン終了時のデータの返却・削除と、削除したことの報告
不正アクセスの疑いを検知したときの報告期限と、調査への協力
再委託する場合に、同じ条件を再委託先にも適用すること

委託先の事故では、発注側が「そもそも何件預けていたか」をすぐに答えられないことがよくあります。台帳と契約で預けている範囲を把握しておけば、影響範囲の特定と顧客への連絡を早く進められます。

まとめ

@cosmeの約300万人分の会員情報漏えいは、氏名や住所に加えて肌質や髪質まで含む、影響の大きい事案です。侵入の手口はまだ公表されていませんが、同じ会社が2か月の間に、社内のファイル受け渡し、委託先のメール配信、自社サービスへの不正アクセスと、経路の異なる3件を公表していることは、個人データの出口が1つではないことを示しています。発注側にできるのは、個人データの流れ図と台帳を作り、連絡用と分析用のデータを分け、共通IDに集める属性を最小限にし、事故の教訓を同じ型の入口すべてに広げ、委託先とはデータの返却・削除まで契約で決めておくことです。まずは、自社の会員データが本番DB以外のどこにコピーされているかを書き出してみてください。

参考

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