アソビュー、予約管理システム「satsuki」のパートナーアカウントが不正ログイン — 予約者2万7163件が流出

項目	内容
発生日・検知日	2026年5月20日（外部からの不審なアクセスを検知）
公表日	2026年6月22日（Security NEXT報道）
対象組織・業界	アソビュー株式会社（レジャー施設予約サイト「アソビュー」運営／事業者向け予約管理システム「satsuki」提供）
攻撃手法	パートナーアカウントへの不正ログイン、認証情報の悪用による横方向の到達
情報源	Security NEXT（2026年6月22日） / アソビュー株式会社 お知らせ

概要

レジャー施設予約サイト「アソビュー」を運営するアソビュー株式会社は、同社が提供するアクティビティ事業者向け予約管理システムがサイバー攻撃を受け、個人情報が流出したことを公表しました。

流出したのは予約者に関する情報2万7163件で、氏名、生年月日、性別、住所、電話番号、予約情報が含まれます。あわせて取引先111件について、社名、住所、電話番号、代表者氏名、請求担当者氏名、請求先住所、口座情報、メールアドレス、請求書、支払通知書が流出対象となりました。

攻撃の経路として、一部パートナーのアカウントに対する不正ログインが行われ、その後認証情報が悪用されて別のパートナーの予約者情報にも到達したことが説明されています。

経緯

• 2026年5月20日: 外部からの不審なアクセスを検知
• 一部パートナーのアカウントに対する不正ログインが行われ、当該パートナーの予約者情報へのアクセスが発生。さらに認証情報を悪用した別のパートナーの情報へのアクセスも行われた
• 2026年5月21日付: 個人情報保護委員会へ報告
• 警察当局へ相談し、被害届提出の準備を進行
• 2026年6月22日: Security NEXTが報道。予約者2万7163件、取引先111件の流出を公表

原因

パートナーアカウントへの不正ログインが起点であることは公表されていますが、そのアカウントの認証情報が攻撃者にどう渡ったかは明らかにされていません。

考えられる原因（推測）: 事業者向けSaaSのアカウントが侵害される経路としては、(a) パートナー側の担当者がフィッシングで認証情報を入力してしまった、(b) 他サービスから流出した認証情報の使い回しによるリスト型攻撃、(c) パートナー側の端末が情報窃取型マルウェアに感染し保存済み認証情報が抜かれた、が典型です。アソビュー側のシステムではなく「一部パートナーのアカウント」が起点とされている点から、侵害の入口は利用事業者側にあった可能性が考えられます。 さらに深刻なのは、その後「認証情報を悪用して別のパートナーの情報にもアクセスされた」という記述です。これは1つのパートナーの権限で本来到達できないはずの他パートナーのデータに手が届いたことを意味し、テナント間の分離、または認可（どのアカウントがどのデータを読めるか）の検証に隙があった可能性が考えられます。いずれも推測であり、確定した原因は同社の調査結果を待つ必要があります。

対策

組織が学ぶべきこと

1. プラットフォーム事業者の攻撃面は、自社の外側に広がっている

「satsuki」のようなB2Bのシステムでは、ログインするのは自社の従業員ではなく、多数の利用事業者の担当者です。この構造では、自社のセキュリティ水準がどれだけ高くても、最も弱いパートナーのアカウント管理水準が全体の入口になります。 パートナー側にMFAを強制できるか、認証情報の使い回しを検出できるか、異常な時刻・地域からのログインを止められるか——プラットフォーム側が提供する認証の作り方が、そのまま攻撃面の広さを決めます。

2. 「1テナントの侵害」が「複数テナントの流出」に広がる設計は避けられる

本件で最も重い事実は、認証情報の悪用によって別のパートナーの情報にもアクセスされた点です。マルチテナント型のシステムでは、リクエストごとに「このアカウントはこのデータを読む権限があるか」を必ずサーバ側で検証する必要があります。これが画面遷移やIDの推測に依存していると、1アカウントの侵害が全テナントの侵害に等しくなります。被害が2万7163件に達した理由は、侵入の巧妙さではなく、侵入後にどこまで到達できたかにあります。

3. 予約情報は、本人が「どこに行ったか」を含む

流出情報には氏名・生年月日・性別・住所・電話番号に加えて予約情報が含まれます。レジャー施設の予約は、その人が特定の日にどこにいた（いる予定だった）かという行動情報です。加えて取引先111件については口座情報・請求書・支払通知書が対象となっており、これは請求書を装ったなりすまし詐欺（BEC）の材料としてそのまま使えます。個人向けと事業者向けで、二次被害の性質が異なる点に注意が必要です。

ヤグラの視点 — 攻撃面の拡張：「自社の外にあるログイン画面」を誰が守るのか

セキュリティ対策は長く「自社の従業員と自社の設備」を前提に組まれてきました。しかし、事業者向けにシステムを提供する企業では、日々そのシステムにログインしているのは自社の管理下にない人たちです。 本件はまさにその境界で起きています。侵害の起点は「一部パートナーのアカウント」であり、そこから同社が預かる2万7163件の予約者情報に到達しています。

この構造では、責任の所在が曖昧になりがちです。認証情報を失ったのはパートナーであり、データを預かっていたのはプラットフォーム側です。しかし、実際に説明責任を負い、個人情報保護委員会に報告し、被害届を出すのはプラットフォーム側です。であれば、パートナーの認証を「相手の責任」に委ねるのではなく、プラットフォーム側の設計課題として引き受ける必要があります。MFAの必須化、既知の流出パスワードの拒否、通常と異なる場所・時刻からのログインの検知——これらはパートナーの努力ではなく、提供側の実装で決まります。

そして本件のもう一つの教訓は、侵入の検知だけでは足りないことです。同社は5月20日に外部からの不審なアクセスを検知しています。にもかかわらず、認証情報の悪用による別パートナーへの到達までが被害範囲に含まれています。ここで問われるのは、「不正ログインの検知」から「そのアカウントがその後どのデータに触れたか」「別テナントへの越境が起きていないか」を、どれだけ短時間で相関できるかです。

ヤグラのCEOは「マルウェアフリーと呼ばれる、ウイルスを使わずに単純にIDを奪って攻撃を仕掛ける攻撃が増えている」と述べています。本件はその典型で、検体もマルウェアも存在せず、見えるのは正規のアカウントによる不自然なアクセスのログだけです。ヤグラの AI SOC は、Entra ID・Okta・AD等のアイデンティティ基盤やクラウド環境のログを集約し、AIが横断して相関することで「奪われたIDがどこまで到達したか」を短時間で切り分けることを目指す製品です。攻撃面が自社の外に広がっている事業では、境界での防御より、IDの振る舞いを見る監視の比重が上がります。

今後の対応

同社は個人情報保護委員会への報告を完了し、警察当局へ相談のうえ被害届提出の準備を進めています。パートナー事業者・予約者への個別通知の状況、および認証・認可設計の見直しについて続報が想定されます。取引先情報については口座情報・請求書類が流出しているため、請求書を装った詐欺への警戒が必要です。

更新履歴

日時	内容
2026-06-22	初稿公開（Security NEXT報道日時点）