2026年にスマートフォンでフライトを予約する場合、リクエストはモバイルアプリ、ウェブサービス、決済処理業者など、複数の最新技術レイヤーを経由して、実際に座席を確保するシステムに到達します。そのシステムは、ほとんどの場合、1960年代にルーツを持つソフトウェアであり、旅行業界が何十年も置き換えようと試みてきたものの、完全には実現できていないインフラストラクチャ上で稼働しています。Sabre、Amadeus、Travelportは、地球上のほぼすべての航空予約を処理しています。これら3社は、数百の航空会社、数千の旅行代理店、そして数百万の座席組み合わせにわたるリアルタイムの在庫を合わせて、年間数十億件の取引を処理しています。最も古いものは、予約時間を90分からわずか数秒に短縮し、商業航空を永久に変えた1964年のIBMメインフレームに起源を持ちます。
これらのシステムが現状のまま維持されている理由は、組織の惰性やエンジニアリングの保守主義によるものではありません。それは、ソフトウェアがミッションクリティカルな業務プロセスに深く組み込まれ、現実的なスケジュールで置き換えにかかるコストとリスクを正当化できなくなった場合に何が起こるか、そして業界がそれを置き換えるのではなく、コアシステムを中心に近代化することでどのように対応してきたか、という物語です。大規模なレガシーシステムの近代化に取り組む人にとって、航空会社の予約システムは、「失敗させるには重要すぎる」とは実際にはどういうことなのかを最も明確に示す事例研究と言えるでしょう。
内部構造を把握する。依存関係グラフを理解する。
SMART TS XL COBOLプログラムおよびレガシープログラム全体から、ビジネスルール、依存関係マップ、およびデッドコードを抽出します。
さらに詳しく…起源：メインフレームが航空業界の問題を解決した理由
オリジナルのSABRE（Semi-Automated Business Research Environment）は製品ではなく、特定の業務上の危機に対応するためのカスタムソリューションでした。1950年代後半、アメリカン航空は手動予約システムでは対応しきれないほど急速に成長していました。座席を予約するには、電話、在庫カードの手動確認、保留、折り返し電話、紙の記録が必要で、1件の予約につき平均90分かかり、拡張性に欠けていました。
SABREは1964年に本格稼働を開始し、2台のIBM 7090メインフレームを基盤として、米国とカナダ全土の1,500台の端末に接続されました。これにより、ほぼゼロのエラー率で1時間に7,500件の予約を処理できるようになりました。航空会社は初めて、リアルタイムの座席在庫管理、乗客の完全な記録保存、そしてネットワーク全体での即時予約が可能になりました。予約時間は90分から数秒に短縮されました。
この実現を可能にしたアーキテクチャの選択、すなわちメインフレームハードウェア上での集中型トランザクション処理は、哲学的な理由から選ばれたものではありませんでした。1964年当時、リアルタイムの航空会社在庫管理に必要なレイテンシ、信頼性、同時アクセスといった要件を満たすことができる唯一のアーキテクチャだったからです。そして、その性能は非常に優れていたため、その後のすべての航空会社予約システムの基盤となるアーキテクチャとなりました。
IBMのトランザクション処理施設（TPF）は、元々はSABRE向けに設計されたものですが、この分野全体のオペレーティング環境となりました。IBMによると、大手銀行、保険会社、小売業者、航空会社のほぼすべてが今でもTPFを使用しています。1987年にアマデウスが設立された際も、TPFを基盤として構築されました。ガリレオ（現在のトラベルポート）がGDSを立ち上げた際も、TPFを基盤としていました。現在、民間航空業界では3世代の旅客サービスシステムが共存しており、その多くは今でもTPFメインフレーム上で稼働しています。これは、TPFの技術に疑問が呈されたことがないからではなく、TPFがメインフレームハードウェア上で実現するトランザクション処理能力、信頼性、耐障害性が、他のアーキテクチャでは同等の規模で再現することが極めて困難であることが証明されているためです。
これらのシステムが大規模に実際に行うこと
航空券予約システムが運用されている規模は、ソフトウェアエンジニアリングの観点からは直感的に理解しにくい。グローバルな流通システムは、座席の空き状況だけでなく、途方もなく複雑な組み合わせ在庫問題を管理しているのだ。
大西洋横断便だけでも、数百もの運賃クラスが存在します。各運賃クラスには、事前購入要件、最低滞在日数、利用除外日、変更手数料、途中降機の可否、提携航空会社とのコードシェア提携など、それぞれ固有のルールがあります。2つの航空会社を利用し、乗り継ぎ便を含む往復予約の場合、数千もの有効な運賃組み合わせが生成される可能性があり、それらはすべてリアルタイムの在庫状況と照合され、確認、価格設定、保留された後、通常1秒以内に結果が返されます。
予約ピーク時には、SabreとAmadeusは連携して毎秒数万件の取引を処理します。毎分ではなく、毎秒です。各取引には、リアルタイムの在庫検索、運賃規則の評価、PNR（旅客名記録）の作成または変更、出発管制、マイレージプログラム、付帯サービスシステムとの連携が含まれます。保証される応答時間はミリ秒単位で計測されます。なぜなら、旅行代理店や予約エンジンは、運賃チェックに数秒以上待つとタイムアウトになり、再試行するか、取引を放棄することになるからです。
メインフレームハードウェア上のTPFは、他業界のIT専門家が信じがたいほどの低故障率でこのスループットを実現します。メインフレームの耐障害性、冗長プロセッサ、ホットスワップ可能なコンポーネント、数十年にわたる堅牢なオペレーティングシステムコードにより、99.9999%の可用性が目標ではなく、標準的な運用パラメータとなっています。これをクラウドインフラストラクチャ上で同等のコストで再現することは、1990年代以降、航空会社のIT近代化プログラムにおける中心的な技術的課題でした。
近代化の試み：10年にわたるプログラムが実際に発見したこと
航空券予約システムの近代化の歴史は、当初はシステムの中核部分を置き換えることを目指したプログラムが、数年後には中核部分を包み込むハイブリッドシステムにたどり着いたという歴史である。
アメリカン航空のジェットストリーム・プロジェクトは、2000年代にSabreメインフレームPSSの置き換えを明確な目標として開始されましたが、最終的には代替システムを構築するのではなく、新しいSabre製品を採用することで完了しました。当初、自社で代替システムを構築すればより優れたシステムをより早く実現できるという前提で進められましたが、ほぼすべての大規模なレガシーシステム置き換えプログラムが直面するのと同じ現実に直面しました。つまり、既存システムには、置き換え後のシステムでは満たせない要件が含まれていたのです。
スタックの奥深くに入り込み、コアエンジンを変更し、ルールを分離して迅速に変更できるようにする必要がある。ジェットストリーム・プログラム実施中のアメリカン航空のIT部門責任者のこの発言は、まさに問題点を的確に言い表している。レガシーシステムに組み込まれたルール、運賃計算ロジック、コードシェア協定の実装、規制遵守計算、収益管理統合などは、数十年にわたるビジネスの変化の中で蓄積されてきたものであり、既存のシステムを実行してその動作を観察しなければ抽出できないような形で文書化されていなかった。
Sabre独自の近代化プログラムは2010年代に本格的に開始され、10年以上を要し、数十億ドルの費用をかけて、コードの大部分をオンプレミスのメインフレームインフラストラクチャから移行しました。2019年の時点で、Sabreのコードの約11%は依然としてオンプレミスのデータセンターで稼働しており、残りは移行済みです。2026年2月、SabreはWestJetとの長期PSS契約を更新し、10年にわたる近代化への取り組みと数十億ドルの投資を経てもなお、PSSが事業の商業的基盤であり続けていることを示しました。
アマデウスは、メインフレームの廃止をより徹底的に進め、最後のメインフレームをクラウドインフラストラクチャに移行させるという大きな節目を迎えました。しかし、アマデウスのアプローチは、コアとなるデータモデルとトランザクションアーキテクチャを維持しながら、機能コンポーネントを段階的に置き換えるというもので、ハードウェアが変更されても、メインフレームで生まれたアーキテクチャ上の決定事項を効果的に維持しました。トランザクションのセマンティクス、PNR構造、在庫管理ロジックなどは、基本的な設計を維持したまま、最新のインフラストラクチャに移行されました。
交換作業が見た目より難しい理由：隠された複雑さ
航空券予約システムが依然としてメインフレーム上で稼働している理由としてよく挙げられるのは、コストとリスクです。確かにどちらも現実的な問題です。しかし、これらはより深い技術的現実の兆候に過ぎず、その現実を正確に理解することが重要です。なぜなら、それはあらゆるミッションクリティカルなレガシーシステムの近代化プログラムに当てはまるからです。
コードの中にのみ存在するビジネスルール。グローバル流通システムの運賃計算ロジックは、数十年にわたる規制要件、航空会社間の協定、IATA規格の改訂、およびビジネスルールの変更を反映していますが、これらは実装するコードとは独立した形で文書化されていません。仕様は実装そのものです。仕様なしで実装を置き換えるということは、既存システムの動作を徹底的に観察して仕様が何を述べていたかを再構築することを意味しますが、このプロセスには何年もかかり、決して完了することはありません。なぜなら、あらゆる例外ケースを網羅できるほど包括的な観察範囲を確保することは不可能だからです。
現代のアーキテクチャでは再現が難しいトランザクションセマンティクス。TPFは、PNR全体にわたる一貫性を保証する同期アトミックトランザクション処理を提供します。座席の保留、乗客記録の更新、支払い承認、確認記録はすべて単一のアトミックユニットとしてコミットされるか、まったくコミットされないかのどちらかです。これを分散マイクロサービスアーキテクチャで再現するには、慎重なオーケストレーション、補償トランザクション、分散ロック管理が必要となり、複雑で、同期メインフレームの同等のものよりも遅くなる可能性があります。航空業界の経験では、「最終的に一貫性がある」ことは座席在庫にとって許容できる特性ではなく、オーバーブッキングされたフライトは、後で解決できる一時的な不整合ではなく、具体的な運用上の壊滅的な障害です。
統合サーフェス。成熟した航空会社のPSSは、出発管制、収益管理、マイレージプログラム、空港システム、サードパーティGDS接続、コードシェアパートナー、規制報告など、数百もの外部システムに接続されています。各接続には、既存システムが実装し、依存するすべてのシステムが構築されている、特定のインターフェース契約、メッセージ形式、タイミング要件、エラー処理動作があります。PSSを置き換えるには、既存のすべてのインターフェース契約を同時に維持するか（これにより、置き換えアーキテクチャが制約されます）、依存するすべてのシステムとの変更を調整するか（これにより、単一のプログラムで管理できる範囲を超えて範囲が拡大します）のいずれかが必要です。
ライブデータの問題。航空券の予約はライブデータであり、数か月前に予約された内容は、予約どおりに正確に履行されなければなりません。旧システムのデータを完全に切り離せるような明確な切り替えポイントは存在しません。移行では、関連するすべての規則、運賃、制限、付帯サービスを含め、すべてのライブPNRを旧システムから新システムへそのまま引き継ぐ必要があります。データ損失ゼロ、動作の完全性保証を伴うグローバル規模のPNR移行は、企業近代化における最も困難な技術的課題の一つであることが証明されています。
建築的対応：中心部を中心に近代化する
アマデウス、セイバー、そして個々の航空会社において実際に成功を収めたアプローチは、置き換えではなく、戦略的な包括化と段階的な抽出である。
APIラッパーは、コアとなる予約機能を最新のRESTまたはSOAP APIとして公開することで、新しいアプリケーションがコアとなるトランザクションロジックに触れることなく、最新のインターフェースを通じてレガシーシステムと連携できるようにします。航空会社は、最新のリクエストをTPFトランザクション呼び出しに変換し、構造化されたレスポンスを返すAPIレイヤーの上に、モバイルアプリ、Web予約エンジン、カスタマーサービスツールを構築しています。グリーン画面の端末は最新のGUIに置き換えられますが、基盤となるトランザクション処理は変更されません。
非コア機能のための「絞め殺しのイチジク」戦略。収益管理、ロイヤルティプログラム管理、レポート作成と分析、乗務員スケジューリングなど、コア機能に隣接する機能を一つずつ抽出し、最新のインフラストラクチャ上で再実装します。抽出するたびに、最もリスクの高いトランザクションコアに手を加えることなく、レガシーシステムのフットプリントを削減します。10年以上にわたる段階的な抽出により、レガシーシステムの役割は、包括的なアプリケーションプラットフォームから、トランザクションエンジンに特化したものへと縮小していきます。
アーキテクチャを維持したままクラウドインフラストラクチャを構築。アマデウスのメインフレーム廃止に伴い、ワークロードはクラウドインフラストラクチャに移行されましたが、メインフレームで開発されたトランザクションアーキテクチャはそのまま維持されました。ハードウェアは変更されましたが、ソフトウェア設計、データモデル、トランザクションセマンティクス、PNR構造など、数十年にわたり正しかったことが証明されているアーキテクチャ上の決定はそのまま維持されました。
従来のPNRに加えて、新しいオファーと注文管理を導入。PNRベースのレコードを最新の注文管理モデルに置き換えるIATA ONE Order標準は、既存のPNRベースのシステムに加えて、航空会社によってレイヤーとして導入されています。Sabreの次世代オファーおよび注文テクノロジーは、2026年のWestJetの更新で言及されており、PSSの置き換えではなく、最終的には予約の増加する割合を処理するように成長する最新の商用レイヤーの追加として、この方向性を示しています。残りの部分はPNRコアが処理します。
これは、あらゆるミッションクリティカルなレガシーシステムの近代化にとって何を意味するのか
航空券予約システムの事例は、航空業界に限った話ではない。これは、銀行の中核システム、保険契約管理、通信料金請求、政府給付金処理などにも見られるパターンを最も分かりやすく示す例である。つまり、ソフトウェアが業務ルールの権威ある仕様となり、数十もの依存システムの統合ハブとして機能し、大規模かつ高い信頼性が求められるため、一括置換は事実上不可能となるのだ。
これらの教訓は、あらゆる業界に共通している。
近代化を開始する前に、コードから業務ルールを抽出することは必須です。運賃計算、コードシェア協定ロジック、規制遵守ルールを実装するCOBOLおよびTPFプログラムは、これらのルールに関する唯一の現存する文書です。このロジックを最初に抽出して検証しない近代化では、すべてのケースを分析せずにすべてのケースを把握することはできないため、あらゆるケースで正しく動作する代替コードを作成することはできません。
依存関係マップによって移行順序が決まります。最も重要で統合性の高いコンポーネントから始めてPSSを正常に置き換えた航空会社は存在しません。成功した近代化はすべて、エッジ部分、つまり報告システム、付帯サービス、重要度の低い管理機能から始まり、段階的に内側へと進んでいきました。この順序は依存関係グラフから導き出されます。つまり、インバウンド依存関係が最も少ないコンポーネントから着手するのが最も安全です。
あらゆる段階における運用検証は必須です。新システムを旧システムと並行して稼働させ、出力を比較し、トラフィックの切り替え前に同等性を検証するデュアルラン検証方式は、障害発生時に物理的、経済的、および規制上の影響が生じるシステムの信頼性要件を満たす唯一の方法です。
認定条件 SMART TS XL 航空会社関連のレガシー分析に適用されます
SabreやAmadeus PSSを自社のCOBOLプログラム、料金計算システム、収益会計、ロイヤルティポイント計算、規制報告と並行して運用している航空会社は、あらゆるエンタープライズメインフレームの近代化プログラムが直面するのと全く同じ分析上の課題を抱えている。それは、コードに実際に何が含まれているかを理解し、それに対して何をするかを決定することである。
SMART TS XLさん 静的コード分析 COBOLプログラムに組み込まれたビジネスルールロジック、運賃検証ルール、収益会計計算、ロイヤルティティア資格判定ロジックなど、プログラムコード以外には存在しないロジックを抽出します。PSSコアに手を加えることなく隣接システムを近代化しようとしている航空会社にとって、この抽出によって、代替システムが準拠しなければならない仕様が生成されます。
アプリケーション依存関係マッピングは、移行順序を決定する依存関係グラフを構築します。つまり、航空会社側のどのプログラムがPSSからのどのデータフィードに依存しているか、どのレポートプログラムがどのCOBOLバッチ出力に依存しているか、コンポーネントが変更された場合にどの下流システムを更新する必要があるかなどを決定します。この依存関係グラフによって、段階的かつ安全な近代化が可能になります。これは、SabreやAmadeusがコアシステムで採用したのと同じアプローチを、それらを取り巻く航空会社側のコードに適用したものです。
影響分析機能は、あらゆる近代化決定に先立つ疑問、すなわち「このプログラムが変更された場合、他にどのような影響が出るのか？」という問いに答えるものです。航空会社のシステムでは、収益会計プログラムの計算方法の変更が、規制報告、パートナー決済、財務連結に同時に影響を与える可能性があるため、変更を行う前に影響範囲を把握しておくことが、航空会社の信頼性要件を満たす変更管理の前提条件となります。
レガシーシステムの近代化分析では、近代化前の完全なインベントリが提供されます。対象となるすべてのプログラム、その複雑さ、依存関係、デッドコードの割合、および移行リスク分類が含まれます。航空会社の近代化プログラムで常に求められる教訓は、「エッジから始めて内側へ進み、各ステップで検証する」ことです。そのためには、エッジがどこにあるのか、依存関係の構造がどのようなものなのかを把握する必要があります。この知識は、コードが進化する前に書かれたドキュメントからではなく、実際のコードの構造分析から得られます。
ミッションクリティカルソフトウェアの地質学的階層構造
2026年にスマートフォンで航空券を予約する際、あなたは複数の異なる地質学的層を持つソフトウェアに触れていることになります。表面にあるのは最新のインターフェース。その下にはAPI層。さらにその下にはPSSトランザクションエンジンがあり、1960年代以降大きく変化したインフラストラクチャ上で動作していますが、設計当時は適切だったトランザクションセマンティクスとデータモデルを維持しており、それらは放棄するにはあまりにも信頼性が高すぎるのです。
航空予約システムは、近代化の失敗例ではありません。それは、60年にもわたるエンジニアと経営陣による合理的な判断の積み重ねの結果です。彼らは、代替案が提案されるたびに、既存のシステムを維持するコストよりも、代替案を誤るリスクの方が大きいことを理解していました。これほど長く存続するシステムは、一つ一つの取引、一つ一つのフライト、一つ一つの予約シーズンを通して、その価値を証明してきたからこそ、生き残ってきたのです。
近代化チームにとっての実践的な教訓は、古いシステムを決して置き換えてはいけないということではない。そうではなく、システムの内容、依存しているもの、そして実際の変更範囲を完全に把握した上で、置き換えの決定を下すべきだということである。複雑さを測定する前に楽観的な見積もりを立てて決定を下すべきではない。航空業界はこのことを高い代償を払って学んだ。新しいコードの最初の行を書く前に、構造に関する完全な知識を生み出す分析ツールこそが、より低コストでこの教訓を学ぶことを可能にするのだ。
