航空分野についてプログラマが信じがちな誤った常識
(flightaware.engineering)- 航空データには複雑で非標準的な性質が多い
- 航空便、空港、ナビゲーション、トランスポンダ情報について、開発者はしばしば誤った前提を置いてしまう
- 実際のフライト追跡システムは、多様な例外状況やデータ異常に柔軟に対応しなければならない
- 多くの誤解は、ソフトウェアや顧客システムで予期しないエラーを引き起こす
- データ設計では、現実の複雑さを綿密に反映する視点が必要である
概要
FlightAwareは、世界中の航空データを処理・配信するソフトウェアを開発する企業である。しかし実際の航空データは直感に反して、定型的ではなく例外や変則が多い。多くの開発者は、データ構造、フロー、識別体系などについてさまざまな前提を置くが、これらは現実では誤った仮定となり、システムのエラーや不整合を招く。この文章は「名前は間違った常識」シリーズの延長として、航空業界のソフトウェアで頻繁に犯される誤解と、それによって生じる事例を整理したものである。
Flights（航空便情報）
- 航空便は常にゲートから出発するという誤解があるが、実際には何度もゲートを移動したり、予定より大幅に遅れたり早く出発したりする場合がある
- 航空便のスケジュールや出発・到着空港が明確だと思われがちだが、ヘリコプター・軍用機などは空港以外の場所で離着陸する事例が存在する
- 航空便の飛行時間やスケジュールは規則的に見えても、数日にわたる長距離飛行や変則的な運航も頻繁にある
- 航空便識別番号（例: UAL1234）は一意だと仮定しがちだが、実際には1機の航空機に複数の識別子や番号が付与され、同じ番号が複数の状況で使われることもある
- 表記上は同じ番号でも、便名、登録番号、その他の標識が混在して混乱を招き、チケット、管制、パイロットごとに使う識別情報が異なることがある
Airports（空港情報）
- 空港の位置や識別コードは固定だと思われがちだが、実際には空港が閉鎖されたり、移転・統合されたりして、位置やコードが変更されることがある
- ターミナル/ゲート番号、滑走路などの命名体系も一貫しておらず、例外的なルールが多い
- ICAO/IATAコード体系についても、重複、複数コードの付与、位置コードに関する誤解など、現実と合わない事例が多数存在する
- ある識別情報（例: IATAコード）があるからといって、必ずしも実在の空港であるとは限らず、鉄道駅・バスターミナルなどにIATAコードが付与された事例もある
- さらにはICAOコードの中には、地球上ではない場所（例: 異星のクレーター）に割り当てられたものもある
Airlines（航空会社情報）
- 個別の行で具体的な誤った常識が挙げられていないため省略する
Navigation（航法および航路情報）
- ウェイポイント名は固有だという誤解があるが、実際には重複がある
- 航空で使われる高度の定義は1つに統一されておらず、複数の基準によって異なる解釈がされる
- 航空管制データは完全に正確だと思われるかもしれないが、実際には誤りや変更が頻繁に発生する
- 航空便計画の取り消しやプラン変更が実際の飛行に反映されなかったり、同じ航空便が何度も目的地を変更したりすることがある
- レーダーや航空管制機関の間でデータ不一致が起きたり、同時観測でも位置が食い違ったりする現象も存在する
Transponders and ADS-B（トランスポンダおよびADS-B関連情報）
- ADS-B信号は飛行機からしか送信されないと仮定しがちだが、空港車両やその他の装置から送信されることもある
- GPS座標の正確性や信号の信頼性を過信するのも誤解である
- トランスポンダ登録情報（識別番号、Mode Sアドレスなど）の誤り・重複、保守漏れ、フォーマットエラーなどにより、リアルタイムデータと実際の情報の不一致が頻繁に発生する
- ADS-B情報はそのまま受信・保存されると思われがちだが、伝送エラー、信号偽装などさまざまな問題が起こる
- 機器故障、管理不備、外部要因（例: ネズミによるケーブル損傷）も現実的な変数である
まとめ
この一覧は、FlightAwareおよびHyperfeed開発チームが長年にわたり数多くの実例から得た経験と知見をもとに、航空データの信頼性の複雑さを示している。さまざまなエラーや誤解を減らすためには、実在する例外状況を徹底的に考慮したデータモデリングと運用が重要であることを強調している。
4件のコメント
データの標準化がだからこそ…重要なんだよね…（笑）
本文は本当に簡潔なのに、にじみ出る感情が;;
読むだけで血圧が上がりますね（笑）
Hacker Newsの意見
航空機には、時間が経っても変わらない単一の一意識別子が存在しないという話。各機体にはシリアル番号が与えられるが、それだけでは一意性は保証されないという実体験の共有。「製造者、機種、シリアル番号」の組み合わせがかろうじて生涯にわたる一意識別子になるが、機体が構造変更でタイプ変更されると、これすら変わる場合がある。航空のように巨大で複雑なシステムに不変の識別子がないのは不思議だという個人的な感想も添えられている。航空機登録番号（テールナンバー）は自動車のナンバープレートのように変わり、ICAOの24ビット識別子はADS-B機器に結び付いているため移設・変更も自由だという説明もある
「製造者、機種、シリアル番号」の組み合わせが特許対象になったことに驚いた、という好奇心の表明。どうしてこんなものが新規性ありと認められて特許になったのか疑問を呈している
この話を「テセウスの船」のパラドックスと結び付けて、航空機の同一性や識別子の変化に関する哲学的連想を紹介 Ship of Theseus ウィキペディアリンク
航空業界は国ごとにサイロ化した形でそれぞれ別々に発展してきたため、標準化が遅れたという歴史的背景の共有。世界的標準がきちんと定着したこと自体が驚くべきことだという見方。現在は大手メーカーが少数に集約されたため、ようやくそれが可能になっているという分析
現実の現場では「真の」一意識別子が重要な問題として頻繁に現れる、という実務経験の共有。解決策はほぼ常に「モデル、製造者、シリアル番号」の組み合わせで、必要なら製造年まで加える。人間のデータでさえ、言語（母語）のような基準で重複排除を試みた事例に触れている
滑走路番号も時間の経過とともに変わる例として、ウィキ文書を共有 Runway ウィキペディアリンク
こうしたリストは、いつももっと詳しい説明が付いていればずっと有益なのに、という意見。ただ、リンク先の出典情報には有用なものが多く、たとえば「火星のクレーターにICAO空港コードが与えられた事例（JZRO）」の紹介 Jezeroクレーターのウィキペディアリンク, 出発は正常なのに40時間後に着陸遅延となった便の例
製造者・機種・シリアル番号の組み合わせがあまりにも自明に見えるのに、それがどうして特許になったのか、そして今でも誰かがその特許で利益を得ているのか疑問を呈している
飛行データ分析ソフトウェアの開発経験から、ヘリコプターも飛行機も病院、屋上、駐車場、運動場、空港、ゴルフ場などさまざまな場所で離着陸するため、「航空に関するあらゆる嘘」の中で大半の時間を過ごす実際の開発者の苦労
"Falsehoods..." シリーズの記事を見るたび、多くの開発者が人間中心のシステムも厳密なルールだけに従うはずだと思い込んでいる点が興味深い、という見方
開発者はすべてを厳密なルール体系に還元したがるが、実際の世界はそうではないことを認める
プログラミングという職業そのものが、柔軟な人間のシステムと厳密なルールベースの機械との間のインターフェースである、という分析
プログラマの立場では、世界をソフトウェアとしてモデル化するときにこうした前提を当然視しがちだが、現実にはまったくそうではなく、そのために生じるジレンマと混乱の共有。たとえば、フライトには出発空港と到着空港があるのが当然だと思ってしまうが、現実はそうではないという例
ソフトウェアの本質上、ドメインモデリングは必ずルールの集合として作らなければならない、と主張。もしルールがなければ何の機能も提供できないからだ。一般の人に「うるう秒」のような例外を説明すると戯言だと誤解されがちなだけに、むしろ開発者のほうが世界の例外や複雑さをよく認識していることも多い、という主張
"Falsehoods Programmers Believe..." シリーズでは、各項目をテストケースとして扱う方法が提示されている。プログラムに誤って埋め込まれた前提を検証する単体・統合テストへ拡張できる
「フライトは空港で離着陸する」という前提が、かつてブラジルの航空システムに無条件で存在しており、それを応急処置で解決した事例への言及。「空港／滑走路は位置や方角が変わらない」もまた非常によくある誤った前提だと批判している。「航空機は滑走路かヘリポートでしか着陸しない」という前提まで追加すべきだという提案
CGP Greyによる、空港コードがいかにめちゃくちゃな経緯で決まったかをうまく要約した動画を共有 YouTubeリンク。システム特有の事情まで説明している
同じテーマを扱うFlightAwareフォーラムの関連議論も紹介 FlightAwareフォーラムリンク
プログラマとして、このリストの前提はどれも合理的だと思っていたのに、あとから苦痛とともに現実を思い知って頭が爆発しそうになった、という感想の共有。見事な要約だったという称賛