日本航空（JAL）と日本トランスオーシャン航空（JTA）は2026年10月28日、旅客サービスシステムの委託先であるアマデウス（Amadeus IT Group）への不正アクセスで、予約情報の一部が外部から参照された形跡があると発表しました。対象は約9万2000人で、うち約2,000人は旅券番号やマイレージ番号まで含まれます。同じ委託先を使うANA・アシアナ航空・大韓航空なども相次いで公表しました。前半では予約した人が対象かどうかを確かめる手がかりと窓口を、後半では企業が出張記録から対象社員を抜き出す手順と、委託先のシステムアカウントの使われ方を監視するコードをPythonで示します。
まとめ：JAL不正アクセスで参照された予約情報と利用者・企業がいま確かめること
JAL・JTAの発表を報じたAviation Wire・トラベルボイスなど複数の報道で一致している内容は次のとおりです。JALの公式発表ページは本記事の確認環境から開けなかったため、報道の一致した範囲で書いています。
| 項目 | 公表内容（10月28日時点） |
|---|---|
| 委託先 | アマデウス（旅客サービスシステム） |
| JALへの報告 | 2026年10月23日 |
| 対象の予約記録 | 2023年8月10日〜2026年9月23日の一部 |
| 約9万人 | 予約番号・氏名・搭乗日・区間・クラス |
| 約2,000人 | 上記に加え連絡先・旅券番号・国籍など |
| 対象外 | クレジットカード番号・各種パスワード |
約2,000人の追加項目は、メールアドレス・電話番号・パスポート番号・国籍・マイレージ番号・航空券番号・座席情報などです。
予約した人は、JALからの個別連絡を待ちつつ、予約番号と搭乗日を書いた「変更」「返金」の連絡に応じないことが先です。企業は、出張で使ったJL・NU便の予約を自社の記録から抜き出し、国際線の出張者から確かめます。予約や会員の基盤を外部のサービスに預けている事業会社は、委託先に払い出したシステムアカウントの使われ方を自社のログで見られるかを点検します。
予約した人向け：対象かどうかの確かめ方と旅券番号まで載った約2,000人の備え
2023年8月10日〜2026年9月23日の読み方と個別連絡・専用窓口の番号
対象期間は、予約日や搭乗日ではありません。Aviation Wireによると、アマデウスのシステム上に予約情報が存在していた期間です。2023年7月に予約して8月20日に乗った便も、記録がシステムに残っていた以上は期間に入りえます。逆に、9月24日以降に作った予約は入りません。
JL便名またはNU便名の予約記録を持っていた人のうち一部が対象で、全員ではありません。JALは対象者に個別に連絡するとしています。問い合わせ窓口は10月29日に開設され、国内は0120-25-6050と03-4332-7280、海外からは+81-3-4332-7280です。受付は日本時間10時から17時、土日祝日は休みです。
予約番号と搭乗日を知った相手からの「予約変更」「返金」連絡に応じない理由
参照された5項目（予約番号・氏名・搭乗日・区間・クラス）がそろうと、実際の旅程を書いた連絡文を作れます。「ご搭乗便の欠航に伴う払い戻し」「予約の再確認」と称するメールやSMSが、本物と見分けにくくなる組み合わせです。JALは、JALグループを装った不審なメール・電話・偽サイトへの誘導に注意するよう呼びかけています。
IPAの安心相談窓口だより（10月26日）は、氏名・メールアドレス・電話番号が漏えいした場合、突然届くメールやSMSは基本的に詐欺と考えてリンクを開かないよう求めています。予約の確認は、届いた文面のリンクではなく、自分で開いたJALの公式アプリやサイトから行います。同じ旅行予約の分野で、メールの本物の見分け方を扱った例はskyticketの不正アクセスと本物メールの見分け方です。
約2,000人に入った人は、パスポート番号と国籍、マイレージ番号まで知られています。IPAの同じ資料が信用情報機関への本人申告を挙げているのは、運転免許証などの本人確認書類の画像が漏れた場合です。今回はカードやパスワードではなく番号の参照なので、マイレージのパスワードをほかのサービスと使い回していないかの見直しが現実的な対処になります。
公表資料で追う経緯：アマデウスの声明と韓国2社・ANAの公表で異なる説明
9月24日の検知から10月28日の公表まで、航空会社ごとの日付と件数
同じ委託先の事案でも、航空会社が知った日と公表した日は数日ずつずれています。
| 航空会社 | 委託先から知った日 | 公表日 | 対象 |
|---|---|---|---|
| アシアナ航空 | 10月20日 22時49分 | 10月23日 | 一部顧客の予約番号 |
| ANA | 10月20日 | 10月29日・30日 | 約3万7800人 |
| JAL・JTA | 10月23日 | 10月28日 | 約9万2000人 |
アシアナ航空の告知は、アマデウスから公式の通知を受けた時刻を分単位で書き、自社のデータベースへの侵害の形跡はないと確認しています。Aviation WireによるANAの発表の報道では、アマデウスは9月24日に不正アクセスを検知していました。ANAは10月16日に他社の被害情報を得て自ら照会し、20日に報告を受けています。検知から委託元への通知まで、およそ4週間かかった計算です。
「表示環境の脆弱性」と「システムアカウントの認証情報」の2つの説明
アマデウスの声明（October 2026）は、旅行予約の表示環境に影響する脆弱性を把握し、その脆弱性を通じて予約表示データにアクセスできる状態だったと書いています。決済・金融データにアクセスされた証拠はなく、ランサムウェア目的で悪用された兆候もないとし、修正と監視・検知の強化を済ませたとしています。
一方でアシアナ航空の告知は、原因を「アマデウスのシステムアカウントに付与されたログイン認証情報を用いた非認可アクセス」と説明しました。ANAの報道でも、関係する認証情報は無効化されたとされています。表示画面の作りの問題と、人ではなくシステムに払い出したアカウントの認証情報の悪用が重なった事案と読めます。認証情報がどこから漏れたか、侵入の手口は公表されていません。
企業の出張管理：JL・NU便の予約記録から対象社員を抜き出すPythonの例
予約日でも搭乗日でもなく「記録が存在した期間」で区切る条件の書き方
出張手配の記録から対象者を探すとき、搭乗日だけで区切ると取りこぼしが出ます。2023年8月10日より前に予約して、その後に乗った便の記録は、期間の初日にシステム上に残っていました。条件は「予約を作った日が2026年9月23日以前」かつ「搭乗日が2023年8月10日以降」の2つで書けます。
次のコードは、出張手配システムから書き出した想定のCSVをcsvモジュールで読み、便名の先頭2文字がJLかNUの予約を、datetime.dateで比べて抜き出します。往復の片方が国外の空港なら国際線として印を付けます。
# 出張手配の記録から、公表された対象期間に JL・NU 便名の予約を持つ社員を抜き出す（Python 3.9以上・標準ライブラリのみ）
import csv
import io
import sys
from datetime import date
# 出張手配システムから書き出した想定のCSV（created=予約作成日、flight_date=搭乗日）
SRC = """emp_id,name,flight,created,flight_date,route
E001,山田 太郎,JL0123,2023-08-01,2023-08-20,HND-ITM
E002,佐藤 花子,JL0407,2024-02-10,2024-03-05,NRT-FRA
E002,佐藤 花子,NH0203,2024-05-01,2024-05-20,HND-FRA
E003,鈴木 一郎,NU0601,2025-07-01,2025-07-15,NHA-ISG
E004,高橋 次郎,JL0005,2026-09-20,2026-10-30,HND-JFK
E005,伊藤 三郎,JL0905,2026-09-24,2026-10-02,HND-OKA
"""
FROM, TO = date(2023, 8, 10), date(2026, 9, 23) # 予約情報がシステム上にあった期間（両端を含む）
DOMESTIC = {"HND", "NRT", "ITM", "KIX", "NHA", "ISG", "OKA", "CTS", "FUK"}
def in_scope(r):
# 期間中に予約記録が存在した＝作成日が TO 以前で、搭乗日が FROM 以降
created = date.fromisoformat(r["created"])
flown = date.fromisoformat(r["flight_date"])
return r["flight"][:2] in ("JL", "NU") and created <= TO and flown >= FROM
people = {}
for r in csv.DictReader(io.StringIO(SRC)):
if not in_scope(r):
continue
intl = any(a not in DOMESTIC for a in r["route"].split("-"))
p = people.setdefault(r["emp_id"], {"name": r["name"], "bookings": [], "intl": False})
p["bookings"].append(f'{r["flight"]}:{r["flight_date"]}')
p["intl"] = p["intl"] or intl
out = csv.writer(sys.stdout, lineterminator="\n")
out.writerow(["emp_id", "name", "bookings", "passport_check"])
for emp, p in people.items():
# 国際線の予約がある人は、旅券番号まで載っている約2,000人側に入りうるので優先して確認する
out.writerow([emp, p["name"], "|".join(p["bookings"]), "優先" if p["intl"] else "-"])
print(f"# 対象 {len(people)}名", file=sys.stderr)空港コードの一覧は例として9空港だけを入れています。実際の運用では、自社の出張先に合わせて国内空港を足します。
実行結果の4名と国際線の予約を持つ社員を優先して確認する理由
Python 3.14.10（Windows）で2026年11月11日に、python -X utf8 trip_check.pyとして実行した結果です。JALやアマデウスのデータ形式を再現したものではありません。
# 対象 4名
emp_id,name,bookings,passport_check
E001,山田 太郎,JL0123:2023-08-20,-
E002,佐藤 花子,JL0407:2024-03-05,優先
E003,鈴木 一郎,NU0601:2025-07-15,-
E004,高橋 次郎,JL0005:2026-10-30,優先E001は予約が8月1日で期間の前ですが、搭乗日が8月20日なので記録は期間中に残っており、対象に入ります。E004は搭乗が10月30日でも、予約が9月20日なので抽出の対象です。E005は9月24日の予約で外れ、佐藤さんのNH便（ANA）は今回のJALの抽出から外れます。ANAも同じ委託先の事案を公表しているので、NH便は別の条件で同じ抽出をかけます。
国際線の予約に「優先」を付けたのは、旅券番号と国籍は国際線の手配で入力される項目だからです。約2,000人の内訳が国際線の予約に偏るとは公表されていないため、これは確かめる順番の目安にとどまります。対象かどうかの最終判断は、JALからの個別連絡と窓口の回答で行います。
開発者の実装：システムアカウントの参照件数と接続元を平常値と比べる検知コード
3年間気づかれなかった型を前提にしたアカウントごとの平常値と閾値
今回の対象期間は約3年あります。アシアナ航空の説明どおりシステムアカウントの認証情報が使われていたなら、ログ上は「いつものシステムが、いつものアカウントで予約を読んでいる」ように見えます。人のアカウントのように、深夜のログインや見慣れない端末では引っかかりません。
そこで見るのは、アカウントごとの1日の参照件数と接続元です。次のコードは、監査ログを日次で集計した想定のCSVを読み、先頭7日を平常値として学習します。statisticsモジュールの中央値と、中央値からの偏差の中央値（MAD）を使い、平常値＋5×MADを超えた日と、学習期間に見なかった接続元を通報します。平均と標準偏差ではなく中央値を使うのは、外れ値の日が混ざっても基準が引きずられないためです。
# システムアカウントの参照件数と接続元を、アカウント自身の平常値と比べて検知する（Python 3.9以上・標準ライブラリのみ）
import csv
import io
import statistics
from collections import defaultdict
# 監査ログを日次・アカウント・接続元で集計した想定のCSV（reads=予約記録を読んだ件数）
LOG = """day,account,src,reads
2026-09-14,svc-checkin,10.0.1.5,1180
2026-09-15,svc-checkin,10.0.1.5,1210
2026-09-16,svc-checkin,10.0.1.5,1195
2026-09-17,svc-checkin,10.0.1.5,1230
2026-09-18,svc-checkin,10.0.1.5,1205
2026-09-19,svc-checkin,10.0.1.5,1190
2026-09-20,svc-checkin,10.0.1.5,1220
2026-09-21,svc-checkin,10.0.1.5,1200
2026-09-21,svc-checkin,203.0.113.40,35
2026-09-22,svc-checkin,10.0.1.5,1215
2026-09-22,svc-checkin,203.0.113.40,38
2026-09-23,svc-checkin,10.0.1.5,4980
2026-09-14,svc-report,10.0.2.8,300
2026-09-15,svc-report,10.0.2.8,310
2026-09-16,svc-report,10.0.2.8,290
2026-09-17,svc-report,10.0.2.8,305
2026-09-18,svc-report,10.0.2.8,295
2026-09-19,svc-report,10.0.2.8,300
2026-09-20,svc-report,10.0.2.8,315
2026-09-21,svc-report,10.0.2.8,310
2026-09-22,svc-report,10.0.2.8,298
2026-09-23,svc-report,10.0.2.8,305
"""
LEARN_DAYS = 7 # 先頭7日を平常値として学習する
K = 5 # 中央値 + K × MAD を超えた日を通報する
rows = list(csv.DictReader(io.StringIO(LOG)))
days = sorted({r["day"] for r in rows})
learn = set(days[:LEARN_DAYS])
daily = defaultdict(int) # (account, day) -> 合計件数
known_src = defaultdict(set) # 学習期間に見た接続元
for r in rows:
daily[(r["account"], r["day"])] += int(r["reads"])
if r["day"] in learn:
known_src[r["account"]].add(r["src"])
for acct in sorted({r["account"] for r in rows}):
base = [daily[(acct, d)] for d in days if d in learn]
med = statistics.median(base)
mad = statistics.median(abs(x - med) for x in base) or 1
limit = med + K * mad
for d in days[LEARN_DAYS:]:
n = daily[(acct, d)]
if n > limit:
print(f"{d} {acct} 件数 {n}（上限 {limit:.0f}）")
for r in rows:
if r["account"] == acct and r["day"] not in learn and r["src"] not in known_src[acct]:
print(f'{r["day"]} {acct} 新しい接続元 {r["src"]}（{r["reads"]}件）')ログの集計は、利用しているSaaSが出す監査ログやAPIの呼び出し記録を、日・アカウント・接続元の3つで数える前提です。委託先がこの粒度のログを出さない場合は、契約で求める項目になります。
実行結果の3件と人のアカウントより先にシステムアカウントを点検する理由
Python 3.14.10（Windows）で2026年11月11日に実行した結果です。値は説明用の架空のもので、アマデウスのログを再現したものではありません。
2026-09-23 svc-checkin 件数 4980（上限 1280）
2026-09-21 svc-checkin 新しい接続元 203.0.113.40（35件）
2026-09-22 svc-checkin 新しい接続元 203.0.113.40（38件）svc-checkinの平常値は中央値1205件、MADは15件で、上限は1280件です。9月23日の4,980件は件数で引っかかります。注目したいのは9月21日と22日です。見慣れない接続元から1日35件ほどしか読んでおらず、合計件数は平常値の範囲に収まっています。件数の閾値だけでは見逃し、接続元の比較でだけ拾える型です。少量ずつ長く読む不正アクセスは、件数ではなく「誰がどこから」で捕まえます。
システムアカウントは、パスワードの定期変更や多要素認証の対象から外されがちで、退職者のアカウントのような棚卸しの機会もありません。人のアカウントより先に、払い出した先・権限・最終利用日・接続元の4点を一覧にします。貸し出しと操作記録の考え方は特権ID管理の仕組みと監査で問われる要件、キーの失効と再発行の手順はAPI不正アクセス対策の実装手順にまとめています。
委託元の判断：予約基盤の委託先を使い続ける条件と自社側で診断する範囲
委託先から通知を受けた日が起点になる報告期限と速報・確報の分担
個人情報保護法ガイドライン（通則編）の3-5-3-2は、取扱いを委託している場合、報告対象の事態では原則として委託元と委託先の双方が報告義務を負うとしています。3-5-3-5により、委託元は遅くとも委託先から通知を受けた時点で事態を知ったことになります。JALなら10月23日、ANAなら10月20日が起点です。
速報の目安は知った時点から概ね3〜5日以内で、不正アクセスのような不正の目的による漏えいは、確報の期限が60日以内です。アマデウスの検知が9月24日でも、委託元の期限を数える起点は通知を受けた日です。ただし通知が遅れた分、本人への連絡も遅れます。報告の様式と本人通知の流れは個人情報保護委員会への報告義務の実務に、委員会の窓口は漏えい等の対応とお役立ち資料にあります。
委託先に求める3つの資料と自社の連携アカウント・APIキーの点検範囲
予約・会員の基盤のように乗り換えに年単位かかる委託先は、事故1回で切り替える判断になりません。使い続ける条件は、委託先から3つの資料を受け取れるかで決めます。自社分のどの記録が参照されたかの一覧、使われた認証情報の種類と無効化した日、検知から委託元への通知までの社内手順の見直しです。今回は検知から通知までに約4週間かかっているので、3つ目を契約の通知期限として書き込めるかが分かれ目です。
委託先を選ぶときと契約で決めておく報告の取り決めは委託先管理と個人情報保護法25条の監督義務、委託先経由の侵害の型はサプライチェーン攻撃の起点別3類型、委託先ごとに預けた項目を棚卸しするコードはNTTデータ委託先の情報漏洩と漏えい項目で扱いました。
自社側では、委託先のSaaSに入れる管理アカウント、連携のために払い出したAPIキー、委託先から自社システムに入ってくる接続の3つを点検します。権限の広すぎるアカウントや失効していないキーが残っていないかを第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
JALの不正アクセスについて、予約した人と、出張手配や予約基盤を管理する企業の担当者から出やすい質問をまとめました。
JALの不正アクセスで自分が対象かどうか、どこで確かめられますか？
JALは対象者に個別に連絡するという案内です。待たずに確かめたい場合は、10月29日に開設された窓口に問い合わせます。番号は国内が0120-25-6050と03-4332-7280、海外からが+81-3-4332-7280で、受付は日本時間10時から17時、土日祝日を除きます。対象は2023年8月10日から2026年9月23日にアマデウスのシステム上にあったJL・NU便名の予約記録の一部です。
クレジットカード情報やJALのパスワードは漏れましたか？
報道によると、JALの説明ではクレジットカード番号と各種パスワードの漏えいはないとのことです。アマデウスの声明も、決済・金融データにアクセスされた証拠はないと書いています。ただし予約番号・氏名・搭乗日は参照されているので、旅程を書いた偽の払い戻しや予約確認の連絡には応じず、公式アプリやサイトから確かめます。
パスポート番号が対象になった約2,000人は何をすればよいですか？
約2,000人は、連絡先・パスポート番号・国籍・マイレージ番号・航空券番号・座席情報なども参照された人です。JALからの個別連絡で、自分がどちらの区分かを確かめます。番号の参照で旅券が使えなくなるとは発表されていません。連絡先が知られている前提で、航空会社や大使館を名乗る連絡にはその場で応じず、公式の窓口にかけ直します。
ANAやほかの航空会社も同じ不正アクセスの対象ですか？
同じアマデウスのシステムを使うANAは10月29日・30日に約3万7800人の対象を公表し、アシアナ航空と大韓航空は10月23日に公表しました。報道では、キャセイパシフィック航空やフィンエアーなども自社の予約が影響を受けたとしています。航空会社ごとに対象の人数と項目が違うので、予約した会社の告知を個別に確かめます。
JALの不正アクセスの原因は何ですか？
JALの発表では、委託先アマデウスへの不正アクセスとされています。アマデウスは旅行予約の表示環境の脆弱性を、アシアナ航空はアマデウスのシステムアカウントに付与されたログイン認証情報を使った非認可アクセスを原因に挙げています。認証情報の入手経路や侵入の手口は11月11日時点で公表されていません。
関連記事
- skyticket不正アクセス：1,464万件流出の対象確認と本物メールの見分け方：旅行予約サービスの流出で利用者が確かめること
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：委託元が出す速報と確報の書き方
- 委託先管理とは？個人情報保護法25条の監督義務とチェックリスト・契約条項の実務：委託先との契約で決めておく通知期限
- 特権ID管理とは：貸出・操作記録・パスワード変更の仕組みと監査で問われる要件：システムアカウントの棚卸しと操作記録
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：連携のAPIキーを失効・再発行する手順
