JAL機と衝突した海上保安庁機(JA722A)がフライトレーダーに表示されない理由
2024年1月2日18時前ごろ、新千歳発・東京/羽田行のJAL516便（エアバスA350-900、JA13XJ）と、海上保安庁所属「みずなぎ」（DHC-8 Dash 8、JA722A）が羽田空港C滑走路で衝突する事故が発生しました。
※事故自体の経過についてはNHKの記事などをご覧ください（随時更新されるようです）。
要約
Flightradar24など、航空機追跡サイトはボランティアによる受信で成り立っている
海保機は「ADS-B」に対応していなかったので、航空機追跡サイトでは低高度（地上走行中）に表示されなかった
加えて、Flightradar24は自主規制によって海保機の位置を表示していなかった
「ADS-B非対応」はトランスポンダを積んでいないという意味ではない。トランスポンダは積まれていたし、管制側のレーダーには表示される
ADS-B非対応機は民間機にも存在するため、海保機のみが特例というわけではない
海保機が表示されない？
事故直前時点でのFlightradar24のスクリーンショットは以下の通りです。NHKで報じられた資料と比較すると、衝突位置付近の海上保安庁機が表示されていないことがわかります。
本稿ではこの理由について解説します。
前提
まずは前提となる事項を再確認します。
前提1:「フライトレーダー」と「フライトレコーダー」は別物
フライトレーダー24（Flightradar24）、通称「フライトレーダー」「FR24」はスウェーデンのFlightradar24社が運営するWebサイト・スマホ向けアプリです。ボランティアベースの受信ネットワークで成り立っており、誰でもアクセスすることができます。
フライトレコーダー（Flight Recorder、FDR）は、航空事故の原因究明のために航空機に備え付けられている装置です。計器の値などを記録するデジタルフライトデータレコーダー（DFDR）と、操縦室の音声を記録するコックピットボイスレコーダー（CVR）の2つをまとめた総称です。事故調査委員会やマスメディアが公表する場合を除き、一般人はその内容を知ることはできません。
カタカナでは1文字違いですが、両者は全くの別物ですので注意してください。
前提2: Flightradar24は航空管制のレーダーではない
Flightradar24は世界各地のボランティアが受信した情報を集約して表示しています。これは実際の航空管制のレーダーで使われている仕組みとは異なるため、「Flightradar24に表示されている情報は、航空管制で使われているものとは別物（あくまで参考程度）」と認識する必要があります。
また、Flightradar24に表示されていないことが事故の原因になっているわけではありません。事故調査の観点からは「管制塔のレーダーが追跡できているか」が重要になり、Flightradar24は外野が参考にする程度にしか使えません。
要素1: ADS-BとMLAT
Flightradar24のような航空機追跡サイトにおいて、航空機を捉える手段は主に2種類あります。ADS-BとMLATです。
ADS-B
ADS-Bは、簡単に言ってしまえば「飛行機が自らのGPSの座標を取得し、それを無線で発信する」という仕組みです。Flightradar24は世界中のボランティアが設置した受信機で、このADS-Bのデータを受信し、運営側でリアルタイムに集約して表示しています。
MLAT （マルチラテレーション）
古い航空機などはADS-Bに対応していないものがあります（今回のJA722Aも非対応の機材でした）。
航空管制はADS-Bに依存しているわけではないので、運航には何ら問題ありません（管制塔のレーダーには表示されますし、ANAやJALにもADS-B非対応機があります）。ただし、Flightradar24はこういった飛行機の座標をそのままでは取得できません。
そこで、航空管制用に発信されている電波（GPS座標データなし）を複数の地点で受信し、その受信時刻の差から航空機の座標を計算するという仕組みが用いられます。これをMLATと呼びます。要は三角測量です。
ただ、MLATには欠点があり、複数の受信局で同時に受信できないと、位置を絞り込めません。そのため、表示が不正確になったり、そもそも表示されなかったりといった挙動が発生します。
特に低高度や空港の地上を走行している航空機は、障害物が多くなるため受信しづらく、「地上では表示されないが、離陸後になると表示される」といったケースが頻発します。
なお、MLATの概念自体は特殊なものではないため、Flightradar24以外の航空機追跡サイト（RadarboxやADS-B Exchangeなど）でも導入されています。
追記：
MLATの仕組み自体は実際の航空管制でも利用されていますが、これは「レーダーにおいて地上の死角を補うため」という別の目的によるものです。Flightradar24やADS-B ExchangeにおけるMLATは「三角測量という同じ概念を各サービスが勝手にやっている」だけであり、航空管制のデータと同じものが表示されているというわけではありません。
そのため、「Flightradar24のMLATに不備があった（映らなかった）」としても、それはアプリ上の話で管制レーダーとは別の問題です。
https://www.mlit.go.jp/koku/content/001471477.pdf
要素2: LADDと表示自粛
Flightradar24は閲覧者にとっては便利な反面、運航者によっては現在位置が丸わかりになることで問題が生じることがあります。例えばプライベートジェットや警察のヘリなどで、セキュリティ上の理由で位置を伏せたいという要望が発生するのは想像しやすいでしょう。
そこで、アメリカ連邦航空局（FAA）はLimiting Aircraft Data Displayed (LADD)という仕組みがあり、このリストに登録することで「この航空機は位置を表示することを望んでいない」ということを明示できます。
Flightradar24はこれを遵守しており、LADDに掲載された航空機は航空機の機種のみを表示するようになっています。
また、一部の軍用機・政府専用機などはFlightradar24に対して直接申し入れが行われるケースもあります。
ただし、このような表示規制を遵守しないサイトもあります（おそらく法的には遵守する義務がないのでしょう）。代表例がADS-B Exchangeです。先ほど示した「GL7T」ですが、こちらではN512GLという機体番号が表示されています。
衝突した海保機「JA722A」はどうだったのか
結論から言うと、合わせ技です。JA722Aは両方に当てはまっており、航空機追跡サイトではスムーズに追跡しづらい機材です（繰り返しになりますが、管制・運航上は全く問題ありません。同様の条件に当てはまる民間機も多く存在します）。
LADDについて
ADS-B ExchangeでJA722Aと打ち込むと、以下のような表示が得られます。DB Flagsに "LADD" と記載されているのがわかるでしょうか。
つまり、保安上の理由によってLADDに登録されており、少なくともFlightradar24で表示がブロックされる機体だったわけです。データベース検索でもヒットしませんし、Playbackでも表示されていないことから、LADD以外に海保から個別で秘匿要請があった可能性も否定できません。
MLATについて
LADDに登録されているので、ADS-B Exchangeで過去のデータを確認しましょう。事故前日の1月1日、JA722Aは能登半島地震に伴い、羽田から小松基地への人員輸送ミッションを行っており、この様子がADS-B Exchange上で記録されています。羽田空港の地上でのデータのみが欠損しており、離陸後になるとその姿が同サイトに捉えられている様子がわかると思います。また、離陸後も航跡がギザギザしており、MLATゆえに精度が出ていないことが分かるかと思います。
また、精度が低い（＝受信局数が足りず、三角測量できずに位置を特定できない）ために追跡サイト上では地上で非表示になっていただけであり、海保機のトランスポンダの電源が切られていたわけでも、トランスポンダを積んでいなかったわけでもありません。Flightradar24は日本時間17:47:32にJA722Aからの最後の信号を受信していたことを明らかにしています。
The last Mode S frame received from the Japan Coast Guard DHC-8 aircraft was logged at 08:47:32 UTC on January 02. The aircraft was not equipped with an ADS-B transponder.
https://www.flightradar24.com/blog/jl516-tokyo-accident/
追記：また、ANNの報道によれば、海保機は管制塔のモニターには表示されており、滑走路への進入も検知されていたとのことです。
滑走路進入の海保機 管制官のモニターに赤く表示 羽田空港の航空機衝突事故(2024年1月6日)
https://www.youtube.com/watch?v=WQ4vbSkrhTA
参考までに、以下はJAL機（JA13XJ）の表示です。ADS-Bをデータソースにしているため、追跡サイトが地上のデータも取れているほか、航跡が滑らかであることがわかります。
もちろん、FR24での非表示が事故の原因ではない
繰り返しになって恐縮ですが、実際の航空機の運航に使われているレーダーと、我々一般人が閲覧できる追跡アプリ・Webサイトは別物です。
本件は「フライトレーダーに映っていなかったから発生した事故」ではありませんし、「海上保安庁機はそこに存在していなかった」わけでもありません。
実際の管制塔のレーダーでどう表示されていたか、管制官とパイロットの間でどういうやり取りがあったかが争点となります。
Flightradar24やADS-B Exchangeは強力なツールではありますが、一方で多くの技術的な限界もあります。その限界を知った上で情報を得るのは良いのですが、一般人がアクセスできるサイト・アプリに映っているものが全てであるという過信は禁物です。
こちらのツイートも併せてご覧いただけると幸いです。
羽田空港におけるJAL機・海上保安庁機の衝突事故に関して、いくつかデマが出回っていることを確認したため、1枚の画像にまとめました。
— ryo-a (@geo_vitya) January 3, 2024
フライトレーダーに表示されていない件についてはnote記事に詳細にまとめていますので、そちらも併せてご覧ください。https://t.co/5WImgGZWkh pic.twitter.com/41fhyynXSu
関連記事
この記事が気に入ったらサポートをしてみませんか？