楽天グループは2026年10月26日、旅行予約サービス「楽天トラベル」の海外ホテル予約サイトの一部ページと多言語予約サイトに、社外の第三者による不正アクセスがあったと公表しました。海外ホテル予約ページでは、ログインした最大約260万件の氏名・メールアドレス・電話番号と、予約者最大約4万件の予約情報が対象です。そのうち最大約3万6千件には、カードの下4桁や有効期限を含む支払情報も対象です。本記事の前半は、自分は対象か、カードはどうなるのか、届いた連絡は本物かという利用者の疑問に、公式発表の文言で答えます。後半では予約サイトの開発者向けに、APIが返す項目の絞り込みと会員情報の大量読み出しの検知をPythonのコードで示します。
まとめ：楽天トラベル不正アクセスで公表された2つの事象と利用者・運営者の対応
公表されたのは、時期も対象サイトも違う2つの事象です。1つ目は子会社のRakuten Travel Xchangeが管理・運営する海外ホテル予約ページの一部で、9月10日に異常を検知しました。2つ目は楽天グループが運営する多言語予約サイトで、10月20日に検知しています。どちらもクレジットカード番号の全桁、セキュリティコード、パスワード、パスポート等の身分証明書情報、住所は対象外とされています。
利用者がまず押さえることは2つあります。発表のとおり、今回の情報だけで買い物や旅行予約の決済、キャッシングに使われることはありません。一方で、名前とカードの下4桁、有効期限、泊まったホテル名を知っている相手からの連絡は、本物らしく見えます。開発者が受け取る教訓は、画面が使わない項目までAPIが返していないか、1つのアクセス権で多数の会員の情報を読めないかの2点を見直すことです。
| 項目 | 公表内容（2026年10月28日時点） |
|---|---|
| 事象①の対象サイト | 海外ホテル予約ページの一部 |
| 事象①のログイン者 | 最大約260万件 |
| 事象①の予約者 | 最大約4万件 |
| うち支払情報 | 最大約3万6千件 |
| 事象②のログイン者 | 最大約86万件 |
| 事象②の施設従業員 | 最大約4万件 |
| 対象外の情報 | カード全桁・パスワード等 |
| 未公表 | 侵入経路・期間・補償 |
利用者が最初に確かめること：対象かどうか、届く連絡の真偽、事象ごとの問い合わせ先
欧米やアジア・オセアニアの海外ホテルを予約・ログインした人が事象①の対象になる範囲
事象①の対象は、海外ホテル予約ページのうちRakuten Travel Xchangeが管理・運営する一部のページです。楽天トラベルのお詫びとお知らせは、対象エリアをヨーロッパ、アメリカ・カナダ、アジア・オセアニアの一部の国・地域としています。除かれるのは韓国、台湾、香港、シンガポール、マカオと、タイ・ベトナム・フィリピン・インドネシアの一部地域、米国のハワイ・グアム・ロサンゼルス等です。
このページで予約した人は最大約4万件、ログインした人は最大約260万件が対象です。予約した人は、本人と同伴者の氏名・居住国、予約した施設名や予約金額まで含まれます。ログインしただけの人は、氏名・メールアドレス・電話番号・社内用の識別番号です。自分が使ったページがどの会社の管理かを利用者が見分ける方法は案内されていません。楽天グループは対象者へ順次、個別に連絡するとしています。
多言語予約サイトのログイン利用者と宿泊施設の管理画面を使う従業員が事象②で確かめること
事象②の対象は「楽天トラベル」の多言語予約サイトにログインした最大約86万件で、公表された項目はメールアドレスと社内用の識別番号の2つです。問い合わせ先が英語・韓国語・繁體中文（香港・台湾）のフォームであることから、主に海外から日本の宿を予約する利用者のサイトと読めます。
同じ事象②で、多言語予約サイトの管理画面に入力された宿泊施設の従業員最大約4万件のアカウント名・メールアドレス・社内用の識別番号も対象です。宿泊施設の担当者は、楽天トラベルを名乗って管理画面へのログインや振込先の変更を求める連絡に注意が要ります。施設側が受けるフィッシングの型は、手間いらずの不正アクセスと宿泊予約フィッシングで施設向けの点検手順として整理しています。
カードの発行者識別番号・下4桁・名義・有効期限を知る相手からの連絡を疑う理由
事象①の支払情報に含まれるのは、クレジットカードの発行者識別番号と下4桁、名義、有効期限、国際ブランド区分です。発行者識別番号は先頭の数桁で、どのカード会社のどの券種かを示します。発表は、この支払情報だけでは決済やキャッシングの不正利用はできないとしています。
危ないのは、これらを示して信用させる連絡です。たとえば「◯◯カードの末尾1234、有効期限◯年◯月のカードに不正利用の疑いがあります」と言われると、本物のカード会社に見えます。そこで残りの番号やセキュリティコード、ワンタイムパスワードを聞き出す手口が考えられます。カード会社が電話やメールでセキュリティコードを尋ねることは通常ありません。不安なときは、届いた連絡の番号ではなく、カードの裏面にある番号へかけ直してください。
楽天を名乗るメールの確かめ方と事象①・事象②それぞれの問い合わせ先
届いたメールのリンクは開かず、ブックマークや検索から公式サイトに入って確かめます。楽天カードのフィッシングメールへの注意喚起は、楽天グループのメールでは受信トレイにブランドシンボルの「Rロゴ」や「緑のチェックマーク」が表示されるとし、見分けに使うよう案内しています。ただし表示があっても、本文で暗証番号やカード番号の入力を求めてきたら応じないでください。
問い合わせ先は事象ごとに分かれています。事象①の海外ホテル予約サイトは専用メールアドレス travel-support＠faq.rakuten.co.jp（＠は半角）です。事象②の多言語予約サイトは各言語の問い合わせフォーム、管理画面については宿泊施設の関係者向けのフォームが案内されています。電話窓口は10月28日時点の発表には書かれていません。手口の全体像はフィッシング詐欺の仕組みと実装者向けの対策で解説しています。
公式発表で整理する2つの事象：検知日・改修日・件数・対象となった項目の違い
海外ホテル予約ページと多言語予約サイトの事象を対象別に比べた一覧表
| 項目 | 事象① | 事象② |
|---|---|---|
| 対象サイト | 海外ホテル予約の一部 | 多言語予約サイト |
| 管理・運営 | Rakuten Travel Xchange | 楽天グループ |
| 検知 | 9月10日 | 10月20日 |
| 原因特定 | 9月15日 | 10月20日 |
| 改修完了 | 9月16日 | 10月21日 |
| ログイン者 | 最大約260万件 | 最大約86万件 |
| その他 | 予約者約4万件 | 施設従業員約4万件 |
報道には両事象の件数を足して約350万件とするものがありますが、単純に合計した数字です。同じ人が両方のサイトを使っていれば重複します。楽天グループは合計値も重複の有無も出していません。
9月10日の異常検知から10月26日の公表までを発生順に並べた時系列
- 9月10日：海外ホテル予約ページの一部で異常を検知
- 9月15日：事象①の原因を特定
- 9月16日：事象①のシステム改修を完了
- 10月20日：多言語予約サイトへの不正アクセスの可能性を検知し、同日に原因を特定
- 10月21日：事象②のシステム改修を完了
- 10月26日：公表、個人情報保護委員会と国外の関係当局へ報告済みと発表
事象①は検知から改修まで6日、事象②は翌日に改修を終えています。一方、事象①の検知から公表までの期間は46日です。発表は、改修の後に社内調査で対象の情報を確定したと説明しており、この期間は対象の洗い出しに充てられたと読めます。
10月28日時点で公表されていない侵入経路・不正アクセスの期間・補償
発表は「原因を特定」と書くだけで、どの仕組みのどの不備が突かれたのか、管理画面の認証情報が取られたのかには触れていません。不正アクセスがいつ始まったか、対象のうち日本に住む人が何件か、補償の有無も未公表です。本記事はこれらを推測で補いません。以降の技術章は、公表された対象項目の組み合わせから、予約サイトが一般に点検すべき範囲を扱います。同じ楽天グループの事案でも、楽天ドライブの不正アクセスは別のサービスで起きた別の事象です。
予約サイトの開発者が点検する範囲：カードの一部情報と会員情報を返しすぎない設計
予約者・同伴者・支払情報が1件の予約にまとまる海外ホテル予約のデータの持ち方
事象①で予約者について対象となったのは、氏名、メールアドレス、電話番号、居住国、予約情報、同伴者の氏名と居住国、支払情報です。予約1件の中に、本人と同伴者の個人情報、泊まる場所と日付、カードの一部情報がまとまっています。予約の確認画面やメールに必要な項目を1つの単位で持つ作りは、ホテル予約では一般的です。ホテル予約システムの機能とOTA・PMS連携でも、予約データは多くの機能から参照される中心のデータとして扱われます。
この持ち方では、予約1件を読める経路が1つあるだけで、詐欺に使える情報がひとそろい出ていきます。カード番号の全桁を持たない設計は、カード情報の取り扱い基準であるPCI DSSの範囲を小さくする意味でも有効です（要件の全体はPCI DSSの12要件と準拠レベルを参照）。ただ、下4桁と名義と有効期限が残れば、今回のように詐欺の材料にはなります。
OWASPのAPIセキュリティTop10が示す応答項目の過剰な露出と件数制限の欠如
OWASP API Security Top 10 2023のAPI3は、利用者が読むべきでない項目をAPIが返してしまう不備を扱います。対策として、to_json()のような汎用の変換を避け、返す項目を1つずつ選ぶこと、応答をエンドポイントの業務要件に必要な最小限に保つことを挙げています。画面側で表示を隠しても、通信の中身には残ったままです。
もう1つの観点がAPI4（リソース消費の制限なし）で、1人の利用者が一定時間に呼べる回数に上限を置くよう求めています。認可の不備と回数制限の欠如が重なると、IDを変えながら大量の会員情報を読む攻撃も短時間で完了する状態です。レート制限と認可、トークン失効の実装手順はAPI不正アクセス対策の実装手順にまとめています。
実装例：応答項目の絞り込み・大量読み出しの検知・通知メールの送信ドメイン認証
予約照会APIの応答を画面ごとの許可リストで絞るPythonコードと実行結果
予約一覧と予約詳細で、返してよい項目を画面ごとに列挙し、列挙に無い項目は返さない作りにします。データベースの1行をそのまま変換して返す書き方をやめるのが目的です。
# 予約照会APIの応答を画面ごとの許可リストで絞る（Python 3.9以上・標準ライブラリのみ）
import json
# 画面ごとに返してよい項目。ここに無い項目は応答に入らない
ALLOWED = {
"booking_list": ["booking_id", "hotel_name", "check_in", "status"],
"booking_detail": ["booking_id", "hotel_name", "check_in", "check_out",
"guest_name", "amount", "card_last4"],
}
def to_response(record, view):
return {k: record[k] for k in ALLOWED[view] if k in record}
record = {
"booking_id": "B-1001", "hotel_name": "Example Hotel Paris",
"check_in": "2026-11-03", "check_out": "2026-11-05",
"status": "confirmed", "guest_name": "YAMADA TARO",
"phone": "+81-90-0000-0000", "country": "JP", "amount": 48000,
"card_bin": "411111", "card_last4": "1111",
"card_holder": "TARO YAMADA", "card_expiry": "2028-12",
"companions": [{"name": "YAMADA HANAKO", "country": "JP"}],
}
print(json.dumps(to_response(record, "booking_list"), ensure_ascii=False))
print(json.dumps(to_response(record, "booking_detail"), ensure_ascii=False))Python 3.14.7で実行すると、一覧の応答は予約ID・施設名・チェックイン日・状態の4項目だけになりました。詳細の応答も7項目で、発行者識別番号、名義、有効期限、電話番号、同伴者は入りません。カードは下4桁だけを返し、名義と有効期限は決済の処理の中でしか読まない、という分け方です。新しい項目をテーブルに足したとき、許可リストに書かない限り応答に出ないので、うっかり公開される経路が減ります。
1つのトークンが1時間に他人の会員情報を何件読んだかを数える集計コード
会員が自分の予約や会員情報を読むのは普通の操作です。他人の会員情報を1時間に何十件も読むトークンは、運営側の業務用でない限り説明がつきません。この性質で異常を拾います。
# トークンごとに、1時間に読んだ「本人以外の会員」の数を数える
import json
from collections import defaultdict
THRESHOLD = 30 # 1時間あたりの上限。自社の通常値の数倍に置く
def find_bulk_readers(lines):
others = defaultdict(set)
for line in lines:
ev = json.loads(line)
if ev["action"] != "member.read":
continue
if ev["member_id"] == ev["subject"]:
continue # 本人が自分の情報を読んだ操作は数えない
hour = ev["time"][:13]
others[(ev["token_id"], hour)].add(ev["member_id"])
return {k: len(v) for k, v in others.items() if len(v) >= THRESHOLD}入力は、トークンID、トークンの持ち主（subject）、操作の種類、読まれた会員（member_id）、時刻を1行1件のJSONで記録した操作ログです。本人の情報を5回読んだトークンと、別のトークンが2分間で120人分の会員情報を読んだ記録を渡すと、後者だけが{('t-bad', '2026-10-20T10'): 120}として返りました。運営側の問い合わせ対応用アカウントは別のしきい値で数え、通知先は運用担当とは別の人にします。
個別通知メールを偽物と区別してもらうためのDMARCレコードの設定例
漏えいの後は、運営会社を装うメールが増えます。自社の通知メールを本物と確かめてもらうには、送信ドメイン認証を「失敗したら受け取らない」設定まで進めておく必要があります。DMARCは2026年5月にRFC 9989として改訂され、RFC 7489を置き換えました。改訂でpctタグが削除され、存在しないサブドメインへの方針を示すnpタグと、試験運用を示すtタグが加わっています。
; 例：example.com の DMARC レコード（DNS の TXT レコード）
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s"
; 反映の確認
dig +short TXT _dmarc.example.comp=rejectは認証に失敗したメールを受け取らないよう受信側に求める設定で、np=rejectは実在しないサブドメインを名乗るメールも同様に扱わせます。集計レポートの送り先はruaタグに自社の受信用アドレスを書いて足してください。いきなりrejectにすると正規の配信が止まることがあるため、noneから段階を踏む手順はフィッシング対策ガイドライン2026年度版のDMARC要件、タグの意味はDMARCの仕組みとレコードの書き方で解説しています。
予約サイトの運営者が当事者になったときの報告期限と外部点検の段取り
個人情報保護委員会への漏えい等の報告対象と発覚後の速報・確報の期限
個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある行為による個人データの漏えい等は、件数にかかわらず報告の対象です。本人の数が1,000人を超える漏えい等も別の類型として対象になります。速報は発覚から概ね3〜5日以内、確報は原則30日以内で、不正の目的によるものは60日以内とされています。
今回の楽天グループのように、国外の利用者を抱える予約サイトでは、国外の関係当局への報告も並行します。どの国の利用者が何件含まれるかを確報までに出せるよう、会員データに居住国を持っているかも点検項目です。報告の4類型と速報の書き方は個人情報保護委員会への報告義務と速報・確報の実務で解説しています。
予約サイトのAPIと管理画面を外部の目で点検するときの順番と採用条件
点検の順番は、予約照会や会員情報のAPIが返す項目の棚卸し、他人のIDを指定したときに拒否されるかの確認、1つのトークンが呼べる回数の上限の確認、管理画面のログインにMFAが必須かの確認、会員情報の読み出しログの保存期間と通知先の確認です。似た構図の予約サイトの事案として、skyticketの不正アクセスと予約完了ページの認可も参考になります。
外部の点検を入れるべきなのは、カードの一部情報や同伴者の情報を予約データに持つサイト、子会社や提携先が運営する画面と会員データを共有しているサイト、海外の利用者を抱えるサイトです。会員数が数千人規模で、APIを外部に公開していない社内向けの予約システムなら、上の5項目を自社で確かめるところから始めて構いません。APIの応答項目と認可、管理画面の認証をまとめて確かめたい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
楽天トラベルの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。
自分が対象かどうかはどうすれば分かりますか？
楽天グループは、対象となる利用者・予約者に順次、個別の連絡と注意喚起を行うとしています。自分で対象かを調べる画面は案内されていません。事象①は欧米やアジア・オセアニアの一部の海外ホテル予約ページ、事象②は多言語予約サイトが対象です。連絡に似せた偽のメールも考えられるため、リンクから操作せず、公式の問い合わせ先で確かめてください。
クレジットカードは再発行したほうがよいですか？
発表は、対象の支払情報だけでは決済やキャッシングの不正利用はできないとしており、再発行には触れていません。対象となったのは発行者識別番号と下4桁、名義、有効期限、国際ブランド区分で、番号の全桁とセキュリティコードは含まれません。利用明細に身に覚えのない請求があるときや不安が残るときは、カード裏面の番号からカード会社に相談してください。
パスワードは変更する必要がありますか？
発表では、パスワードは対象の情報に含まれていません。ただし、メールアドレスと氏名が知られると、楽天を装ったログイン画面へ誘導するメールが届きやすくなります。偽の画面にパスワードを入れてしまった場合は、すぐに公式サイトから変更し、同じパスワードを使う他のサービスも変更してください。
楽天トラベルの国内の宿の予約も対象ですか？
発表の対象は、海外ホテル予約サイトのうちRakuten Travel Xchangeが管理・運営する一部のページと、多言語予約サイトの2つです。楽天グループのセキュリティ専門チームによるモニタリングでは、当該サイト以外で同様の事象は確認されていないとしています。二次被害やその他のサービスへの影響も、10月26日時点では確認されていません。
原因や補償は発表されていますか？
10月28日時点の発表には、侵入の手口、不正アクセスが始まった時期、補償のいずれも書かれていません。原因は特定済みで、アクセス経路の遮断とシステムの改修を終えたとされています。続報が出た場合に備え、楽天トラベルのお知らせ一覧を確認してください。
関連記事
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：会員情報を読むAPIの認可と回数制限を実装するときに
- skyticket不正アクセスの対象確認と1,464万件の範囲：同じ旅行予約サイトの事案と予約ページの認可
- 手間いらずの不正アクセス・情報漏洩（最大約445万人）｜届くメールの見分け方と施設の点検手順：宿泊施設が受けるフィッシングへの備え
- フィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順：通知メールを本物と確かめてもらう送信側の設定
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：自社が当事者になったときの報告手順
