セキュリティ

トラベルコ不正アクセス：メール38万件の対象確認と偽メール対策、アララとの違い

トラベルコ不正アクセス：メール38万件の対象確認と偽メール対策、アララとの違い

旅行比較サイト「トラベルコ」のウェブサイトが不正アクセスを受け、メールマガジン登録者のメールアドレス381,926件が流出したと、運営するオープンドアが2026年11月9日に公表しました。5日前に公表された委託先アララ経由の318,495件とは別の事案です。前半は、自分は対象か、届いたメールは本物か、カード情報を入力してしまったらどうするかに公式の文言で答えます。後半では名簿を預かる事業者の開発者に向けて、一括取得を見つけるログ検査と、2事案の通知先を名寄せするPythonを実行結果つきで示します。

まとめ：トラベルコのメール38万件流出と、メルマガ登録者が先に取る偽メール対策

流出が確認された経路は2つあり、同じ登録者が両方に含まれているため件数は足せません。

事案 件数 項目 公表日
委託先アララ経由 318,495件 メールアドレスのみ 11月4日
トラベルコのサイト 381,926件 アドレス＋一部に地域 11月9日

氏名、住所、電話番号、性別、生年月日、パスワード、クレジットカード情報の流出はないとされています。登録者がいま行うのは、不審なメールのリンクを開かないことです。パスワードの変更を一律に求める案内は出ていません。

対象者には順次メールで連絡が届く予定です。オープンドアの11月9日の発表によれば、同社がメールでパスワードやカード情報の入力を求めることは一切ありません。入力を求めるメールは、その時点で偽物と判断できます。

メルマガ登録者が確かめる対象の有無と偽メールの基準、カード入力後の連絡先

順次届く個別メールで分かる対象と、窓口に今聞いても答えが出ない範囲

対象の登録者には、オープンドアから個別にメールで案内が届きます。11月9日の発表では「両事案で流出した対象範囲を精査のうえ、準備が整い次第、順次」とされ、開始日は示されていません。自分で照会するページの案内もありません。

メールマガジンに登録した覚えがある人は、案内を待ちながら対象である前提で身構えておくのが現実的です。窓口は [email protected] ですが、11月4日の発表には、現時点では流出対象かどうかを個別に答えられない場合があると書かれています。

「パスワードとカード情報は求めない」を基準にした偽メールの判断手順

公式の基準は単純です。オープンドアがメールでパスワードやカード情報の入力、開示を求めることはありません。旅行の比較サイトなので、割引クーポンや予約の確認を装う文面が届いても不思議ではありません。件名が自然でも、次の順で判断します。

  1. 本文のリンクや添付ファイルは開かず、返信もしない
  2. パスワードやカード番号の入力を求めていれば偽物として削除する
  3. 内容を確かめたいときはブックマークから トラベルコの公式サイト を開く

都道府県が書かれたメールが届いても、本物の証拠にはなりません。152,655件には都道府県が含まれていたからです。偽のメールとサイトの仕組みはフィッシング詐欺の成立の仕組みと対策で解説しました。

カード情報を入力した場合の連絡先とパスワード変更が必要になる人の条件

偽のサイトにカード情報を入力してしまったら、すぐにカード発行会社へ連絡します。これは発表文に書かれた手順で、利用停止や番号の再発行は発行会社の判断になります。

パスワードは今回の流出項目に入っていません。変更が必要になるのは、偽のサイトに入力してしまった人です。入力したサービスに加えて、同じパスワードを使い回している他のサービスも変えます。旅行分野で流出メールが悪用された例は、skyticket不正アクセスの対象確認と本物メールの見分け方でも扱いました。

メルマガ停止中も使える検索機能と、比較サイトが予約情報を持たない範囲

メールマガジンは停止中ですが、その他のサービスはすべて利用できると発表されています。11月4日の発表では、トラベルコは比較サイトであり予約サイトではないため、基本的に旅行予約に関する個人情報を持っていないと説明されました。

比較したあとに予約した旅行会社や宿泊サイトの情報は、それぞれの会社が管理しています。「基本的に」という留保があるので、予約先の会社から別途お知らせが届いたら、その内容を個別に確かめてください。

11月4日のアララ経由31.8万件と11月9日の自社サイト38.2万件を分ける根拠

侵害された場所と件数、項目を並べて確かめる2事案の公表内容の違い

公式の発表2本を並べると、侵害された場所と持ち出された項目が違います。

比較項目 11月4日の公表 11月9日の公表
侵害された場所 アララの配信システム トラベルコのサイト
流出件数 318,495件 381,926件
付随する項目 なし 都道府県、郵便番号
判明の経緯 11月3日にアララから報告 11月6日に自社で確認
確認した対応 委託先の管理体制を確認 侵入経路を遮断

都道府県は152,655件、郵便番号は616件で、いずれも381,926件の内数です。配信元のアララでは、11月6日の第3報で重複を除いて81,329,467件のメールアドレスの持ち出しが示されました。サービス全体の経過と契約企業の作業はアララの不正アクセスと契約企業の対応で追っています。

「ほとんどが重複」から読める範囲と合算70万件が誤りになる理由

2つの件数を足すと700,421件ですが、この数字に意味はありません。発表文は、両事案で流出したアドレスの「そのほとんどが重複」していると説明しています。

読み取れるのは、影響を受けた宛先の実数が70万には届かず、38万に近い側にあるらしいということです。重複を除いた正確な件数は公表されていません。件数はメールアドレスの数であって、人数とも一致しません。

未公表の侵入経路と2事案の関係など、続報で確かめる5つの項目

2026年11月10日に確認した時点で、次の5つは公表されていません。この記事でも推測しません。

  • サイトへの侵入経路と利用された弱点
  • 不正アクセスが続いていた期間
  • 重複を除いた流出アドレスの実数
  • 2つの事案に攻撃者などの関係があるか
  • 個別案内の開始日

発表にある「侵入経路を遮断」は対応の事実で、経路の内容を説明したものではありません。別の事案と明記されているので、アララの手口をそのままトラベルコに当てはめる読み方も避けてください。

1つのメルマガ名簿が2か所から流出した構造と、配信基盤へ渡す項目の絞り方

配信基盤はアドレスのみ、自社サイト側は都道府県つきだった項目の差

開発者が注目したいのは、持ち出された項目の差です。11月4日の発表によると、アララのシステムに保管されていたのはメールアドレスのみでした。一方でサイト側からは、都道府県と郵便番号も一緒に流出しています。

配信に要らない項目を委託先に渡していなければ、委託先が破られても失う情報はその分だけ減ります。今回の委託先側の流出がアドレスだけで済んだ理由は、発表文を読む限りこの点にあると考えられるのです。ただ、原本が自社側にある以上、委託先だけを絞っても自社側の項目は残ります。

同じ名簿を2か所に持てば、攻撃を受ける場所も2か所になります。今回は、その2か所がどちらも破られました。

単独で個人情報に当たるメールアドレスと、名簿を置く場所の棚卸し

メールアドレスだから軽い、とは言えません。個人情報保護委員会のQ&A（Q1-4）は、ユーザー名とドメイン名から特定の個人を識別できるアドレスは、単独で個人情報に該当するとしています。それ以外も、他の情報と容易に照合できれば全体として個人情報になることがあります。

点検は、名簿が存在する場所を全部書き出すことから始めます。次の表の順に見ると抜けが減ります。

置き場所 確かめる点
登録フォームのDB 配信に使わない列の有無
配信システム 同期している項目
CSVの受け渡し 作業後の削除の記録
バックアップ 保管期限と復元の権限
解析・広告の連携先 送っている識別子

配信を止めたアドレスの扱いも同じ棚卸しに入ります。東京メトロの件で流出したのは配信停止中のアドレスで、平文を持たずに照合する実装は東京メトロの不正アクセスと配信停止リストの設計で示しました。

登録者一覧の一括取得を止めるAPIの上限と、抜き取りをログで見つけるPython

侵入経路が未公表でも点検できる、登録者を返す機能の認可と件数上限

トラベルコの侵入経路は分かっていません。ここからは今回の原因の説明ではなく、登録者の情報を返す機能を持つサイトに共通する点検項目です。

最初に見るのは認可です。OWASP API Security Top 10のAPI1:2023は、ログイン中の利用者がそのレコードに操作してよいかを確かめることを求めています。登録情報の変更画面や配信停止の画面で、URLのIDを書き換えると他人の情報が返らないかを試す手順です。実装は認可バイパスを止めるサーバ側の実装が参考になります。

次に件数です。API4:2023は、返すレコード数を決めるパラメータのサーバ側検証とレート制限を挙げています。管理画面のCSV出力や一覧APIに上限がなければ、奪われた権限1つで名簿全体が持ち出せます。制限の方式はAPIレート制限の5方式と429の設計で比較しました。トークンの失効まで含めた手順はAPI不正アクセス対策の実装手順にあります。

10分間に読んだ登録者数で一括取得を検知するPythonと実行結果

リクエスト数だけを見ると、1人の登録者を何度も開く操作と、名簿を読み進める操作の区別がつきません。そこで、主体ごとに「直近10分間に読んだ異なる登録者の数」を数えます。次のスクリプトは標準ライブラリだけで動き、ダミーのログを内部で作るのでそのまま実行できます。

# 登録者を短時間に大量に読んだ主体を、アプリの操作ログ（JSON Lines）から探す（Python 3.9以上・標準ライブラリのみ）
import json
import sys
from collections import Counter, defaultdict, deque
from datetime import datetime, timedelta

WINDOW = timedelta(minutes=10)
LIMIT = 50  # 10分間に読んだ異なる登録者の数の上限
ALLOWED = {"svc-delivery"}  # 配信バッチなど、一括読み取りを承認済みの主体


def sample_log():
    start = datetime(2026, 11, 1, 3, 0, 0)
    lines = []

    def add(seconds, actor, subscriber_id):
        ts = (start + timedelta(seconds=seconds)).isoformat()
        lines.append(json.dumps({"ts": ts, "actor": actor, "action": "subscriber.read", "subscriber_id": subscriber_id}))

    for i in range(5):  # 担当者の通常の閲覧
        add(i * 60, "staff-01", 100 + i)
    for i in range(100):  # 同じ1人を何度も開く操作は件数を増やさない
        add(i, "staff-02", 500)
    for i in range(500):  # 承認済みの配信バッチ
        add(i, "svc-delivery", 1000 + i)
    for i in range(60):  # 改行を混ぜた主体名で連番を読み進める
        add(i * 3, "unknown\r\nFAKE-LOG-LINE", 2000 + i)
    for i in range(49):  # 約10分半かけて少しずつ読む主体は上限に届かない
        add(i * 13, "staff-03", 3000 + i)
    lines.append("{broken json")
    return lines


def clean(value):
    # ログ由来の文字列は改行を除いて長さを切ってから表示する
    return "".join(ch for ch in str(value) if ch.isprintable())[:40]


def detect(lines):
    windows = defaultdict(deque)
    counters = defaultdict(Counter)
    peak = {}
    broken = 0
    for line in lines:
        try:
            event = json.loads(line)
            ts = datetime.fromisoformat(event["ts"])
            actor, sid = event["actor"], event["subscriber_id"]
        except (ValueError, KeyError, TypeError):
            broken += 1
            continue
        if event.get("action") != "subscriber.read" or actor in ALLOWED:
            continue
        window, counter = windows[actor], counters[actor]
        window.append((ts, sid))
        counter[sid] += 1
        while ts - window[0][0] > WINDOW:
            _, old = window.popleft()
            counter[old] -= 1
            if not counter[old]:
                del counter[old]
        peak[actor] = max(peak.get(actor, 0), len(counter))
    return peak, broken


def main():
    peak, broken = detect(sample_log())  # 主体ごとに時刻順で並んでいる前提
    flagged = {a: n for a, n in peak.items() if n > LIMIT}
    for actor, count in sorted(peak.items(), key=lambda kv: -kv[1]):
        mark = "要確認" if actor in flagged else "問題なし"
        print(f"{mark}: {clean(actor)} が10分間に読んだ登録者 最大 {count} 人")
    print(f"解析できない行 {broken} 件")
    sys.exit(1 if flagged else 0)


if __name__ == "__main__":
    main()

Python 3.14.10（Windows）で2026年11月10日に実行した結果です。終了コードは1でした。

要確認: unknownFAKE-LOG-LINE が10分間に読んだ登録者 最大 60 人
問題なし: staff-03 が10分間に読んだ登録者 最大 47 人
問題なし: staff-01 が10分間に読んだ登録者 最大 5 人
問題なし: staff-02 が10分間に読んだ登録者 最大 1 人
解析できない行 1 件

同じ1人を100回開いた staff-02 は1人と数えられ、承認済みの配信バッチは対象から外れています。主体名に混ぜた改行は、表示の前に取り除かれました。外部から来る文字列をそのまま出力すると、偽のログ行を作られるためです。

検知スクリプトの限界と、操作ログに残す項目・残さない項目の線引き

このスクリプトは、ゆっくり読み進める相手を見逃します。出力の staff-03 は49人を読みましたが、約10分半に分けたので47人で止まり、上限の50を超えていません。10分の窓とは別に、24時間の累計にも上限を置いて補います。主体を次々に変えられた場合は、IPや認証トークンの単位で同じ集計を行います。

前提となる条件は、読み取りの操作がログに記録として残っていることです。OWASPのLogging Cheat Sheetは、記録すべき操作に画面帳票を含むデータのインポートとエクスポートを挙げ、セッションIDやアクセストークン、パスワードは残さないよう整理しています。上のスクリプトのログも、メールアドレスではなく登録者IDだけで書いています。

2事案の通知先を1通に名寄せするPythonと、事案を混同させない連絡文の条件

委託先分と自社分を宛先ごとに統合し通知文を分けるPythonと実行結果

同じ宛先が2つの事案に入っていると、通知の作業で問題が起きます。単純に2回送れば受信者は混乱し、片方の件数だけで報告すれば対象が漏れます。オープンドアも「両事案で流出した対象範囲を精査のうえ」連絡するとしており、この突き合わせは避けられない工程です。次のスクリプトは、宛先ごとに1行へまとめ、事案の組み合わせと属性の有無で通知文を分けます。

# 2つの事案の流出リストを宛先ごとに1行へまとめ、通知文の種類を決める（Python 3.9以上・標準ライブラリのみ）
# 宛先そのものは画面に出さず、件数だけを出す
import csv
import io
import sys
from collections import Counter

AT = chr(64)  # アットマークの文字

# 検証用のダミー。実運用では事案ごとのCSVをopenで読む
INCIDENT_VENDOR = f"""email
Taro{AT}example.com
hanako{AT}example.com
jiro{AT}example.net
"""
INCIDENT_SITE = f"""email,prefecture,postal_code
taro{AT}EXAMPLE.com,東京都,
 hanako{AT}example.com ,,
saburo{AT}example.org,大阪府,5300001
broken-address,,
"""
ATTRIBUTES = ("prefecture", "postal_code")


def normalize(raw):
    value = raw.strip()
    if value.count(AT) != 1:
        return None
    local, domain = value.split(AT)
    if not local or "." not in domain:
        return None
    # ドットや+以降は消さない。別人の宛先を1通にまとめてしまうため
    return f"{local.lower()}{AT}{domain.lower()}"


def load(text, label, merged):
    rejected = 0
    for row in csv.DictReader(io.StringIO(text)):
        email = normalize(row["email"])
        if email is None:
            rejected += 1
            continue
        entry = merged.setdefault(email, {"incidents": set(), "attrs": set()})
        entry["incidents"].add(label)
        entry["attrs"].update(k for k in ATTRIBUTES if row.get(k))
    return rejected


def template_of(entry):
    incidents = "+".join(sorted(entry["incidents"]))
    return f"{incidents}:{'属性あり' if entry['attrs'] else 'アドレスのみ'}"


def main():
    merged = {}
    rejected = load(INCIDENT_VENDOR, "委託先", merged)
    rejected += load(INCIDENT_SITE, "自社", merged)

    vendor = sum("委託先" in e["incidents"] for e in merged.values())
    site = sum("自社" in e["incidents"] for e in merged.values())
    print(f"委託先 {vendor} 件 + 自社 {site} 件 = 単純合計 {vendor + site} 件")
    print(f"宛先の実数 {len(merged)} 件")
    for name, count in sorted(Counter(template_of(e) for e in merged.values()).items()):
        print(f"  {name}: {count} 件")
    print(f"形式不正で除外 {rejected} 件")
    sys.exit(1 if rejected else 0)  # 除外があれば人が確かめるまで送信へ進めない


if __name__ == "__main__":
    main()

同じ環境で2026年11月10日に実行した結果です。形式不正の行があるため、終了コードは1で止まりました。

委託先 3 件 + 自社 3 件 = 単純合計 6 件
宛先の実数 4 件
  委託先+自社:アドレスのみ: 1 件
  委託先+自社:属性あり: 1 件
  委託先:アドレスのみ: 1 件
  自社:属性あり: 1 件
形式不正で除外 1 件

小文字にそろえることで、大文字で登録された Taro と、サイト側の taro が1件になっています。Gmailのドットや + 以降の文字は、消すと別人の宛先を統合してしまうので残しました。実運用では事案ごとのCSVを読み込み、結果も暗号化した場所にだけ保存します。

本文のリンクで誘導しない通知メールの書き方と送信ドメインの確認

お詫びの通知そのものが、偽メールの見本になることがあります。受信者に「リンクを開かないで」と呼びかける文面に、ログインのリンクを入れては矛盾します。通知文には、どの事案で、どの項目が対象かを書き、確認先は公式サイトのお知らせ欄と案内して、再設定などのリンクは置きません。

事案が2つあるなら、件数を足した数字を書かず、事案ごとに分けて説明します。送信元の信頼性は、SPF、DKIM、DMARCの設定で支えます。移行の手順はフィッシング対策ガイドラインのDMARC要件とp=rejectへの移行にまとめました。

委託先の報告が訂正された場合に備える、通知対象データの版管理

委託先の数字は変わります。アララの第3報では、ある区分の件数が3,386,187件から2,842,400件に改められ、別のクラウド環境から3,249,492件の持ち出しも追加されました。同社のお知らせには、持ち出し期間の案内を「10月28日から29日まで」から「10月31日に停止するまで」に訂正したとあり、影響範囲の誤りも認めています。

委託元は、対象リストを受け取るたびに上書きしてはいけません。受領日と版を付けて保存し、前の版との差分だけを追加の通知に回します。訂正前の期間を報告に使っていたなら、アララの案内どおり訂正後の期間へ改めることになります。

個人情報保護委員会への報告と、名簿の項目を減らす判断・診断を入れる条件

1,000人超と不正目的の類型に当たる漏えい等報告の速報・確報期限

個人情報保護委員会の案内では、民間事業者の報告対象に、本人の数が1,000人を超える漏えい等と、不正の目的をもって行われたおそれがある漏えい等が含まれます。速報は発覚から3〜5日以内、確報は30日以内で、不正の目的によるおそれがある場合は60日以内です。オープンドアは委員会等へ報告済みと発表しました。

委託先で起きた場合でも、委託元の報告の要否は自社で判断します。報告と本人通知の流れは個人情報保護委員会への報告義務の実務で、委託先へ確認すべき項目は委託先管理の監督義務とチェックリストで確認できます。

配信に使わない属性を消す判断と、第三者の診断を先に入れる3条件

結論から書くと、メルマガ名簿の属性は「いま配信の出し分けに使っている列」だけを残します。都道府県で地域別の案内を実際に送っているなら、その用途が列を残す理由です。過去に一度聞いただけで使っていない郵便番号は消します。

外部の配信サービスをやめて自社で持つ判断は、流出対策としては勧めません。自社で持てば委託先のリスクは消えますが、今回トラベルコのサイト側で起きたように、守る責任が全部自社に集まります。配信基盤の運用人員を確保できない会社では、むしろ弱くなります。

次のいずれかに当てはまるなら、第三者の診断を先に入れます。登録者が万単位である、登録内容を変更する画面や配信停止の画面を自社で開発している、管理画面からCSVを出力できる担当者が複数いる、のいずれかです。登録者が数百人で外部サービスの標準フォームだけを使っているサイトは、診断より先に、名簿の棚卸しと管理者の多要素認証を済ませれば十分です。登録者一覧を返す機能まで含めて第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断でご相談いただけます。

よくある質問

トラベルコの不正アクセスについて、メールマガジン登録者から出やすい質問をまとめました。内容は2026年11月4日と11月9日の公表文に基づきます。

トラベルコの不正アクセスで自分が対象かどうかはどう確かめますか？

対象の登録者には、オープンドアから順次メールで個別の案内が届く予定です。2026年11月10日に確認した時点で、開始日と、自分で照会するページの案内はありません。流出が確認されたのはメールマガジンに登録されていたアドレスなので、登録した覚えがあれば対象の可能性を考えて行動してください。窓口はありますが、11月4日の発表では、調査中は対象かどうかを答えられない場合があるとされています。

トラベルコからのお知らせメールが本物かどうかはどう見分けますか？

パスワードやクレジットカード情報の入力を求めるメールは偽物です。オープンドアは、メールでそれらを求めることは一切ないと明言しました。ただ、入力を求めていないメールが本物とも言い切れません。本文のリンクは開かず、お知らせの内容はブックマークや検索から公式サイトを開いて確かめます。都道府県が正しく書かれていても、流出項目に含まれるので本物の証拠にはなりません。

トラベルコのパスワードは変更したほうがよいですか？

今回の流出項目にパスワードは含まれておらず、発表文に変更を求める案内はありません。偽のサイトに入力してしまった場合は、そのパスワードをすぐに変えてください。同じパスワードを他のサービスで使っているなら、そちらも対象です。特に入力した覚えがなくても、使い回しをやめる機会としては意味があります。流出したアドレス宛てに届くメールの方が、当面の危険は大きいと考えられます。

予約した旅行や支払いへの影響はありますか？

クレジットカード情報の流出はなく、メールマガジン以外のサービスはすべて利用できると発表されています。トラベルコは比較サイトなので、基本的に旅行予約に関する個人情報を持っていないと説明されました。実際の予約や支払いの情報は、予約先の旅行会社などが管理しています。「予約の確認」や「返金」を装うメールが届いたら、リンクを開かずに予約先の会社の公式サイトで確かめてください。

メールマガジンを解除すれば流出の心配はなくなりますか？

解除しても、すでに流出したアドレスを取り戻すことはできません。メールマガジンは2026年11月9日の発表の時点で停止しており、再開の時期も示されていません。偽のメールへの注意は、解除の有無にかかわらず続ける必要があります。メールアドレス自体を変えるかどうかは、不審なメールの増え方を見てから決めれば間に合います。解除の手続きを装うメールのリンクも開かないでください。

関連記事

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

一創の公式 SNS

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

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

資料請求

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

  1. 2026.11.07　コラム サイバーセキュリティ緊急対策パッケージとは？4本柱の施策と期限、企業と委託先が今やること
  2. 2025.04.30　テックブログ IMSIキャッチャー（偽基地局）とは？2Gフォールバックの手口と日本での対策
  3. 2026.11.06　テックブログ ドコモ不正アクセスの見舞金・対象確認とMy docomo再開状況：最大29.5万件の流出項目【11月9日第四報】
  4. 2026.11.06　テックブログ あいおいニッセイ同和の不正アクセス：44.4万件の漏えい項目と窓口、止まった手続きの代わり
  5. 2026.11.06　テックブログ TeamSpirit不正アクセス：28,824件流出の原因と利用企業の確認点、開発用サーバーの認証情報を守る実装

RELATED POSTS 関連記事

一覧へ戻る

目次