2026/04/11 23:03
「一つの産業を築き上げた課題」
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
以下の改訂版サマリーでは、文の流れが改善され、具体的な歴史的経緯（IBM の役割と TPF を明記）が整理されています。また、元草稿に欠けていた Ajitem Sahasrabuddhe 氏の言及も加えられています。
改訂版サマリー：
航空券予約インフラストラクチャは、1960 年代に設計されたシステムに大きく依存しており、現代的なユーザーの期待とレガシー機能の間で大きなギャップを生み出しています。Sabre や Amadeus などのグローバルディストリビューションシステム（GDS）は、Unix の開発以前に登場した IBM の TPF ランタイム上で動作しており、固定化されたメモリーセルと同期データ処理を用いて、数万のトランザクション毎秒という圧倒的なスループットを実現しています。主要な GDS システムは 1960 年代から 1980 年代にかけてこの基盤に収束しましたが（SABRE、Apollo、Galileo、Worldspan、Amadeus）、航空会社側はそのインターフェースを近代化してきています。例えば Air India は 2023 年に Amadeus Altéa に移行し、IndiGo も現在 Navitaire の NewSkies プラットフォーム上で動作しています。しかし、インターフェースのアップデートにもかかわらず、コアなデータモデルやコマンド言語は依然として 60 年ぶりのプロトコルに基づいています。その結果、インディゴの遅延が Air India の便に影響を与えるといった事象が発生した際、新しいプラットフォームと陳腐化したレガシーアーキテクチャの衝突により、相互運用性が頻繁に機能しなくなります。これにより、自動化された回復ではなく人的介入への依存を余儀なくされ、目的適合性（fitness for purpose）が、流行りのモダンなアーキテクチャよりも優先されるという重要なボトルネックが浮き彫りになります。これらの示唆は、Technogise のソフトウェアエンジニアである Ajitem Sahasrabuddhe 氏が ContainerDays 2026 で発表しました。同氏は、年間 45 億人の旅客輸送に関するこれらの課題について議論を行いました。
本文
産業を支えた問題：鉄核シリーズ第 1 部／6 回から——年間に 45 億人を輸送する、60 年もの歴史を持つインフラストラクチャー
2025 年 12 月、Technogise の担当者によって MakeMyTrip の企業向けプラットフォームがアクセスされ、目的地を入力し、私にロンドン行きのフライトを 2 便予約しました。全体のプロセスは不足 1 分で完了。確認用メールが届いたのにはわずかの時間がかかりました。6 文字の予約照会番号が表示されました：DDTCIV と DHB4AL です。
私は「ContainerDays 2026」で講演する予定でした。コンテナ、オーケストレーション、クラウドネイティブインフラストラクチャーをテーマとしたカンファレンスであり、私のキャリアを通じて考えてきた現代で一時性を持ち、ステートレスなシステムに関するものでした。その皮肉は、飛行機に乗り込んでから気づくことができました。私がそれらのフライトを予約したインフラストラクチャーは 1960 年に設計されました。UNIX よりも先に登場するオペレーティングシステム上で動作し、テレタイプライタ向けに構築されたコマンド言語を使用しています。実に 6 decades 以上もフルスケールの書き換えなしで継続的に稼働しており、ピーク時には最大約 1 万トランザクション毎秒を処理します。私は分散システムを開発する者ですが、複雑なインフラストラクチャーのあり方を理解していたと自負していましたが、自分の搭乗券を確認し、すべてを見直しました。
今回は私が発見した内容について記述する 6 部構成シリーズです。
SABRE の世界以前
このインフラストラクチャーが存在することの背景を理解するためには、それが解決しようとした問題を知る必要があります。1950 年代半ばまでには、アメリカン・エアラインは予約管理をインデックスカードで行っていました。予約を取ろうとすると、エージェントへの電話が必要で、複数の都市办公室にまたがる物理的なカードラックを検索し、口頭で利用可能性を確認し、搭乗者に呼び戻す必要がありました。跨大西洋航线の予約の確認には 90 分もかかっていました。航空会社は、50 を超える都市を跨ぎながら、毎日約 85,000 の予約リクエストを処理する必要があり、システムは限界に達していました。
GDS（グロバル・ディストリビューション・システム）へと進化するシステムの起源は、ほぼ神話的です。1953 年、アメリカン・エアラインの CEO クリストファー・R・スミス氏は、国中を横断する飛行中に IBM のセールスマンの R・ブレイア・スミス氏の隣に座っていました。着陸時にはすでに解決策のスケッチが描かれていました。1959 年、IBM とアメリカン・エアラインは公式の開発パートナーシップを結びました。その結果として生まれたのが SABRE（Semi-Automated Business Research Environment）であり、1964 年に稼働を開始しました。
同年に IBM System/360 が発表され、ATM が初登場したのは 3 年後、アポロ計画による月面着陸はさらに 5 年後、最初の VisiCalc シート計算機は 15 年後のことでした。その間に主要な航空会社の追随は以下のように進みました：
| GDS | 設立年 | 創設オーナー | 技術的基盤 |
|---|---|---|---|
| SABRE | 1964 | アメリカン・エアライン ＋ IBM | IBM ACP / TPF |
| Apollo | 1971 | ユナイテッド航空 | IBM TPF |
| Galileo | 1987 | ユナイテッド ＋ BA ＋ KLM ＋ スイス航空 | IBM TPF |
| Worldspan | 1990 | デルタ ＋ ノースウエスト ＋ TWA | IBM TPF |
| Amadeus | 1987 | エール・フランス ＋ ルフトハンザ ＋ イベリア ＋ SAS | Bull メインフレーム → UNIX |
共通点に注目してください。すべての GDS は、同じ基盤ランタイムに収束しました。これは、多くのソフトウェアエンジニアが聞いたことのない技術であり、あなたがこれを阅读している間に世界のどこかでフライト予約を処理している可能性が高いシステムです。
TPF —— 不死の OS
トランザクション処理ファシリティ（TPF）とは、アメリカン・エアラインの元「Airline Control Program」（ACP）に由来する IBM メインフレーム向けオペレーティングシステムです。設計された目的は一つ：膨大な量の単純なトランザクションをサブミリスエコンドオーダーで処理することでした。UNIX とは関係ありません。UNIX の系譜、哲学、抽象化とは無縁で、むしろ一桁以上 UNIX よりも先行する存在です。
TPF を理解するためには、現代のオペレーティングシステムに関するほぼ全ての知識を手放す必要があります：
| プロパティ | TPF | 現代的 OS |
|---|---|---|
| プロセスモデル | プロセスなし。スレッドなし。短いライフサイクルを持つ「プログラム」のみが実行・終了する。 | プロセス、スレッド、コルーチン |
| メモリモデル | トランザクションごとに固定されたメモリセル。ヒープなし。動的割当なし。 | バチャルメモリ、ヒープ、GCI |
| I/O モデル | DASD（直接アクセスストレージ）に対する極めて高速な同期 I/O。 | 非同期 I/O、ブロックストレージ、NVMe |
| スケジューリング | プレビューティブ、優先度ベース、マイクロ秒単位 | 通常ミリ秒単位 |
| 障害モデル | トランザクションレベルでのロールバック。システム自体はクラッシュせず、トランザクションのみが失敗する。 | アプリケーション次第 |
| 主な言語 | アセンブラ（C は後日追加） | 全て |
ここでの重要なポイントは、TPF が「OS」というよりは現代用語で言えば「トランザクションランタイム」に近いことだということ。タスクを受け取り、それに対して短いプログラムを実行し、状態変更をコミットしてすぐに次の処理へ移るように特別に設計されたシステムです。デーモンも、バックグラウンドスレッドもなく、トランザクション間でメモリ上に接続状態を保つこともありません。
この設計は特定のワークロードに最適化されています。その点で極めて優れています。現代の TPF ベースシステムは通常の運用条件下で約 10,000 トランザクション毎秒を処理可能です。運賃セール時など、何百万人にも及ぶ顧客が同時に「フライトが安価」と気づく状況では、这个数字は最大 50,000 TPS まで達します。エンドツーエンメッセージの往復時間は約 100 ミリセコンドです。
1990 年代には他の業界がメインフレームから UNIX へ移行していく中、航空会社はその性能数字を見てその場にとどまりました。代替システムではスループットを達成できませんでした。多くは現在でもまだ実現できていません。今日 z/TPF を動作させる IBM Z シリーズ・メインフレームは、ノスタルジーのためではなく、この特定のタスクにおいて過去 60 年間でこれほど優れたものは他にないからです。そこには教訓があります。後で触れることにしましょう。
私のフライトがこの世界にどう位置づけられるか
Technogise が myBiz を通じて ContainerDays の旅行を予約した際、このエコシステムの特定のレイヤーが関与しました。MakeMyTrip は Amadeus という GDS を使用しており、これは 1987 年にエール・フランス、ルフトハンザ、イベリア、SAS が結成したパートナーシップから誕生し、現在ヨーロッパ、インド、およびアジア太平洋地域の多くの地域で主要な GDS となっています。
Amadeus は当初の 1987 年の Bull メインフレーム上で稼働しているわけではありません。1990 年代に UNIX へ移行し、以降より現代的なアーキテクチャへと徐々に進歩を続けています。しかし、データモデル、プロトコル、特にエージェントが使用するコマンド言語「cryptic mode」は、1960 年代からの設計を引き継いでいます。私の PNR の形式、電子チケットの構造、運賃計算の方法に至るまで、私が生まれる以前に確立された慣例に従っています。
帰りのフライトにはさらに複雑な要素がありました。往路はインド国内航线すべてが Air India で行われました（DDTCIV、NAG→DEL→LHR）。Air India は Amadeus Altéa という、Amadeus インフラストラクチャーの上に構築された現代の PSS（パッセンジャーサービスシステム）を使用しています。これは 2023 年に導入され、アジア航空史上最大型の airline PSS の移籍の一つとして、旧来の SITA システムを代替しました。
復路（DHB4AL、MAN→LHR→DEL→NAG）は British Airways（これも Amadeus Altéa を使用）と Air India との混成です。1 つの PNR に 2 つの航空会社、同じ基盤プラットフォーム—that の整合性が予約を成功させた要因であり、問題が発生した際のリアレンジメントも可能にした要因でもあります。しかし、私はまだ先へ進んでいます。
IndiGo と低価格キャリアとの分岐
さらに理解しておくべき重要なインド航空会社がもう一つあります：IndiGo。市場占有率においてインド最大の航空会社の IndiGo は Amadeus を使用していません。Navitaire という、低価格キャリア向けに特別に設計された PSS を使用しており、現在 Amadeus が所有しつつも独立した製品として運用されています。Navitaire の NewSkies プラットフォームは、高ボリューム・ローマージン・ポイントツーポイント飛行に最適化されており、インターライン接続も複雑な運賃構築も古い荷物システムもありません。
これは意図的なアーキテクチャ上の選択です。Navitaire は運用コストが低く、構成も速く、IndiGo モデル（高い頻度、固定価格付け、最小限の複雑性）に最適化されています。代償として相互運用性は低下します。IndiGo は旅行代理店経由での予約のために在庫を Amadeus へ配信しているため、cryptic 表示で 6E のフライトを見ることはできますが、チケット発行とチェックインシステムは完全に Navitaire です。この分割は何かが起きた際に重要になります。IndiGo の遅延が Air India との接続に影響しても、システムの間の自動的な再アレンジメントは発生しません。人間が介入する必要があります。
| 航空会社 | PSS | GDS ディストリビューション |
|---|---|---|
| Air India (AI) | Amadeus Altéa | Amadeus（主） |
| IndiGo (6E) | Navitaire NewSkies | Amadeus / Sabre（ディストリビューション層経由） |
| Vistara | Amadeus Altéa | Amadeus |
| Air India Express | Navitaire | Amadeus / Sabre |
30 秒間の予約が実際に引き起こすもの
myBiz が 2025 年 12 月に私の予約を確認した際、以下のシーケンスが発火しました：
- Technogise 旅行管理（myBiz 企業ポータル）
- MakeMyTrip OTA レイヤー（利用可能性確認、価格算出）
- Amadeus GDS（座席在庫、PNR 作成）
- Air India Altéa PSS（セグメント確認、HK ステータス）
- IATA BSP（Billing Settlement Plan）——決済ルーティング
- Air India ナンバーコード 098 下で電子チケット発行
- PNR DDTCIV の作成と Amadeus への保存
- 確認メール → myBiz → Technogise → 私
各矢印はシステム境界を表し、各境界には独自のプロトコル、独自の障害モード、そして最終一貫性特性があります。30 秒間の予約の下に隠されているのは、異なる国で設立された企業によって設計されたシステム間で実行される同期および非同期の呼び出しの連鎖です。その連鎖の最後にある PNR（6 文字の DDTCIV）がそれを支える糸口です。次回以降では、その 6 文字とは実際には何なのか、中にどのような情報が含まれており、なぜ電子チケット上の運賃計算行が商業航空における最も情報密度の高い文字列の一つなのかを解明します。
ポイント
- 用途適合性がファッショナブルなアーキテクチャを上回る。 TPF は現代ではありません。現代的なエンジニアリングチームによる建築審査には耐えられません。それでもなお、クラウド相当のインフラコストの断片に過ぎないハードウェアで 50,000 トランザクション毎秒、100 ミリセコンド未満のレイテンシを処理しています。60 年もこれを続けています。古いソフトウェアが良いソフトウェアとは限りませんが、適切なタスクに対して適切に維持されたツールの良さは非常に難易度が高いです。
- **収斂進化は実在する。**各主要な GDS は独立して同じ基盤プラットフォームへ至りました。これは偶然ではなく、市場が特定の課題に対する最適解を発見した結果です。あなたのドメインでそのパターンを見つけたら注意深く観察してください。
- **移行は高コストである。**Air India が 2023 年に Amadeus Altéa への移行を行いましたが、これは数年にわたって行われたものです。航空会社という規模を持ち、数十年の予約履歴、インターライン契約、ロイヤルティプログラム統合、空港システムへの依存関係を有する企業にとって、「リフト＆シフト」は不可能です。その移転による瘢痕はまだ業界に見えます。第 4 部でも触れます。
**次号：**第 2 部——6 文字とは何か。DDTCIV が実際に何であるか、何を含んでおり、なぜあなたが想像するほどユニークではないのか。
「鉄核」は Ajitem Sahasrabuddhe による 6 部構成シリーズです。Ajitem は Technogise のソフトウェアエンジニアであり、ロンドンで開催された ContainerDays 2026 で講演しました。