セキュリティ

teket不正アクセス：全会員の氏名流出と入場方法、偽メールの確認手順

teket不正アクセス：全会員の氏名流出と入場方法、偽メールの確認手順

電子チケット「teket（テケト）」を運営する株式会社teketは2026年11月8日、第三者の不正アクセスにより、全会員の氏名とメールアドレスなどが外部へ流出したと発表しました。サービスは11月5日20時30分から全面停止しており、QRチケットを表示できません。本記事の前半では、自分は対象か、チケットで入場できるのか、パスワードやカード番号はどうなのか、届いた連絡は本物かを、11月9日時点の発表と報道に沿って整理します。後半では、チケットやイベントのサービスを運営する開発者に向けて、発券コードの無効化と、障害時の受付リストをPythonのコードで示します。

まとめ：teket不正アクセスで流出した情報と購入者・主催者が取る対応

流出を確認済みとされるのは、全会員の氏名とメールアドレスです。登録や購入の状況によっては、生年月日、年齢、性別、住所、電話番号、チケットの発券用コード、主催者発行のシリアルコードも対象に入ります。対象者の人数は精査中で、再開の時期も決まっていません。詳細はteketの第一報が起点になります。

購入者がまずやることは2つです。購入完了メールを探して保管し、公演の主催者が出している入場案内を確かめます。teketを名乗るメールやSMSのリンクは開きません。主催者は、受付を購入完了メールの確認に切り替える準備が要ります。開発側が持ち帰る論点は、発券コードが漏れた後に未使用分だけを無効化できる設計か、基盤が止まった日に受付を続ける手段を用意しているかの2点です。

項目 公表されている内容（11月9日時点）
全会員が対象の項目 氏名・メールアドレス
状況により対象の項目 生年月日・年齢・性別・住所・電話番号
チケット関連の項目 発券用コード・シリアルコード
確認項目に含まれない パスワード・カード番号
対象人数 精査中
サービス停止 11月5日20時30分から
再開時期 未定
二次被害 11月8日時点で確認なし
未公表 侵入経路・原因

teketの購入者が最初に確かめること：対象の範囲と入場方法、連絡の真偽

全会員は氏名とメールが対象、購入状況で住所や発券コードまで広がる範囲

会員登録をしている人は、購入の有無にかかわらず氏名とメールアドレスが対象と考えて動きます。ITmedia NEWSの報道によれば、全会員の氏名とメールアドレスに加え、登録や購入の状況に応じて生年月日、年齢、性別、住所、電話番号、チケットの発券用コード、主催者発行のシリアルコードが流出の対象です。

すべての会員について全項目が流れたわけではありません。同社は対象者を特定したうえで順次案内するとしています。案内がまだ届かないことは、対象外の根拠になりません。第一報の時点で人数自体が精査中だからです。

QRチケットが出ないときの入場：購入完了メールの提示と見つからない場合

停止中はQRチケットを表示できないため、公演の受付で購入完了メールを見せます。メールが見つからなければ、受付で購入者の名前を伝える流れです。メールソフトで「teket」や公演名を検索して、当日までに該当のメールを見つけておくと受付が短く済みます。

ただし、案内は公演ごとに違います。リーグHは11月6日の告知で、入場方法は各ホームチームが案内するとし、復旧していれば通常どおりQRコードで入場できると説明しました。武蔵野音楽大学は11月9日の告知で、購入完了メールの保管を求めつつ、停止が続く場合の入場方法は運営会社と調整中としています。第一報の一般的な案内より、主催者の個別案内を優先してください。

パスワードとカード番号：11月8日時点の確認項目に含まれない点と留保

ログインパスワードとクレジットカード番号は、11月8日時点で流出を確認した項目に含まれていません。ただし原因の究明と影響範囲の特定は続いています。「確認項目に含まれない」は、調査が終わって流出なしと確定した状態とは違います。

カードを今すぐ止める根拠は、現時点の発表にはありません。明細に見覚えのない請求があればカード会社に連絡する、という通常の対応で足ります。他方でteketと同じパスワードを別のサービスで使っているなら、今回の発表とは切り離して変えておく価値はあります。

teketを装うメール・SMS・電話の見分け方と公式発表の確認先

判断の基準は単純です。teketは、メール、SMS、電話でパスワードやクレジットカード情報を尋ねることはないとしています。これらの入力や返答を求める連絡は、本物として扱いません。「チケットの再発行」「返金手続き」を理由に急がせるメールも、リンクを開かずに公式サイトで確かめます。手口の全体像はフィッシング詐欺の仕組みと技術的な対策にまとめています。

今回の流出には氏名と購入に関わる情報が含まれるため、公演名や自分の名前が書かれたメールでも本物とは言えません。問い合わせはteketの公式発表に記載のフォームから行い、再開の予定は同社のコーポレートサイトと公式SNSで確認します。11月9日時点で、第二報は確認できていません。

チケットの有効性と払い戻し：第一報に書かれていない2点と確認先

購入済みチケットが無効になったとする発表はありません。一律の払い戻しの案内も、11月9日時点では確認できません。公演の開催可否と払い戻しの条件を決めるのは各主催者なので、問い合わせ先は主催者です。

発券用コードが不正に使われたという発表も出ていません。一方で、流出したコードで第三者が入場できるかどうかも公表されていません。主催者によってはQRの読み取りを止めて購入者名で照合しているため、当日は名前が確認できるものも持参すると安心です。

主催者が公演当日までに準備する受付手順と購入者リストの取り扱い

QR読み取りが使えない受付：購入完了メールの目視と名前照合の2段構え

主催者管理画面へのログインとQRチケットによる受付は、どちらも停止しています。報道によれば、主催者は来場者の購入完了メールで入場を確認し、確認に必要な購入者リストはteketが主催者ごとに個別に案内する形です。売上金は通常どおり入金される予定で、販売手数料の扱いは別途案内するとされています。

受付では、メールの提示を先に、名前の照合を後に置くと列が詰まりにくくなります。メールの画面は複製しやすいので、照合済みの行には印を付け、同じ購入の2回目を止める運用です。東京体育館などの施設で販売してきた東京都スポーツ文化事業団のように、主催者自身が告知と窓口を出している例もあります。購入者は、まず主催者の窓口を探すからです。

受け取った購入者リストも個人データ：渡す範囲と公演後に消す手順

購入者リストを受け取った時点で、主催者の手元にも個人データが増えます。共有先は受付担当に限り、メールやチャットへの転送は避け、公演が終わったら削除の担当者と期限を決めます。流出事案への対応の中で新しい持ち出しを作らない、という考え方です。

公式発表で整理する経緯：11月5日の全面停止から11月8日の第一報公表まで

外部からの不正アクセスの判断から個人情報保護委員会への報告まで4つの出来事

  1. 11月5日：外部からの不正アクセスの可能性が高いと判断し、20時30分にサービス全体を停止して遮断措置に着手
  2. 11月6日：会員情報を管理するシステムへの不正アクセスと、保管情報の一部の流出を確認。個人情報保護委員会へ報告
  3. 11月6日21時：停止が11月7日、8日中には終わらない見込みを告知（リーグHの告知による）
  4. 11月8日：第一報で流出を公表。原因究明と影響範囲の特定は継続

停止から公表までは約3日です。11月8日の時点で、不正ログインや流出情報の悪用といった二次被害、新たな不正アクセスは確認されていないとしています。teketはNTTドコモが2023年10月に設立を発表した会社が企画・開発するサービスで、報道では「ドコモ傘下」「ドコモ系」と表現されています。

10月30日のStudioの件は別の発表：対象システムの違いと未公表の項目

同社は10月30日にもコーポレートサイトで使うクラウドサービス「Studio」への不正アクセスで、問い合わせ情報の漏えいの可能性を発表しています。11月8日の発表は電子チケットサービスの会員情報を管理するシステムが対象で、題名からも別の件です。両者の関連を示す発表はありません。

侵入経路、悪用された脆弱性、対象人数は未公表です。保存形式も出ていません。本記事は、発券コードが平文で保存されていた、あるいは暗号化されていたとは書きません。以降の技術章で扱う範囲は、確定している「発券用コードとシリアルコードが流出の対象になった」「全面停止でQR受付が止まった」の2点です。

発券コードが漏れても入場させない電子チケットの保存方式と無効化の実装

氏名の流出と発券コードの流出で異なる：入場権そのものが値になる問題

氏名やメールアドレスの流出は、詐欺に使われる被害です。発券コードの流出は性質が違います。コードが入場の権利そのものなら、持っている人がそのまま権利を使えるからです。同じ種類の値に、クーポンコードやパスワード再設定用のトークンがあります。

対策は2段階で考えます。1つ目は、データベースが抜かれてもコードが再現できない保存方式にすること。2つ目は、万一漏れたときに未使用分だけを一括で無効にできること。入場済みの記録を壊さずに無効化できるかどうかが、事故当日の作業量を分けます。

HMACで発券コードをDBに持たず世代番号で無効化するPythonコード

次の例は、発券コードをデータベースに保存せず、チケットIDと世代番号からPython標準のhmacで都度計算します。データベースだけが漏れても、鍵がなければコードは作れません。無効化は世代番号を1つ進めるだけで、入場処理は未使用かつ現行世代のときにだけ1行更新します。

# 発券コードをDBに保存せず、流出時に世代を進めて無効化する最小例（Python 3.9以上・標準ライブラリのみ）
import hashlib, hmac, secrets, sqlite3

SECRET = secrets.token_bytes(32)  # 本番ではDBと別の場所（KMSなど）に置く

con = sqlite3.connect(":memory:")
con.execute("""CREATE TABLE tickets (
    id TEXT PRIMARY KEY, event TEXT NOT NULL,
    generation INTEGER NOT NULL DEFAULT 1, used_at TEXT)""")
con.executemany("INSERT INTO tickets (id, event) VALUES (?, ?)",
                [("T0001", "E100"), ("T0002", "E100")])

def sign(ticket_id, generation):
    msg = f"{ticket_id}:{generation}".encode()
    return hmac.new(SECRET, msg, hashlib.sha256).hexdigest()[:32]

def code_for(ticket_id):
    """表示のたびに計算する。コード自体はDBのどの列にも入らない"""
    gen = con.execute("SELECT generation FROM tickets WHERE id = ?", (ticket_id,)).fetchone()[0]
    return f"{ticket_id}.{gen}.{sign(ticket_id, gen)}"

def admit(code, at):
    try:
        ticket_id, gen, sig = code.split(".")
        gen = int(gen)
    except ValueError:
        return "拒否:形式不正"
    if not hmac.compare_digest(sig, sign(ticket_id, gen)):
        return "拒否:署名不一致"
    # 未使用かつ現行世代のときだけ1行更新する（同時読み取りでも1回しか通らない）
    cur = con.execute(
        "UPDATE tickets SET used_at = ? WHERE id = ? AND generation = ? AND used_at IS NULL",
        (at, ticket_id, gen))
    if cur.rowcount == 1:
        return "入場可"
    row = con.execute("SELECT generation FROM tickets WHERE id = ?", (ticket_id,)).fetchone()
    if row is None:
        return "拒否:該当なし"
    return "拒否:無効化済みの世代" if row[0] != gen else "拒否:使用済み"

def revoke_unused(event):
    """流出時に、未使用のチケットだけ世代を1つ進める"""
    return con.execute("UPDATE tickets SET generation = generation + 1 "
                       "WHERE event = ? AND used_at IS NULL", (event,)).rowcount

leaked = code_for("T0001")   # 流出前に発行されたコード
used = code_for("T0002")
print("改ざんコード:", admit(leaked[:-1] + ("0" if leaked[-1] != "0" else "1"), "18:00"))
print("T0002 1回目:", admit(used, "18:01"))
print("T0002 2回目:", admit(used, "18:02"))
print("無効化した枚数:", revoke_unused("E100"))
print("流出した旧コード:", admit(leaked, "18:03"))
print("再発行したコード:", admit(code_for("T0001"), "18:04"))

Python 3.14.10（SQLite 3.50.4・Windows）で実行した結果です。

改ざんコード: 拒否:署名不一致
T0002 1回目: 入場可
T0002 2回目: 拒否:使用済み
無効化した枚数: 1
流出した旧コード: 拒否:無効化済みの世代
再発行したコード: 入場可

入場済みのT0002は無効化の対象から外れ、枚数は1枚になりました。流出した旧コードは署名としては正しいものの、世代が古いため止まります。署名の比較には、処理時間の差から値を推測されないよう hmac.compare_digest を使っています。

鍵が漏れた場合の限界と主催者発行シリアルコードを別扱いにする判断基準

この方式が守るのは、データベースだけが抜かれた場合です。OWASPの暗号化保存チートシートは、可能な限り鍵をデータと別の場所に保管すること、漏えいまたはその疑いがある鍵はローテーションすることを挙げています。サーバー自体が侵害されて鍵まで読まれたなら、世代番号では足りません。鍵を入れ替え、全チケットを再発行します。そのため運用では、コードに鍵のIDも含めておきます。

主催者が発行するシリアルコードは、この方式に載せられません。値を外部が決めるので、計算で再現できないからです。保存が要るなら暗号化し、画面に出す権限を絞ります。流出時の無効化と再発行は主催者の作業になるため、連絡手段と手順を契約の段階で決めておきます。

判断は言い切れます。入場や特典の権利そのものになるコードを平文の列に持つ設計は、規模を問わず直すべきです。一方、数百人規模の単発イベントで、QRの有効期限を秒単位で切り替える動的コードまで入れるのは過剰です。その規模なら、世代管理と1回限りの消し込みで足ります。APIの認可まで含めた点検の順番はAPI不正アクセス対策の実装手順で示しました。

チケット基盤が止まった日に入場を続ける代替受付リストの設計と実装

照合に要る3列だけを出すCSV生成と数式注入を防ぐPythonコード

teketの事案では、QRの読み取りが止まった穴を購入完了メールと購入者リストで埋めています。リストの形式は公表されていないため、ここでは自社で同じ仕組みを作る場合を考えます。リストは事故対応の最中に作られ、社外へ渡るデータです。列は許可リストで決め、公演ごとに分ける運用です。OWASPのCSV Injectionの解説が示すとおり、購入者が入力した名前が = などで始まると、表計算ソフトで数式として解釈されます。出力にはPython標準のcsvを使います。

# 障害時に主催者へ渡す受付リストを、照合に要る列だけで作る最小例（Python 3.9以上・標準ライブラリのみ）
import csv, sys

ALLOWED = ["order_no", "buyer_name", "quantity"]   # 出力してよい列の許可リスト
FORMULA_HEAD = ("=", "+", "-", "@", "\t", "\r", "\n", "＝", "＋", "－", "＠")  # 数式扱いされる先頭文字

orders = [
    {"order_no": "A-1001", "buyer_name": "山田 花子", "quantity": 2, "event": "E100",
     "email": "(省略)", "phone": "(省略)", "address": "(省略)"},
    {"order_no": "A-1002", "buyer_name": "=SUM(1+1)", "quantity": 1, "event": "E100",
     "email": "(省略)", "phone": "(省略)", "address": "(省略)"},
    {"order_no": "B-2001", "buyer_name": "佐藤 一郎", "quantity": 1, "event": "E200",
     "email": "(省略)", "phone": "(省略)", "address": "(省略)"},
]

def safe(value):
    text = str(value)
    return "'" + text if text.startswith(FORMULA_HEAD) else text

def write_door_list(event, out):
    writer = csv.writer(out, lineterminator="\n")
    writer.writerow(ALLOWED)
    rows = [o for o in orders if o["event"] == event]   # 他の公演の購入者は渡さない
    for order in sorted(rows, key=lambda o: o["order_no"]):
        writer.writerow([safe(order[column]) for column in ALLOWED])
    return len(rows)

count = write_door_list("E100", sys.stdout)
print("出力件数:", count)

実行結果は次のとおりです。

order_no,buyer_name,quantity
A-1001,山田 花子,2
A-1002,'=SUM(1+1),1
出力件数: 2

メールアドレス、電話番号、住所は列に出ません。別公演の購入者も含まれません。数式で始まる名前には先頭にシングルクォートが付き、文字列のまま残りました。OWASPは、Excelで保存して開き直すとこの方法が効かなくなる場合があるとも注意しています。受け取った側がCSVを編集して再配布しない運用とセットで考えてください。

障害時の受付は事前に印刷せず前日生成に留める判断と報告期限の確認

代替リストは、公演の前日に公演単位で生成し、当日使ったら消す運用を勧めます。全公演分を平時から主催者に配っておく方式は採りません。平時の持ち出しを増やすだけで、障害の確率に見合わないからです。全面停止のあとでも生成できるよう、リストの作成手段は本番の基盤から切り離して用意します。これが抜けると、データベースを止めた瞬間にリストも作れなくなります。

個人データの漏えいは、個人情報保護委員会の案内によると、不正の目的によるおそれがある場合に報告の対象です。速報は発覚日から3〜5日以内、確報は60日以内とされています。teketは確認当日の11月6日に報告しました。段取りの詳細は個人情報保護委員会への報告義務の実務にまとめています。

チケット販売や会員サービスを運営する立場なら、確かめる順番は、発券コードの保存方式、無効化の手段、代替受付の作り方です。購入者データを扱う画面やAPIの弱点を第三者の目で確かめたい場合は脆弱性診断・セキュリティ診断で相談を受け付けています。

よくある質問

teketの不正アクセスと情報流出について、購入者から出やすい質問をまとめました。内容は11月9日時点の発表と報道に基づきます。

teketの購入履歴がなくても情報は流出していますか？

氏名とメールアドレスは、全会員が対象とされています。購入していなくても会員登録をしていれば、この2項目は含まれると考えて動いてください。住所や電話番号、発券用コードなどは登録と購入の状況によって対象が変わります。同社は対象者を特定して順次案内するとしていますが、案内が届いていないことは対象外の根拠にはなりません。

購入したチケットで公演に入場できますか？

QRチケットは表示できませんが、購入完了メールを受付で提示する方法が案内されています。メールが見つからない場合は、受付で購入者名を伝える方法です。ただし入場方法は公演ごとに異なり、主催者が個別に案内している例があります。公演が近い場合は、主催者の公式サイトやSNSの案内を先に確かめてください。購入済みチケットを無効にしたとする発表はありません。

teketのサービスはいつ再開しますか？

11月9日時点で再開の時期は未定です。同社は精査中としており、決まり次第コーポレートサイトと公式SNSで知らせるとしています。公演が停止期間に重なる場合に備えて、購入完了メールを手元に残し、主催者の案内を確認してください。teketを名乗って再開や再発行の手続きを急がせるメールのリンクは開かないようにします。

パスワードの変更やカードの停止は必要ですか？

11月8日時点で、ログインパスワードとクレジットカード番号は確認済みの流出項目に含まれていません。カードの利用停止を求める発表もありません。サービス停止中はteketでのパスワード変更もできないため、同じパスワードを使っている他のサービスがあれば、そちらを先に変えてください。調査は続いているので、続報の内容で判断を見直します。

teketからのメールやSMSは本物ですか？

パスワードやクレジットカード情報の入力、返答を求めるものは偽物と判断してください。teketはメール、SMS、電話でこれらを尋ねることはないとしています。流出した氏名や購入に関わる情報が使われている可能性もあるので、名前や公演名が正しくても信用しません。公式の発表はコーポレートサイトと公式SNSで確かめてください。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.07　コラム サイバーセキュリティ緊急対策パッケージとは？4本柱の施策と期限、企業と委託先が今やること
  2. 2026.11.06　テックブログ ドコモ不正アクセス：最大29.5万件の流出項目と見舞金、My docomo停止の経過と偽連絡の見分け方
  3. 2025.04.30　テックブログ IMSIキャッチャー（偽基地局）とは？2Gフォールバックの手口と日本での対策
  4. 2026.11.03　テックブログ ネットマイル不正アクセスで最大約549万人に漏えいの可能性：ログイン・マイル・退会・登録した覚えがない場合
  5. 2026.11.06　テックブログ あいおいニッセイ同和の不正アクセス：44.4万件の漏えい項目と窓口、止まった手続きの代わり

RELATED POSTS 関連記事

一覧へ戻る

目次