チケプラで他人の個人情報が表示される事象、最大107名に影響の可能性―Webキャッシュ設定変更が原因

株式会社チケットプラスは2026年10月1日、電子チケットサービス「チケプラ」で、一部利用者の画面に別の利用者の個人情報が一時的に表示される事象が発生したと公表しました。

原因は、アクセス集中時の負荷軽減を目的として9月28日に実施したWebページのキャッシュ設定変更です。一定の条件下で同じ対象ページへ同じタイミングでアクセスした場合、本来表示される本人の情報ではなく、別の利用者の情報が表示される状態になっていました。

自身の情報が別の利用者に表示された可能性があるのは最大107名、自身の画面に別の利用者の情報が表示された可能性があるのは最大322名です。

表示された可能性がある情報には、氏名、メールアドレス、郵便番号、住所、電話番号、クレジットカード番号の下4桁、Plus member IDなどが含まれます。クレジットカード番号の全桁やパスワードが表示される事象は確認されていません。

チケプラの個人情報誤表示のサマリー

• チケットプラスは2026年10月1日、チケプラで別の利用者の情報が表示される事象を公表しました。
• 原因は9月28日7時に実施したWebページのキャッシュ設定変更です。
• 影響が生じた可能性がある期間は9月28日7時から9月29日22時35分までです。
• 最大107名について、自身の情報が別の利用者に表示された可能性があります。
• 最大322名について、自身の画面に別の利用者の情報が表示された可能性があります。
• 表示された可能性がある情報には、氏名、住所、電話番号、メールアドレス、クレジットカード下4桁などが含まれます。
• クレジットカード番号全桁やパスワードが表示される事象は確認されていません。
• チケプラアプリとチケプラトレードは対象外です。
• 9月29日22時35分にサービスを停止し、9月30日7時に原因を解消してサービスを再開しました。
• 本件以外の同様の誤表示、不正アクセス、データベース改ざんは確認されていません。
• 10月1日時点で、本事象に起因する個人情報の不正利用などの二次被害は確認されていません。

アクセス集中対策のキャッシュ設定変更後に誤表示

チケットプラスは9月28日7時、チケプラサイトへのアクセス集中時の負荷を軽減するため、Webページのキャッシュに関する設定を変更しました。

その後、同じ対象ページへ複数の利用者が同じタイミングでアクセスした場合に、別の利用者向けに生成された情報が表示される場合があることが判明しました。

9月29日21時40分頃、利用者からログイン後に「他の人の情報が表示される」との問い合わせがあり、同社が調査を開始しています。

同日22時35分にはチケプラを緊急メンテナンスとして停止しました。

原因となった設定を修正し、同様の事象が発生しないことを確認したうえで、9月30日7時にサービスを再開しています。

最大107名の個人情報が別の利用者に表示された可能性

チケットプラスは、9月28日7時から9月29日22時35分までに対象ページへアクセスし、一定の条件下でアクセスが重なった利用者について影響を調査しました。

その結果、

• 自身の情報が別の利用者に表示された可能性がある利用者：最大107名
• 自身の画面に別の利用者の情報が表示された可能性がある利用者：最大322名

としています。

107名と322名は異なる意味の数字です。

107名は「情報を見られた側」の最大人数、322名は「他人の情報が画面に表示された側」の最大人数を示しており、単純に合算して「429名分の個人情報が漏えいした」とすることはできません。

対象となる可能性のある利用者には、10月1日に個別の案内メールを送付しています。

氏名・住所・電話番号・カード下4桁などが表示された可能性

誤表示された可能性がある情報は、アクセスしたページによって異なります。

チケット申込み・購入手続きの画面遷移

• 氏名（漢字・フリガナ）
• メールアドレス
• 郵便番号
• 住所
• 電話番号
• クレジットカード番号の下4桁

利用ガイドからマイページへの画面遷移

• Plus member ID
• メールアドレス

チケットプラスは、クレジットカード番号の全桁やパスワードが表示される事象は確認していないとしています。

また、チケプラアプリと公式チケットトレードサービス「チケプラTrade」は今回の対象外です。

クレジットカード下4桁だけでカード決済できるわけではない

今回表示された可能性があるクレジットカード情報は下4桁です。

個人情報保護委員会は、クレジットカード番号全体が漏えいした場合は財産的被害が生じるおそれのある漏えいに該当するとしています。

一方、クレジットカード番号の下4桁と有効期限の組み合わせについては、それだけで直ちに同じ基準へ該当するものではないとの見解を示しています。

今回、チケットプラスはカード番号全桁やパスワードの誤表示を確認していません。

ただし、氏名、住所、電話番号、メールアドレスなど複数の情報とカード下4桁が同時に表示された可能性があります。

これらの情報を組み合わせることで、実際のサービス利用者を知っているように装ったフィッシングメールや電話などに利用される可能性はあります。

10月1日時点で、本事象に起因する個人情報の不正利用などの二次被害は確認されていません。

不正アクセスではなくキャッシュ設定による情報誤表示

今回の事案では、第三者がチケプラへ不正侵入してデータベースから情報を取得したとは公表されていません。

チケットプラスは、自社管理下のシステムを調査した結果、

• 対象箇所以外で同様の情報表示が発生した事象
• 不正アクセス
• データベースの改ざん

は確認されていないとしています。

原因として公表されているのは、アクセス集中時の負荷軽減を目的として変更したWebキャッシュの設定です。

そのため、今回の事象は外部からのサイバー攻撃を起点とした情報漏えいではなく、システム設定変更によって本来ユーザーごとに分離されるべき情報が別ユーザーへ表示されたインシデントとして整理する必要があります。

Webキャッシュでなぜ別ユーザーの情報が表示されるのか

Webキャッシュは、一度生成したWebページやレスポンスを保存し、同じ内容を再利用することでサーバー負荷や応答時間を減らす仕組みです。

HTTPキャッシュの標準仕様であるRFC 9111では、複数の利用者でレスポンスを再利用するものを「shared cache」、1人の利用者専用のものを「private cache」と定義しています。

通常、ニュース記事や画像のように利用者によって内容が変わらないページでは、共有キャッシュによって負荷を下げられます。

一方、ログイン後のマイページや購入画面のように利用者ごとに内容が異なるレスポンスを誤って共有すると、ある利用者向けの内容が別の利用者へ返される可能性があります。

RFC 9111では、共有キャッシュに保存させないレスポンスにprivate、キャッシュ自体に保存させない場合にno-storeなどの制御方法を定義しています。

ただし、チケットプラスは今回どのキャッシュ製品や設定項目に問題があったか、HTTPヘッダーがどのような状態だったかまでは公表していません。

そのため、「Cache-Controlの設定ミスだった」「CDNの設定ミスだった」など、具体的な技術原因を現時点で断定することはできません。

キャッシュ設定はセキュリティ設定として扱う必要がある

RFC 9111は、キャッシュの実装や展開時の不備によって、本来プライベートと考えられている機微情報がキャッシュされ、権限のない第三者へ露出する可能性があると明記しています。

キャッシュは一般にWebサイト高速化や負荷対策として利用されるため、セキュリティ製品の設定という認識を持たずに変更される場合があります。

しかし、ログイン後ページを扱うサイトでは、

• どのURLをキャッシュ対象にするか
• Cookieやセッションによってキャッシュを分離するか
• 認証済みページをキャッシュ対象外にするか
• クエリパラメータをキャッシュキーへ含めるか
• 個人情報を含むレスポンスを保存しないか

といった設定が、利用者間のデータ分離そのものに影響します。

今回のチケットプラスの事象では、アクセス集中への対策として変更したキャッシュ設定が個人情報の誤表示につながりました。

性能改善を目的とした設定変更であっても、認証・認可や個人情報保護への影響を確認する必要がある事例です。

設定変更から発覚まで約39時間

今回の時系列は次の通りです。

設定変更から利用者の問い合わせによる発覚までは約39時間でした。

同社は再発防止策として、システム変更時の確認・検証プロセスを見直すとしています。

情報システム・Web運用部門が確認したいポイント

今回の事案では、変更作業そのものよりも「変更後にユーザー間のデータ分離が維持されているか」を検証できるかが論点になります。

キャッシュ対象をURL単位だけで決めない

ログイン後のページでは、同じURLでも利用者ごとに返す内容が異なる場合があります。

URLだけを基準にキャッシュすると、他ユーザーのレスポンスを再利用する設計になる可能性があります。

認証状態、Cookie、セッション、ヘッダーなどを含め、ユーザーごとのレスポンスが混在しない構成かを確認します。

本番変更後に複数アカウントで確認する

単一アカウントで正常表示されるだけでは、他ユーザーとの情報混在は検知できません。

キャッシュ、CDN、WAF、ロードバランサーなどの設定を変更した際は、複数アカウントから同時にアクセスし、

• Aユーザーの情報がBユーザーに表示されないか
• ログアウト後に前ユーザーの情報が残らないか
• 高負荷時でもセッション分離されるか

を確認するテストが必要です。

性能変更もセキュリティレビューの対象にする

キャッシュ設定は可用性やレスポンス速度を改善するための変更ですが、認証済みページでは機密性へ直接影響します。

変更管理では、

• 性能
• 可用性
• セキュリティ
• 個人情報
• ロールバック手順

を同じ変更審査の中で確認します。

誤表示を自動検知できるか確認する

今回の事象は利用者からの問い合わせを契機に発覚しました。

テスト環境や監視環境で、レスポンスに別ユーザーのID、メールアドレス、氏名などが混入していないか検証する仕組みがあれば、利用者からの申告前に発見できる可能性があります。

個人情報を扱うWebサービスでは、障害監視だけでなく「認証ユーザー間のデータ分離」をテスト項目として持つ必要があります。

出典

• 一部のお客様情報が別のお客様に表示される事象についてのお詫びとご報告 – 株式会社チケットプラス
• 漏えい等報告・本人への通知の義務化について – 個人情報保護委員会
• 個人データであるクレジットカード番号のみが漏えいした場合の考え方 – 個人情報保護委員会
• 個人データである住所、電話番号、メールアドレス等が漏えいした場合の考え方 – 個人情報保護委員会
• RFC 9111: HTTP Caching – RFC Editor