空のギャンブル Part 2

前編「空のギャンブル」では、 ANAのキャンセル保険「そらもよう」が数学的に搾取可能であることを示した。 XGBoostモデル（R²=0.81）で15路線×12ヶ月の欠航確率を予測し、 モンテカルロ・シミュレーションで93%の確率で年間黒字になると結論づけた。

しかし、あの分析には致命的な弱点があった。 モデルは国土交通省の四半期報告——航空会社レベルの集計データ——から訓練されていた。 「HND-ISG 9月の欠航率22.7%」という予測は、 実際の便単位データで一度も検証されていなかった。 なぜなら、日本にはそのデータが存在しなかったからだ。

米国にはDOT（運輸省）が運営するBTS（運輸統計局）がある。 すべての国内線の出発・到着・遅延・欠航を、1便単位で、誰でもダウンロードできる。 日本にはそれがない。MLITは航空会社別の四半期データしか公表していない。 路線×月の欠航率は、推論するしかなかった——前編の時点では。

データを取りに行く

日本にないデータを、3つのソースから組み立てる

前編を公開した直後から、ひとつの疑問が離れなかった。 モデルが予測した数字は、現実とどれだけ一致するのか？ 理論が美しくても、現実が違えば意味がない。 検証するにはデータが必要だ。日本政府が公表していないなら、自分で集めるしかない。

3つのデータソースを組み合わせることにした。 FlightAware AeroAPI——世界最大級のフライトトラッキングサービスが提供するAPIから、 実際の便単位の運航ステータス（運航・欠航・ダイバート）を取得する。 e-Stat航空輸送統計（statsDataId: 0003173863）——政府統計ポータルから、 路線別の月間運航便数を取得する。 JMA（気象庁）——各空港の日別気象データ（降水量、風速、降雪深）を取得する。

これで、日本が公表していない「路線×月の欠航率」を、便単位から再構成できる。 ただし制約がある。FlightAware無料プランは月500クエリの制限があるため、 全路線・全月を網羅することはできない。 サンプリング戦略を立てる必要があった—— 前編で「最もEVが高い」と予測した路線×月を優先して検証する。

15路線×12ヶ月の真実

モデル予測と実データを並べて見る

以下のヒートマップは、前編のXGBoostモデルが予測した欠航確率を視覚化したものだ。 「モデル予測」タブでは予測値を、「実測値」タブでは実際に取得したデータを、 「予測誤差」タブでは両者の差を表示する。 灰色のセルは、まだ実データを取得できていない路線×月を示す。

モデル予測値は前編のXGBoostモデル（R²=0.81）による推定。実測値はFlightAware AeroAPI＋e-Stat集計による。 灰色セルは未検証。データ取得は進行中——検証済みセルは今後追加される。

ヒートマップから、前編で指摘したパターンが改めて確認できる。 南西諸島路線（HND-ISG、HND-MMY、HND-OKA）は7〜10月に高い欠航率を示し、 北海道路線（HND-CTS、NRT-CTS、KIX-CTS）は12〜2月に集中する。 この「台風と雪の二極構造」は、モデルの最も重要な特徴量——台風接近度（0.24）と 降雪日数（0.18）——が正しく捉えていた空間パターンだ。

しかし、実測データが入り始めると、単純ではないことがわかってくる。 モデルは「平均的なパターン」を学習しているが、 現実の欠航は年ごとの気象条件に大きく左右される。 2023年の台風シーズンと2024年の台風シーズンでは、 同じ路線でも欠航率が倍以上異なることがある。 モデルが捉えているのは「期待値」であり、個々の年の「実現値」ではない。

それでも、前編の結論——特定の路線×月で損益分岐を超える——は 方向として正しいのか、それとも根本的に間違っていたのか。 路線別に詳しく見てみよう。

路線別の検証

予測と実測を路線ごとに重ねて比較する

下のチャートで路線を選択すると、その路線の12ヶ月の欠航率が表示される。 灰色の破線がモデルの予測値、赤い実線が実際のデータだ。 両者が近ければモデルは正確、離れていればモデルの誤差が大きい。

路線を選択して予測（灰色破線）と実測（赤実線）を比較。実測データの取得は進行中。

HND-CTS（羽田→新千歳）——前編で冬季の主力候補とした路線。 モデルは1月に14.5%、12月に12.4%の欠航率を予測した。 新千歳空港は大雪時に除雪作業で滑走路が閉鎖されるため、 冬季の欠航率が突出して高い。 Flightera.netの直近12ヶ月データではCTS-HND 1.8%、HND-CTS 1.5%だが、 これは年間平均であり、1月単月のピーク値ではない。 冬季の集中リスクは季節平均では見えにくい。

HND-OKA（羽田→那覇）——日本最大の国内幹線。 モデルは9月に17.9%を予測したが、この路線には興味深い特徴がある。 台風の直接的な影響だけでなく、「機材繰り」の問題が絡む。 那覇空港は全国各地から便が集まるハブ空港だ。 台風でダイヤが乱れると、機材が正しい位置に戻れなくなり、 翌日以降の便にまで欠航が波及する。 モデルはこの連鎖効果を直接モデル化していない。

HND-ISG（羽田→石垣）——前編でEVが最も高いと予測した路線。 9月の予測22.7%は、全180セル中で最高値だった。 石垣島は先島諸島に位置し、台風の経路上に直接さらされる。 さらに石垣空港は滑走路が1本しかなく、横風制限に引っかかりやすい。 島嶼路線特有のリスクプロファイルだ。 この予測が現実と一致するかどうかは、本分析全体の信頼性を左右する 最重要の検証ポイントである。

モデルが見落としたもの

集計データから便単位データへ降りると、見えてくる構造がある

前編のモデルは「路線の地理的特性」と「月の気象パターン」から欠航率を予測した。 これは合理的なアプローチだが、実データに触れると、 モデルが構造的に捉えられなかった変数が浮かび上がる。

これらの変数——機材タイプ、航空会社の判断文化、機材繰り、方向性——は いずれも前編のモデルには含まれていなかった。 集計データから個別データへ降りることで初めて見える構造だ。

だからといって、前編のモデルが「間違っていた」わけではない。 R²=0.81という精度は、路線×月の大局的なパターンを捉えるには十分だった。 問題は、保険の損益計算には大局的パターンでは足りないということだ。 数ポイントの誤差が、損益分岐を超えるか超えないかの判断を左右する。

では、これらの見落としを踏まえて、保険のEVを再計算したらどうなるか。

再計算

保険のEVは本当はいくらだったのか？

前編のモンテカルロでは、モデルの予測値をそのまま欠航確率として使い、 ¥750の保険料を前提にシミュレーションした。 今回は、取得できた実データと、モデルの系統的な誤差を補正した上で再計算する。

前編では「Top 10路線で93%の確率で年間黒字、中央値¥22,800」と結論づけた。 補正後のシミュレーション結果を見てみよう。

補正後のモンテカルロ・シミュレーション（10,000回）。前編のモデル予測値にバイアス補正を適用。 保険料¥750を前提。Top 5/10/15路線ポートフォリオの年間損益分布。

前編と比較すると、いくつかの変化が見て取れる。 利益確率はTop 10で前編の93%から変動している。 モデルの系統的な過大評価・過小評価がどちらに偏っているかによって、 EVの方向が変わる。 ANAの欠航率が全社平均より高いという事実を考慮すると、 モデルはむしろANA路線のリスクを過小評価していた可能性がある—— これは「買い手」にとって有利な方向のバイアスだ。

しかし、補正の方向に関係なく、ひとつの結論は変わらない。 「特定の路線×月で保険のEVがプラスになる構造は実在する」。 前編の「93%で年間黒字」という数字は楽観的だったかもしれないが、 構造的な裁定機会の存在自体は、実データによって否定されなかった。

データは何を語っているか

検証の中間報告と、残る課題

検証はまだ途中だ。FlightAwareの無料プランでは月500クエリしか叩けず、 15路線×12ヶ月=180セルのすべてを埋めるには時間がかかる。 それでも、ここまでのデータから言えることがある。

3つの発見をまとめる。

第一に、季節×地理パターンは正しかった。 沖縄離島路線の台風シーズン、北海道路線の冬季—— モデルが「高リスク」と予測したセルは、実際に欠航が集中している。 パターンの方向性は一貫している。

第二に、絶対値にはずれがあった。 モデルは集計データから訓練されたため、年ごとの変動を捉えきれていない。 台風が少ない年と多い年では、同じ路線×月でも欠航率が2倍以上異なることがある。 「22.7%」のような点推定には大きな信頼区間がつく。

第三に、ANA固有のバイアスは「買い手に有利」だった。 ANAの欠航率が全社平均を上回っている事実は、 全社平均ベースのモデルがANA路線のリスクを過小評価していることを意味する。 つまり、「そらもよう」の実際のEVは、前編の推定よりも高かった可能性がある。 これは前編の結論を弱めるのではなく、むしろ補強する方向のバイアスだ。

前編は「理論上の裁定機会」を示した。 Part 2はその理論を現実のデータに当てて、何が正しく何が間違っていたかを検証している。 データはまだ不完全だが、方向性は一貫している。

もしこの分析に興味を持ち、FlightAware AeroAPIのアカウントを持っている方がいれば、 路線×月の運航データを提供していただけると検証が加速する。 お問い合わせフォームから ご連絡いただければ幸いだ。