ウクライナに勝利を！
|
YSFLIGHT.COM内のプログラムはすべてがオープンソースでは無いですが、オープンなものについては、以下のURLからダウンロードできます。
https://github.com/captainys/public
ウクライナに勝利を！
去年のいつごろだったか、アメリカを斜めに横断する形で皆既日食が見れるとの情報を得た。ピッツバーグから北に車で2時間程度のエリーまで行けば皆既日食が見れるとのこと。ちなみに、日本語では「エリー湖」と訳すが、発音は「イーリー」である。これも発音に即したカタカナにしておけば通じるのに。「ストール」を「失速」と訳したやつと、「イーリー」を「エリー」と日本語にしたやつらの罪は重い。今からでも正しく矯正するための抵抗で、以後イーリーと書く。イーリーには空港があるから飛行機で行けば楽だ。昔フライトスクールから飛行機を借りていたころは、直前になるまで飛行機を予約できなかったが、今のBeaver Valley Flying Clubではどれだけ先でも予約できる。僕は早速飛行機を予約してしまった。
ピッツバーグには、ビールを醸造してその場で飲めるBreweryがたくさんある。全米でも多い方なのではないだろうか。そして、在住日本人の中で、月に一度集まって醸造所を巡って酒を飲むビール部なるグループがある。その部長が飛行機で行くなら一緒に乗せてほしい、とのことだった。たまたまその時その場にいたもう一名一緒に行きたいとのことで、その二人を乗せていくことにした。本当は我が妻ともう一人乗せて行こうと思っていたのだが、我が妻はどうも乗り気ではない。
当日午前10時ピッツバーグを出て空港に向かう。11時には空港に着いて、12時にはイーリー空港に着陸、いろいろセットアップして3時10分ごろから皆既日食の予定だった。
[続きを読む]
なお、↓は世界初の一般向けデジカメ、カシオQV-10で撮影した皆既日食。
Linux対応って、もうLinux上で走るじゃんということじゃなくて、津軽のVM上でLinux+JE4 1995-12というのが動くようになった。このLinux、1995年12月のものだけにカーネルのバージョンがなんと1.3.30。まだインストールまでは試してないけど、CDから起動するバージョンで、X-WindowとFVWMまで動作を確認した。ハイレゾモードでX-Windowを立ち上げるとマウスインテグレーションにも対応する。ちょっとウィンドウサイズ変えようとしたときマウスがグラグラするけど。
Windows 95まで起動できるんだからあっさり起動するだろう、と、思ったら、まずCD-ROMドライバが割り込み許可状態でタイマーI/Oをポーリング。本来タイマーアップのフラグは割り込みハンドラが消してしまうから、割り込み禁止しておかないとポーリングできないはずなのだ。しかし、実機で同じコンディションでテストしたところ、ポーリングできてしまうことが判明。しかも、タイマー割り込みもかかってきていた。どうも実機ではタイマーがアップしてから割り込みがかかるまでの間に少なくとも20クロック程度のラグがあるようだ。しかも、同じコードは386 TOWNSでも動いたはずだから、結構なラグと思われる。どうやって実装したもんかなと思ったけど、いい方法を思いついたのでここは突破。
続いて、なんと他のどのOSでも使ってなかったCPUによるタスクスイッチングを使用していることが判明。80386以降のCPUはCPUがタスクスイッチングの面倒を見る機能がある。が、しかし、余計な処理までしているらしくソフトウェアで切り替えた方が効率が良いということで、誰も使わなくなり、AMDのCPUでは既に削除された機能らしい。複数の情報から、Linuxも相当初期のバージョン以降はハードウェアタスクスイッチングは使わなくなったと聞いていたので、遭遇しないだろうと思っていたら、これはその相当初期のバージョンだった！このハードウェアタスクスイッチング、単純に他のタスクにジャンプするだけならいいのだが、ネステドタスクというものが存在するらしく、CPUのリファレンスを見てもどう対応していいかわからない。しかし、他のタスクにジャンプするとこだけ実装してみたら動いちゃった。
ということで、下はそのFM TOWNS用Linuxのスクリーンショット。
この1月から大きく動きがあって、ついにFM TOWNS/Martyエミュレータ「津軽」がWindows 95に対応した。いや、Windows 95で実行できるようになったんじゃなくて、VM上でwindows 95を実行できるようになった。
FM TOWNS/Martyエミュレータ「津軽」はもともとFM TOWNS II MXの再現を目指してスタートした。本当にFM TOWNS II MXを再現するならば、TOWNS OSに加えてFM OASYS, Windows 3.1, Windows 95, Linuxも起動できなくてはならない。ただし、WindowsやLinuxをエミュレートするなら敢えてFM TOWNSを使う必要はない。当初はTOWNS OSのゲームまでサポートできればいいだろうというつもりだったから、DOS6、Windows 3.1, Windows 95には対応しないつもりだった。しかし、ユーザの皆さまからの強い要望により、DOS6に対応。Windows 3.1の要望はほとんどなかったものの、DOS6までできたらWindows 3.1もできるんじゃね？という安易な考えを起こして、結果さんざん苦労してWindows 3.1まで対応、3.1までやったならどうせなら95も対応したい、というところで止まっていた。
似たような経験が大学生の頃にあった。青森県弘前市のド田舎から、ほぼ同じレベルの田舎である神奈川県藤沢市北部に引っ越して一年目、エアコンなんてなくても死なないだろう、と、思ってエアコンを買わなかった。今の温暖化した地球よりは涼しかったとはいえ、何度かものすごく熱い日を経験した。二年目、さすがにもうエアコン無いと死ぬだろう、と、思ったので買おうかと思ったのだが、いや、ここで買ってしまっては去年の苦労が水の泡だ。やっぱりやめよう。と、思って買わなかった。そして、ものすごく暑い日で苦しんだ。三年目、さすがに今度こそエアコン無いと死ぬ、今度こそ買うだろう。と、思ったのだが、いや、ここで買ってしまっては去年と一昨年の苦労が水の泡だ。やっぱりやめよう。と思って買わなかった。以下これを合計7年間繰り返してしまった。という非常によく似た経験であった。(どこが!?)
(続きを読む)羽田日航機・海保機衝突事故は、衝突の瞬間は目撃していないとはいえ、自分が事故が起きた瞬間事故現場の空港にいたということがあり、どうしても他人事と思えない。 アメリカで飛行機操縦してるパイロットとしては、皮肉に思えてしまう。アメリカ連邦航空局は躍起になって滑走路上の衝突事故をなんとしても阻止しようとしてきた。今回の羽田の事故は、アメリカ連邦航空局が心配していた事故が日本で起こってしまったようなものだ。
新たにわかってきたことは、管制官が滑走路侵入警報を見ていなかった、と証言している点だ。この点、まだはっきりしないのは、事故の瞬間見ていなかったという意味なのか、それ以前からまったく見ていなかったのか。想像では、着陸許可・離陸許可を出すときだけチラ見していたのではないかと思う。事故の瞬間見ていなかったという意味ではないだろうか。
また、色だけではなく音の警報を出すことを検討している、という記事があり、その中に注目するべき一文があった。https://www.sanyonews.jp/article/1501218 この記事によると「空港の混雑時に頻繁にアラームが鳴ると管制官の業務に支障が出るとの懸念も踏まえ」とある。だから、頻繁に警報が出てしまうシステムだったものと思われる。
この記事が出る前、わからなかったのは、この警報システムがどこまで頭がいいかだった。許可を得ていない飛行機を識別して、無許可の滑走路侵入があったときのみ警報を出していたのか、許可の有無にかかわらず航空機が滑走路に入ったら警報を出していたのか、これがわからなかった。上の記事から、どうやらこの警報システムは、あまり頭が良いものではなく、許可があろうとなかろうと航空機が滑走路に入ったら警報を出すもののようだ。そうであれば、離着陸があるたびに赤く点灯していたのではないだろうか。
警報というのは本当に危ないときだけ発令されるから意味がある。頻繁に出ていたのでは、警報が出ることに慣れてしまって意味をなさなくなる。狼少年化とも言える。だとすると、音を出すようにしたところで意味は無い。そのようなシステムだったとすると、もしも僕が管制官だったらと想像力を働かせると、離着陸の許可を出すとき既に誰かが滑走路上にいてはならないので、そのタイミングでチラっと見るだけのような使い方になっていたと思う。
警報システムに意味のある改修をしようと思ったならば、滑走路に飛行機が入っただけなら黄色、衝突の危険が迫ったとき赤色にするのがいい。それは航空機の正確な位置を知ることができれば可能で、アメリカではすでに義務化されたADS-Bを日本でも義務化すればいい。ADS-Bは航空機がGPSによる位置情報を管制官とほかの航空機に通知するシステムで、これがあるとレーダーよりもはるかに小さな遅延で正確に航空機の位置を把握することができる。位置情報がわかれば、滑走路に接近している着陸機を判断できるので、ゴーアラウンド限界に近づく機体があるのに滑走路上に航空機がいたら衝突の危険ありと判定できる。
さらに、衝突の危険を自動的に察知できるのであれば、合成音声によってパイロットにゴーアラウンドを自動的に指示することもできる。空中では既に衝突を避けるTCASというシステムが実用化されているので、これと同じようなものを滑走路周辺で実現すればいい。
もうひとつ気になっていたのは、日本には、アメリカ連邦航空局のFAASTチームのような、航空安全を推進するチームが存在するのか。だったが、どうも無いらしい。https://www.tokyo-np.co.jp/article/301942 この記事によると、日本でも国土交通省が滑走路誤侵入対策チームを立ち上げたらしい。 そして、そのチームは平成11年3月に解散してしまっていたらしい。しかも、会社など組織単位で加入するものだったらしく、パイロットが自主的に参加できるようなものではなかったらしい。もしもFAASTチームのような組織があるならば、委員会を立ち上げたり解散したりする必要もなく、日本版FAASTチームが担当すればいいことだ。ということは、日本にはFAASTチームに相当するような組織は無いんだろうな。
FAASTチームは、アメリカ連邦航空局の一部門で、航空安全の啓蒙を主目的としている。FAASTチームはWingsというプログラムを主導していて、パイロットは自主的に参加することができる。Wingsプログラムの訓練やセミナーに参加していると、もしも航空事故や法令違反があった場合でもパイロットの安全意識が高かったことを考慮する、ということになっている。さすがに無罪放免ではないが、日ごろから安全意識が高いパイロットがうっかりミスを犯してしまったのか、それともそもそも安全意識の欠如したパイロットが起こすべくして起こしたことなのか区別するということだ。これはパイロットにとってもインセンティブになるので、参加しているパイロットは多い。航空ショーに出張ってきてFAAのテントでWingsプログラムを推進する力の入れようだ。
そして、Wingsプログラムのセミナーで、何度も事故、あるいは事故寸前だったケースを見せられたし、「Cleared for take off」「Line up and wait」以外は滑走路に入るな、「hold」という単語が聞こえても滑走路入るな、「Take in position and hold」はもう使わない、など、同じことを何度も聞いた。が、同じことを何度も聞くのが重要だ。飛行機免許を取って自分で飛び始めると、そういうことを何度も言ってくれた教官は隣にいない。そのうち、使わないことから忘れていく。それを防止するために、航空安全セミナーで同じことを何度も聞くことには非常に大きな意味があると思っている。思っているけど、日本にはそういうの無いみたいね。
今回の羽田の事故は、まさにFAASTチームがなんとしても防止しようとしてきた教科書通りのケースだった。僕は、日本版FAASTチーム設立を提案するけどな。誰もこんな書き込み読んでないかもしらんけど。 事故が起きたら対策チームを立ち上げて、しばらくしたら解散、というのは航空安全にはほとんど効果が無いだろう。空の安全は継続的なもので、終わりがあるものではない。 ほとぼりが冷めたら対策チームを解散して、報告書を誰もみないような本棚にしまって良いものではない。
もうひとつ、日本航空がエアバス350の燃え残った部分、翼などの保存を検討しているとのこと。良いと思う。燃え残った翼を残骸と呼んでくれるな。この機体は航空機として最も重要な任務、乗員・乗客の生命を守ること、を全うした栄誉の機体だ。あの翼はもう空を飛ぶことは無い。しかし、あの燃え残った翼を無残とは思わない。事故の翌日早朝、羽田からワシントンの飛行機に乗る前、第二ターミナル展望デッキから見たエアバス350の翼は誇らしげに滑走路に横たわってた。是非、翼とエンジン、保存してほしいと思う。もしも、自分が見る機会があるならば、よくやった、と言ってあげたい。
海保機の側面にJAL機がぶつかったのであれば海保機乗員は全員ほぼ即死だっただろうから、機長が生き残ったとすれば後方から激突だったに違いない。だとすると、海保機が滑走路に入って90度ターンする時間にファイナルのJAL機が海保機を視認する時間があったのではないか。夜間、これから降りようとする滑走路上で赤または白の衝突防止灯が点滅していてはならない。JAL機がまったく視認できない状況でぶつかったのだとすると、JAL機の接地と海保機の滑走路進入がほぼ同時だったのではないか。ある意味海保機がJAL機の前に飛び出して来たような状態だったのではないか。しかし、そうであれば滑走路に入って90度ターンする間もなくJAL機に側面からぶつかられるはず。と、思ったら 空港ダイアグラム によるとタクシーウェイC5は斜め誘導路。接地直前に海保機が滑走路に進入したとしてもそもそも最初からJAL機に背後を見せている。これだと、このアングルでは海保機からはファイナルのJAL機も見えないから、海保機からファイナルにいるJAL機を目視確認もできなかった点まで、矛盾なく説明できる、かと思ったら、どうもこのダイアグラム、古い物で今の空港レイアウトだとタクシーウェイC5は直交滑走路である、という説を聞いたのだが、なんでか日本の空港のアプローチチャートとかダイアグラムって無料でなかなか見つからないんだよね。アメリカの空港は、ほとんど全部Airnavとか、AOPAから取れるのに。
他の多くの航空機事故と同様、何人も事故を阻止するチャンスを持った人がいたのだが、すべてがそのチャンスを逃してしまった。いわゆる事故に至る連鎖が完成してしまった。誰もが確率的にエラーを犯すのは避けられない。エラーの連鎖をシステムが断ち切って事故を防止しなくてはならないんだけど、今回の事故もそうだし、、他のどの事故を見てもシステムが連鎖の管制を阻止できなかったことに問題の本質がある。
C5が直交誘導路だったとすると海保機の副操縦士からはファイナルのJAL機のランディングライトが煌々と見えていたはずなんだが。夜間は距離の把握が難しいとはいえ、さすがに高度350ftまで降りて来てたら相当明るく、また左右のポジションライトから日航機が相当近いことはわかったと思うのだが。
新しい情報だと海保機は滑走路上で衝突前40秒間停止して、おそらく離陸許可を待っていた。これが正しいとすると想像したような直前の飛び出しでは無かった。衝突40秒前。JAL機は接地してから衝突まで数秒はあっただろうから、ざっと接地30秒前と仮定する。仮に700ft/分で降下していたとすると、滑走路上350ft。ぼちぼち電波高度計の読み上げが始まったか始まらないかぐらいのタイミングか。だとすると、滑走路上に障害物が無いか最終確認はした後であとはランディングフレアと接地に神経を集中するタイミングか。海保機が滑走路入るのがあと20秒、せめて10秒早ければJAL機が点滅するフラッシャーまたは衝突防止灯に気が付いてゴーアラウンドできたかもしれないな。セスナだと60～100ftぐらい切ったらあとは接地点と速度計しか見ないもんな。
うん？それは僕が一人で操縦するからだ。操縦してない方のパイロットは滑走路を監視してたのではないか？ヘッドアップディスプレイでよく見えなかった説あり得るだろうか？いや、それよりも、滑走路上は監視していたとしても、直前の着陸機が滑走路から出たことと、滑走路端で待機してる機体が間違って滑走路に進入しないかに注意を集中していただろうから、滑走路中央付近に割り当てる注意力は少なかっただろう。C5インターセクションテイクオフだったのが不幸だった。FAAはインターセクションテイクオフは避けた方がいい、ってなんかの刊行物で言ってたけど、そういうことだったのか。
ただ、もしも接地後に海保機に気づいてしまっていたらもっと大惨事になっていたとも思う。仮に接地後ゴーアラウンド、というかタッチ&ゴーしようとしてエンジン出力を上げて加速して機首を上げていたもんなら、速度がより速い状態で少し浮き上がったところで機体尾部が海保機に激突。尾部を跳ね上げられるように機体はピッチ下げ回転しながらエンジン全開の状態で機首から滑走路に激突、誰も助からない事故になったと思う。あの状態では右にラダーを踏んで滑走路を逸脱させるのが唯一全員が助かる手だったと思うけど、その判断ができるパイロットはまずいないと思う。僕ならエンジン吹かしてゴーアラウンドを試みて死ぬパターンだな。ただ、今回の事例でひとつ学んだとすると降りてみたら目の前に別の機体がいたらラダー踏んで滑走路逸脱させるのもオプションとして心の準備をしておこう。鹿だとかコヨーテだとか動物だったらそのまま動物に航空法違反により死刑になってもらうんだけど。
滑走路進入警報は意味のある情報を表示していたのだろうか？僕が知ってる限りでは、僕が飛ばす飛行機には着陸許可・離陸許可を得た、という情報を入力するような機器もボタンも無い。管制官が手動でどの機体にクリアランスを出したか入力することは可能かもしらんけど、それだと管制塔の中でループが完結してしまうから、管制官が入力を忘れたら警告も出ない。だとすると、滑走路進入警報システムは、どの機体は滑走路上にいてもいいのか知らなかったのではないか？どの機体が滑走上にいてもいいのか、その情報が無いのであれば、単に滑走路上に何かが入ったら表示が赤くなり、出たら元に戻るだけだとすると、事故の前から離着陸のたびに表示は赤く点滅していたのではないか。だとすると、日航機の着陸40秒前、表示が赤くなったとしても、管制官としてはずいぶん早く日航機が降りた、ぐらいにしか思わなかったかもしれない。これがもっと早く、日航機に着陸許可を出す前後だったならば管制官は着陸許可を出そうと思ったら滑走路上になんかいる、と気づいたはずだ。海保機の誤進入のタイミングも運が悪かった。これをなんとかしようと思ったら、着陸機を判別して、滑走路の誤進入は黄色、衝突の危険が迫ったら赤にするようなシステムの変更が必要だと思う。そのためには着陸機の位置がわからなくてはならないから、日本でも各機が自分のGPS位置をそれぞれ通報するADS-Bを義務化する必要があるかもしれない。
どうもこの事故は1月2日の羽田空港はUターンラッシュでキャパシティギリギリのところに海保機を優先的に飛び立たせるのは無理だった、というのが最大の原因だったのではないかという気がしてきた。細かいところに目を向けると、海保機のパイロットは、支援物資を届けるためになんとしても飛ばなければという使命感があった。我々の間では、Get-there-itis、日本語に無理やり訳すと「行かねば症候群」とでも言うのだろうか。明日の仕事に間に合わせるために、あるいは子供の学校に間に合わせるために、なんとしても飛ばなくては。乗せてあげる人の期待になんとしても応えなくては。その使命感から数えきれないパイロットが命を落とした。 なんとしても、と思ったら一呼吸置いて考え直そうか、と何十回も航空安全セミナーで聞いた。海保機パイロットには自分が最優先で滑走路上で待機の指示が出たはずという思い込み、confirmation-biasというらしい。管制官には海上保安庁のパイロットがエラーを起こすはずがない、というcomplacency(油断)が無かったか。管制官にも被災地に物資を最優先で届けなくてはという意識があったのではないか。それは極めて尊敬されるべき人格だと思う。だけど、わずか数分を節約するために海保機に優先離陸させようとしたのは最善の判断ではなかったと言われても仕方ない。仮にそれが海保機からのリクエストだったとしても、Unableと言う勇気が必要だった。ただ、それも結果論であって、エラーと呼ぶほどではない。
しかし、それは個々の問題であって、人間だからパイロットも管制官も間違えるのは仕方ない。 「間違えるな」と言って事故が無くなるものであればとうの昔に事故は無くなってる。 人間のミスをシステムとして守らなければ絶対に事故が起こる。今回の事故では、システムとしてそのエラーをカバーできなかった。 個々の要因をシステムが断ち切って事故の連鎖の完成を阻止しなくてはならない。システムに何が足りなかったのか。 それから、パイロットとしてはこの事故から何を学ばなくてはならないのか。 また詳しい情報が明らかになってくるとわかってくるだろうな。
日本には、FAAの FAASTチーム(航空の安全を専門に担当する部門) みたいなのはあるのだろうか？ 航空安全セミナーとか、事故調査報告のビデオとかときどき見ると、結局わかりきったことの繰り返しと思ってしまう。 そんなのわかりきってる、と、思うのだが、ときどき、わかりきってるけど意識して飛んでたかな？と、気が付くことがある。 わかりきったことでも定期的に再確認するのは悪くない。 まだ無いのであれば、日本版FAASTチームを設立するといいかもね。
日航機・海保機衝突事故、管制官の指示は適切だったのか。17:45:11の管制官からの指示で"taxi to holding point C5"と言ってるけど、ちょっと違和感はある。と言っても、アメリカの管制の方が国際標準よりも遅れてたりするから、実はこっちの方が新しい標準である可能性はあるけど、アメリカだったら"taxi runway 34R at C5"、あるいは、"taxi runway 34R at C5, hold short of the runway"だろう。"holding point"というのが羽田空港のローカルルールで明示的に定められている場合でないと、言われたら「何それ？」と思うかも。ただ、同じような指示を受けたデルタ276便は迷わず滑走路端まで進んで止まっていることを考えると決まってるのかもしれない。(と、思ったら実際アメリカの標準の方が遅れてたっぽい。知り合いのパイロットによると"holding point XX"という言い方の方が新しいということで、アメリカでも多分少しずつ新しい言い方に変わっていくんだろうな。ただ、印象として、それだと昔問題だった"position and hold"と同じ"po"の音が入るからかえって紛らわしくないのかな。)
何であれ、大原則は、"cleared for take off"あるいは"line up and wait"と言われるまでは滑走路に進入してはならないということだ。そう言っていない以上、管制官のミスと言えるようなものは公開された交信記録には無い。
また、仮に"cleared for take off"と言われたとしても、滑走路に入る前に着陸機がファイナルにいないか、あるいは反対側から離陸してくる機体、直前に降りた機体、鹿、コヨーテ、狐などが滑走路上にいないか目視で確認するよう、訓練で何度も何度も言われる。自分が離陸するときだと、
"Cleared for take off." (復唱)
"Nothing on final." (着陸進入機無し)
"Runway is clear." (滑走路上になんもなし)
と確認して、口で言ってから滑走路に入ることにしている。ところが、今回、34Rに海保機が入るとき、滑走路に斜めに入って行くアングルだった。そもそも右かなり後方を見ないとファイナルにいる機体のランディングライトは見えない上に、高翼のボンバーディア機だと、右後方斜め上はコクピットからは翼に遮られて何も見えなかったと思われる。C5から進入したことで、パイロットの目視による衝突回避という最後の防衛戦を無効化し、事故の最後の連鎖を完成させてしまった。 仮に普通に滑走路に直交するC1, C2, あるいはC3Bからの離陸であれば、主翼がコクピットよりかなり後方にあるボンバーディア機からファイナルの機体のランディングライトはよく見えたはずだ。高翼機を斜め誘導路C5から離陸させるのは不適切だったと言わざるを得ない。
海保機はこの日二度目のフライトだったということだが、やはりクルーの疲労がどの程度だったのか検証されるべきだろうな。そして、もしも最初のフライトも同じ34RのC5インターセクションからの離陸だったとしたら、一度目のフライトのときの"cleared for take off 34R"が頭に焼き付いていた可能性もある。もちろん通常の状態ではこの間違いは起こりにくいが、疲労が関わってくると一度目のフライトで言われたことの記憶が混じるということは起こりうる。
とんでもない一年のスタートになった。まず能登地震。実は数日前に新潟に友達を訪ねたばかりだった。 そして、海保機と日本航空516便の衝突事故。なんと偶然にもそのとき僕は羽田空港にいた。
年末から日本に帰省していたのだが、我が妻は実家の九州へ、僕は実家の弘前市で新年を迎え、羽田で合流してピッツバーグに戻ることになっていた。我が妻の乗る飛行機は全日空260便。羽田滑走路34Lに降りたが、止まったまま動かないとテキストが入った。なんでも、滑走路上で日航機がトラブルとのことだった。
オーバーラン？滑走路逸脱？パンク？Flight Radar 24で確認してみたのだが、滑走路上の日航機が見えない。まだ滑走路上なら電源を切っていないはずだから、日航機がいるなら見えるはずだ。滑走路上に日航機がいて、Flight Radar 24で見えないということは、なんらかの原因で電源が落ちているということだ。まもなく、滑走路上で何かが燃えているという情報が入る。悪い予感がする。
我が妻と合流するために第2ターミナルに向かっていた僕は、展望デッキまで出てみた。見ると、滑走路南側で炎が上がっている。しかし、大きな機体にしては炎が小さすぎる。小型機が着陸に失敗したのか？そのうち、望遠レンズを持った航空ファンらしい若い人が3人走って来る。海保機と日航機が接触したらしい、そう言っていた。彼らは滑走路北の方にカメラを向けている。見ると、夜の闇の中、別の炎が上がっていた。黒煙も立ち上っている。黒煙に隠されて機体ははっきり見えないが、大きな機体のようだ。これは、相当な犠牲者が出ているように思えた。その少年にカメラの映像を見せてもらった。JAPAN AIRの文字が見えた。この規模の事故では死者がゼロでは済みそうにない。
炎上する航空機を見るのはこれが初めてではない。デイトン航空ショーで二度事故を目撃している。そのうち一度は本当に目前で見た。しかし、これほど大きなエアライナーが炎上するところを目撃するのは初めてだ。とても現実とは思えなかった。
このとき、夜間だったし我が妻を迎えにきていたので、望遠レンズつきのカメラを持っていなかった。映像を撮ることができたのはiPhoneだけだった。OM-Dがあったとしてどの程度の映像が撮れたかはわからないが、航空ファンは空港でカメラを放すべからずという掟を破ったことを後悔した。仮に自分がここである程度鮮明な映像を撮ることができたとして、どの程度事故調査に貢献できたかというとはなはだ疑問だが、自分以外にもカメラを構えていた人は多数いた。この事故は多くの映像で記録されることになった。事故調査、再発防止という観点では映像は多い方がいい。
少し見ていると日航機の炎は見えなくなった。消火活動が功を奏して沈下に成功したのか？我が妻と合流するために到着フロアに移動する。到着フロアではテレビでニュースが流れていた。どうも、僕が展望デッキを去ってから、炎は再度燃え上がって、しかも客室をほぼ覆ってしまったらしい。衝撃的な映像が流れていた。
衝突から脱出までどのぐらいの時間があったのだろうか？半数でも生き残っていればいいけれど。と、思ったらなんと、日航機は乗員・乗客379人全員が脱出に成功したとのこと。どんだけ日航クルーの訓練度高いんだよ！クルーは称賛されるべきだ。この事故に対するクルーの対応は完璧だったと言っていい。いや、完璧という単語は日航516便のクルーのためにあると言ってもいい。例えば、上空で機体になんらかのトラブルが起きた場合だと、地面に到達するまでの間、クルーはある程度心の準備ができる。接地寸前に衝撃防止姿勢を取るように声を上げ、機体が停止したら速やかに避難を開始する。ところが、この事故ではおそらくクルーは普通に着陸して普通にゲートまで到着すると寸前まで思っていたに違いない。ほぼ不意打ちと言っていい状況で、一人も死者を出さなかったクルーの働きはすごすぎる。このニュースは良かったが、残念ながら海保機のクルーは6人中5人が犠牲になったということだった。まさか朝家を出るとき、二度と帰らないとは思わないだろうからなあ。残されたご家族、友人のショックはどれほどのことか。気の毒だな。
この事故は典型的なRunway Incursion事故だ。アメリカではコロナ後の航空需要の爆発的増加、管制官・パイロット不足の影響による訓練不足などの影響で、滑走路上の衝突寸前が頻発している。連邦航空局はなんとしても破壊的事故が起こる前に防止しようとあの手この手で啓発を続けているが、まさか日本でしかも訓練度は高いはずの解除保安庁のクルーでそれが起こるとは。
その時点では、まだ海保機のクルーが誤って滑走路に侵入したのか、管制官が誤って海保機に滑走路侵入の指示を出したのか、日航機が着陸許可を得ずに着陸した、あるいは誤った滑走路に着陸したのか、日航機が大きく滑走路を逸脱してタクシーウェイ上で待っていた海保機に激突したのか、わからなかった。ただ、展望デッキから見たところ日航機は滑走路上に停止しているようだったので、逸脱はなさそうだった。
ファイナルにいた日航機に着陸許可が出ていなかったとは思えないので、まず間違いなく地上管制あるいは海保機のエラーと思われた。ごくまれな事例で着陸機が並行滑走路の間違った方に降りてしまったケースはあり、また、日航機を使用ターミナルから遠い側の滑走路に降ろしたことにやや違和感を感じたが、単に北からの飛行機を34Rに、南からの飛行機を34Lに降ろしているだけかもしれない。現に我が妻の乗る全日空260便は第2ターミナルと反対側の34Lに降りた。
翌朝のニュースで、海保機には滑走路進入の許可は出ていなかったとのこと。海保機のエラーが確定したようだ。事故調査の焦点はなぜ海保機がエラーを犯したのかが中心になってくると思う。しかし、航空事故はひとつだけの要因で発生することは無い。事故に至るまでの連鎖を解明して、再発防止策が講じられるまで事故調査は終わらない。
視界が良好な状態にもかかわらずなぜ日航機のクルーが海保機の衝突防止灯を視認できなかったのか、果たして衝突防止灯は点灯していたのか、この点も焦点になってくるだろう。自分が飛ぶとき、以前は着陸許可が出たら滑走路上にはほかの機体はいないだろう、と、思って飛んでいたが、元管制官のパイロットと一緒に飛んだ時、隣の彼は降りる前にかならずRunway is Clearと言った。なるほど、たしかに明示的に滑走路上に何もいないことを確認した方が安全だ、と、思って以後着陸前にワンステップ、滑走路上に何もないことを一度は目でスキャンして声に出すことにした。たかだか850時間の僕がこの程度なんだから、訓練されたエアラインのキャプテンがその動作をしていないはずがない。なぜ海保機は見えなかったのか？Bombardier機は真後ろからだと衝突防止灯が見えにくくなるのだろうか？
どういうアングルで衝突したのだろう？もしも、滑走路進入中の海保機のコクピットに横から日航機が突っ込んだのなら日航機の前輪がコクピットを直撃して機長は即死したはずだ。機長が生き残ったということは、機体がクッションのような役割を果たしたはずだ。だとすると機首は滑走路と並行で、機体後部に日航機が衝突したのか。炎上する日航機の映像を見ると、左エンジンに前方から何かが衝突したようなへこみが見えたので、左エンジンが何か大きな構造にぶつかったのは間違いなさそうだ。ノーズギアがまず海保機の尾部に当たり、次に海保機の主翼が左エンジンに当たったのだろうか。と、思ったけど 空港ダイアグラム 見たら滑走路に入るタクシーウェイは直交じゃなくてスムーズに入って行けるようになってたから機体後部から衝突したのは間違いないんだな。
今回の事故で気が付いたけど、羽田空港では公式または非公式にそれぞれの滑走路をＡ滑走路、Ｂ滑走路、Ｃ滑走路、Ｄ滑走路と呼んでいるようだ。どうも、海保機は管制官からC5に行けと指示を受けたらしい。C5はタクシーウェイであって、管制官から明示的に滑走路に入るように指示が出るまで滑走路に入ってはならないことになっているのだが、日常的にＣ滑走路と呼んでいたのでは、この指示を滑走路Ｃに入っても良いと勘違いするリスクが発生する。まして、未確認ながら、3機の別の機体を待たせて海保機を優先的に離陸させようとしていたとする情報もある。だとすると、ますます後続機を待たせないために自分にはすでに離陸許可が出たものと思い込む危険が増す。ここでC滑走路などという呼称を使っていたのでは起こるべくして起きた事故と言えるかもしれない。事故調査委員会から、いくつか改善ポイントを指摘することになると思うが、滑走路16L-34RをC滑走路と呼ぶことをやめることはひとつ入ってくるだろう。これまでC滑走路と呼んでしまっていた以上、その印象が頭に入っているパイロットもいるだろうから、タクシーウェイC1, C2, C3....はまったく違う文字、例えばM1, M2, M3....みたいに呼称を変える必要も出てくるだろう。
クルーの疲労についても調査があるだろう。本来であればお正月の休暇で休んでいるはずのクルーが不幸にして1月1日に能登地震が発生したもんだから、急遽呼び出された可能性もある。また、Uターンラッシュで通常よりも混雑している羽田空港の夕方5時台の出発を選んだのが適切だったのか？おそらく被災地に一刻も早く支援物資を届けなくてはという使命感があったに違いない。残念ながらそれがエラーを誘発する。過去に何度も繰り返されてきた。 そもそも能登地震が無ければこのフライトは無かったわけなので、事故につながる連鎖のひとつは能登地震の発生と言える。地震が起きたから支援物資を輸送するのは海上保安庁の任務としては当然のことと言えるが、一年のうち最も混雑が激しい時期の羽田空港から物資を輸送しようとしたのが適切だったのか、これも調査の一部に入ってくるだろう。いくら被災地に支援物資を届ける必要があったとしても、ぎりぎりのキャパシティで運用している空港から物資を届けるフライトを飛ばすのは不適切だったという調査結果が出るかもしれない。
羽田空港を発つ前、第二ターミナルから日の出を見てきた。左手に、焼け落ちた日航エアバス350は乗員・乗客の命を守るという航空機最大の使命を果たし、誇らしげに横たわっていた。海保のボンバーディア機は5名の乗員を守ることができず、さぞ悔しい思いをしただろう。もちろん飛行機に心がないことはわかっているが、長いこと飛行機を操縦していると心があるように思えてくる。ついでに長いことプログラマーをしているとコンピュータに心があるように思えてくる。
ワシントンDCに向かってる間に、国交省が無線交信記録を公開したものの、海保機がタキシング開始してからのやりとりがごっそり抜け落ちているから肝心の情報が足りない。17:46:11の時点でTOWER JA722A Cと言ったとき、海保機はどこにいたのか。既に滑走路に入っていたのか。
Comments are welcome.
Send E-Mail to:
 |