---
title: "ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方"
url: "https://www.issoh.co.jp/tech/details/18324/"
published: 2026-10-14
updated: 2026-10-14
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方

ブックオフグループホールディングスは2026年10月9日、子会社ブックオフコーポレーションの会員管理システムに不正アクセスがあり、会員情報が外部に漏えいしたと公表しました。10月13日の第2報で、対象は6,383,279人（会員番号ベースで6,427,735件）と確定し、退会した会員も含まれています。本記事の前半は、会員カードだけの人は対象か、10月15日から届くメールは本物か、パスワードは変えるべきかという利用者の疑問への、公式発表に沿った回答です。後半では、退会者の情報が残っていた点と、3日間で大量の会員データが取得された点を取り上げ、会員サイトの開発者が備える実装をPythonのコードで示します。

## まとめ：ブックオフ不正アクセスで確定した約638万人と利用者・事業者の対応

漏えいしたのは、アプリ会員、オンラインストア会員、Web会員として登録した氏名、生年月日、性別、メールアドレス、電話番号、郵便番号・住所、パスワードのハッシュ値、ポイントカード番号、会員番号です。クレジットカード情報と銀行口座情報は、そもそもこのシステムで管理していません。会員カードだけを使い、アプリやWebで登録していない人は対象外です。

利用者がやることは2つです。公式アプリか公式サイトから直接ログインしてパスワードを変え、同じパスワードを使う他のサービスも変えます。そして、ブックオフを名乗ってパスワードやカード番号を聞く連絡には応じません。開発者が受け取る教訓も2つあります。退会から時間がたった会員の情報まで残っていれば、漏えいの対象はその分だけ広がります。もう1つは、会員データの読み出し件数を主体ごとに数えていなければ、大量取得は止まらないという点です。

| 項目      | 公表されている内容（2026年10月14日時点） |
| ------- | ------------------------ |
| 対象者数    | 6,383,279人（退会者212,371人）  |
| 会員データ数  | 6,427,735件（会員番号ベース）      |
| 取得された期間 | 2026年10月4日〜6日            |
| 対象外     | カード情報・口座情報・本人確認書類の画像     |
| 個別メール   | 10月15日から順次送信             |
| 電話窓口    | 0570-01-2902（10時〜18時30分） |
| 未公表     | 侵入経路・脆弱性・ハッシュ方式          |

## 利用者が最初に確かめること：対象の範囲、10月15日からのメール、パスワード変更

### 会員カードだけの人は対象外：アプリ・オンラインストア・Web会員と退会者の扱い

対象は、アプリ会員、オンラインストア会員、Web会員です。[同社のよくあるご質問](https://ssl4.eir-parts.net/doc/9278/ir%5Fmaterial10/287328/00.pdf)は、会員カードだけを利用し、アプリ登録もWeb登録もしていない人は対象に含まれないと答えています。店舗でカードを作っただけの人は、今回の漏えいとは関係がありません。

退会した人は対象になりえます。[10月13日の第2報](https://ssl4.eir-parts.net/doc/9278/tdnet/2894129/00.pdf)によると、対象者6,383,279人のうち212,371人が退会会員です。アプリを消しただけ、あるいは退会手続きを済ませた人でも、過去にアプリやWebで登録していれば通知が届く可能性があります。

サービス単位でも線引きがあります。対象はBOOKOFF、BOOKOFF SUPER BAZAAR、BOOKOFF PLUS、BOOKOFF公式オンラインストア、BOOKOFF FASHION、あそビバ、BINGO、B・SPORTS、B・STYLE、Rehello by BOOKOFF（店舗）の会員です。hugall、aidect、Rehello by BOOKOFF（ECサイト）、Japan TCG Center、ブクログ、青山ブックセンター、ブックオフおかたづけサービスは別のシステムで管理しており、対象外とされています。

### 10月15日から届く「個人情報漏えいに関するお詫びとお知らせ」メールの見分け方

同社は2026年10月15日（木）から、登録メールアドレスあてに順次連絡するとしています。件名は「不正アクセスによる個人情報漏えいに関するお詫びとお知らせ」です。対象者が多いため、全員に届くまでには一定の期間がかかる見込みと案内されています。

見分ける基準は中身です。第2報は、この個別連絡でパスワード、クレジットカード情報、銀行口座情報の入力や返信を求めることはないと明記しています。パスワード変更画面へ誘導するリンクも載せません。同じ件名でもリンク先でログインさせるものや、カード番号を聞くものは偽物と考えて開かずに削除してください。手口の全体像は[フィッシング詐欺の仕組みと技術的な対策](https://www.issoh.co.jp/tech/details/13548/)で解説しています。

登録アドレスを変えた人などには、メールが届かない場合があります。その場合は公式のお知らせをもって個別連絡に代えるとされているため、メールが来ないことは対象外の証明になりません。

### パスワード変更は公式アプリと公式サイトから：同じパスワードを使う他サービスも

同社は対象の会員に対し、BOOKOFF公式オンラインストアとブックオフ公式アプリのパスワード変更を求めています。漏えいしたのはパスワードそのものではなくハッシュ値で、同社は「そのままでは元のパスワードを読み取ることはできません」と説明しています。それでも変更を求めるのは、解析で元のパスワードが割り出されるおそれを消せないからです。

優先して変えるべきは、同じか似たパスワードを使っている他のサービスです。ブックオフの会員情報にはメールアドレスも含まれるため、メールアドレスとパスワードの組み合わせで他のサイトへのログインを試される危険があります。10月13日時点で、ポイントの不正利用と会員情報の書き換えは確認されていません。

### 窓口0570-01-2902とフォーム、本人確認書類・口座・カード番号が対象外の根拠

問い合わせ先は、[本件専用のお問い合わせフォーム](https://www.bookoffgroup.co.jp/contact-us/contact-us-261009/)と、お客様窓口0570-01-2902（ナビダイヤル、10時〜18時30分）です。ナビダイヤルは通話料がかかります。同社はフリーダイヤルを準備中で、開設しだい知らせるとしています。

宅配買取や店頭買取で本人確認書類を出した人の不安には、公式の答えがあります。店頭買取で読み取った文字情報はこの会員管理システムで管理しておらず、店頭では画像も保存していません。宅配買取で提出した運転免許証やマイナンバーカードの画像は別のシステムで管理しており、対象外です。宅配買取の振込先口座と、オンラインストアに登録したクレジットカード番号も対象に含まれません。

## 公式発表で整理する経緯：10月4日の取得開始から第2報までの時系列

### 第1報の最大約643万件と第2報の6,383,279人で数字が違う理由

[10月9日の第1報](https://ssl4.eir-parts.net/doc/9278/tdnet/2893077/00.pdf)は「最大 約643万件」と書き、これは会員番号の件数であって実際の人数ではないと注記していました。第2報では、外部に送信されたことをシステムの記録で確認した会員番号が6,427,735件、同じメールアドレスで登録された複数の会員データを1人として数えた対象者が6,383,279人と、2つの数字に分けて確定させています。

差の44,456件は、1人が複数の会員番号を持っていた分です。報道では「643万件」が見出しに残っていますが、影響を受ける人数として使うべきは6,383,279人です。

### 10月4日の取得開始から10月15日の個別通知まで7つの出来事を並べた時系列

1. 10月4日〜6日：会員管理システムから会員情報が外部へ取得される
2. 10月6日（火）：第三者による不正アクセスを確認
3. 確認後：攻撃元からの通信と不正アクセスに使われた経路を遮断
4. 10月9日：第1報で公表（最大約643万件）、個人情報保護委員会への報告を進める
5. 10月13日：第2報で人数と対象サービスを確定、よくあるご質問を公開
6. 10月13日時点：警察へ相談し、外部専門家と原因調査を継続
7. 10月15日（木）：対象者への個別メールを開始

見落とせないのは、取得が3日間に及んでいた点です。確認した10月6日の時点で、640万件超の会員データはすでに外へ送られていました。この流れは、後半で扱う大量取得の検知につながります。

### 10月14日時点で公表されていない侵入経路・脆弱性名・ハッシュ方式

第2報は、具体的なシステム構成、脆弱性、攻撃手法の詳細について「今後の不正アクセスを誘発するおそれがあるため、公表を差し控えます」としています。第1報には「脆弱性を是正し」とあるため脆弱性が関わったことは読み取れますが、どの製品のどの欠陥かは分かりません。パスワードのハッシュ方式やソルトの有無も未公表です。本記事はこれらを推測で補いません。以降の技術章は、公表された事実のうち形が確定している「退会会員の情報が残っていた」「3日間で大量に取得された」「ハッシュ値が漏れた」の3点に絞ります。

## 退会会員21万人の情報が残っていた教訓：保持期間を過ぎた個人情報の消去

### 個人情報保護法22条の消去努力義務と退会後に残す項目の決め方

[個人情報保護法](https://laws.e-gov.go.jp/law/415AC0000000057)22条は、個人データを利用する必要がなくなったときは遅滞なく消去するよう努めなければならない、と定めています。努力義務であって退会即削除を強制する規定ではありません。返品や返金への対応、ポイントの精算、不正利用の調査のため、退会後もしばらく情報を残す理由は事業者側にあります。ブックオフが退会会員の情報を何のために、何日残していたかは公表されていません。

設計で決めるのは、残す理由ごとの期間と項目です。会員番号と退会日は集計や再登録の判定に要りますが、氏名、生年月日、電話番号、住所、パスワードのハッシュ値まで同じ期間残す理由は通常ありません。期間を過ぎた項目を消す処理が無ければ、退会者の情報は永久に残り、今回のように漏えいの母数に加わります。会員管理システムの機能構成から見直す場合は[会員管理システムの機能と顧客管理との違い](https://www.issoh.co.jp/column/details/12830/)も参考になります。

### SQLiteで退会180日後に個人情報をNULLにするPythonコードと実行結果

次の例は、退会から180日を過ぎた会員の個人情報だけをNULLにし、会員番号と日付を残します。データベースは[Python標準のsqlite3](https://docs.python.org/3/library/sqlite3.html)のメモリ上に作るので、追加のインストールなしで動きます。180日は例示の値で、実際の期間は自社の規程で決める前提です。

```
# 退会から一定期間を過ぎた会員の個人情報を消す最小例（Python 3.9以上・標準ライブラリのみ）
import sqlite3
from datetime import datetime, timedelta

RETENTION_DAYS = 180  # 退会後に個人情報を残す期間（自社の規程で決める値）

con = sqlite3.connect(":memory:")
con.execute("""CREATE TABLE members (
  member_no TEXT PRIMARY KEY, name TEXT, email TEXT, phone TEXT, address TEXT,
  birth_date TEXT, password_hash TEXT, status TEXT, withdrawn_at TEXT, purged_at TEXT)""")

now = datetime(2026, 10, 14)
rows = [
    ("B0001", "山田花子", "mail-B0001", "090-0000-0001", "東京都", "1990-01-01", "scrypt$...", "active", None),
    ("B0002", "佐藤一郎", "mail-B0002", "090-0000-0002", "大阪府", "1985-05-05", "scrypt$...", "withdrawn",
     (now - timedelta(days=30)).isoformat()),
    ("B0003", "鈴木次郎", "mail-B0003", "090-0000-0003", "福岡県", "1979-09-09", "scrypt$...", "withdrawn",
     (now - timedelta(days=400)).isoformat()),
]
con.executemany("INSERT INTO members VALUES (?,?,?,?,?,?,?,?,?,NULL)", rows)

def purge(con, now):
    """保持期間を過ぎた退会会員の個人情報をNULLにし、会員番号と日付だけ残す"""
    limit = (now - timedelta(days=RETENTION_DAYS)).isoformat()
    with con:  # 1トランザクションで実行し、途中失敗なら全件戻す
        cur = con.execute("""UPDATE members SET name=NULL, email=NULL, phone=NULL, address=NULL,
              birth_date=NULL, password_hash=NULL, purged_at=?
              WHERE status='withdrawn' AND withdrawn_at < ? AND purged_at IS NULL""",
                          (now.isoformat(), limit))
    return cur.rowcount

print("消去した件数:", purge(con, now))
print("再実行した件数:", purge(con, now))
for r in con.execute("SELECT member_no, status, name, email, purged_at FROM members ORDER BY member_no"):
    print(r)
```

Python 3.14.6（SQLite 3.53.1・Windows）で実行した結果です。

```
消去した件数: 1
再実行した件数: 0
('B0001', 'active', '山田花子', 'mail-B0001', None)
('B0002', 'withdrawn', '佐藤一郎', 'mail-B0002', None)
('B0003', 'withdrawn', None, None, '2026-10-14T00:00:00')
```

退会400日のB0003だけが消え、退会30日のB0002と有効会員のB0001は残りました。再実行で0件になるのは、purged\_atで処理済みを除いているためです。日次のバッチで流しても二重に処理されません。本番ではバックアップと分析用の複製にも同じ期間を適用しないと、本体を消しても複製側に退会者の情報が残ります。

## 3日間で640万件超を取得されないための会員データ大量読み出しの検知

### OWASPのログ指針で整理する記録すべき操作と記録してはいけない項目

[OWASPのLogging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)は、記録すべき出来事として、画面帳票を含むデータのインポートとエクスポート、特定の操作の上限を超えようとする試み、過剰な利用（Excessive use）などを挙げています。一方で、パスワード、アクセストークン、セッションIDそのもの、口座やカードの情報は、通常ログに直接書かないよう求めています。

会員管理システムに当てはめると、記録するのは「いつ、どの主体が、どの会員番号を読んだか」までです。氏名やメールアドレスは書きません。ログ自体が会員情報の写しになれば、漏えいの経路が1つ増えるだけです。

### 主体ごとに10分間の読み出し件数を数えて警告するPythonコードと実行結果

次の例は、操作ログを10分の窓で区切り、主体（担当者アカウントやAPIキー）ごとに読んだ会員番号の数を数えます。上限500件を超えた主体に警告を出します。

```
# 会員データの大量取得を操作ログから検知する最小例（Python 3.9以上・標準ライブラリのみ）
from collections import defaultdict
from datetime import datetime, timedelta

WINDOW = timedelta(minutes=10)  # 集計する時間幅
THRESHOLD = 500                 # 時間幅の中で読んでよい会員数の上限

# 操作ログ1行＝「時刻, 操作した主体, 操作, 会員番号」。パスワードや氏名はログに書かない
def sample_log():
    base = datetime(2026, 10, 4, 2, 0)
    for i in range(40):  # 窓口担当者の通常業務
        yield base + timedelta(seconds=15 * i), "staff-12", "member.read", f"B{i:07d}"
    for i in range(3000):  # 1つのAPIキーが連続で会員を読む
        yield base + timedelta(seconds=0.1 * i), "apikey-batch-07", "member.read", f"B{i:07d}"

def detect(events):
    seen = defaultdict(set)  # (主体, 窓の開始時刻) ごとの会員番号の集合
    for ts, actor, action, member_no in events:
        if action != "member.read":
            continue
        start = ts - timedelta(minutes=ts.minute % 10, seconds=ts.second, microseconds=ts.microsecond)
        seen[(actor, start)].add(member_no)
    for (actor, start), members in sorted(seen.items()):
        flag = "警告" if len(members) > THRESHOLD else "正常"
        print(f"{flag} {start:%m-%d %H:%M} {actor}: 会員{len(members)}件")

detect(sample_log())
```

実行結果は次のとおりです。

```
警告 10-04 02:00 apikey-batch-07: 会員3000件
正常 10-04 02:00 staff-12: 会員40件
```

窓口担当者の40件は通常業務として通り、5分間で3,000件を読んだAPIキーだけが警告になりました。数えるのは行数ではなく会員番号の種類です。同じ会員を何度も開く業務と、別々の会員を次々に読む取得を区別できます。上限値は、業務ごとの実績の最大値を1か月ほど測ってから決めます。

判断は言い切れます。会員データを読む経路に主体ごとの件数集計が無いなら、ログを残していても取得の最中には気づけません。ブックオフの事案で同社がどう検知したかは公表されていませんが、3日間という期間は、検知を集計に頼る設計の価値を示しています。逆に、会員数が数千人規模で管理者が2〜3人しかいないサイトに常時監視の仕組みまで入れるのは過剰で、週1回の集計で足ります。

## パスワードのハッシュ値が漏れた会員サイトが確かめる保存方式と報告期限

### ハッシュ値でも変更を求める理由とOWASPが推奨する4方式の優先順

ハッシュ値から元のパスワードを直接計算で戻すことはできません。攻撃者は逆向きに、よく使われるパスワードの候補を同じ方式で計算し、一致するものを探します。1回の計算が速い方式ほど、試せる候補が増える仕組みです。ハッシュ化と暗号化の違いは[ハッシュ化とは：暗号化との違いとパスワード保管の仕組み](https://www.issoh.co.jp/column/details/13487/)で整理しています。

[OWASPのパスワード保存チートシート](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)は、第一候補にArgon2id（メモリ19MiB・反復2・並列1が最小構成）、使えない場合はscrypt（N=2^17・r=8・p=1）を挙げています。bcryptは旧システム向けで作業係数10以上、PBKDF2-HMAC-SHA256は60万回です。自社の会員サイトが単純なSHA-256やMD5で保存しているなら、次回ログイン時に推奨方式で計算し直す移行を先に進めます。scryptの具体的な実装と落とし穴は[skyticket不正アクセスの解説](https://www.issoh.co.jp/tech/details/18322/)でコード付きで示しました。

### 個人情報保護委員会への速報3〜5日・確報60日と会員サイト運営者の点検先

ブックオフは個人情報保護委員会への報告を行ったとしています。個人情報保護法26条は、一定の漏えい等が起きたときに委員会への報告と本人への通知を事業者に義務づけています。[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、速報は事態を知った日から3〜5日以内、確報は30日以内で、不正アクセスのように不正の目的によるおそれがある場合は60日以内です。報告の段取りは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)にまとめています。

自社で会員アプリやECの会員サイトを運営する立場なら、確かめる順番は退会者データの保持期間、会員データを読む経路の件数集計、パスワードの保存方式です。既存の会員管理を作り直す、または消去と検知の仕組みを足す場合は[会員管理システム開発](https://www.issoh.co.jp/service/system/usersystem/)で相談を受け付けています。

## よくある質問

ブックオフの不正アクセスと情報漏えいについて、会員や元会員から出やすい質問をまとめました。

### ブックオフの会員カードしか持っていませんが対象ですか？

会員カードだけを使い、アプリ登録やWeb登録をしていなければ対象外です。同社のよくあるご質問がそう答えています。対象はアプリ会員、オンラインストア会員、Web会員で、店舗でカードを作っただけの人は含まれません。過去にアプリやWebで登録した覚えがある人は、10月15日から順次届くメールと公式のお知らせを確認してください。

### ブックオフを退会していても情報は漏えいしていますか？

漏えいしている可能性があります。第2報によると、対象者6,383,279人のうち212,371人が退会会員です。退会前にアプリやWebで登録していた人は、氏名やメールアドレス、パスワードのハッシュ値などが含まれている可能性があります。同じパスワードを他のサービスで使っているなら、そちらを先に変えてください。

### ブックオフから届いた漏えいのお知らせメールは本物ですか？

同社は10月15日から「不正アクセスによる個人情報漏えいに関するお詫びとお知らせ」という件名で、登録アドレスあてに順次連絡するとしています。ただしこのメールにパスワード変更画面へのリンクは無く、パスワード、カード番号、口座情報の入力や返信も求めません。入力を求めるものは開かずに削除し、パスワードは公式アプリか公式サイトから直接変更します。

### 宅配買取で出した免許証の画像や振込口座は流出しましたか？

対象外です。宅配買取で提出した本人確認書類の画像は別のシステムで管理しており、振込先の銀行口座情報とオンラインストアに登録したクレジットカード番号も、今回の会員管理システムでは管理していません。店頭買取で提示した書類は、読み取った文字情報もこのシステムの外で、画像は保存していないと説明されています。

### ブックオフから補償やお詫びのポイントはありますか？

10月14日時点で、補償やポイント付与についての公表はありません。補償や返金を名目に振込、手数料、カード番号の入力を求める連絡があれば応じないでください。気になることはお問い合わせフォームか0570-01-2902（10時〜18時30分）へ問い合わせます。フリーダイヤルは準備中で、開設しだい案内されます。

## 関連記事

- [skyticket不正アクセス：1,464万件流出の対象確認と本物メールの見分け方](https://www.issoh.co.jp/tech/details/18322/)：同じ週に公表されたハッシュ化パスワード流出の事例
- [タイムズカー情報漏洩・流出：自分が対象かの確認と補償、0120-25-8924は本物か](https://www.issoh.co.jp/tech/details/17925/)：退会者が対象かを確かめる手順の先行事例
- [Commune不正アクセス：約30.7万人漏えいの対象確認と共通署名鍵の教訓](https://www.issoh.co.jp/tech/details/18320/)：同時期に公表された会員情報の漏えい
- [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順](https://www.issoh.co.jp/column/details/18313/)：運営者として点検する範囲の全体像
- [会員管理システムとは？機能・顧客管理との違いと、Excelから移行する判断基準を解説](https://www.issoh.co.jp/column/details/12830/)：会員データを持つシステムの基本構成

---

出典: [ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方](<https://www.issoh.co.jp/tech/details/18324/>)（株式会社一創）