---
title: "RAGTAGの情報漏洩：延べ約120万件の対象項目と会員の備え、侵入から検知まで11日の意味"
url: "https://www.issoh.co.jp/tech/details/19146/"
published: 2026-11-01
updated: 2026-11-01
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# RAGTAGの情報漏洩：延べ約120万件の対象項目と会員の備え、侵入から検知まで11日の意味

ブランド古着の買取販売「RAGTAG」を運営する株式会社ティンパンアレイの業務サーバーが不正アクセスを受け、会員情報が外部へ流出した可能性があると、親会社の株式会社ワールドが2026年10月30日に開示しました。対象は延べ約120万件です。前半では開示文をもとに、漏れた可能性がある項目、カード情報の扱い、偽の連絡への備えを整理しました。後半では、侵入から検知まで11日かかった点を手がかりに、監査ログで大量の抽出を見つける方法と、延べ件数を実人数に直す名寄せのPythonの例を示します。

## まとめ：RAGTAGの情報漏洩で流出した可能性がある項目と会員がまず行うこと

[株式会社ワールドの適時開示](https://www.release.tdnet.info/inbs/140120261030560364.pdf)によると、10月17日（土）14時51分頃に外部から業務サーバーへの侵入とデータを抽出する操作が行われました。不正な操作を検知したのは10月28日（水）12時08分頃で、同日中にサーバーを隔離し、21時36分までに不正アクセスの経路を遮断しています。10月29日には警察へ相談し、個人情報保護委員会へ報告しました。

流出した可能性があるのは、氏名・住所・電話番号・生年月日・性別・メールアドレスの6項目です。クレジットカード情報その他の決済情報と顔情報については、流出は確認されていないとしています。会員がまず行うことは、RAGTAGやワールドを名乗るメール・SMS・電話のリンクを開かず、個人情報やカード番号を入力しないことです。

| 区分       | 開示文の記載                 |
| -------- | ---------------------- |
| 流出の可能性   | 氏名・住所・電話番号・生年月日・性別・メール |
| 件数       | 会員情報 延べ約120万件（詳細は確認中）  |
| 確認されていない | カード情報その他の決済情報、顔情報      |
| 会員への連絡   | HPでの告知と個別メールを準備中       |

## 会員が確かめること：6つの対象項目・決済情報の扱い・偽の連絡への備え

### 氏名・住所・電話番号・生年月日・性別・メールの6項目と延べ約120万件

6項目がそろうと、本人の名前で届け先と連絡先が分かり、年齢と性別まで特定できます。RAGTAGはEC・店舗・買取の窓口を持つため、会員がどの窓口で登録したかで漏れた項目は違う可能性がありますが、開示文は窓口ごとの内訳を示していません。対象となる会員と件数の詳細は、10月30日時点で確認中とされています。

件数が「延べ」で書かれている点にも注意が要ります。延べ件数は、同じ人が複数の記録に載っていれば重ねて数えた数で、通知を受ける実人数はこれより少なくなるのが普通です。実人数がどれだけになるかは、続報を待つ必要があります。この数え方の違いは、後半の技術章で実際に計算して示します。

### カード情報と顔情報は流出を確認していない、パスワードは記載なし

開示文は「クレジットカード情報その他の決済情報および顔情報の流出は確認されておりません」と書いています。「確認されていない」は「流出していない」と同じ意味ではなく、調査の途中で見つかっていないという表現です。同社は外部のセキュリティ専門家に調査を依頼するとしており、結果によって記載が変わる余地があります。

ログイン用のパスワードについては、対象項目にも「確認されていない」項目にも書かれていません。RAGTAGのパスワードをほかのサービスでも使い回しているなら、念のためそちらを先に変えておくと安全です。カードの利用明細に身に覚えのない請求がないかも、毎月確かめておきます。

### RAGTAGを装うメールやSMS、電話に応じないための見分け方

氏名とメールアドレス、電話番号がそろって漏れると、本人の名前を書いた偽の連絡が届きやすくなります。「お詫びとしてポイントを付与するので、カード情報を再登録してください」「買取代金の振込先を確認してください」という文面は、今回の事案を知っている人ほど本物らしく見えるものです。

見分ける基準は単純です。届いた連絡のリンクから入力するのではなく、ブックマークや検索から公式サイトを開き、告知と照らし合わせます。電話で個人情報を尋ねられたら、いったん切って公式の窓口にかけ直します。偽の連絡が成り立つ仕組みは[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で解説しました。同じリユース業で起きた別の事案と確認の手順は[ブックオフ不正アクセス：約638万人の確認方法](https://www.issoh.co.jp/tech/details/18324/)で扱っています。

### 個別メールと公式告知を待つ間に登録会員が手元でできる3つのこと

同社は、ホームページでの告知と会員への個別メールで、お詫びと注意喚起を行うとしています。10月30日の開示時点では「準備が整い次第、速やかにご案内」という段階でした。連絡を待つ間にできることは次の3つです。

1. RAGTAGに登録したメールアドレスと電話番号を思い出し、そこに届く連絡を注意して見る
2. RAGTAGと同じパスワードを使っているサービスがあれば、そちらのパスワードを変える
3. カードの利用明細と、心当たりのない宅配の不在連絡や請求を確かめる

## 開示文から読む事案の構造：10月17日の侵入から28日の検知まで11日

### 土曜14時51分の侵入から隔離・遮断・報告までの時系列と未公表の点

開示文に書かれた日時を並べると、侵入から検知までが11日、検知から報告までが1日です。

| 日時              | 出来事                  |
| --------------- | -------------------- |
| 10月17日（土）14:51頃 | 業務サーバーへの侵入とデータ抽出の操作  |
| 10月28日（水）12:08頃 | 不正な操作を検知、サーバーを隔離     |
| 10月28日 21:36まで  | 経路を遮断、社内業務システムの一部を停止 |
| 10月29日（木）       | 警察へ相談、個人情報保護委員会へ報告   |
| 10月30日（金）       | ワールドが適時開示            |
| 未公表             | 侵入経路・脆弱性・サーバーの用途・実人数 |

以降は、開示された事実から読めることに絞ります。侵入の手口やサーバーの構成は、外部の専門家による調査の結果を待つ必要があります。

### 抽出の操作が11日間見つからなかったことが監視の設計に投げかける問い

開示文は、10月17日に「侵入およびデータを抽出する操作」が行われ、28日に「不正な操作を検知」したと書いています。17日の抽出の時点では気づけず、28日に何らかの操作で気づいたと読めます。28日に検知した操作が17日と同じ種類だったのか、別の操作だったのかは書かれていません。

断定はできませんが、業務サーバーからまとまった量の会員情報が持ち出されたのであれば、その時点のアクセス量は普段と違っていたはずです。加えて土曜の午後は、平日向けの社内業務が少ない時間帯です。普段の量と比べて多すぎる取得を見張る仕組みがあれば、11日を短くできた可能性があります。攻撃者が持ち出しの量を小分けにして目立たなくする手口は、[MITRE ATT&CKのT1030（Data Transfer Size Limits）](https://attack.mitre.org/techniques/T1030/)として整理されています。

### 延べ件数が大きくなる理由と、古物営業法が求める本人確認記録の保存

リユース事業者は、ほかの小売より多くの個人情報を持ちます。[古物営業法](https://laws.e-gov.go.jp/law/324AC0000000108)の第15条は、古物を買い受けるときに相手方の住所・氏名・職業・年齢の確認を古物商に義務付けた条文です。第16条はそれを帳簿等に記録すること、第18条は記録を3年間保存することを定めています。買取の利用者は、EC会員や店舗会員とは別の記録に載ることになります。

今回流出の可能性がある記録が買取の記録を含むかどうかは、開示文に書かれていません。ただ、EC・店舗・買取で記録が分かれていれば、同じ人が複数の記録に載り、延べ件数が実人数より大きくなります。古物台帳の要件は[古物営業法の三大義務と古物商許可](https://www.issoh.co.jp/column/details/18224/)、買取と販売の記録を一つのシステムでつなぐ考え方は[リサイクルショップのPOSシステムの選び方](https://www.issoh.co.jp/column/details/18548/)にまとめました。

### 施行規則7条3号・4号に当たる事案と、確報60日の期限の数え方

[個人情報保護法施行規則](https://laws.e-gov.go.jp/law/428M60020000003)の第7条は、委員会への報告が必要な事態を4つ挙げています。本件は、不正の目的をもって行われたおそれがある行為による漏えい（第3号）と、本人の数が1,000人を超える漏えい（第4号）に当たる事案です。第8条は、第3号に当たる場合の確報を、事態を知った日から60日以内としています。

[ガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)は、速報の目安をおおむね3〜5日以内としています。検知の翌日に行われた同社の報告は、この目安の範囲内です。確報は検知した10月28日から数えると12月下旬が期限で、それまでに実人数と原因、再発防止策を報告することになります。報告と本人への通知の全体の流れは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しました。

## 開発側の対策：監査ログで大量抽出を検知し、延べ件数を名寄せする

### 口座ごとの平常値と比べて、1時間の取得行数が多すぎるものを拾う考え方

ここから先は、ティンパンアレイの仕組みを推測するものではありません。業務サーバーからの持ち出しを早く見つけるには、データベースやアプリの監査ログに「誰が・いつ・何行取ったか」を残し、普段の量と比べます。[MITRE ATT&CKのExfiltration（TA0010）](https://attack.mitre.org/tactics/TA0010/)は、持ち出しに使われる手口をまとめた一覧です。手口が何であれ、会員テーブルを丸ごと取れば取得行数は増えます。

比べる相手は全体の平均ではなく、口座ごとの平常値です。夜間の集計バッチは毎回数万行を読みますが、それは普段どおりの処理に当たります。一方、平日に数千行しか読まない社内ツールの口座が、土曜に数十万行を読んだら異常です。口座ごとに分けて見ることで、こうした違いを区別できます。

### 大量取得の検知と延べ件数の名寄せを行うPythonスクリプト

次のコードは、Pythonの標準ライブラリだけで実行できる構成です。detectモードは、監査ログを口座と1時間ごとに集計し、口座ごとの中央値の10倍か5万行の多い方を超えた時間帯を出力して終了コード1を返します。dedupeモードは、流出候補の記録を、メールアドレスか「電話番号＋生年月日」が一致すれば同じ人として束ね、延べ件数と実人数をそれぞれ出す仕組みです。表記の揺れ（全角数字・ハイフン・大文字）はNFKC正規化でそろえます。

```
# 業務サーバーからの大量抽出を監査ログで検知し、流出候補の「延べ件数」を名寄せして実人数に直す
# （Python 3.9以上・標準ライブラリのみ）
# 使い方: python incident_tools.py detect audit_log.csv    … 口座ごとの平常値と比べて大量取得を検知する
#         python incident_tools.py dedupe leaked.csv       … 延べ件数を名寄せして通知対象の実人数を数える
import csv, re, sys, unicodedata
from collections import defaultdict
from datetime import datetime
from statistics import median

FACTOR, FLOOR = 10, 50_000      # 平常値の10倍か、1時間5万行の多い方を超えたら検知

def detect(path):
    hourly = defaultdict(int)                       # (口座, 時間帯) ごとの取得行数
    for r in csv.DictReader(open(path, encoding="utf-8")):
        hour = datetime.fromisoformat(r["ts"]).strftime("%Y-%m-%d %H:00")
        hourly[(r["account"], hour)] += int(r["rows_returned"])
    per_acct = defaultdict(list)
    for (acct, hour), rows in hourly.items():
        per_acct[acct].append((hour, rows))
    alerts = 0
    for acct, series in sorted(per_acct.items()):
        base = median(rows for _, rows in series)   # その口座の平常値（1時間あたり中央値）
        limit = max(base * FACTOR, FLOOR)
        for hour, rows in sorted(series):
            if rows > limit:
                alerts += 1
                print(f"ALERT {hour} {acct}: {rows:,} rows (baseline {base:,.0f}, limit {limit:,.0f})")
    print(f"detect done: {alerts} alerts")
    return 1 if alerts else 0

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

def dedupe(path):
    parent = {}
    def find(x):
        parent.setdefault(x, x)
        while parent[x] != x:
            parent[x] = parent[parent[x]]
            x = parent[x]
        return x
    total = 0
    for r in csv.DictReader(open(path, encoding="utf-8")):
        total += 1
        keys = []
        if r["email"]:
            keys.append("m:" + norm(r["email"]))
        phone = re.sub(r"\D", "", norm(r["phone"]))
        if phone and r["birth"]:
            keys.append("p:" + phone + "|" + r["birth"])
        keys.append("r:" + r["source"] + ":" + r["record_id"])   # どのキーも無い行は1人として数える
        for k in keys[1:]:
            parent[find(k)] = find(keys[0])          # メールか電話＋生年月日が一致すれば同一人物
        find(keys[-1])
    people = {find(k) for k in parent if k.startswith("r:")}
    print(f"records (延べ): {total:,}")
    print(f"persons (名寄せ後): {len(people):,}")
    return 0

if __name__ == "__main__":
    sys.exit(detect(sys.argv[2]) if sys.argv[1] == "detect" else dedupe(sys.argv[2]))
```

### 架空の監査ログ10,288行と会員記録8,511件で実行した結果

動きを確かめるため、架空のデータを用意しました。監査ログは10月1日から28日までの4週間分で、Webアプリ（app\_web）、平日だけ動く社内ツール（staff\_tool）、毎晩2時の集計バッチ（batch\_report）の3口座が普段どおりに動いています。そこへ10月17日（土）14時51分から、社内ツールの口座で1回1万行ずつ合計120万行を抜き出す操作を混ぜました。会員記録は、架空の5,000人がEC・店舗・買取の3台帳に重なって載る想定で、店舗台帳は電話番号を全角とハイフンで、買取台帳はメールを大文字混じりで入れています。Python 3.14.7（Windows）で2026年11月1日に実行した結果です。

```
$ python incident_tools.py detect audit_log.csv
ALERT 2026-10-17 14:00 staff_tool: 90,000 rows (baseline 5,230, limit 52,300)
ALERT 2026-10-17 15:00 staff_tool: 600,000 rows (baseline 5,230, limit 52,300)
ALERT 2026-10-17 16:00 staff_tool: 510,000 rows (baseline 5,230, limit 52,300)
detect done: 3 alerts
$ echo $?
1
$ python incident_tools.py dedupe leaked.csv
records (延べ): 8,511
persons (名寄せ後): 4,647
```

抜き出しが始まった14時台から3つの時間帯が検知されました。毎晩4万行前後を読む集計バッチは、口座ごとの平常値が高いため検知されていません。全体で一つの閾値を決めていたら、バッチを誤検知するか、閾値を上げて社内ツールの異常を見逃すかのどちらかになります。終了コード1を監視の仕組みに渡せば、土曜の午後でも担当者へ通知できます。

名寄せでは、延べ8,511件が4,647人になりました。延べ件数は実人数の約1.8倍で、通知のメールを延べ件数どおりに送ると、同じ人に何通も届くことになります。全角の電話番号や大文字のメールをそろえずに突き合わせると、同じ人が別人として数えられ、実人数を多く見積もります。名寄せのキーの選び方は[顧客データ統合の進め方と名寄せのキー設計](https://www.issoh.co.jp/column/details/18983/)で詳しく扱いました。

### 検知した後の隔離と、端末側で持ち出しの痕跡を追う手段の組み合わせ

監査ログの検知は、データベースに届いた操作しか見えません。侵入の入口になった端末やサーバー上で何が実行されたかは、[EDRの検知の仕組み](https://www.issoh.co.jp/tech/details/13303/)のように端末側の記録で追います。インシデント対応を検知・対応・復旧の流れで組み立てるときは、[NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)が手順を考える土台になります。外部に公開したAPIが入口になる場合のレート制限と認可は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)にまとめました。

## リユース・小売事業者の判断：業務サーバーの外部診断を急ぐ条件

### 業務サーバーの監査ログ・口座・保存期間・外部経路を点検する5つの項目

会員情報や買取の記録を業務サーバーに置いている会社が点検する項目を、優先度の高い順に並べました。上から2つは、今日のうちに確かめられます。

| 順 | 点検項目    | 見る箇所                     |
| - | ------- | ------------------------ |
| 1 | 監査ログ    | 誰が何行取ったかが記録され、誰かが見ているか   |
| 2 | 外部からの経路 | 業務サーバーへインターネットから届く経路がないか |
| 3 | 口座の権限   | 業務用の口座が会員テーブル全件を読めないか    |
| 4 | 保存期間    | 法定の3年を過ぎた買取記録を残していないか    |
| 5 | 台帳の重複   | EC・店舗・買取で同じ人の記録が分かれていないか |

1番目は前の章のdetectで機械的に確かめられます。4番目は、古物営業法が求める保存は3年間で、それを過ぎた記録を消せば漏れる量そのものが減るという意味です。消す前に、ほかの法令や社内規程で保存が必要な期間と照らし合わせます。原因ごとの防ぎ方の全体像は[情報漏洩対策の原因別4類型](https://www.issoh.co.jp/column/details/18315/)で整理しました。

### 外部診断を急ぐべきサーバー構成と、年1回の定期診断で足りる構成

次のどれかに当てはまる会社は、外部の脆弱性診断を急いでください。業務サーバーにインターネットから届く経路があり、その経路を誰が管理しているか答えられないこと。業務用の口座が会員テーブルを全件読めること。取得行数を見る監視がなく、大量の抽出があっても翌日以降まで気づけないことです。RAGTAGの件は、侵入経路が公表されていない段階でも、3つ目に当てはまる会社には同じ11日が起こりうることを示しています。

業務サーバーを外部から切り離し、口座ごとの取得行数を監視して通知が届く体制なら、年1回の定期診断で足ります。診断の種類と費用の考え方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)にまとめました。自社の業務サーバーや会員システムに同じ弱点が残っていないかを第三者に確かめてもらいたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。

## よくある質問

RAGTAGの情報漏洩について、会員や利用者から出やすい質問をまとめました。

### 自分がRAGTAGの情報漏洩の対象かどうか、どうすれば分かりますか？

10月30日の開示時点では、対象となる会員と件数の詳細は確認中とされています。同社はホームページでの告知と会員への個別メールで案内するとしており、準備が整い次第送るという段階でした。RAGTAGに登録したメールアドレスに届く連絡と、公式サイトの告知を確かめてください。届いたメールのリンクではなく、ブックマークや検索から公式サイトを開いて照らし合わせると安全です。

### RAGTAGの情報漏洩でクレジットカード情報は漏れましたか？

開示文は、クレジットカード情報その他の決済情報の流出は確認されていないとしています。顔情報も同じ扱いです。ただし調査は続いており、外部の専門家の調査結果で記載が変わる可能性はあります。念のため、カードの利用明細に身に覚えのない請求がないかを確かめておくと安心です。

### RAGTAGのパスワードは変えたほうがいいですか？

パスワードは、流出の可能性がある項目にも、確認されていない項目にも書かれていません。RAGTAGと同じパスワードをほかのサービスで使っているなら、そちらを先に変えておくことを勧めます。RAGTAG自体のパスワード変更は、公式の告知で案内が出たらそれに従ってください。

### 延べ約120万件というのは、120万人の情報が漏れたということですか？

延べ件数は、同じ人が複数の記録に載っていれば重ねて数えた数なので、実人数はこれより少なくなるのが普通です。開示文も、対象となる会員と件数の詳細は確認中としています。本文の架空データでは、延べ8,511件を名寄せすると4,647人になりました。実人数は続報で示される見込みです。

### RAGTAGの不正アクセスの原因は分かっていますか？

10月30日時点で、侵入経路、悪用された脆弱性、攻撃者は公表されていません。開示文にあるのは、10月17日に業務サーバーへの侵入とデータを抽出する操作が行われ、28日に検知して隔離・遮断したという経緯までです。同社は外部のセキュリティ専門家に調査を依頼し、結果と助言を踏まえて再発防止策を講じるとしています。業績への影響も精査中です。

## 関連記事

- [ブックオフ不正アクセス：約638万人の確認方法](https://www.issoh.co.jp/tech/details/18324/)：同じリユース業で起きた別の事案と会員の確認手順
- [古物営業法とは？三大義務・古物商許可と2026年の改正点をわかりやすく解説](https://www.issoh.co.jp/column/details/18224/)：買取事業者が持つ本人確認記録の要件
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい時に求められる報告と本人通知
- [顧客データ統合の進め方｜名寄せのキー設計とCDPを入れずに済む条件](https://www.issoh.co.jp/column/details/18983/)：延べ件数を実人数に直す名寄せの設計
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：診断を外注するときの判断

---

出典: [RAGTAGの情報漏洩：延べ約120万件の対象項目と会員の備え、侵入から検知まで11日の意味](<https://www.issoh.co.jp/tech/details/19146/>)（株式会社一創）