ハクソク

世界を動かす技術を、日本語で。

プログラマーが信じる航空に関する誤解

2025年6月7日原文(flightaware.engineering)

概要

  • 航空データ は現実世界では非常に 複雑かつ不規則
  • 多くの 前提や常識 が実際には 誤り である事例
  • FlightAware や Hyperfeed が直面する課題の紹介
  • 航空業界の データ設計 で起こりやすい誤解
  • 現場でのトラブル やシステム障害の原因となる誤認識

航空データに関するよくある誤解

  • 航空データ は常に クリーン で 標準化されている という思い込み
  • データ型やスキーマ設計 時の前提が 現実と乖離 している場合
  • Hyperfeed （FlightAwareのフライト追跡エンジン）が 複雑な状況 を解釈する役割

フライトに関する誤解

  • フライトは必ず ゲートから出発 する
  • ゲート出発は 一度きり である
  • フライトは 予定時刻の数時間以内 に出発する
  • フライトは 予定日以内 に出発する
  • フライトには 必ずスケジュール が存在
  • フライトは 空港で離着陸 する
  • 飛行機（ヘリコプター以外） は空港でしか離着陸しない
  • フライトの 最大飛行時間 は十数時間、または数日以内
  • フライト識別は 航空会社コード＋数字 （例：UAL1234）
  • フライト識別は 航空会社コードまたは機体登録記号 で一意
  • 識別子（例：B6459）は 登録記号や便名で明確に区別 できる
  • フライトには 複数の便名が存在しない
  • 複数便名のフライトは 必ず“主”便名がある
  • 便名は 途中で変更されない
  • チケット記載の便名＝ パイロットや管制が使う便名
  • フライト識別子に 無関係な航空会社コード が使われない
  • 同日に 同じ便名を使うフライトは存在しない
  • 同時刻に 同じ便名のフライトは存在しない
  • 大手航空会社で 同じ便名が数分差で重複しない

空港に関する誤解

  • 空港は移転しない
  • ターミナルやゲート番号は 一貫した命名規則
  • 滑走路は一つの空港専用
  • 空港には ICAOコード（4文字）とIATAコード（3文字） が常に存在
  • 空港には ICAO、IATA、地域コード が必ず存在
  • 米国運輸省が 一意の空港コード を割り当てている
  • 空港に 複数のIATAコード は存在しない
  • 米国空港のICAOコードは 必ずKで始まる
  • ICAOコードの 末尾3文字＝IATAコード （米国空港）
  • ICAOコードで 地理的地域が分かる
  • IATAコード保有＝空港
  • ICAOコード保有＝地球上の場所
  • 空港は 何らかの有名な識別子 を必ず持つ

航空会社に関する誤解

  • IATAコードの重複はない
  • 航空会社が 複数のIATA/ICAOコード を使うことはない
  • 機体を見れば 運航会社が分かる
  • 航空会社は 特定路線に便名を割り当て
  • 航空会社は 自社運航便のみに便名を付与
  • 航空会社は 便名を自社運航便だけに割り当てる

ナビゲーション・航空管制に関する誤解

  • ウェイポイント名は一意
  • 高度の定義は一つだけ
  • 航空管制の フライト情報は正確
    • 出発済み表示＝実際の出発
    • フライトプランキャンセル＝絶対に運航しない
    • レーダーデータは正確に機体を識別
    • 重複エリアのレーダーは同じ位置を示す
    • フライトプランの到着地＝到着意図
    • ダイバート（目的地変更）は一度きり

トランスポンダ・ADS-Bに関する誤解

  • ADS-Bメッセージは機体からのみ発信
  • ADS-Bは機体や空港車両からのみ発信
  • ADS-Bは何らかの車両からのみ発信
  • GPS位置は常に正確
  • GPS位置は既知の誤差範囲内で正確
  • ADS-Bメッセージは正しい便名を常に含む
  • トランスポンダは機体種別を正確に表示
  • ADS-Bで機体登録記号が常に分かる
  • トランスポンダのMode Sアドレスは正確に設定
  • 同一機体のトランスポンダは同じMode Sアドレス
  • 便名にNULL等の変な値は使われない
  • 登録変更時にトランスポンダも必ず更新
  • ADS-Bメッセージは送信通りに受信される
  • 偽のADS-Bメッセージは送信されない
  • トランスポンダ故障やケーブル断線は起こらない

まとめ

  • 航空データの設計や運用 には多数の 落とし穴
  • 現実の運用やデータ管理 で想定外が頻発
  • FlightAware や 同業他社 でも 誤解に起因する障害 が発生
  • 柔軟で堅牢なシステム設計 の重要性
  • 現場経験と多様な事例 の蓄積が信頼性向上の鍵

Hackerたちの意見

こういうリストは、もっと詳しい説明があった方がいいよね。このリストは、少なくとも多くの主張に対して例をリンクしてくれてるけど（例えば、定刻に出発したのに40時間遅れて到着するフライト[1]）、何が起こったのかは説明してないんだよね。とはいえ、リンクの中にはすごく参考になるものもあるよ。例えば、ICAO空港コードを持つ火星のクレーター[2]について：「2021年4月19日、インジェニュイティがジェゼロから火星で初めての動力飛行を行い、記念のICAO空港コードJZROを受け取った。」

└

これはしばしば退屈な理由によるものです。例えば、2週間のフライトはGoogleの気球で、悪天候のためにフライトが40時間遅れたり、ADS-Bはパイロットによって設定されるのですが、多くのパイロットが単純に間違って設定してしまったり、という感じです。

CGP Greyによる空港コードの混乱をまとめた素晴らしい動画だよ。https://www.youtube.com/watch?v=jfOUVYQnuhw いくつかの深い理由についても（試みとして）説明してる。

フライトは空港で離着陸する。私の印象では、ブラジルの航空を管理しているすべての古い（2010年以前の）コンピュータシステムがそれを感じ取って、ハックで修正したと思う。 > 空港は決して動かない。また、滑走路も決して動かない。もし滑走路が動いたとしても、方向は変わらないし、空港や滑走路が動くなら、その前に工事があるはずだよ。そこに「航空機は滑走路にしか着陸しない」とも付け加えたいな。「そう、航空機は滑走路とヘリポートにしか着陸しない。」

└

私の印象では、ブラジルの航空を管理しているすべての古い（2010年以前の）コンピュータシステムがそれを感じ取って、ハックで修正したと思う。もう少し詳しく説明してくれる？

この記事についての別の議論だけど、FlightAwareのフォーラムでね。https://www.flightaware.com/squawks/view/1/7_days/popular_ne...

「プログラマーが信じる誤解…」のリストは、テストのソースとして見ることが多いんだ。各項目は、ソフトウェアに間違って組み込まれた仮定を根本から覆すためのユニットテストや統合テストを生むべきだと思う。

└

これらは確かにテストを生み出しました。以前そこで働いていた時、地味なものからデビッド・ブレインのスカイダイビングまで、千を超えるテストがありました。彼らは本当に良いエンジニアリングに重点を置いている集団です。

面白いのは、これらの「誤解…」投稿の共通点が、プログラマーたちが人間が設計し、人間が運営し続けるシステムが、厳密にルールに従っていてエッジケースがないと思っていることだよね。

└

プログラマーとして航空の世界をモデル化するソフトウェアを書いていると、次のようなことを前提に考えがちですが、残念ながらそうはいかないんですよね。ソフトウェアは残念ながら厳格なルールに従うので、現実を包括できる厳格なルールのセットを見つけるのが課題です。データベーススキーマを書くときには、フライトには出発空港と到着空港があるのが自然だと思いますが、残念ながらそうではありません。

└

プログラミングの職業は、柔軟な人間のシステムと厳格なルールに基づく機械とのインターフェースに関するものです。それが繰り返し出てくるのも不思議ではありません。

└

プログラマーはすべてを厳格なルールのセットに還元するのが好きです。なぜなら、それが私たちの思考の仕方だからです。確率的な「アナログ」パラメータが少ないほど良いです。でも、もちろん現実はそんな風には動かないんですよね。

Hacker Newsで議論の続きを見る