JAL・アマデウスの予約システム不正アクセス：委託先リスクをAIで防ぐ実務対策

公開日：2026年10月28日更新日：2026年11月3日文：クリスタルメソッド編集部監修：河合継（代表取締役）

予約システムへの不正アクセス事案：何が起きたか

2026年10月28日、日本航空（JAL）および日本トランスオーシャン航空（JTA）は、旅客サービスシステムの委託先であるスペインのアマデウス社のシステムが不正アクセスを受けたと発表した（トラベルボイス（観光産業ニュース）、日本経済新聞）。被害に遭われた方々に対して深くお見舞い申し上げる。

対象は2023年8月10日から2026年9月23日にかけてシステム上に存在した予約記録の一部で、約9万2000人分の予約情報が閲覧された可能性がある。このうち約9万人分は予約番号・氏名・搭乗日・搭乗区間・搭乗クラス、さらに約2000人分はメールアドレス・電話番号・パスポート番号・国籍・マイレージ番号・便名・座席番号まで含まれる（www.aviationwire.jp）。クレジットカード番号・各種パスワードの漏洩は確認されておらず、現時点で不正利用の事実も確認されていない（日本経済新聞）。

JALがアマデウスから報告を受けたのは2026年10月23日。同日、韓国の大韓航空・アシアナ航空でも同じシステム経由の情報流出が発覚しており、ANAも同システムを利用して不正アクセスの有無を確認中だという（トラベルボイス（観光産業ニュース））。

同じ時期に国内外でどのような被害が出ているかは、日本・世界の主なAIハッキング被害一覧で解説しています。

関連記事AIによる情報漏洩とは？漏れる原因と企業の対策は？

なぜこうした事案は繰り返されるのか：委託先リスクの構造的課題

今回の事案で核心をなすのは、不正アクセスの起点がJAL自身のシステムではなく、委託先であるアマデウス社のプラットフォームだった点だ。JALは2017年にアマデウスのAlteaシステムへ移行しており、同システムは複数の航空会社が共同利用する大規模な基盤である（日本経済新聞、www.aviationwire.jp）。複数社が同一基盤を共有する構造は、一社での侵害が他社の利用者データにも波及するリスクを内包している。

この構造は旅行・航空業界に限らない。予約・在庫・決済などの基幹機能をSaaSや外部ベンダーに委託している企業では、自社のセキュリティ投資がいかに充実していても、委託先の脆弱性が直接的な侵害の入口になりうる。発見の遅れも深刻な課題だ。今回の対象期間は2023年8月から2026年9月まで及ぶが、JALが報告を受けたのは2026年10月23日であり、異常が長期間検知されなかった可能性がある。予約システムはパスポート番号・国籍・渡航パターンといった機微情報を保持するため、流出した場合はなりすまし・フィッシングなど二次被害のリスクが高まる。

図：委託先システムを起点とした不正アクセスの伝播経路（赤の破線）と、AI異常検知レイヤーによる早期発見の位置づけ（緑の破線）。自社フロントエンドのセキュリティだけでは委託先経由の侵害を防げず、監視対象をサプライチェーン全体に拡張する必要がある。

次に読む：AIセキュリティ対策とは？企業が知るべきリスクは？

AIセキュリティ対策とは？企業が知るべきリスクと今すぐできる対策【2026年】

予約システムの不正アクセス防止にAIをどう活用するか

未然に防ぐ：アクセスパターンの統計的外れ値を検知する

予約システムへの正規アクセスは一定の行動パターンを持つ。検索・比較・選択・購入という一連のフローに沿ったアクセスが大半を占め、操作間隔・対象レコードの範囲・セッション継続時間には自然な分布がある。これに対して、短時間で大量の予約レコードを参照するスクレイピング的なアクセスや、通常ありえない時間帯・地域からのログインは統計的な外れ値として浮かび上がる。

機械学習を用いた異常検知モデルは、こうした外れ値をルールベースのファイアウォールよりも柔軟に、かつ新種のパターンに適応しながら捉えられる。IPアドレスごとのリクエスト頻度・アクセス対象レコードの分散・ユーザーエージェントの組み合わせなどを特徴量として学習し、通常の分布から乖離したセッションに対してアラートを発する構成が基本だ。教師なし学習（クラスタリングや自己符号化器）を用いることで、過去の攻撃事例として学習していないパターンにも対応しやすくなる。

早く見つける：委託先のログを含めた統合監視

今回の事案が示すように、委託先で起きた異常を自社が把握するまでにはタイムラグが生じやすい。このギャップを縮めるには、SIEM（セキュリティ情報・イベント管理）にAI分析エンジンを組み合わせ、委託先から提供されるAPIログ・アクセスログを自社の監視基盤に取り込む構成が有効だ。

自然言語処理を活用したログ解析ツールは、膨大なログから意味のあるイベントシーケンスを自動抽出し、セキュリティ担当者が目視で追いきれない量の異常候補を優先度付きで絞り込む。どの委託先にどの権限でどの範囲のデータを参照させているかをリアルタイムで把握できれば、問題の切り分けと初動対応の速度が上がる。

被害を小さくする：機微情報へのアクセス制御をAIで補強する

パスポート番号・電話番号・国籍といった機微情報は、業務上必要なロール以外には見えない設計が基本だ。AIを用いたデータ分類ツールは、システム内に散在する個人情報フィールドを自動的に特定し、意図せず平文で保存されている箇所や、過剰なアクセス権が付与されているAPIエンドポイントを検出する。定期的なスキャンをデプロイパイプラインに組み込むことで、設定変更や仕様追加に伴う過剰公開を早期に発見できる。

アクセス制御の評価にもAIは活用できる。実際のアクセスログからロール別の利用実態を可視化し、「権限は付与されているが実際には使われていない過剰権限」を洗い出して最小権限原則への是正を促す仕組みは、ゼロトラスト設計の実装コストを下げる効果が期待できる。

業種別・立場別に見る具体的な対応アクション

今回の事案を踏まえ、業種・立場ごとに検討すべき対応を整理する。

業種・立場	主な課題	AIを活用した具体的な対応
航空・旅行会社（システム委託元）	委託先のログを自社で監視できていない	委託先APIのアクセスログをSIEMに集約しAI異常検知を適用。契約でログ提供義務と通知期限を明記する
OTA・予約プラットフォーム	大量参照型スクレイピングと正規アクセスの区別が難しい	機械学習ベースのボット検知を導入。セッション単位の行動分析でルールベース検知を補完する
ECサイト・チケット販売	個人情報の保存箇所が複数システムに分散している	AIデータ分類ツールで個人情報フィールドを自動スキャン。過剰権限APIの棚卸しを継続的に自動化する
ITセキュリティ担当者（全業種）	ログ量が多く手動では追跡しきれない	SIEMのAI分析機能でアラートを優先度付け。SOAR（自動対応）と組み合わせて初動対応の一部を自動化する
調達・ベンダー管理部門	委託先のセキュリティ水準が不明瞭	AIを活用したサードパーティリスク評価ツールで委託先のセキュリティスコアを定期モニタリングする

AIで解決できないこと：現場担当者が押さえるべき限界と注意点

誤検知と見逃しのトレードオフ。AI異常検知モデルは感度を上げると正規アクセスへの誤ブロック（誤検知）が増え、絞り込みすぎると本物の攻撃を見逃す。旅行繁忙期やセール期間中はアクセスパターンが大きく変動するため、モデルを定期的に再学習させない限り「繁忙期の大量アクセス＝異常」と誤判定するリスクがある。最終的な判断は人が行う体制が不可欠だ。

委託先への適用限界。AIによる監視は自社が制御できる範囲でのみ有効に機能する。委託先のシステムに自社の監視エージェントを埋め込むことは多くの場合できない。ログの提供範囲・形式・頻度をSLAや契約に盛り込み、受け取ったデータを分析する形が現実的な対応になる。技術的な防御だけを先行させ、契約上の手当てを後回しにすると死角が残る。

監視しすぎによるプライバシーリスク。行動分析を精緻にやりすぎると、正規ユーザーの個人情報を必要以上に収集・解析することになり、個人情報保護法の観点での問題が生じうる。何をどの目的で収集・分析するかを明確にし、利用目的の範囲内に収める設計が必要だ。

未知の攻撃手口にはAIが追いつくまでのギャップがある。今回のような大規模な共有プラットフォームへの攻撃は、類似事例がなければAIモデルの学習データに存在しない。新種の手口に対してAIが対応するまでの空白期間を埋めるのは、人間の判断と定期的なペネトレーションテスト・脆弱性診断だ。AIはそのサポートツールであり、全てを代替するものではない。

コストと運用体制。SIEMとAI分析エンジンの組み合わせは、初期構築・チューニング・継続的な運用に相応のコストと専門人材を要する。小規模事業者にとって自社構築のハードルは高く、マネージドSOCサービスやクラウドプロバイダーが提供するセキュリティサービスの活用が現実的な選択肢となる場合も多い。

明日から着手できる実務的な確認事項

大規模なシステム刷新よりも先に、現状の把握から始めることが実効性の高い第一歩だ。以下の確認を担当チームで行うことを推奨する。

まず、自社が利用する予約・在庫・決済関連の外部サービス・SaaSの一覧を洗い出し、それぞれについて「どの個人情報フィールドにアクセスできるか」「そのAPIキーやアカウントの権限範囲はどこまでか」を確認する。次に、各サービスのインシデント通知・ログ提供の仕組みが契約に含まれているかを確認し、含まれていない場合は契約改定または代替手段を検討する。

既存のSIEMやクラウドセキュリティサービス（AWSであればCloudTrail・GuardDuty、Google CloudであればCloud Audit Logs・Security Command Centerなど）が導入済みであれば、委託先からのAPIアクセスログをそこに集約する設定を追加できないかを確認する。この手順は既存契約の範囲で実施できる場合もある。

最後に、インシデント発生時の連絡体制と初動対応手順（誰がいつ何をするか）を文書化し、担当者間で共有する。技術的な防御と組織的な対応の両方が揃って初めて、予約システムの不正アクセス対策は実効性を持つ。

参考文献