ファインズの店舗向け予約システムへの不正アクセス（予約者情報1,536,322件が対象）
公表日
お店向けの予約システムを提供するファインズが不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。を受け、予約した人の氏名や連絡先、予約の内容など1,536,322件が対象になりました。実際にどこまで持ち出されたかは、まだ公表されていません。
対象者は？
ファインズの予約システムを使っているお店で予約をした方です。氏名・電話番号・メールアドレスと、予約したお店・メニュー・日時が対象です。どの予約システムなのか、どのお店が使っていたのかは公表されていません。クレジットカード情報やパスワードが含まれるかどうかも、お知らせには書かれていません。
自分が対象かどうかを調べる方法は、まだ案内されていません。ファインズにはWebフォームと電話（平日9:30〜18:00）の問い合わせ窓口があります。
いますぐできること
- お店を名乗って「ご予約の件で」と連絡するメールやSMSのリンクは開かず、お店の公式サイトや電話番号に自分から確認する
- 予約日時やメニューなど本当の内容が書かれていても、それだけで本物と判断しない
- 知らない番号からの電話で、個人情報や支払いを求められても応じない
何が起きたのか
2026年9月22日、ファインズは自社が提供する予約システムで異常に気づき、調べたところ第三者による不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。が確認されました。会社はアクセスを遮断するなどの緊急の対応を行い、弁護士と一緒に詳しい調査を始めました。9月25日には速報として、予約者の情報1,536,322件が対象になったと発表しました。
なぜ起きたのか・なぜ広がったのか
どこから、どのように侵入されたか、いつから不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。が始まっていたかは、まだ公表されていません。対象の件数が大きいのは、1つの予約システムを多くのお店が共同で使っていて、そのお店の予約者の情報が1か所に集まっていたためです。
いまの状況2026-09-25 時点続報待ち
9月25日の速報のあと、続報は出ていません。侵入の経路、実際に持ち出された範囲、システムの名前、使っていたお店の数、お店への連絡の状況は、まだ発表されていません。会社は個人情報保護委員会などに報告するとしています。
企業として考えたいこと
自社のお客様の情報を、予約や会員管理などの外部サービスに預けていないでしょうか。その提供元が攻撃を受けたとき、お客様に誰がどう知らせるかを決めているでしょうか。
技術的な要約
動画制作・集客支援を手がける株式会社ファインズ（東証グロース）は、2026年9月22日に同社が提供する予約システムの異常を検知し、調査の結果、第三者による不正アクセスを確認した。同社はアクセス遮断などの緊急措置を行い、弁護士と連携して詳細調査を進めている。9月25日の【速報】では、対象を1,536,322件とし、予約者の氏名・電話番号・メールアドレスと予約店舗・予約メニュー・予約日時などが含まれるとした。侵入経路、不正アクセスの開始時期、実際に持ち出された範囲、対象システム名、導入店舗数は公表されていない。2026年10月10日時点で同社ニュース一覧に続報はなく、導入店舗側の公表も確認できなかった。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 不明公式発表は『弊社が提供する予約システムにおいて異常を検知し、調査の結果、第三者による不正アクセスを確認』とするのみで、侵入経路（Webアプリの脆弱性、管理画面の認証情報流用、クラウド設定不備、委託先経由など）は非公表。報道（セキュリティ対策Lab、一創）も侵入経路・攻撃者・開始時期は未公表と整理しており、報道ベースの経路情報も確認できなかった。
- 脆弱性
- CVE 非公表不明ファインズ提供の店舗向け予約システム（名称非公表）脆弱性悪用の有無、製品・コンポーネント名、CVEはいずれも非公表（2026-10-10時点）。自社開発システムか外部製品・OSSの組込みかも不明。
- 攻撃者
- 特定・主張なし
- ATT&CK
- —
影響
- 業務停止
- なし 『アクセス遮断などの緊急措置』を実施したと公表されているが、予約システム自体の停止や導入店舗の予約受付への影響の有無・期間は公表されていない。
- データ
- おそれ上限 1,536,322確定 —件氏名電話メールその他（予約店舗・予約メニュー・予約日時）公表文のタイトルは『情報漏えいについてのお詫び』だが、本文は対象件数1,536,322件を示すにとどまり、全件が外部へ持ち出されたとは説明していない（セキュリティ対策Labの整理）。件数が予約件数か予約者数（名寄せ後）かは不明。クレジットカード情報・予約システムのパスワードが対象に含まれるかは記載がない。導入店舗別・業種別の内訳も非公表。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- ファインズは店舗向け予約システムの提供者（SaaS／個人情報の取扱い委託先）で、漏えい対象は導入店舗の顧客である予約者の情報（予約店舗名を含む）。したがって被害は多数の導入店舗（委託元）に波及する構造だが、導入店舗数・店舗名・業種は非公表で、2026-10-10時点で導入店舗側の公表は確認できなかった。一創の解説記事は、提供元への攻撃でも店舗側に個人情報保護委員会への報告・本人通知義務が及びうること、委託先が委託元へ速やかに通知すれば報告義務は委託元に移ることを指摘している。
時系列
技術解説
公表された事実：速報1本のみ 事実
ファインズの公表は2026年9月25日の【速報】1本で、内容は(1)9月22日に予約システムの異常を検知し第三者の不正アクセスを確認、(2)アクセス遮断などの緊急措置と弁護士と連携した調査、(3)対象1,536,322件、予約者の氏名・電話番号・メールアドレス・予約店舗・予約メニュー・予約日時、(4)個人情報保護委員会等への報告、影響範囲特定とセキュリティ強化、の4点に限られる。侵入経路・開始時期・攻撃者・持ち出しの確定範囲・対象システム名・導入店舗数はいずれも記載がない。同社ニュース一覧では10月10日時点まで続報は掲載されておらず、攻撃者の犯行声明や研究者の分析も確認できなかった。
SaaS提供者と導入店舗の関係：誰が通知するのか 解釈
漏えい対象の大半は、ファインズ自身の顧客ではなく、予約システムを導入した店舗の顧客（予約者）である。個人情報保護法上はファインズが委託先、各店舗が委託元という整理になるのが通常で、委託先が委託元に速やかに通知すれば報告・本人通知の主体は委託元である店舗側になる（一創の解説）。しかし公表文は導入店舗への通知状況に触れておらず、店舗側の公表も見当たらない。予約者からすると、自分の情報がどの予約システムに預けられていたかを知る手段が乏しく、店舗が通知しない限り自分が対象かを判断できない。150万件規模で導入店舗側の発表が表に出てこないこと自体が、この構造の弱点を示している（ここまでの評価は解釈）。
予約データの二次被害リスク 解釈
漏えい項目は氏名・連絡先に加え、どの店舗でいつ何を予約したかという行動情報である。カード番号やパスワードは含まれないとみられる（記載なし）が、『○月○日に△△店で□□メニューを予約した』という具体的な文脈は、店舗を装ったSMS・メールによるフィッシングの信憑性を大きく高める。セキュリティ対策Labも、予約内容を含む連絡を装う詐欺への注意を促している。また業種によっては、予約メニュー自体（美容医療、整体、エステなど）が本人にとって知られたくない情報になりうる。対象システムの業種構成が非公表であるため、どの程度の機微性を持つかは評価できない（解釈）。
対応
- 封じ込め
- 9月22日の検知後、アクセス遮断などの緊急措置を実施。弁護士と連携して詳細調査を継続し、影響範囲の特定とセキュリティ強化を進めるとしている。具体的な技術対策（脆弱性修正、認証情報リセット、外部フォレンジック等）は非公表。
- 公表の仕方
- 検知から3日後の9月25日に【速報】として公表。件数と項目は示したが、システム名・侵入経路・導入店舗への通知状況は記載なし。問い合わせ窓口はWebフォームと電話（平日9:30〜18:00）。10月10日時点で続報なし。
- 当局対応
- 個人情報保護委員会：関係機関とあわせて報告する方針を表明（報告日・受理状況は未公表）
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 予約SaaSは多数店舗の顧客データを一か所に集約しており、単一侵害で100万件規模に達する | テナント（導入店舗）単位で論理分離し、管理者・サポート用の横断検索や一括エクスポートAPIは用途を限定。1セッション/1APIキーあたりの取得件数上限と、テナント横断アクセスの監査ログ・アラートを実装する |
| 侵入経路・開始時期が非公表で、導入店舗が自社顧客への影響を判断できない | アプリ・DB・管理画面のアクセスログを最低1年保持し、テナントIDと参照件数を記録。インシデント時にテナント別の影響件数を即座に集計できるクエリ・手順を平時に用意しておく |
| 委託元（店舗）への通知と本人通知の役割分担が不明確 | SaaS利用規約・委託契約に、漏えい時の通知期限（例：確認から24〜72時間）、提供するデータ（テナント別件数・項目・期間）、本人通知・PPC報告の主体と連名報告の手順を明記しておく |
| 予約日時・店舗・メニューを含む情報はフィッシングの材料になる | 予約確認・変更の連絡では外部リンクを最小化し、送信ドメイン認証（SPF/DKIM/DMARC p=reject）とSMS送信元の登録を徹底。漏えい時は店舗と共同で『当店からこの形式の連絡はしない』旨を告知するテンプレートを用意する |
自組織などでの確認項目
- あなたの会社が使っている予約・顧客管理SaaSが侵害された場合、提供者から何時間以内に、どの粒度（自社分の件数・項目・期間）で情報を受け取れる契約になっているか。
- 提供元が公表しても自社が公表しなければ、顧客は自分が対象かを知る術がない。SaaS側の事故で自社顧客の情報が漏えいしたとき、誰が・いつ本人通知とPPC報告を行うかを決めているか。
- 自社が複数の顧客企業のデータを預かるSaaSを提供している場合、1つの管理者アカウントやAPIキーで全テナントのデータを取得できる経路は残っていないか。
未解明点
- 対象となった予約システムの名称（TSUNAGUシステムか否か）と導入店舗数・業種
- 侵入経路（脆弱性、認証情報流用、設定不備等）と不正アクセスの開始時期
- 1,536,322件が予約件数か人数か、実際に持ち出された（確定）件数
- 導入店舗への通知状況と、店舗側による本人通知・個人情報保護委員会報告の有無
- 予約システムの停止有無と、カード情報・パスワード等の他の情報が対象外であるかの明示
出典
- 1株式会社ファインズ2026-09-25公式本文確認済
- 2株式会社ファインズ2026-10-05公式本文確認済
- 3株式会社ファインズ公式本文確認済
- 4日本取引所グループ2022-09公式本文確認済
- 5セキュリティ対策Lab（Rocket Boys）2026-09-28報道本文確認済
- 6株式会社一創2026-10-07報道本文確認済
- 7SmartScope2026-10-05報道本文確認済