はじめに
2026年10月31日、旅行会社のクラブツーリズムが、外部からの不正アクセスにより、インターネット会員の個人情報約432万件が漏えいした可能性があると発表しました。公式ホームページは調査と被害拡大防止のために停止され、親会社のKNT-CTホールディングスも11月1日にお詫びを公表しています。
10月は、公式アプリや会員サービスからの大規模な漏えいの公表が相次いだ月でした。個人情報保護委員会が10月28日に示した資料では、不正アクセスによる漏えい等の報告は9月が303件だったのに対し、10月は16日までの半月で830件に達しています(速報値で、報告の受付月ベースの数字です)。
この記事では、クラブツーリズムの事案を整理したうえで、会員サービスで漏えいが繰り返し起きる構造と、発注側として自社で決めておくべきことを、発注側支援の立場から解説します。
何が起きたのか
クラブツーリズムの発表(第1信、10月31日)と報道によると、概要は次のとおりです。
- 2026年10月30日午前5時45分、同社サーバの一部への外部からの不正アクセスを検知した
- 不正アクセスを受けたサーバを隔離し、攻撃元からの通信を遮断した。侵入経路と手段を特定し、問題点を修正したとしている(経路の詳細は公表されていない)
- 漏えいの可能性があるのは、インターネット会員の約432万件。項目は氏名、国籍、性別、生年月日・年齢、住所、電話番号、メールアドレス、会員ID、緊急連絡先
- ログインパスワード、パスポート情報、クレジットカード情報、金融機関口座番号は含まれないとしている。インターネット会員に登録したことがない顧客には影響はない
- 警察に相談し、個人情報保護委員会と監督官庁に報告。対象者には順次連絡するとしている
- 公式ホームページは停止中で、安全性を再確認しだい再開する予定
- 11月1日には、同社を装った不審なメールやSMSが確認されているとして、別途注意を呼びかけている
なお、432万件は「漏えいの可能性」がある件数で、全件の流出が確定したわけではありません。また、同社は2024年11月1日にも、サーバへの不正アクセスにより海外ツアー参加者の情報が漏えいした可能性を公表しています。今回の事案との関係は示されていないため、ここでは「同じ会社で2年前にも不正アクセスの公表があった」という事実にとどめます。
なぜ会員サービスで漏えいが繰り返されるのか
個別の原因は公表されていないため、ここでは特定の会社の話ではなく、会員サービス一般に起きやすい構造を整理します。
会員データは「増える一方」で「減らない」
ネット会員の仕組みは、予約や問い合わせの手間を減らすために作られます。一度登録してもらえば次回以降の入力が省けるので、事業側にとっても顧客にとっても便利です。その結果、会員数は年々積み上がり、何年も利用のない会員の情報も、現役会員と同じデータベースに同じ形で残り続けます。
本人以外の情報まで抱え込む
今回の項目に「緊急連絡先」が含まれている点は見落とせません。旅行では必要な情報ですが、緊急連絡先は多くの場合、会員本人ではなく家族などの第三者の氏名や電話番号です。予約のときだけ必要な情報が、会員情報の一部として常に保存されていると、漏えい時の影響は会員本人を超えて広がります。
再発防止策が「実施済み」で止まる
事故が起きると、侵入経路の修正、監視の強化、委託先への指導といった再発防止策が打たれます。ところが多くの組織では、対策が「実施済み」になった時点で管理が終わり、その対策が数年後も機能しているか、別のシステムにも同じ弱点がないかを確かめる仕組みがありません。担当者の異動や委託先の入れ替わりで、当時の教訓は少しずつ薄れていきます。
発注側が自社で整えておきたい仕組み
ここからは、発注側支援のコンサルタントとして、同じことを自社で起こさないために何を決めておくべきかを整理します。ポイントは「技術的な穴をふさぐ」ことよりも、「穴があっても被害を小さくし、事業を止めすぎない」ための決めごとです。
1. 会員データに「持たない・残さない」のルールを作る
まず、会員サービスで保存している項目を一覧にし、それぞれについて「何のために持っているか」「いつまで必要か」を書き出します。そのうえで、次のようなルールを決めます。
- 予約や申込みのときだけ必要な情報(緊急連絡先、同行者の情報など)は、会員情報には常時保存せず、予約データ側に持たせ、旅行や利用の終了後一定期間で削除する
- 最終利用から一定期間(例:3年)たった会員は、通知のうえ退会扱いとし、個人情報を削除する
- 国籍や生年月日のように、使う場面が限られる項目は、本当に必須かを見直す
退会者や休眠会員のデータが被害を大きくする点は、So-netの会員データベースの事案を取り上げた記事でも整理しています。データは「持っているだけで責任が生じるもの」と捉え、削除の仕組みを要件として委託先に作ってもらうことが大切です。
2. 過去の事故の再発防止策を、毎年「効いているか」で点検する
自社や委託先で過去に起きた事故について、再発防止策の一覧を作り、年に一度、次の観点で点検します。
- その対策は今も運用されているか(担当者や委託先が変わっても続いているか)
- 同じ弱点が、他の会員サイトやキャンペーンサイトにも残っていないか
- 対策の効果を、脆弱性診断の結果やログの確認で裏付けられるか
点検の結果は、情報システム部門だけでなく、事業部門の責任者や経営層にも報告します。「直した」という報告ではなく、「今も効いている」という確認を定期的に残すことで、教訓が組織に定着します。
3. サイトを止める基準と、再開する基準を先に決めておく
今回、クラブツーリズムはホームページを停止しました。被害拡大を防ぐための正しい判断ですが、旅行会社にとってネット予約の停止は売上と顧客対応に直結します。こうした判断を事故当日に一から考えるのは困難です。平時に次の点を決めておきます。
- 停止を判断する権限者(夜間・休日の代理者を含む)と、停止する条件
- 停止中の代替手段(電話・店頭での予約受付、既存予約の問い合わせ窓口)
- 再開の条件(どの調査が終わり、誰が安全性を確認したら再開してよいか)
特に再開の基準は見落とされがちです。基準がないと、早く再開したい事業部門と、慎重に進めたい情報システム部門・委託先の間で判断が長引き、停止期間が延びてしまいます。
4. 委託先・グループ会社と「検知から報告まで」を数字で握る
今回の検知は早朝5時45分でした。夜間や早朝の異常に誰が気付き、誰に連絡が入るのかは、委託先やグループ会社との取り決めしだいです。契約や覚書、グループの規程で次の点を確認しておきます。
- 不正アクセスの疑いを検知してから、発注側(親会社を含む)に報告するまでの時間
- 調査への協力義務と、ログやデータの提出範囲、ログの保存期間
- 年1回以上の脆弱性診断の実施と、その結果の共有
- 再委託先がある場合に、同じ義務を適用すること
親会社の立場であれば、グループ会社が運営する会員サービスも含めて台帳を作り、上の項目がそろっているかを横並びで確認するのが現実的な第一歩です。
5. 顧客と第三者への連絡手順を準備する
漏えい後は、なりすましメールやフィッシングが増えます。対象者への連絡文、問い合わせ窓口、偽の連絡への注意喚起の文面をひな形として用意しておきます。緊急連絡先のように本人以外の情報を持っている場合は、その第三者にどう説明するかも決めておく必要があります。年に一度、「会員データが全件抜かれた」という想定で、事業部門・情報システム部門・広報・委託先を交えた机上訓練をしておくと、連絡網の古さや判断者の不在といった穴が見つかります。
まとめ
クラブツーリズムの会員情報約432万件が漏えいした可能性のある事案は、会員サービスが大量の個人情報、さらには緊急連絡先のような本人以外の情報まで抱え込んでいることを改めて示しました。侵入経路の詳細は公表されていませんが、会員データは増える一方で減らず、再発防止策は「実施済み」で止まりやすいという構造は、多くの企業に共通します。発注側にできるのは、保存する項目と期間を絞り、過去の対策が今も効いているかを毎年点検し、サイトを止める基準と再開する基準を決め、委託先やグループ会社と検知から報告までの時間を数字で握っておくことです。まずは、自社の会員サービスが保存している項目を一覧にし、「本当に持ち続ける必要があるか」を確かめるところから始めてみてください。
参考
- クラブツーリズム「不正アクセスによる個人情報漏えいに関するお詫びとお知らせについて(第1信)」(2026年10月31日)
- KNT-CTホールディングス「グループ会社における不正アクセスによる個人情報漏えいに関するお詫びとお知らせ」(2026年11月1日)
- トラベルボイス「クラブツーリズム、不正アクセスで約432万件の顧客情報が漏えいの可能性、ネット会員の氏名・住所・連絡先など」(2026年11月2日)
- ITmedia NEWS「クラブツーリズムに不正アクセス 個人情報約432万件漏えいの可能性、サイト停止」(2026年11月2日)
- Yahoo!ニュース(テレビ朝日系 ANN)「クラブツーリズム 400万件超の個人情報が漏洩か 自社のサーバーの一部に不正アクセス」
- 個人情報保護委員会「最近の不正アクセスによる個人データの漏えい等の傾向」(第374回委員会 参考資料2、2026年10月28日)
- ScanNetSecurity「クラブツーリズムのサーバに不正アクセス、海外ツアー参加者の個人情報が漏えいした可能性」(2024年11月15日)
執筆者プロフィール:SIer(元請け)とITコンサルファーム(発注側支援)、両方の立場でプロジェクトに従事(通算9年)。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。


コメント