ANA国内線リニューアルで大混乱、変更点と「なぜ不調か」を徹底解説

ANA（全日本空輸）が2026年5月19日に実施した国内線サービスのリニューアルで、予約・購入・チェックインといった利用者の接点に広く不具合が出ています。ANAは6月11日に公式サイトで「お客様には多大なるご不便とご心配をおかけしています」とお詫びを出し、問い合わせ窓口は電話がつながりにくく、メールの返信は「2週間〜2か月ほど」かかると報じられています。

この記事では、何が起きているのかを技術の視点で整理します。今回のリニューアルの正体は、ANAが約50年使ってきた自社開発の予約システムを、国際線と同じ世界標準のシステムへ載せ替える大移行でした。なぜ予約もチェックインも不調になったのか、利用者として何が変わったのか、そして「事前に防げたのか」「そもそもの土台（アーキテクチャ）の問題なのか」までを、確認できた事実と、まだ公表されていない部分を分けて掘り下げます。

今回つまずいたのは新しいシステムの土台が脆かったからではありません。世界の200社以上が使う標準基盤への移行そのものは堅実な計画でしたが、「リニューアルと同時に複数の変更を一気にやった」運用設計と、顧客接点の備えに穴がありました。過去の大規模移行トラブルとも共通する、繰り返される失敗の型です。

何がどう変わったのか

今回の刷新の中心は、ANA国内線の「旅客サービスシステム（PSS）」の入れ替えです。PSSとは、航空券の予約・発券・搭乗手続きを支える基幹システムのこと。ANAはこれまで、自社開発の「able-D（エイブル）」を使ってきました。able-Dは日本ユニシス（現BIPROGY）が構築したシステムで、2013年にはメインフレーム（大型汎用機）での34年間の運用から脱却し、大手ネットワーク航空会社として世界初の「オープンシステム化」を達成した、技術的にも由緒ある仕組みでした。

ANAはこのable-Dを廃止し、国際線ですでに使っているスペイン・アマデウス社のクラウド型システム「Altéa（アルテア）」へ統合しました。Altéaは世界200社以上が採用する業界標準で、JALも2017年から使っています。ANAは2023年2月にこの方針を発表し、国内線と国際線の予約を一つの基盤にまとめる「内際統合」を打ち出しました。ANAホールディングスのプレスリリースによれば、狙いは自社運用の固定費を外部委託の変動費に変えること、国内・国際の顧客情報を連携させること、そして世界標準を採用してサービス改善を速めることでした。

利用者から見た一番大きな変化は、2026年5月19日搭乗分からの国内線運賃の3種類化です。従来の細かい運賃体系が、変更可否などに応じて「Simple」「Standard」「Flex」の3つに整理され、あわせて予約・搭乗のルールが国際線と統一されました。つまり今回は、システムの載せ替えと、運賃の作り直しと、ルールの統一が同じ日に重なったわけです。この「同日に複数の変更」が、後で述べる混乱の引き金になります。

利用者にいま起きていること

移行が始まった5月19日以降、利用者からはさまざまな不調が報告されています。報道や利用者の声をまとめると、主な症状は次の通りです。

これらに加えて、移行期間特有の機能制限もかかっています。ANAの公式の案内によると、ウェブサイトからは一時的にお子様一人での特典航空券の予約ができないといった制限が出ているほか、システム移行期間中のサービス制限として、5月18日搭乗分までの便を5月19日以降の便へ変更できないなどの制約も生じています。5月19日から6月上旬にかけては全国の空港の設備やバックエンドを順次切り替える「移行期間」にあたり、この間は新旧のシステムが混在する不安定な状態が続きます。

SNS上では「炎上対応の遅さにはビックリ」「大手企業なのに粗末すぎ」といった批判の声も上がり、格安航空会社（LCC）と比較する反応も見られました。普段は意識しない予約システムが、いざ不調になると空港での待ち時間や予定変更に直結することが、改めて浮き彫りになっています。

移行のタイムライン

今回のリニューアルは突然始まったものではなく、3年がかりの大型プロジェクトの最終局面で起きました。発表から混乱までの流れを整理します。

← スワイプで移動

利用者目線での主な変更点

不具合とは別に、国際線と同じ仕組みに揃えたことで、利用ルールそのものも変わりました。公式に告知された運賃の3種類化に加えて、解説サイトや利用者の報告では次のような変更も指摘されています（不具合ではなく「仕様の変更」である点に注意してください）。

運賃の3種類化はANAが公式に告知したものですが、それ以外の細かなルール変更は、解説サイトの分析などで報告されている内容を含みます。いずれも「国際線と同じルールに統一する」という今回の方針から導かれるもので、システムが重く感じる一因も、国際線基準の複雑な運賃計算やアライアンス連携がバックエンドで常時動くようになったことにあると指摘されています。正確な適用条件は、予約前にANA公式サイトで確認することをおすすめします。

なぜ顧客接点で躓いたのか（筆者の分析）

ここからは事実の整理ではなく、筆者の見解を含む分析です。今回の混乱は、システムそのものが動かなかったというより、利用者との接点（予約画面・問い合わせ窓口）に負荷が集中して回らなくなった、という性格が強く見えます。この点を分析した記事の整理も参考に、要因を3つに絞ります。

第一に、変更を同じ日に詰め込みすぎたこと。5月19日には「システム移行」「運賃の作り直し」「予約ルールの統一」が同時に起きました。利用者から見れば疑問点が一度に増えるため、問い合わせの量は足し算ではなく掛け算で膨らみます。一つひとつは合理的でも、同時にやれば負荷が乗算的に跳ね上がる、という典型です。

第二に、問い合わせの急増に備える体制が薄かったこと。大きなリニューアルの直後に問い合わせが殺到するのは、業界では十分に予見できる事象です。それでも電話はつながりにくく、メール返信は数週間〜数か月という状態になりました。これは技術の問題というより、立ち上げ直後に手厚く人員を張る「ハイパーケア」の設計が小さすぎた、運用面の見積もりの問題だと考えられます。

第三に、世界標準と日本の利用者の期待のズレ。Altéaは世界中の航空会社が使う標準システムで、日本の国内線向けに磨かれてきたable-Dとは作法が違います。氏名のローマ字統一や手荷物の個数制など、グローバルでは当たり前でも国内利用者には戸惑いの大きい変更が一度に表面化しました。標準への統一は中長期では正しくても、移行の瞬間には摩擦を生みます。

事前に予測・回避できたのか

公平に見るべきは、ANAの技術的な移行計画は決して雑ではなかった、という点です。ANAは旧able-Dと新Altéaを約1年かけて並行稼働させる段階移行を選びました。5月18日搭乗分までは旧システムで予約記録を作り、5月19日以降は新システムで作る、という重ね方です。一気に切り替える「ビッグバン移行」のリスクを避けた、むしろ慎重な部類のやり方でした。

それでも顧客接点で混乱したのは、回避可能だった部分があったからだと筆者は見ています。問い合わせの急増は予見できたのだから、サポート人員の増強や、変更を時期をずらして少しずつ見せる工夫、移行を止める・進めるの判断基準（Go/No-Go）に「顧客接点が回るか」を入れておくことは可能だったはずです。技術の移行設計には力を入れたが、その出口にある「人が問い合わせる窓口」の容量設計が手薄だった——そこに今回の教訓があります。

そもそもアーキテクチャの問題なのか

「土台のシステム（アーキテクチャ）がしっかりしていれば起きなかったのでは」という疑問は自然です。結論から言えば、今回はアーキテクチャの欠陥が原因ではないと筆者は考えます。移行先のAltéaは世界200社以上が長年使う実績のある基盤で、JALも2017年から本番運用しています。基盤そのものが脆いという話ではありません。

対比として分かりやすいのがJALの事例です。JALは2017年11月16日に同じAltéaへ一晩で一括切り替えしました（社内では「SAKURAプロジェクト」と呼ばれ、JAL・アマデウス・JALインフォテック・三菱電機インフォメーションシステムズが関わったとされます）。同じ基盤でも、JALは一括切替、ANAは1年並行という別の進め方を採りました。基盤が同じでも結果が分かれるのは、躓きの所在が「土台」ではなく「移行の進め方」と「運用・顧客接点の設計」にあることの裏返しです。

言い換えると、アーキテクチャは合格点でも、移行設計と運用設計が伴わなければ顧客接点は崩れます。良い建物（基盤）を建てても、引っ越しの段取り（移行）と入居直後の管理人体制（運用）が甘ければ住人は混乱する、というイメージに近いでしょう。

開発の中身で、分かっていること・いないこと

エンジニアとして気になる「誰が作ったのか」「いくらかかったのか」「どのくらいの期間か」について、公表情報には濃淡があります。誤った推測を避けるため、確認できた範囲と非公表の範囲を分けて整理します。

新システムの中核がアマデウスのSaaSであること、旧able-Dを日本ユニシス（現BIPROGY）が構築したことは公表情報で確認できます。一方で、ANAの新システム移行を実装面で支えた統合パートナー（SIer）や開発費用は公表されていません。参考までに、JALの同種プロジェクトでは費用が数百億円規模と報じられ、JALインフォテックや三菱電機インフォメーションシステムズが関与したとされますが、ANAについて同等の情報は出ていません。ここを断定的に書く記事もありますが、本記事では確認できないものは「非公表」として扱います。

この事例から学べること（筆者の見解）

今回のANAの混乱は、特定の企業だけの失敗ではなく、大規模なシステム移行で繰り返し起きるパターンの最新例です。当サイトでは過去に日本のIT移行が失敗する5つのパターンを整理しましたが、ANAはそのうち「リニューアル初日に顧客接点が落ちる」型に重なります。ハローワークのサイトがリニューアルで重くなった事例とも構造が似ています。

エンジニアや発注側の立場で持ち帰れる教訓を、3点に絞ります。

1. 変更は分割して出す。システム移行・料金改定・ルール変更を同日に重ねると、利用者の混乱と問い合わせが乗算で膨らみます。技術的に同時にできることと、利用者に同時に見せてよいことは別問題です。

2. 顧客接点の容量をGo/No-Goに入れる。移行可否の判断基準は、技術的な切り替えの成否だけでなく「問い合わせが捌けるか」「サポートが回るか」を含めるべきです。立ち上げ直後のハイパーケアは、想定の数倍を見ておくくらいでちょうどよいことが多いものです。

3. 標準化の摩擦を前もって翻訳する。世界標準への統一は長期的には正しくても、国内利用者には作法の違いが摩擦になります。何がどう変わるのかを、移行前にかみ砕いて伝える「翻訳」の手間を惜しまないことが、結果的に問い合わせを減らします。基盤の刷新と同じくらい、決済インフラの全銀システムの全面刷新のような大型移行でも、この「出口の設計」が成否を分けます。

よくある質問

参照元

• ▸ANA - ウェブサイトリニューアルにおける機能制限について
• ▸ANA - システム移行期間のサービス制限について
• ▸ANAホールディングス - 国内線・国際線旅客サービスシステムの統合（2023年2月14日）
• ▸トラベルボイス - ANA、国内線もアマデウスに、自社システムからアウトソースへ移行
• ▸Aviation Wire - ANA、国内線旅客システムもアマデウスに 自社開発「エイブル」から
• ▸日経クロステック - ANA国内線の新旅客系システムが稼働開始へ 完全移行に1年
• ▸Infoseekニュース（ORICON NEWS）- ANA、サービス刷新の混乱で謝罪
• ▸JALがアマデウス「Altéa」にシステム移行（2017年11月16日）
• ▸note（ぶちょう）- ANAサービス刷新の混乱に学ぶ、なぜ大企業のシステム刷新は顧客接点で躓くのか
• ▸弾丸トラベルは怖くない! - ANA国内線システムがアマデウスへ刷新、変更点と重い理由