はじめに
日本航空（JAL）と日本トランスオーシャン航空（JTA）は2026年10月28日、予約・発券などを担う旅客サービスシステムの委託先が不正アクセスを受け、約9万2,000人分の予約情報が外部から参照された形跡があると発表しました。翌29日には、全日本空輸（ANA）も同じ委託先からの報告を受け、一部の顧客の個人情報が閲覧された形跡があると公表しています。
委託先は、スペインのアマデウス（Amadeus IT Group）です。世界の多くの航空会社が使っている、いわば業界の共通基盤のような存在です。
自社のシステムが直接攻撃されたわけではなくても、顧客から見れば「JALから」「ANAから」情報が漏れたことになります。そして、こうした大手ベンダーは、問題が起きたからといって簡単に乗り換えられる相手ではありません。
この記事では、事案の概要を整理したうえで、「代わりがきかない委託先」に業務やデータを預けるとき、発注側が何を決めておくべきかを、コンサルタントの視点で考えます。
何が起きたのか
JALの発表（2026年10月28日）と報道をもとに整理すると、概要は次のとおりです。
- 10月23日：JALが委託先のアマデウスから不正アクセスの報告を受ける
- 10月28日：JAL・JTAが公表。対象は2023年8月10日〜2026年9月23日の予約記録の一部
- 10月29日：ANAも、アマデウスからの報告を受けて予約情報への不正アクセスを公表
JAL・JTAの対象は約9万2,000人で、予約番号・氏名・搭乗区間などの予約情報が中心です。このうち約2,000人については、パスポート番号や国籍、連絡先なども含まれていたとされています。クレジットカード番号やパスワードは含まれず、現時点で不正利用は確認されていないとのことです。
ANAは、影響を受けた人数や項目、不正アクセスの時期をまだ明らかにしておらず、アマデウスと連携して調査を進めるとしています。報道によれば、韓国の大韓航空やアシアナ航空も、10月23日に同じシステムに関する告知を出しています。
侵入の手口や原因は、各社の発表時点では明らかにされていません。
なぜ「委託先経由」の漏えいは起きるのか
今回の事案は航空業界の話ですが、構造そのものは多くの企業に当てはまります。
業務の中核を外部の基盤に預けるのが当たり前になった
予約、会計、人事、顧客管理など、業務の中核をSaaSや業界共通のプラットフォームに載せるのは、今では当たり前の選択です。コストを抑え、運用の手間を減らせるからです。ANAも、国際線に続いて2026年5月に国内線をアマデウスのシステムに移行したと報じられています。
その結果、「自社の顧客データの多くが、自社の外にある」という状態が普通になりました。
共通基盤は、狙われたときの影響が大きい
多くの企業が使う基盤は、攻撃者から見れば「一度入れば多くの会社のデータに届く」場所です。1社が対策をがんばっても、共通基盤側に穴があれば、利用している全社が同時に影響を受けます。
発注側からは「中が見えない」
大手ベンダーほど、個別の顧客に合わせて契約条件を変えてくれることは少なく、監査を求めても標準の報告書が渡されるだけ、ということがよくあります。発注側は「大手だから大丈夫だろう」と考え、預けているデータの範囲や、事故のときに何が起きるかを詰めないまま使い続けがちです。
発注側が自社で整えておきたい仕組み
ここからは、発注側を支援するコンサルタントとして、「代わりがきかない委託先」と付き合うために整えておきたいことを挙げます。ポイントは、「相手を変えられないなら、自社側でコントロールできる部分を増やす」という考え方です。
1. 「代替困難な委託先」を一覧にして、重さを測る
まず、業務の停止や漏えいが起きたときに、すぐには乗り換えられない委託先を洗い出します。基準は「止まったら業務が止まるか」「顧客の個人情報を預けているか」「乗り換えに半年以上かかるか」の3つで十分です。
この一覧は、情シスだけでなく、事業部門や法務、経営層と共有しておきます。どこに依存しているかが見えていないと、事故が起きたときに「どの業務が、どの顧客に、どう影響するか」をすぐに説明できません。
2. 「預けるデータ」を最小限にする設計を要件に入れる
委託先のセキュリティを自社で直接コントロールすることはできません。しかし、何を預けるかは自社で決められます。
今回、パスポート番号などが含まれていたのは一部の顧客に限られていました。このように、業務上必要なときだけ機微な情報を持たせる、一定期間が過ぎたら削除・匿名化する、といった設計ができているかは、被害の大きさを左右します。
導入や更改のときには、「どの項目を、いつまで、どこに置くか」をデータ項目ごとに決め、要件定義書に残しておきます。後から変えるのは難しいので、最初の要件で決めておくのが大切です。
3. 契約で「通知の期限」と「伝えてほしい内容」を決める
今回、JALは委託先から報告を受けてから5日後に公表しています。発注側にとって、委託先からの第一報がいつ届くかは、その後の対応すべてに影響します。
標準契約の変更に応じてもらいにくい相手でも、次の点は確認・交渉する価値があります。
- 事故を検知してから発注側に知らせるまでの期限
- 第一報に含めてほしい情報（影響範囲の見込み、対象期間、データ項目）
- 調査の途中経過をどの頻度で共有してもらえるか
- 発注側が顧客や当局に説明するための資料提供への協力
条件を変えられない場合でも、「標準契約ではここまでしか約束されていない」と把握しておくこと自体に意味があります。足りない部分は、自社側の準備で補うことになるからです。委託先のSaaSで事故が起きたときの備え方は、メール配信SaaS「ブラストメール」の事案を取り上げた記事でも整理しています。
4. 「委託先が事故を起こした場合」の対応手順を先に作る
多くの企業の事故対応手順は、自社のシステムが攻撃された場合を想定しています。しかし、委託先経由の場合、自社では原因の調査ができず、情報も委託先からの報告を待つしかありません。
そこで、委託先起因の事故を想定した手順を、別に用意しておくことをおすすめします。
- 委託先からの報告を受ける窓口と、社内でのエスカレーション先
- 委託先の調査が終わる前に、自社として何を、いつ公表するかの判断基準
- 顧客への連絡方法と、問い合わせ窓口を立ち上げる手順
- なりすましメールや偽サイトへの注意喚起の文面のひな型
年に一度は、主要な委託先が事故を起こしたという想定で、机上訓練をしておくと実際に動けるようになります。
5. 「大手だから」で評価を止めない
代わりがきかない相手だからこそ、定期的な評価をやめないことが大切です。第三者認証や監査報告書を毎年受け取り、内容を確認する、ベンダーのセキュリティ情報や障害報告を追いかける、同業他社や業界団体と情報を交換する、といった活動を誰が担当するのかを決めておきます。
また、すぐに乗り換えられないとしても、「乗り換えるとしたら何が必要か」を一度整理しておくと、ベンダーとの交渉の場で発注側の立場を保ちやすくなります。
まとめ
JALとANAの事案は、自社のシステムが攻撃されなくても、業務やデータを預けた委託先を通じて顧客に影響が及ぶことを改めて示しました。業界の共通基盤のような大手ベンダーは、乗り換えも契約条件の変更も簡単ではありません。だからこそ発注側は、代替が難しい委託先を把握し、預けるデータを最小限にし、通知の期限を契約で確かめ、委託先起因の事故に備えた手順を用意しておくことが大切です。「相手を変えられないなら、自社でコントロールできる範囲を増やす」。この考え方で、自社の委託先との付き合い方を一度見直してみてください。
参考
- 日本航空 お知らせ（2026年10月28日）
- ITmedia NEWS「ANAの予約情報に不正アクセス、JALと同じ委託先経由で」（2026年10月29日）
- 朝日新聞（Yahoo!ニュース）「JALとANAの委託先に不正アクセス 個人情報閲覧の形跡」
- 株式会社アクト「JAL・JTAの予約情報約9.2万名分に不正アクセス 委託先アマデウスで」
- セキュリティ対策Lab「ANA、アマデウスへの不正アクセスで予約情報に外部参照の形跡」
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント