動画制作や店舗向けのWeb予約システムを手がける株式会社ファインズは2026年9月25日、同社が提供する予約システムが第三者から不正アクセスを受け、予約者の情報が漏えいしたと速報で公表しました。対象は1,536,322件で、予約者の氏名、電話番号、メールアドレスに加えて、予約した店舗やメニュー、日時も含まれます。本記事で整理するのは、公式発表に書かれた事実と、まだ書かれていない事項の区別です。そのうえで、この予約システムを使って予約を受け付けていた店舗の側に、どのような報告と本人への通知の義務が及ぶのかを確かめ、店舗が手元のデータで進められる作業をPythonとSQLで示します。
まとめ：ファインズの予約システム不正アクセスで公表された事実と店舗側の対応
確定しているのは次の事実です。ファインズは2026年9月22日にシステムの異常を検知し、調査で第三者による不正アクセスを確認しました。ただちにアクセス遮断などの緊急措置を取り、弁護士と連携して詳細な調査を進めています。対象件数は1,536,322件、対象データは予約者の氏名、電話番号、メールアドレス、予約店舗・メニュー・日時などです。
侵入経路、不正アクセスの開始時期、実際に持ち出されたデータの内訳は、速報の時点で公表されていません。本記事は原因を推測しません。一方で、予約システムは多くの店舗が共同で使う外部サービスです。提供元への攻撃でも、予約を受け付けていた店舗の側に個人情報保護委員会への報告と本人への通知の義務が及ぶ場合があります。店舗はまず、自店の予約者が対象に入っているかを提供元に確かめ、自店分の本人の数を数えてください。
| 項目 | 公表されている内容 |
|---|---|
| 異常の検知 | 2026年9月22日 |
| 公表 | 2026年9月25日（速報） |
| 対象件数 | 1,536,322件 |
| 対象データ | 氏名、電話、メール、予約内容 |
| 侵入経路 | 未公表 |
| 開始時期 | 未公表 |
公式発表を時系列で確認する｜9月22日の異常検知から9月25日の速報公表まで
9月22日の異常検知とアクセス遮断から弁護士と連携した調査まで
ファインズの公式発表（2026年9月25日・速報）によると、2026年9月22日にシステムの異常を検知して調査したところ、第三者による不正アクセスが確認されました。同社はただちにアクセス遮断などの緊急措置を実施しています。調査は弁護士と連携して進めている段階です。
検知から公表までは3日です。発表の題名には【速報】と付いており、新たな事実が判明した場合は追って知らせるとしています。2026年10月7日時点で、同社のニュース一覧に続報は掲載されていません。
個人情報保護委員会への報告と影響範囲の特定・お問い合わせ窓口
今後の対応として、個人情報保護委員会などの関係機関へ報告し、影響範囲の特定とセキュリティ強化を進めるとしています。問い合わせ窓口は同社のお客様対応窓口で、お問い合わせフォームと電話（03-5459-4073、平日9時30分〜18時）が案内されています。
発表には、どの予約システムが対象なのかという名称の記載がありません。同社のサービス一覧には、店舗の空き状況を公開して24時間予約を受け付けるWeb予約システム「TSUNAGUシステム」が掲載されています。ただし今回の対象がこのサービスかどうかは、発表からは確認できません。利用している店舗は、提供元からの連絡で確かめてください。
153万6,322件の対象データと公表されていない侵入経路・開始時期・持ち出しの内訳
氏名・電話番号・メールアドレスに予約店舗とメニューと日時がそろう意味
対象データは、予約者の氏名、電話番号、メールアドレスと、予約店舗・メニュー・日時などです。連絡先だけでなく、どの店で何をいつ予約したかという行動の記録がそろっている点に特徴があります。予約店舗が分かれば、その人の生活圏や通っている業種も推測されます。
対象件数の1,536,322件が、予約の件数なのか人数なのかは発表に書かれていません。予約システムでは同じ人が何度も予約するため、予約の件数と本人の数は一致しないのが普通です。店舗が個人情報保護委員会に報告するときに求められるのは本人の数なので、この違いは後の章の作業に関わります。
侵入経路と不正アクセスの開始時期と実際に持ち出された範囲は調査中
速報で公表されていないのは、侵入経路、悪用された弱点や認証情報の有無、不正アクセスが始まった時期、実際に外部へ持ち出されたデータの範囲です。対象件数はあくまで影響範囲として示された数字で、すべてが持ち出されたと確定したわけではありません。
予約システムを狙った事故は、ほかにも起きています。イエローハットの個人情報流出 最大180万件では、予約システムへの不正プログラムが原因として公表され、グループ全体での是正が進みました。ファインズの事案の原因がどれに近いかは、続報を待つ必要があります。10月5日には、予約サイトのプログラムの脆弱性を起点に基幹システムまで侵入され約105万アカウント分が持ち出されたホワイトエッセンスの不正アクセスも公表されています。
予約者が今やること｜予約店舗やメニューを名乗るSMSとメールのリンクを開かない
予約確認を装う連絡は本物と見分けにくい・別の予約管理システムで起きた実例
予約店舗、メニュー、日時まで知っている攻撃者は、「ご予約内容の確認」「キャンセル料のお支払い」といった、本物とほとんど区別できない連絡を送れます。実際に別の予約管理システムの事案では、藤田観光が2026年10月2日に公表したお知らせによると、宿泊予約者にフィッシングサイトへ誘導する通知が送られたことが、事故の発覚のきっかけになりました。
ファインズの事案で、このような連絡が送られたという公表は2026年10月7日時点でありません。それでも、予約の心当たりがある人ほどリンクを開いてしまいやすい点に注意が必要です。手口と報告件数はフィッシング対策協議会が公開しており、偽サイトの報告先も同協議会のサイトで確認できます。
店舗の公式窓口での予約確認と不審な連絡でのカード情報入力の防止
予約やキャンセルに関する連絡が届いたら、本文のリンクからではなく、店舗の公式サイトや電話番号を自分で調べて確認してください。届いたメッセージの指示でクレジットカード番号やパスワードを入力しないことも大切です。万一入力してしまった場合は、すぐにカード会社へ連絡します。攻撃が成立する仕組みはフィッシング詐欺とはで解説しています。
利用店舗にも報告義務が及ぶ理由｜規則7条3号と委託元への通知による例外の読み方
第三者の提供するサービスへの不正アクセスも件数を問わず報告の対象になる
個人情報保護委員会への漏えい等の報告が必要になる事態は4つあり、そのうち規則7条3号は「不正の目的をもって行われたおそれがある行為」による漏えい等です。個人情報保護委員会の通則ガイドラインの3-5-1は、この行為の相手方に、事業者が個人データを取り扱うに当たって第三者の提供するサービスを利用している場合の当該第三者も含むと明記しています。報告を要する事例の1つめは、不正アクセスによる個人データの漏えいです。
4号の「本人の数が千人を超える」とは別の類型なので、3号に当たれば人数が少なくても報告の対象になります。つまり、予約システムの提供元が不正アクセスを受け、自店の予約者のデータが対象に入っていれば、予約者が数十人の小さな店舗でも報告と本人への通知の義務が及ぶ可能性があります。確報の期限は、3号の事態では知った日から60日以内です。
提供元から通知を受けた店舗が報告と本人通知の主体になる場合の対応
同じガイドラインの3-5-3-2は、個人データの取扱いを委託している場合、原則として委託元と委託先の双方が報告義務を負い、連名で報告できるとしています。そのうえで3-5-3-5は、委託先が委託元に必要な事項を速やかに通知したときは、委託先の報告義務が免除されると定めます。この場合、委託元は遅くとも通知を受けた時点で事態を知ったことになり、速やかに報告しなければなりません。速報の目安は、知った時点からおおむね3〜5日以内です。
本人への通知も同じ構造で、委託元に通知した委託先は本人への通知の義務から外れます。ファインズが自社で報告する形を取っているのか、利用店舗へ通知する形を取っているのかは、発表からは分かりません。提供元から連絡を受けた店舗は、その日付を記録し、自店が報告と本人への通知を行う立場かを提供元に確かめてください。報告の段取りは個人情報保護委員会への報告義務で、報告の記載例は漏えい等の対応とお役立ち資料で確認できます。
予約エクスポートから本人の数を数える｜電話番号とメールで名寄せするPythonの手順
電話番号とメールで予約の件数と本人の数を分けて数える名寄せスクリプト
報告の項目には「本人の数」が含まれ、本人への通知には連絡先の一覧が要ります。予約システムの管理画面から自店の予約データをCSVで書き出せる場合、同じ人の複数の予約を1人にまとめる作業が必要です。次のスクリプトは、電話番号の表記ゆれ（ハイフン、+81）とメールアドレスの大文字小文字をそろえ、電話番号かメールアドレスのどちらかが一致した予約を同じ本人として数えます。Python 3の標準ライブラリだけで動き、列名は書き出したCSVに合わせて書き換えてください。notify_list.pyとして保存します。
import csv, re, sys
from collections import defaultdict
SRC, DST = sys.argv[1], sys.argv[2]
def norm_tel(s):
d = re.sub(r"\D", "", s or "")
if d.startswith("81"):
d = "0" + d[2:] # +81 90-... を 090... にそろえる
return d if len(d) >= 10 else ""
def norm_mail(s):
return (s or "").strip().lower()
rows = list(csv.DictReader(open(SRC, encoding="utf-8-sig")))
parent = list(range(len(rows)))
def find(i):
while parent[i] != i:
parent[i] = parent[parent[i]]
i = parent[i]
return i
first = {}
for i, r in enumerate(rows):
for key in ("t:" + norm_tel(r["電話番号"]), "m:" + norm_mail(r["メールアドレス"])):
if key in ("t:", "m:"):
continue
if key in first:
parent[find(i)] = find(first[key]) # 電話かメールが一致したら同じ本人
else:
first[key] = i
people = defaultdict(list)
for i in range(len(rows)):
people[find(i)].append(rows[i])
with open(DST, "w", newline="", encoding="utf-8-sig") as f:
w = csv.writer(f)
w.writerow(["氏名", "メールアドレス", "電話番号", "予約件数", "連絡手段"])
by = defaultdict(int)
for recs in people.values():
mail = next((norm_mail(r["メールアドレス"]) for r in recs if norm_mail(r["メールアドレス"])), "")
tel = next((norm_tel(r["電話番号"]) for r in recs if norm_tel(r["電話番号"])), "")
how = "メール" if mail else ("SMS・電話" if tel else "連絡先なし")
by[how] += 1
w.writerow([recs[0]["氏名"], mail, tel, len(recs), how])
print(f"予約レコード: {len(rows)}件")
print(f"本人の数（電話・メールで名寄せ）: {len(people)}人")
for k, v in sorted(by.items()):
print(f" 連絡手段 {k}: {v}人")架空の予約3,000件で実行した結果と連絡先のない予約の数え方
2026年10月7日に、架空の予約データで実行した結果です。1店舗の顧客1,200人がのべ3,000件を予約した想定で、電話番号のハイフンの有無や+81表記、メールアドレスの大文字を混ぜ、一部の予約は連絡先の欄を空にしています。
$ python notify_list.py reservations.csv notify.csv
予約レコード: 3000件
本人の数（電話・メールで名寄せ）: 1211人
連絡手段 SMS・電話: 240人
連絡手段 メール: 960人
連絡手段 連絡先なし: 11人3,000件の予約が1,211人にまとまりました。実際の顧客は1,200人なので、差の11人は電話番号もメールアドレスも空の予約で、ほかの予約と結び付けられず1件ずつ1人と数えています。ガイドラインは千人を超えるかの判定で、本人の数を確定できない場合は最大の数で判断するとしています。同じ考え方で、結び付けられない予約は1件1人として扱うのが安全です。出力のnotify.csvは本人への通知の送付先一覧として使えます。予約と顧客を同じIDで持つ設計の考え方は予約システムの顧客管理で整理しています。
予約データを残しすぎない保存期間の設計｜来店から180日を過ぎた個人情報を消すSQL
来店日を基準に氏名・電話番号・メールアドレスだけを消すUPDATE文
予約システムに何年分もの予約が個人情報付きで残っていると、事故のときに対象となる人数がその分だけ増えます。予約の件数やメニューの集計に氏名や連絡先は要りません。そこで、来店日から一定期間を過ぎた予約は、集計に使う列を残したまま個人情報の列だけを消します。次はSQLiteの例で、180日の部分は店舗の業務に合わせて決めます。
-- 保存期間を過ぎた予約の件数を先に確かめる
SELECT CASE WHEN visit_at < date('now', '-180 days') THEN '保存期間超過' ELSE '保存期間内' END AS 区分,
COUNT(*) AS 件数
FROM reservations
WHERE name IS NOT NULL
GROUP BY 区分;
-- 個人情報の列だけを消す（予約日時とメニューは集計用に残る）
UPDATE reservations
SET name = NULL, tel = NULL, email = NULL
WHERE visit_at < date('now', '-180 days')
AND name IS NOT NULL;2026年10月7日に、2024年1月から2026年10月までの架空の予約1万件で実行しました（基準日を固定するため、検証ではnowを2026-10-07に置き換えています）。実行前は保存期間超過が7,557件、保存期間内が2,443件でした。UPDATEで7,557件の個人情報の列が消え、個人情報が残る予約は2,443件になりました。この状態で同じ事故が起きれば、対象は1万件から2,443件へ、およそ4分の1まで減ります。
外部の予約システムでは削除の設定と書き出しの保管場所を確かめる
外部の予約システムを使っている店舗は、このSQLを自分で実行できません。代わりに、過去の予約を自動で削除する設定があるか、退会した顧客のデータがいつ消えるかを提供元に確認します。もう1つの見落としは、店舗が書き出したCSVです。共有フォルダやメールに残ったCSVは、予約システムの外にある複製として事故の範囲を広げます。退会者のデータまで残さない保管の考え方はタイムズカーの不正アクセスと免許証画像160万件の流出でも扱っています。
予約SaaSを使い続ける店舗と自社での管理へ切り替える店舗を分ける判断基準
予約SaaSを使い続ける店舗が事故後に提供元へ確かめる4項目
今回の事故だけを理由に、予約システムの提供元を変える必要はありません。予約の受付を自前で作るより、提供元の運用に任せたほうが安全な店舗も多いからです。使い続ける場合は、次の4項目を提供元に確かめ、回答を記録として残してください。
- 自店の予約者のデータが今回の対象に含まれるか、含まれる場合は件数と項目
- 個人情報保護委員会への報告と本人への通知を、提供元と店舗のどちらが行うか
- 過去の予約と退会者のデータを何日で削除するか、店舗側で設定できるか
- 管理画面のログインに多要素認証を設定できるか、操作のログを店舗が見られるか
2つ目の回答があいまいなまま時間が過ぎると、店舗が報告の期限を逃すおそれがあります。外部サービスの設定とログを点検する手順はSaaSセキュリティ対策の実装手順にまとめています。
予約データを自社の顧客管理と結び付けている店舗が事故後に見直す範囲
予約データを自社の顧客管理システムや会員アプリと連携している店舗は、見直す範囲が広がります。連携のために予約システムへ渡しているAPIキーや、予約システムから受け取ったデータの複製が自社側にもあるためです。提供元の事故をきっかけに、連携の認証情報を入れ替え、受け取ったデータの保存期間も同じ基準でそろえてください。取引先のサービスを経由して被害が広がる構図はサプライチェーン攻撃とはで整理しています。
判断に迷うのは、予約データがどのシステムに何件残っていて、どこから外に取り出せるのかを社内で把握できていない場合です。予約システムと自社システムの間の連携や、管理画面とAPIの認可を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、顧客データへの経路を含めて点検できます。
よくある質問
ファインズの予約システムへの不正アクセスについて、予約者と予約システムを使う店舗の担当者から出やすい質問をまとめました。
自分の予約情報が対象に入っているかはどう確かめればよいですか？
公式発表は対象件数を1,536,322件としていますが、どの店舗の予約が対象かは示していません。心当たりがある場合は、予約した店舗に問い合わせるか、ファインズのお客様対応窓口（お問い合わせフォーム、または03-5459-4073、平日9時30分〜18時）に確認してください。届いたメッセージのリンクからではなく、公式の連絡先を自分で調べて問い合わせることが大切です。
クレジットカード情報やパスワードは漏えいしていますか？
公式発表が挙げている対象データは、予約者の氏名、電話番号、メールアドレス、予約店舗・メニュー・日時などです。クレジットカード情報やパスワードについては、速報には記載がありません。対象データに含まれるとも含まれないとも書かれていないため、続報を待つ必要があります。不審な連絡でカード番号やパスワードを求められても入力しないでください。
対象になった予約システムはTSUNAGUシステムですか？
公式発表には予約システムの名称が書かれていません。ファインズのサービス一覧にはWeb予約システムの「TSUNAGUシステム」が掲載されていますが、今回の対象がこのサービスかどうかは発表からは確認できません。名称や対象の店舗は、続報か提供元から店舗への連絡で明らかになるのを待つことになります。
予約システムを使っていた店舗は個人情報保護委員会に報告が必要ですか？
必要になる可能性があります。通則ガイドラインは、第三者の提供するサービスへの不正アクセスによる漏えい等も、不正の目的によるおそれがある事態として報告の対象に含めています。この類型は人数を問いません。提供元が店舗に通知する形を取った場合は、店舗が報告と本人への通知を行う立場になるため、提供元とどちらが行うかを早めに確かめてください。
店舗はまず何から手を付ければよいですか？
最初に、提供元から連絡を受けた日付と内容を記録します。次に、自店の予約者が対象に含まれるか、報告と本人への通知をどちらが行うかを提供元に確かめます。並行して、予約データを書き出せるなら本記事の名寄せスクリプトで本人の数と連絡先の一覧を作り、予約者には公式の窓口からリンクを含まない形で注意を呼びかけてください。
関連記事
- 焼肉きんぐの不正アクセスと1,078万件の会員情報｜全件規模の流出を防ぐAPIとログの点検：全会員規模の流出を防ぐAPIとログの点検手順
- 大和証券の不正アクセスと約11万人分の口座番号：問い合わせ管理の委託先に残さない設計：委託先のシステムに顧客データが残る構図
- Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：外部サービスの事故で利用者が行う点検
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の段取り
- 予約システムとは？機能・種類・費用と既製サービスで足りない場合の開発判断：予約システムの種類と選び方
