私たちはより速い航空乗務員ソルバーを作った。ただ、より速く失敗しただけだった。
初めて実際のカスケード（連鎖障害）のさなかに航空会社の運用管制センターに座ったのは、午前3時を少し回った頃で、冬の嵐が数時間前に主要拠点を閉鎖していた。部屋の前方に沿ったビデオウォールは赤で埋め尽くされていき — 欠航に次ぐ欠航だった — そして最も強く覚えているのは、その航空会社が数百万ドルを払って導入した乗務員スケジューリングソルバーを、誰も使っていなかったことだ。ディスパッチャーたちはキーボードを脇に押しやり、崩れた乗務員ペアリングを手作業で、スプレッドシートとホワイトボードの上で処理していた — まさにそのソフトウェアが真価を発揮するはずの瞬間に。
その光景こそが、やがて私たちにIROPS復旧のための航空乗務員スケジューリングAIを構築させることになった — ただし、それは私が予想していた形ではなく、しかも私が誤った解決策に肩入れし、それが失敗するのを見届けた後のことだった。IROPSとは、もし経験したことがなければ幸いだが、次を指す業界用語である — 不規則運航（irregular operations）：嵐、空港閉鎖、そしてスケジュールが崩壊したときに連鎖的に広がる混乱のことだ。これは航空業界に、推定で年間600億ドル、IATAによれば世界の航空収入の約8%に相当するコストをもたらしている。世界の全便のおよそ5便に1便が、その影響を受けている。そして、あの夜私が学んだ後ろ暗い秘密は、航空業界で最も高度な最適化ソフトウェアが、最も大きなコストを生むまさにその事象の最中に、本質的に役立たずになるよう設計されている、ということだった。
ソルバーは、もはや存在しない航空会社を最適化していた
従来の乗務員ソルバーが実際に何をしているのかを知っておくと役に立つ。それらは列生成（column generation）— 既知のスケジュールを法令に適合させつつ最も安価に人員配置する方法を見つけることにかけては、本当に見事な、分枝価格法（branch-and-price）の最適化手法 — を実行する。落とし穴は、次の言葉にある — 既知。ソルバーはネットワークのスナップショットを取り、時間を凍結し、その凍結された世界に対する最適な乗務員割り当てを計算する。通常は30〜60分ごとのバッチサイクルで動作する。
通常運航のときは、それで問題ない。サイクルの間に世界はほとんど動かないからだ。しかし連鎖的な障害（カスケード）の最中は、ネットワークの状態が数分ごとに変化する。乗務員は移動する。接続便は途絶える。機材は足止めされる。ソルバーが解を返す頃には、与えられた入力はすでに間違っている — つまりその答えは、もはや存在しない航空会社にとっての完璧な計画なのだ。
私はこれを、次のように呼ぶようになった — 最適化・実行ギャップ（Optimization-Execution Gap）。すなわち、ソルバーが前提とした世界と、実際に駐機場（ランプ）に広がっている世界との間の隔たりである。このギャップは、単発の遅延のときには無害だ。しかし連鎖障害の最中には致命的になる。なぜなら、ソルバーは次のために作られたからだ — 効率性 — 既知の世界における最も安価なスケジュール — であり、午前3時に切実に必要となるのは、次のものだからだ — 回復力、すなわち未知の世界でも生き延びられるスケジュールなのだ。
従来型の乗務員ソルバーの最も残酷な点は、崩壊のさなかでも動き続けることだ — 計算しているあいだに崩れ去ったネットワークに対して、完璧な計画を淡々と差し出してくる。
なぜ、ただソルバーを速くするだけではだめだったのか？
ここは私が誇りに思っていない部分であり、そして実のところ最も重要な部分でもある。
私のチームが最初にこの問題を検討したとき、私たちの診断はエンジニアらしいありきたりの診断だった — ソルバーが遅すぎる、と。世界は5分ごとに変化しているのに、オプティマイザーは30分から1時間かかる。だからギャップを埋めよう — 速くすればいい。私たちは実際に時間をかけて、より高速な復旧エンジンを構築した。証明可能な最適解を待つのではなく、運用上の意思決定の枠内で実行可能な答えを得るために、より安価なヒューリスティクスに頼ったのだ。
そしてそれは、より速く答えを返すという狭い意味では機能した。ところが実際の混乱データでテストしてみると、それがすでに無効な復旧計画を、ただ以前より早く、自信満々に生み出す様子を私は目にした。私たちは、幻の航空会社をより高速に最適化する機械を作り上げていたのだ。
間違いは、速度をボトルネックだと捉えたことだった。だが、そうではなかった。ボトルネックは、その入力が虚構だったことにあった。ソルバーは — 私たちのものも含めて — 確かな事実を必要とする。「スミス機長はデンバーのB7ゲートにいる」といった具合に。しかし連鎖障害の最中には、スミス機長はホテルにいるかもしれないし、従業員シャトルに乗っているかもしれないし、レンタカーを借りてコロラドスプリングスへ向かう途中かもしれない。世界の正直な状態は「おそらくデンバーにいる」であり、列生成ソルバーは次のものでは何もできない — 「おそらく」。私たちは、データがゴミであるような問いに対して、その答えを研ぎ澄まし続けていたのだ。
その失敗こそが、この製品が存在する理由だ。もしあの高速ソルバーを世に出していたら、私たちは航空会社に、同じ高くつく間違いをより速く犯す手段を売っていたことになる。
12億ドルのデータ・ブラックホール
この失敗をまさに最大規模で見たいなら、2022年12月にサウスウエスト航空に起きたことを見ればいい。その崩壊が同社にもたらした損失は、およそ12億ドルにのぼり、欠航となったのは約16,900便、そして休暇シーズンに200万人近い乗客を足止めした。
よくある説明は「古いソフトウェア」だ。だが本当の話はもっと具体的で、もっと役に立つ。サウスウエストの乗務員スケジューリングシステム「SkySolver」は、計算しきれない組合せ爆発に直面した。しかしその根底では、同社は自社のパイロットや客室乗務員が物理的にどこにいるのかを見失っていた。乗務員の位置報告は主に電話を通じて行われていた — 地方空港に足止めされた乗務員が、保留時間が数時間にも及ぶスケジューリングセンターに電話をかけていたのだ。この遅延が、私が「データ・ブラックホール」と考えるものを生み出した — システムは、思っていた場所にいない乗務員のためにスケジュールを生成していた。それは幻のネットワークを最適化していたのであり、ポイント・トゥ・ポイントの路線構造は、乗務員と機材が自然に再集結するハブの「再生成ポイント」が存在しないことを意味した。そのため被害の範囲は、空港から空港へと広がり続けたのだ。
これは、その後みなが解決した大昔の話ではない。2024年7月、スピリット航空のスケジューリングシステムが矛盾する割り当てを生じさせた対象は、次のとおりだ — 稼働可能な運航乗務員の43%。これは推定5,000万〜1億ドル規模の事態であり、システムが混乱の最中に乗務員をきれいに再割り当てする柔軟性を欠いていたためだった。このパターンが繰り返されるのは、根底にあるアーキテクチャ — 凍結されたスナップショットを最適化し、確定した入力を要求する — が業界全体で同じだからだ。
サウスウエストは、その名誉のために言えば、支出をもって対応した — およそ2024年に技術へ17億ドルを、より大規模な複数年プログラムの一環として投じたのだ。データセンターの規模を劇的に削減したAWSへの移行や、約30%高速化されたスケジューリングアルゴリズムも、その一環だ。それは正しい直感だ。しかし、同じアーキテクチャの高速版 — これは私たち自身も危うく陥りかけた罠だ — が埋めるのは、次の速度のギャップだけであり、その一方で次のデータの確実性のギャップは、大きく開いたまま残してしまう。
遅延が3時間を超えると、いま何が起きるのか？
航空の歴史の大半において、復旧の遅さが失わせるのは信用（グッドウィル）だった。怒った乗客、悪い報道、いくらかのバウチャー。その計算は2024年10月28日に変わった。
その日、米国運輸省（DOT）の自動払い戻し規則が施行された — 史上初となる、義務的な自動払い戻し要件である。3時間を超える国内線の遅延（国際線は6時間）は、いまや現金での払い戻しを発生させ、7営業日以内に、しかも乗客が求めることさえなく支払われる。バウチャーではない。予約の振り替えでもない。現金だ。
1日300便を運航する中規模航空会社で、その計算をしてみよう。本当にひどい日に、そのうちのわずか6分の1 — 50便 — が3時間の壁を超えただけでも、平均チケット価格280ドル、1便あたり150人の乗客とすれば、直面するのはおよそ次の額だ — たった1日で210万ドルの義務的払い戻しリスク。IROPS復旧の遅れは、かつては評判の問題だった。いまやそれは、同じ週のうちに響いてくる会計項目なのだ。
いまや、復旧が遅れる1時間ごとにメーターが回り続けており、昨年10月以降、それは影響を受けたすべての乗客に対して、自動的に、現金で支払われるのだ。
ここが、私にとって議論全体の枠組みを変えた部分だ。最適化・実行ギャップのコストは、もはや抽象的なものではない。それは、嵐が始まったその瞬間に動き出した時計に逆らって、ドル単位で膨らんでいくのだ。
ソルバーを置き換えるのではなく、拡張せよ
ここに、私たちのアプローチを決定づける判断がある。しかもそれは、あえて地味な判断だ — 私たちはあなたのソルバーを置き換えない。
既存のソルバーには、数十年にわたる航空会社固有のドメイン知識が組み込まれており、その周辺の分野は、崩壊ではなく統合へと向かっている。Jeppesen — 100社を超える航空会社を顧客に持つ業界標準 — は、ボーイングからThoma Bravoへ、105.5億ドルで、2025年4月に売却された。これは航空宇宙史上最大級のテクノロジー事業売却の一つであり、その後Jeppesenは、予測的な混乱管理のためのAIレイヤー「Stratosphere」を立ち上げている。IBS SoftwareのiFlightプラットフォームは、最新のクラウドネイティブ導入を次々と獲得している — 大韓航空が2026年初頭に本番稼働し、AeroitaliaやGroupe Dubreuil傘下の航空会社などもこれに移行しつつある — その背後には、AWSとの共同エンジニアリング体制がある。OptymのCrewSolverは、計画段階で3〜7%の乗務員コスト削減という実証された成果を提供している。
それらのどれも敵ではない。だが、それぞれが何に強いのかに注目してほしい — 計画段階の最適化と予測分析、つまり既知の世界を、美しく計算することだ。リアルタイムで、不確実な入力を扱う復旧の問題こそが、開いたまま残るギャップなのだ。プラットフォームの全面的な置き換えは、12〜18か月に及ぶプロジェクトでもある。そして、うまくいかない15日のために、年間350日は機能しているシステムを引きはがしたいと思う運用責任者はいない。実際に契約に署名するCIOにとって、その計算はカレンダー以上に厳しい — 数十年にわたる航空会社固有のCBA（労働協約）ロジックが組み込まれたシステムを、しかもJeppesen自身の所有権が105.5億ドルで移ったばかりで、その長期的なロードマップが未知数であるまさにその瞬間に引きはがすというのは、ほとんどのテック組織が賭けようとしない賭けだ。既存の導入環境の隣に位置し、そのスキーマを置き換えるのではなくそのフィードを取り込むこと — それが、彼らが承認する唯一の統合形態なのだ。
そこで私たちは、MLを活用したIROPS復旧エンジンを構築した。それが位置するのは、並んで動作する既存のJeppesenまたはIBSの導入環境のかたわらであり、それはコアソルバーにはできないことを担う — 乗務員の位置が不確実な連鎖的混乱、ネットワーク全体の被害範囲（ブラストレイディアス）分析、そして通常は手作業の復旧に4〜12時間かかるところを、数分で生成される復旧計画だ。ある地域の事例データは、自動化によってその復旧時間を約78%短縮できることを示唆している。要点は、既存製品より賢くあることではない。既存製品が決して想定していなかったまさにその状況で、役に立つことにあるのだ。
「おそらくデンバーにいる」で機能するモデルを教える
ソルバーを速くしようとするのをやめた途端、本当のエンジニアリング上の問題が焦点を結んだ — 不確実性に窒息するのではなく、不確実性を糧に力を発揮するものを作る、ということだ。
第一の要素は、乗務員位置インテリジェンスだ。確定した位置を要求する代わりに、私たちはモデルに確率的な位置を与える — 存在するあらゆるリアルタイム信号を過去の行動と融合させることで、システムに次のことを推論させるのだ — 乗務員がどこにいる可能性が高いかを。保留列で4時間も待たされる電話を待ち続けるのではなく、である。この一つの転換 — 「確定かゼロか」から「確率分布」へ — こそが、復旧計画を現実の連鎖障害との接触に耐えさせるものなのだ。
第二の要素は、ネットワークをグラフとして扱い、障害が伝播する前に、どこへ伝播するのかを分析することだ — 被害範囲を、その航空会社固有の路線構造に対応づけることで、どの空港の閉鎖が2時間後に下流の6便を静かに欠航させるのかが見えるようになる。
第三の要素は、シナリオシミュレーター、実質的には運用のデジタルツインだ。これによって運用チームは、冬の嵐のシナリオを事前にリハーサルし、実際の嵐も実際の時計もない状況で復旧戦略を試すことができる。航空業界はすでに、データが豊富な領域ではデジタルツインを信頼している — ルフトハンザのAVIATARプラットフォームは、34の航空会社との統合を通じて1日あたり23.7テラバイトを取り込み、整備故障予測において93.6%の精度を達成している。乗務員やスケジューリングのツインはまだ黎明期にあり、まさにそこにこそ機会があるのだ。
そして、そのすべてを貫いているのが制約エンジンだ。すべての推奨は、FAA Part 117の疲労規則 — 8〜9時間の飛行時間制限、9〜14時間の乗務時間 — のもとで合法でなければならず、さらに航空会社の労働組合との契約のもとでも合法でなければならない。その契約は、規制よりも、しばしばいっそう制限的だ。ほとんどのベンダーは、それらの規則を「設定（コンフィギュレーション）」として扱う。私たちは、航空会社固有の労働協約（CBA）を、機材ごと・基地ごとに符号化することを、中核的なエンジニアリングとして扱う。なぜなら、CBAの条項に違反する復旧計画は計画ではない — それは苦情申立て（グリーバンス）だからだ。
なぜ私たちは、まずシャドウモードで動かすのか
この業界の人々が、午前3時にパイロットの動かし方を指図してくるブラックボックスを信用しないのは、もっともなことだ。だから、私が最もよく耳にする反論をお伝えしよう。私自身、その反論を抱いていたからだ。
ある運用担当VPは初期の頃、要するにこう言った — 既存ベンダーからAI混乱対応アドオンのライセンスを取得したばかりで、なぜ私たちが必要なのか分からない、と。もっともだ。ところが次の嵐が来たとき、そのアドオンが与えたのは予測であって、実行可能な乗務員復旧ではなかった。そしてディスパッチャーたちは、またホワイトボードに逆戻りした。その会話が私に教えてくれた区別はこうだ — 次の二つの間には、天と地ほどの違いがある — 乗客向けチャットのためのエージェント型AI — 2026年のカンファレンス業界の流行語 — と、乗務員や機材に関する運用上の意思決定を下すAIとの間に、である。乗客を別便に振り替えるチャットボットは、結構なものだ。だがそれは、ネットワークを復旧させることと同じエンジニアリング問題ではない。
だからこそ、どの航空会社であれ、初めて私たちのエンジンを動かすとき、それは運用に手を触れない。それは次のモードで動作する — シャドウモード：私たちのモデルの推奨は、人間のディスパッチャーの実際の判断の隣に置かれ、私たちはそのギャップを、その航空会社自身の混乱に対して、来る日も来る日も測定する。信頼は、営業資料の中で主張されるものではない。それは、運用上のリスクを一切伴わずに、比較シートの上で獲得されるものだ — 運用チーム自身が、その推奨はホワイトボードより優れていると判断するまで。
誰かのパイロットを再ルーティングする権利は、ベンチマークで得られるものではない。それは、誰かがあなたを信じなければならなくなるより前に、何週間もの間、人間のかたわらで、静かに正しくあり続けることで得られるのだ。
正直なところ、シャドウモードを見ていて初めて、私たちが実際に売っているものが何なのかを理解した。オプティマイザーではない。速度でもない。私たちが売っていたのは、運用責任者が、その年で最悪の夜に機械を信じられるようにする手段だった — そして信頼は、嵐の最中ではなく、嵐の前に築かれていなければならない。
その15日が、本当はどれほどの価値を持つのか
中規模航空会社の運用を担っているなら、あなたの乗務員ソルバーは年間350日は問題なく機能する。私はそれに異を唱えるつもりはない。問題は、機能しない15日に何が起きるかだ — そしてそれこそが、10億ドル規模の見出しや、乗務員の43%が誤割り当てされたという監査結果、そしていまや昨年10月以降は、1時間単位で計上される自動現金払い戻しを生み出す日々なのだ。
業界全体が犯し続けている間違い — 私自身が、自分の高速ソルバーで最初に犯した間違い — は、その15日を、より力ずくで計算すれば解決できる速度の問題として扱うことだ。そうではない。それらは、次の確実性の問題であり、確実性の問題は、まさに崩れつつある世界からより多くの確実性を要求することでは解決できない。解決するには、不確実性のもとで推論し、災害が到来する前にそれをリハーサルし、光の中で信頼される前に影の中で自らを証明するものを作るしかない。それが私たちの構築したエンジンであり、その全容は、私たちの次のページで余すところなく説明されている — 航空乗務員スケジューリングAIソリューション。
今夜もどこかに、ビデオウォールが穏やかに緑色を保ち、乗務員ソルバーが設計どおりにバッチサイクルを淡々と回している運用管制センターがあるだろう。私たちの仕事は、その部屋が赤く染まる夜のためにある — 電話が滞留し、ペアリングが誰も書き留められないほど速く崩れていき、ソフトウェアが要求する確実性が静かにその場を去ってしまったために、ディスパッチャーがホワイトボードに手を伸ばす、その夜のためだ。要するにその狙いは、その夜、機械がもはや完全には見通せなくなった航空会社について、それでもなお正直に推論し続けていられるようにすることなのだ。
