ドトールコーヒーは2026年10月26日、社内システムへの不正アクセスにより、4店舗に勤務していた従業員と退職者の計951名の個人データが外部へ流出した可能性があると公表しました。項目には氏名・住所に加えて銀行口座番号が含まれます。お客様の情報への不正アクセスは確認されていません。前半では公表文をもとに、自分が対象かどうか、退職者への知らせ方、口座番号が漏れたときに気をつける連絡を整理しました。後半では、店舗の勤怠や給与のシステムから口座番号と保存期間を過ぎた退職者のデータを外すと、読まれたときの件数がどう変わるかをPythonで確かめます。
まとめ：ドトールの不正アクセスで従業員と退職者に起きたことと起きていないこと
ドトールコーヒーのニュースリリースによると、同社は10月20日に社内システムへの不正アクセスを検知しました。そのシステムに保存されていた従業員と退職者の個人データが第三者に閲覧され、外部へ流出した可能性があります。対象は特定の4店舗に勤務していた人に限られ、店を利用したお客様は対象ではありません。
現役の従業員には会社から順次連絡が届きます。退職者には個別の連絡ではなく、このニュースリリースが通知の代わりです。二次被害は確認されていませんが、口座番号と電話番号、住所がそろって出た可能性があるので、銀行や会社を名乗る連絡には慎重になってください。
| 項目 | 公表内容（2026年10月26日時点） |
|---|---|
| 検知 | 2026年10月20日、社内システムへ不正アクセス |
| 対象者 | 4店舗に勤務していた従業員と退職者の計951名 |
| 項目 | 氏名・生年月日・住所・メール・電話・銀行口座番号 |
| お客様の情報 | 不正アクセスは確認されず |
| 二次被害 | 確認されず |
| 知らせ方 | 従業員は順次連絡、退職者は公表で通知 |
| 未公表 | 侵入経路・システムの種類・補償 |
対象の従業員・退職者が確かめること：4店舗の範囲、口座番号、不審な連絡
西武大泉学園駅店など4店舗の勤務経験で決まる対象範囲と客の扱い
対象は、次の4店舗に勤務していた従業員と退職者です。ドトールコーヒーショップの西武大泉学園駅店、国立大学通り店、東京駅八重洲中央口店、石神井公園駅前店の4つです。アルバイトとして短期間だけ働いた人や、何年も前に辞めた人も、公表文の書き方では「退職者」に含まれます。
ほかの店舗だけで働いていた人は、今回の公表の範囲には入っていません。公表文はお客様の情報への不正アクセスは確認されていないとしているので、これらの店で買い物をしただけの人も対象外です。自分がどの店舗に登録されていたか分からないときは、給与明細や雇用契約書の勤務先欄で確かめられます。
退職者には個別連絡が届かない、公表文が通知の代わりになる理由
公表文は、現役の従業員には順次連絡し、退職者には本公表をもって知らせるとしています。辞めた人の住所や電話番号は、引っ越しや番号の変更で古くなっていることが多く、全員に確実に届ける手段がありません。個人情報保護法の第26条第2項は本人への通知を義務づけたうえで、ただし書で、通知が困難な場合は本人の権利利益を守るための代わりの措置でよいとしています。退職者向けの公表は、この代わりの措置にあたると読めます。
裏返すと、退職者は自分から公表文を見に行かない限り、対象になったことを知る機会がありません。元同僚や家族がこの4店舗で働いていたなら、このニュースを伝えてあげてください。問い合わせは公表文に載っているメールの窓口だけで、電話の窓口は設けられていません。
銀行口座番号だけで引き出しはされない、警戒すべきは口座を口実にした連絡
口座番号が知られただけで、預金を引き出されることはありません。引き出しや振込には、キャッシュカードと暗証番号、またはネットバンキングのIDとパスワードが要ります。今回の項目には、暗証番号やパスワードは含まれていません。
気をつけたいのは、口座番号を知っていることを信用の材料にした連絡です。「お客様の口座が不正利用されています」と口座番号を読み上げる電話や、氏名と住所入りの「給与振込先の確認」のメールが届くと、本物だと思いやすくなります。銀行が電話で暗証番号を聞くことはありません。会社や銀行を名乗る連絡は、届いた番号やリンクではなく、自分で調べた公式の窓口にかけ直して確かめてください。偽の連絡が通る仕組みはフィッシング詐欺の成立の仕組みと技術的対策にまとめました。
公表文から読む事案の構造：店舗システムの従業員情報と報告・通知の義務
4店舗で951名、人数の多くは退職者と読める店舗の人の入れ替わり
1店舗あたりにすると、平均で約240名です。カフェ1店舗で同時に働く人数としては多く、これまでに働いた人が累積していると考えるほうが自然です。公表文が従業員と退職者を並べて書き、退職者への知らせ方を別に定めているのも、そうした構成を示しています。ただし、内訳は公表されていません。
アルバイト中心の店舗は人の入れ替わりが速く、勤怠やシフトの仕組みに登録された人は年ごとに増えていきます。辞めた人の記録を消す運用が無ければ、システムの中では、現役よりも退職者のほうが多い状態になるということです。後半の再現では、この点を数字で確かめます。
公表文の4項目は個人情報保護法施行規則10条の通知事項に沿った書き方
公表文は「本件の概要及び原因」「漏えいが発生したおそれがある個人データの項目」「二次被害又はそのおそれの有無及びその内容」「その他」の4つで組まれています。この並びは、個人情報保護法施行規則の第10条が本人への通知で求める事項（概要、項目、原因、二次被害のおそれ、その他参考となる事項）とほぼ同じです。
同じ規則の第7条第3号は、不正の目的をもって行われたおそれがある行為による漏えいを、件数にかかわらず委員会への報告の対象にしています。外部からの不正アクセスは、この報告対象にあたる行為です。第8条により、知った後に速やかに速報を出し、この類型では60日以内に確報を出すことになります。手続きの全体は個人情報保護委員会への報告義務の実務で解説しました。委員会の案内は漏えい等の対応とお役立ち資料のページにまとまっています。
大規模な顧客情報の漏えいとの違い、焼肉きんぐ・銀のさらとの比較
10月には飲食チェーンの漏えいが続きました。焼肉きんぐの不正アクセスは1,078万件、銀のさらの不正アクセスは最大650万件と、いずれも会員や注文客の情報です。ドトールの件は951名と桁が小さく、対象は客ではなく働く人に限られます。
件数が小さくても、項目の重さは違います。顧客の会員情報には口座番号が入ることは少ない一方、給与を振り込む相手である従業員の情報には口座番号が入ります。従業員は、勤務先を選び直すことで情報の扱いを避けることもできません。チェーンの本部は、顧客向けのシステムと同じ目線で、店舗の人事や勤怠の仕組みを点検する必要があります。
開発側の教訓：店舗側システムから口座番号と保存期間切れの退職者を外す設計
退職から5年の保存義務と、使わなくなったデータを消す努力義務の両立
ここから先は、ドトールのシステムがどう作られていたかを推測するものではありません。店舗の勤怠・シフト・給与を扱うシステム全般の話です。退職者のデータを残す根拠は、労働基準法の第109条にあります。労働者名簿や賃金台帳を5年間保存する義務で、附則第143条により当分の間は3年です。起算日は労働基準法施行規則の第56条が書類ごとに定め、労働者名簿は退職の日、賃金台帳は最後に記入した日などです。
一方で個人情報保護法の第22条は、利用する必要がなくなった個人データを遅滞なく消すよう努めることを求めています。保存の義務は「その期間は消してはいけない」で、期間後も持ち続けてよいという意味ではありません。給与明細の側から見た保存期間の考え方は給与明細の保管期間と退職者データの設計にまとめました。
口座番号を給与側へ移し保存期間後の退職者を消すPythonとSQLiteの再現
次のコードは標準ライブラリだけで動きます。Pythonのsqlite3で架空の4店舗の勤怠システムを作り、2011年から毎年8〜14人を採用し、在籍は平均2年という人の入れ替わりを乱数で再現しました。給与側は別のデータベースとしてATTACHし、店舗側を読まれたときに持ち出される件数を、対策の前後で数えています。
# 店舗の勤怠・シフト系システムに従業員情報を溜め続けた場合と、
# 口座番号を給与側へ切り離し・保存期間を過ぎた退職者を消した場合で、
# 店舗側システムが読まれたときに持ち出せる件数を比べる（Python 3.8以上・標準ライブラリのみ）
# 使い方: python staff_exposure.py
import random
import sqlite3
from datetime import date, timedelta
TODAY = date(2026, 10, 20) # 不正アクセスを検知した日に合わせる
KEEP_YEARS = 5 # 退職後の保存年数（労基法109条の5年に合わせた社内規程の想定）
rnd = random.Random(2026)
db = sqlite3.connect(":memory:")
db.execute("ATTACH ':memory:' AS payroll") # 給与側は別システム（別DB・別権限）として扱う
db.executescript("""
CREATE TABLE staff (id INTEGER PRIMARY KEY, store TEXT, hired TEXT, retired TEXT,
name TEXT, birth TEXT, address TEXT, email TEXT, phone TEXT, bank TEXT);
CREATE TABLE payroll.bank (staff_id INTEGER PRIMARY KEY, bank TEXT);
""")
# 4店舗 x 2011〜2026年。毎年8〜14人を採用し、在籍は平均2年前後のアルバイト中心の店舗を想定
sid = 0
for store in ["A", "B", "C", "D"]:
for year in range(2011, 2027):
for _ in range(rnd.randint(8, 14)):
sid += 1
hired = date(year, 1, 1) + timedelta(days=rnd.randint(0, 364))
if hired > TODAY:
continue
stay = int(rnd.expovariate(1 / 730)) # 在籍日数の平均730日
retired = hired + timedelta(days=stay)
retired_s = None if retired >= TODAY else retired.isoformat()
db.execute("INSERT INTO staff VALUES (?,?,?,?,?,?,?,?,?,?)",
(sid, store, hired.isoformat(), retired_s, f"name{sid}", "2000-01-01",
"addr", f"mail{sid}", "090", f"{rnd.randint(0, 9999999):07d}"))
def leak():
# 店舗側システムを読まれたときに持ち出される件数（在籍者・退職者・口座番号つき）
rows = db.execute("SELECT retired IS NULL, bank IS NOT NULL FROM staff").fetchall()
active = sum(1 for a, _ in rows if a)
return {"total": len(rows), "active": active, "retired": len(rows) - active,
"with_bank": sum(1 for _, b in rows if b)}
print("[before] ", leak())
# 対策1：口座番号は給与側へ移し、店舗側には下4桁だけを残す
db.execute("INSERT INTO payroll.bank SELECT id, bank FROM staff")
db.execute("UPDATE staff SET bank = NULL")
db.execute("ALTER TABLE staff ADD COLUMN bank_last4 TEXT")
db.execute("UPDATE staff SET bank_last4 = (SELECT substr(bank, -4) FROM payroll.bank WHERE staff_id = staff.id)")
print("[split] ", leak())
# 対策2：退職から保存年数を過ぎた人を店舗側から消す
limit = date(TODAY.year - KEEP_YEARS, TODAY.month, TODAY.day).isoformat()
gone = db.execute("DELETE FROM staff WHERE retired IS NOT NULL AND retired < ?", (limit,)).rowcount
print("[purge] ", leak(), "deleted:", gone)
# 給与振込の処理だけが給与側の口座番号を引ける（店舗側の権限からは見えない前提）
print("[payroll]", db.execute("SELECT COUNT(*) FROM payroll.bank").fetchone()[0], "rows kept in payroll")Python 3.14.7（SQLite 3.50.4・Windows）で実行した結果です。乱数のシードを固定しているので、同じ版なら同じ数字になります。
$ python staff_exposure.py
[before] {'total': 700, 'active': 87, 'retired': 613, 'with_bank': 700}
[split] {'total': 700, 'active': 87, 'retired': 613, 'with_bank': 0}
[purge] {'total': 322, 'active': 87, 'retired': 235, 'with_bank': 0} deleted: 378
[payroll] 700 rows kept in payroll実行結果の読み方、700件のうち現役は87件で口座番号は0件に下がる
1行目は、何も手を入れずに16年分を溜めた状態です。店舗側に700件があり、そのうち現役は87件、退職者が613件です。全件に口座番号が付いています。この想定でも、店舗側を読まれると在籍者の約8倍の退職者の情報が一緒に出ていきます。
2行目は、口座番号を給与側へ移し、店舗側には照合用の下4桁だけを残した状態です。件数は700件のままですが、口座番号つきの件数は0件になりました。シフトの管理や出退勤の打刻に口座番号は要りません。3行目は、退職から5年を過ぎた378件を店舗側から消した状態で、残りは322件です。現役87件は1件も減っていません。最後の行が示すように、口座番号は給与側に700件残るので、給与側にも同じ保存期間の削除を入れる必要があります。
暗号化は報告義務の扱いまで変える、口座番号の列は鍵を分けて守る
切り離した先の給与側も、読まれれば同じことが起きます。そこで効くのが列単位の暗号化です。個人情報保護法施行規則の第7条は、報告の対象になる個人データから「高度な暗号化その他の個人の権利利益を保護するために必要な措置を講じたもの」を除いています。鍵を同じサーバーに置いていれば、この措置にはあたらないと考えてください。
実装では、暗号化の鍵をデータベースとは別の鍵管理サービスに置き、振込データを作る処理だけが復号できる権限にします。共通鍵と公開鍵の使い分けは暗号化の種類と守るべきデータの判断で解説しています。店舗の端末や管理画面を外部から呼べるAPIで作っているなら、入口の認可とレート制限も合わせて見直してください。手順はAPI不正アクセス対策の実装手順で扱っています。
事業者の判断：勤怠・シフト・給与のデータ配置を外部診断で見直す条件
店舗側に口座番号と古い退職者が残るなら、外部診断で店舗系を優先して見る
チェーンの本部は、顧客向けのECサイトや会員アプリは定期的に診断していても、店舗の勤怠やシフトの仕組みは製品を入れたまま点検していないことが多くあります。働く人の情報は、客の情報より件数が小さいぶん後回しにされがちです。
次のどれかに当てはまるなら、店舗系のシステムを外部の脆弱性診断で優先して見てもらってください。店舗の管理画面から従業員の口座番号が見えること。退職から5年以上たった人のデータが削除されずに残っていること。店長やエリア担当が使うアカウントに、多要素認証が入っていないことです。どれにも当てはまらず、口座番号が給与側で暗号化され、退職者の削除が定期的に動いているなら、診断は年1回の定期点検で足ります。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準で解説しています。
自社の店舗系・人事系のシステムに同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
ドトールの不正アクセスについて、従業員や退職者から出やすい質問をまとめました。
ドトールの店を利用しただけでも対象になりますか？
なりません。ドトールコーヒーの公表文は、お客様の情報への不正アクセスは確認されていないとしています。対象は、西武大泉学園駅店、国立大学通り店、東京駅八重洲中央口店、石神井公園駅前店の4店舗に勤務していた従業員と退職者の計951名です。店で買い物をしたり、アプリを使ったりしただけの人は含まれません。
何年も前に辞めたアルバイトですが、連絡は来ますか？
個別の連絡は来ないと考えてください。公表文は、退職者には本公表をもって知らせるとしています。上の4店舗のどれかで働いたことがあれば、在籍期間の長さにかかわらず対象に含まれる可能性があります。対象かどうかを確かめたいときは、公表文に載っているメールの窓口へ問い合わせてください。
銀行口座番号が漏れたら口座を変えるべきですか？
口座番号だけでは預金は引き出せないので、すぐに解約する必要はありません。暗証番号やネットバンキングのパスワードは今回の項目に入っていません。気になる場合は、通帳やアプリで身に覚えのない入出金が無いかを確かめ、銀行を名乗る電話で暗証番号を聞かれても答えないでください。不安が残るなら、取引銀行の窓口で相談できます。
ドトールから補償やお詫びはありますか？
10月26日の公表文には、補償やお詫びの品についての記載はありません。公表文は、新たにお知らせすべき事項が判明した場合は速やかに知らせるとしています。補償をうたうメールやSMSが届いても、リンクは開かず、ドトールコーヒーの公式サイトのニュースリリース一覧に同じ内容が載っているかを先に確かめてください。
原因や侵入経路はもう分かっていますか？
公表されていません。公表文の「本件の概要及び原因」の項は、システムが外部の第三者から不正アクセスを受けたという事実だけを書いています。どのシステムで、どんな方法で侵入されたかは、10月30日時点で追加の発表がありません。同社は被害拡大を防ぐ措置をとり、事実関係の調査と個人情報保護委員会への報告を進めているとしています。
関連記事
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：不正目的の漏えいで求められる報告と本人通知の手順
- 給与明細の保管期間：会社の保存義務と賃金台帳の5年・起算日・電子保存と退職者データの設計：退職者のデータをいつまで残し、いつ消すか
- 焼肉きんぐ不正アクセスで1,078万件の情報漏洩｜対象の確認方法・原因と運営側のAPI点検：同じ10月に起きた飲食チェーンの顧客情報の事案
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：店舗の管理画面やAPIの入口を固める手順
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：口座番号を口実にした偽の連絡が通る仕組み
