見出し画像

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で報じられた資料と比較すると、衝突位置付近の海上保安庁機が表示されていないことがわかります。

Flightradar24より
NHKより

本稿ではこの理由について解説します。

前提

まずは前提となる事項を再確認します。

前提1:「フライトレーダー」と「フライトレコーダー」は別物

フライトレーダー24(Flightradar24)、通称「フライトレーダー」「FR24」はスウェーデンのFlightradar24社が運営するWebサイト・スマホ向けアプリです。ボランティアベースの受信ネットワークで成り立っており、誰でもアクセスすることができます。

フライトレコーダー(Flight Recorder、FDR)は、航空事故の原因究明のために航空機に備え付けられている装置です。計器の値などを記録するデジタルフライトデータレコーダー(DFDR)と、操縦室の音声を記録するコックピットボイスレコーダー(CVR)の2つをまとめた総称です。事故調査委員会やマスメディアが公表する場合を除き、一般人はその内容を知ることはできません。

カタカナでは1文字違いですが、両者は全くの別物ですので注意してください。

前提2: Flightradar24は航空管制のレーダーではない

Flightradar24は世界各地のボランティアが受信した情報を集約して表示しています。これは実際の航空管制のレーダーで使われている仕組みとは異なるため、「Flightradar24に表示されている情報は、航空管制で使われているものとは別物(あくまで参考程度)」と認識する必要があります。

また、Flightradar24に表示されていないことが事故の原因になっているわけではありません。事故調査の観点からは「管制塔のレーダーが追跡できているか」が重要になり、Flightradar24は外野が参考にする程度にしか使えません。

ボランティアが小型のアンテナで受信した情報をFlightradar24に送っている(筆者撮影)
実際の航空管制レーダーの例。非常に大型である。(出典:国土交通省

要素1: ADS-BとMLAT

Flightradar24のような航空機追跡サイトにおいて、航空機を捉える手段は主に2種類あります。ADS-BMLATです。

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に掲載された航空機は航空機の機種のみを表示するようになっています。

LADD登録機で、機種の「GL7T」のみ表示されている(出典: Flightradar24)

また、一部の軍用機・政府専用機などはFlightradar24に対して直接申し入れが行われるケースもあります。

ただし、このような表示規制を遵守しないサイトもあります(おそらく法的には遵守する義務がないのでしょう)。代表例がADS-B Exchangeです。先ほど示した「GL7T」ですが、こちらではN512GLという機体番号が表示されています。

ADS-B Exchangeは表示規制を受け入れておらず、生データを表示する

衝突した海保機「JA722A」はどうだったのか

結論から言うと、合わせ技です。JA722Aは両方に当てはまっており、航空機追跡サイトではスムーズに追跡しづらい機材です(繰り返しになりますが、管制・運航上は全く問題ありません。同様の条件に当てはまる民間機も多く存在します)。

LADDについて

ADS-B ExchangeでJA722Aと打ち込むと、以下のような表示が得られます。DB Flagsに "LADD" と記載されているのがわかるでしょうか。

JA722A(出典: ADS-B Exchange)

つまり、保安上の理由によってLADDに登録されており、少なくともFlightradar24で表示がブロックされる機体だったわけです。データベース検索でもヒットしませんし、Playbackでも表示されていないことから、LADD以外に海保から個別で秘匿要請があった可能性も否定できません。

機材検索にも出ない(出典: Flightradar24)

MLATについて

LADDに登録されているので、ADS-B Exchangeで過去のデータを確認しましょう。事故前日の1月1日、JA722Aは能登半島地震に伴い、羽田から小松基地への人員輸送ミッションを行っており、この様子がADS-B Exchange上で記録されています。羽田空港の地上でのデータのみが欠損しており、離陸後になるとその姿が同サイトに捉えられている様子がわかると思います。また、離陸後も航跡がギザギザしており、MLATゆえに精度が出ていないことが分かるかと思います。

ADS-B Exchangeより。クリックで拡大。

また、精度が低い(=受信局数が足りず、三角測量できずに位置を特定できない)ために追跡サイト上では地上で非表示になっていただけであり、海保機のトランスポンダの電源が切られていたわけでも、トランスポンダを積んでいなかったわけでもありません。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.

Japan Airlines Airbus A350 collides with aircraft on landing in Tokyo
https://www.flightradar24.com/blog/jl516-tokyo-accident/

追記:また、ANNの報道によれば、海保機は管制塔のモニターには表示されており、滑走路への進入も検知されていたとのことです。

滑走路進入の海保機 管制官のモニターに赤く表示 羽田空港の航空機衝突事故(2024年1月6日)
https://www.youtube.com/watch?v=WQ4vbSkrhTA

参考までに、以下はJAL機(JA13XJ)の表示です。ADS-Bをデータソースにしているため、追跡サイトが地上のデータも取れているほか、航跡が滑らかであることがわかります。

ADS-B Exchangeより。クリックで拡大。

もちろん、FR24での非表示が事故の原因ではない

繰り返しになって恐縮ですが、実際の航空機の運航に使われているレーダーと、我々一般人が閲覧できる追跡アプリ・Webサイトは別物です。
本件は「フライトレーダーに映っていなかったから発生した事故」ではありませんし、「海上保安庁機はそこに存在していなかった」わけでもありません。
実際の管制塔のレーダーでどう表示されていたか、管制官とパイロットの間でどういうやり取りがあったかが争点となります。

Flightradar24やADS-B Exchangeは強力なツールではありますが、一方で多くの技術的な限界もあります。その限界を知った上で情報を得るのは良いのですが、一般人がアクセスできるサイト・アプリに映っているものが全てであるという過信は禁物です。

こちらのツイートも併せてご覧いただけると幸いです。

関連記事


いいなと思ったら応援しよう!