---
title: "PFUの不正アクセスと最大16万件の注文データ漏えい｜移行済みEC基盤に残る旧データの消去設計"
url: "https://www.issoh.co.jp/tech/details/18176/"
published: 2026-10-08
updated: 2026-10-08
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# PFUの不正アクセスと最大16万件の注文データ漏えい｜移行済みEC基盤に残る旧データの消去設計

スキャナーやキーボードを製造するPFUは2026年9月18日、直販サイト「PFUダイレクト本店」の利用者情報が、外部サービスであるEストアーの「ショップサーブ」への不正アクセスによって漏えいしたと公表しました。対象となる可能性がある注文データは最大169,355件です。見落とせないのは、PFUが2025年10月の時点でショップサーブの利用をやめていたことです。本記事では公表内容を日付順に整理し、利用者の点検手順を示したうえで、移行した後の旧基盤に注文データを残さないための消去の依頼、対象人数の数え方、保存期間の設計をコード付きで解説します。

## まとめ：PFUダイレクト本店の漏えいで確定した事実と利用者・EC担当者がやること

確定している事実は次のとおりです。2026年5月21日から8月1日にかけてショップサーブのサーバーが不正アクセスを受け、2008年12月5日から2025年10月31日までのPFUダイレクト本店の利用者情報が対象になりました。項目は氏名、住所、電話番号、FAX番号、メールアドレス、勤務先、任意の入力情報です。クレジットカード情報と会員ID・パスワードは、PFUの顧客分では漏えいしていないとされています。

利用者は、PFUやEストアーを装う連絡、とくに勤務先宛ての請求書や納品書を装うメールに注意します。EC担当者にとっての論点は一つです。移行や解約を終えた旧基盤に、何年分の注文データが残っているかを把握しているかどうか。キングジムも2022年8月に移行済みの旧ECサイトの利用者情報が対象になっており、同じ構図は珍しくありません。

| 項目               | 公表されている内容                |
| ---------------- | ------------------------ |
| 不正アクセスの期間        | 2026年5月21日〜8月1日          |
| PFUへの連絡          | 8月2日（Eストアーから）            |
| 自社分の確定           | 9月17日                    |
| 対象期間（本店）         | 2008年12月5日〜2025年10月31日   |
| 対象期間（優待販売など）     | 2008年12月5日〜2026年9月15日    |
| 件数               | 最大169,355件の注文データ（人数ではない） |
| カード情報・会員ID・パスワード | PFUの顧客分は漏えいなし            |

## 公表内容を日付で確認する｜8月2日の連絡から9月18日の公表まで約7週間

### 侵害期間・連絡・確定・公表の日付と自社分の確定まで6週間かかった経緯

PFUの[2026年9月18日のお知らせ](https://www.pfu.ricoh.com/news/2026/news260918-2.html)によると、同社は8月2日にEストアーから事案の連絡を受けました。自社の顧客情報が含まれる可能性が判明したのが9月8日、対象であることと漏えいした項目が確定したのが9月17日で、翌18日に公表しています。Eストアー側は[8月1日](https://estore.jp/press/20260801/)と[8月2日](https://estore.jp/press/20260802/)に公表しており、プレス一覧には10月8日時点でその後の続報は載っていません。

連絡から確定までの6週間について、PFUは理由を説明していません。ただ、現行の本店は対象外で、確認すべきは1年近く前に使い終えた旧環境の過去データでした。自社の手元にデータが無い状態では、どの注文が含まれるかを基盤側の調査に頼るしかありません。ここに、後で扱う移行時の論点が表れています。

### 最大169,355件は注文データの件数で対象人数ではないという数字の読み方

PFUは169,355件について、同じ利用者による複数回の注文を含むため対象者の人数ではないと明記しています。実際に漏えいした件数も調査中です。Eストアー全体の公表件数8,853,839件にも、同一顧客の複数の登録データを含む可能性があるという注記が付いています。

17年分の直販サイトであれば、同じ法人が消耗品を何度も注文している例は多いはずです。人数は注文件数よりかなり少なくなると考えられますが、公表が無い以上、本記事では数字を推定しません。自社で同じ立場になったときに人数を出す方法は、後半のスクリプトで示します。

### 漏えいした6項目とカード情報・会員ID・パスワードが対象外だった範囲

PFUの顧客分で対象になったのは、氏名、住所、電話番号、FAX番号、メールアドレス、勤務先、任意の入力情報です。Eストアーの第2報では基盤全体の漏えい項目に、暗号化された会員パスワードや、カード番号の先頭6桁と下4桁・有効期限も挙がっていました。一方PFUの顧客分では、カード情報と会員ID・パスワードは漏えいしていないことがEストアーの調査で確認されています。

基盤全体の公表項目と、出店企業ごとの対象項目は一致しません。利用者が判断材料にすべきなのは、自分が使った店舗の発表です。ショップサーブ全体の侵害の手口と、カード情報が漏れた店舗での対応は[ショップサーブの情報漏えい最大885万件の技術解説](https://www.issoh.co.jp/tech/details/16098/)で整理しています。

## 移行から11か月後に旧EC基盤から漏れた構図｜解約しても消えない注文データ

### 2025年10月に利用を終えた本店の2008年からの注文データが残っていた事実

PFUダイレクト本店は2025年10月からショップサーブを使っていません。それでも、2008年12月5日の導入時から2025年10月31日までの利用者情報が、2026年5月からの侵害で持ち出されました。移行から約11か月、旧基盤には17年分の注文データが置かれたままだったことになります。

利用をやめることと、データが消えることは別です。多くのSaaS型ECでは、契約の終了後もデータの削除は事業者の規定や個別の依頼に委ねられています。出店企業が消去を求め、その完了を確かめない限り、旧基盤は攻撃対象として残り続けます。

### アフィリエイト優待販売だけ2026年9月15日まで旧基盤を使い続けた影響

PFUの発表では、アフィリエイトプログラムによる優待販売など一部の販売で、2026年9月15日までショップサーブを使っていました。そのため、この販売分の対象期間は2026年9月15日までと、本店とは別になっています。PFUはこの日に利用を終えたとしています。

本店を移しても、特定の販売経路だけが旧基盤に残る形はよくあります。移行計画が本店の切り替えで完了扱いになると、優待販売や法人向けの別窓口といった小さな経路の後始末が漏れます。棚卸しの単位は「サイト」ではなく「旧基盤を参照している販売経路すべて」です。

### キングジムの旧ECサイトでも起きた解約済み店舗のデータ漏えいという共通点

同じ事案で、キングジムは[2026年9月4日のお知らせ](https://www.kingjim.co.jp/news/detail/858.html)で、旧「キングジムストア」と「オフィスオンライン」の利用者情報が対象になったと公表しました。キングジムストアは2022年8月に別のシステムへ移行しており、対象は2022年8月以前の利用者です。Eストアーからの連絡は8月31日でした。

移行から4年が経っても、旧基盤のデータは消えていなかったことになります。漏えい項目もPFUとほぼ同じで、カード情報とログインパスワードは対象外です。2社に共通するのは、侵害時点で現役の店舗ではなかったという点にあります。旧データの扱いは個別企業の不手際というより、SaaS型ECの解約で起こりやすい構造上の穴とみるべきです。

## 旧PFUダイレクト本店の利用者が今やる点検｜対象の確認先と法人宛ての偽連絡

### 対象かどうかの問い合わせ先をEストアーとPFUで使い分ける確認の手順

自分が対象かどうかの確認は、Eストアーの個人情報に関する相談窓口へ問い合わせるよう案内されています。PFUダイレクト本店のパスワード変更や注文履歴の確認は本店のマイページから、それ以外の質問はPFUの窓口へという分担です。連絡先はいずれも、上記のPFUのお知らせに記載されています。

Eストアーは対象者への個別連絡を始めており、PFUも連絡先を確認できる顧客へ案内する予定としています。届いたメールの真偽に迷ったら、メール内のリンクではなく、自分で開いた公式サイトのお知らせから窓口をたどってください。パスワードの漏えいは確認されていませんが、PFUは他サービスと同一や類似のパスワードを使っている場合の変更を求めています。

### 勤務先とFAX番号が漏れた法人購入者に届きやすい請求書・納品書型の偽メール

今回の項目には勤務先とFAX番号が含まれます。スキャナーや業務用キーボードを会社で購入した人の場合、氏名・会社名・会社の電話番号の組み合わせが攻撃者の手に渡った可能性があります。個人向けの当選詐欺より警戒すべきなのは、取引先や販売店を名乗る請求書、納品書、見積書を装ったメールです。

経理や総務へ添付ファイル付きで届く形は、受け取る側が業務として開いてしまいます。社内で共有しておくのは、振込先の変更連絡は電話で折り返して確認すること、マクロ付きの文書や圧縮ファイルは開く前に送信元へ確かめることの2点です。

## 出店企業が移行時に決める旧データの扱い｜消去の依頼・確認の証跡・残す範囲

### 個人情報保護法22条の消去努力義務と25条の委託先監督から見た旧基盤

[個人情報の保護に関する法律](https://laws.e-gov.go.jp/law/415AC0000000057)の22条は、個人データを利用する必要がなくなったときは遅滞なく消去するよう努めなければならないと定めています。25条は、個人データの取扱いを委託する場合に、委託先に対して必要かつ適切な監督を行うことを義務とする規定です。ECの注文データを基盤事業者に預けている出店企業は、この委託元の立場にあたります。

22条は努力義務ですが、移行済みの旧基盤に過去の注文データを置き続ける理由は通常ありません。委託先の監督の具体的な内容は、個人情報保護委員会の[ガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)が委託先の選定、委託契約の締結、取扱状況の把握の3つに分けて示しています。解約時の消去確認は、このうち取扱状況の把握の延長として扱えます。

### 解約前に旧基盤のデータを棚卸しして消去の確認を求める項目と依頼の要点

移行の作業計画には、旧基盤側の後始末を独立した工程として入れます。依頼と確認の対象は次のとおりです。

- 受注データ・顧客データ・会員データ・メールマガジン会員の各テーブル
- 配送先情報と、問い合わせフォームや任意入力欄に入った自由記述
- 管理画面から出力したCSVのうち、基盤側のサーバーに残るもの
- バックアップに含まれる分の消去予定時期
- 本店以外で旧基盤を参照している販売経路（優待販売・法人窓口など）

依頼では、消去の対象範囲、完了予定日、バックアップから消える日付、完了を示す書面の発行可否の4点を文書で確かめます。書面が出ない事業者でも、問い合わせと回答の記録は、委託先を監督したことを示す証跡です。データを自社へ引き取るエクスポートは、消去依頼より前に済ませておきます。

### 旧基盤に注文データを残してよい場面はほぼ無いと判断する理由と例外条件

移行が終わった旧基盤に注文データを残す選択は、原則として採りません。返品や問い合わせへの対応、税務上の記録保存といった必要は、エクスポートして自社の管理下に置いたデータで満たせます。残す期間が長いほど、自社が使わないデータの漏えいリスクだけが積み上がります。

例外は、移行直後の数か月で、旧基盤の会員がまだ新基盤に移り切っていない場合です。この場合も、残す期限を日付で決め、期限が来たら消去を依頼する予定を移行計画に書き込みます。期限の無い「とりあえず残す」は、PFUとキングジムが直面した状態そのものです。

## 影響範囲を自社で数える手順｜注文CSVから対象人数と連絡可能な人を割り出す

### 注文CSVを期間で絞りメールアドレスと電話番号で名寄せするPythonスクリプト

基盤事業者から自社分が対象と連絡が来たとき、最初に要るのは「何人に、どの手段で連絡できるか」です。手元にエクスポート済みの注文CSVがあれば、対象期間で絞り込み、メールアドレスと電話番号で同一人物をまとめるだけで概数が出ます。次の例は、メールか電話番号のどちらかが一致すれば同じ人物として扱います。

```
import csv, re, sys, unicodedata

DATE_FROM, DATE_TO = "2008-12-05", "2025-10-31"
COL_DATE, COL_MAIL, COL_TEL = "order_date", "email", "tel"

def norm_mail(s):
    return unicodedata.normalize("NFKC", s or "").strip().lower()

def norm_tel(s):
    return re.sub(r"\D", "", unicodedata.normalize("NFKC", s or ""))

parent = {}
def find(x):
    parent.setdefault(x, x)
    while parent[x] != x:
        parent[x] = parent[parent[x]]
        x = parent[x]
    return x
def union(a, b):
    parent[find(a)] = find(b)

orders, keys_of = 0, []
with open(sys.argv[1], encoding="utf-8-sig", newline="") as f:
    for row in csv.DictReader(f):
        d = (row.get(COL_DATE) or "")[:10].replace("/", "-")
        if not (DATE_FROM <= d <= DATE_TO):
            continue
        orders += 1
        keys = [k for k in ("m:" + norm_mail(row.get(COL_MAIL)),
                            "t:" + norm_tel(row.get(COL_TEL))) if len(k) > 2]
        for k in keys[1:]:
            union(keys[0], k)
        keys_of.append(keys)

people = {}
for keys in keys_of:
    if keys:
        people.setdefault(find(keys[0]), set()).update(keys)
no_contact = sum(1 for keys in keys_of if not keys)
mailable = sum(1 for ks in people.values() if any(k.startswith("m:") for k in ks))

print(f"対象注文: {orders}件 / 名寄せ後: {len(people)}人"
      f" / メール連絡可: {mailable}人 / 連絡先なし注文: {no_contact}件")
```

8件の注文を入れた模擬CSVで動かすと、期間外の2件を除いた6件から、大文字と末尾の空白が違うメールアドレスや全角で書かれた電話番号を同じ人物にまとめ、「対象注文: 6件 / 名寄せ後: 3人 / メール連絡可: 2人 / 連絡先なし注文: 1件」と出力しました。列名は自社のCSVに合わせて`COL_DATE`などを書き換えます。日付は「2025/10/31」と「2025-10-31」のどちらの形式でも読めます。

家族で同じ電話番号を使っている場合は別人が1人にまとまるため、出てくる人数は下限寄りの概数です。報告や通知の正式な人数は、基盤事業者の調査結果と突き合わせて確定させます。

### 委託元として個人情報保護委員会へ報告する要否と速報3〜5日・確報の期限

個人情報保護法26条1項のただし書は、委託を受けた事業者が委託元に事態を通知したときは、委託先の報告義務がなくなると定めています。つまり出店企業は、基盤事業者から通知を受けた時点で、自らが報告する立場に立ちます。[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的をもって行われたおそれがある行為による漏えい等は件数にかかわらず報告対象で、速報は3〜5日以内、確報は60日以内です。

期限は事態を知った時点から数えるため、基盤事業者から最初の連絡を受けた日と、自社分が含まれると判明した日の両方を記録しておきます。PFUで言えば8月2日と9月17日です。報告書式の項目と記入の段取りは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。

## SaaS型ECを使い続ける企業の設計｜旧データを基盤に溜めない保存期間と移管

### 契約時に確かめる受注データの保存期間・一括削除・エクスポートの3項目

旧データの問題は、解約時ではなく契約時に手を打つのが確実です。SaaS型ECを選ぶ段階で確かめておくのは、受注データの保存期間を店舗側で設定できるか、期間を過ぎたデータや指定した期間のデータを一括で削除できるか、全件を機械で読める形式でエクスポートできるかの3点です。

3点のうち一つでも「不可」なら、契約前に解約時の消去手順と書面の有無を事業者に確認します。委託先を選ぶ段階で相見積りの比較項目を揃える考え方は[システム運用保守の会社を選ぶ手順と契約前の確認点](https://www.issoh.co.jp/column/details/16402/)が参考になります。

### 受注データを自社で引き取り基盤から定期的に消す運用を外注で組む範囲

保存期間の設定ができない基盤でも、出荷や返品の期限を過ぎた受注データを毎月エクスポートして自社のデータベースへ移し、基盤側からは削除する運用を組めば、基盤に置かれるデータは直近の数か月分に限られます。今回のように基盤が侵害されても、持ち出される範囲は17年分ではなく数か月分で済みます。

この運用は、基盤のAPIやCSV出力の仕様に合わせた移管処理、自社側の保管データベース、削除の実行記録の3つで成り立ちます。月間の注文が数十件で担当者が手作業で回せる規模なら、外注せずに手順書で十分です。注文が多く、複数の販売経路が一つの基盤を参照しているなら、移管と削除の仕組みごと[ECシステム開発](https://www.issoh.co.jp/service/system/ec/)の相談先に任せ、移行時の旧基盤の消去まで工程に含めるのが現実的です。

## よくある質問

PFUダイレクト本店の個人情報漏えいについて、利用者とEC担当者から出やすい質問をまとめました。

### 今のPFUダイレクトで買い物をしても大丈夫ですか？

PFUによると、現在のPFUダイレクト本店は2025年10月からショップサーブを使っておらず、Amazonマーケットプレイス店、楽天市場店、Yahoo!店も別のシステムで影響は確認されていません。漏えいの対象は、2025年10月31日までの旧本店の利用者と、2026年9月15日までの優待販売などの利用者です。

### クレジットカードの停止やパスワードの変更は必要ですか？

PFUの顧客分では、クレジットカード情報と会員ID・パスワードは漏えいしていないことがEストアーの調査で確認されています。カードの停止は必須ではありません。ただし他のサービスと同一や類似のパスワードを使っている場合は、変更を検討するようPFUが求めています。

### 自分が対象かどうかはどこで確認できますか？

対象に該当するかどうかは、Eストアーの個人情報に関する相談窓口へ問い合わせるよう案内されています。Eストアーは対象者への個別連絡を始めており、PFUも連絡先を確認できる顧客へ案内するとしています。窓口の連絡先は、PFU公式サイトの2026年9月18日付のお知らせで確認してください。

### 169,355人分の情報が漏れたということですか？

169,355人分の漏えいではありません。169,355件は対象となる可能性がある注文データの最大件数で、同じ利用者による複数回の注文を含みます。PFUは対象者の人数ではないと明記しており、実際に漏えいした件数も調査中です。人数が公表された時点で、正確な規模が分かります。

### ECサイトを移行したら旧サービスのデータはどうすればよいですか？

旧サービスのデータは、必要な分を自社へエクスポートしたうえで、旧サービスの事業者に消去を依頼し、対象範囲・完了日・バックアップから消える日付を文書で確かめます。個人情報保護法22条は不要になった個人データの遅滞ない消去を努力義務としています。本店以外の販売経路が旧サービスを使っていないかも確認してください。

## 関連記事

- [ショップサーブの情報漏えい最大885万件｜対象の確かめ方とサーバー侵害・外部送信の技術解説](https://www.issoh.co.jp/tech/details/16098/)：基盤事業者側で起きた侵害の手口と検知設計
- [タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計](https://www.issoh.co.jp/tech/details/17925/)：使わなくなったデータを残さない保管設計の別事例
- [Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)：事業者側の侵害で利用者が回す点検手順の比較に
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：自社のECや管理画面の外部公開面を点検するときの判断材料

---

出典: [PFUの不正アクセスと最大16万件の注文データ漏えい｜移行済みEC基盤に残る旧データの消去設計](<https://www.issoh.co.jp/tech/details/18176/>)（株式会社一創）