ライオン・エア610便｜最初の737 MAX墜落事故で何が起きたのか

2018年10月29日、ライオン・エア610便（JT610）はジャカルタのスカルノ・ハッタ国際空港を離陸し、パンカルピナンへ向かった。機体はBoeing 737-8（MAX）、登録記号PK-LQP。離陸後まもなく機長側のスティックシェーカーが作動し、左右の速度・高度表示にも不一致が現れた。フラップが格納されると、水平安定板は機首下げ方向へ自動的に動き始めた。

乗員は電動トリムで機首上げ方向へ戻した。しかししばらくすると、また機首下げ方向へ動いた。この繰り返しは十数分の飛行の中で何度も発生した。事故機は最終的にジャワ海へ墜落し、189人全員が死亡した。

この事故を理解するうえで特に重要なのは、異常が事故便で突然初めて現れたわけではないことである。同じ機体は前日のデンパサールからジャカルタへの便でも、スティックシェーカー、速度・高度不一致、機首下げトリムなど類似した問題を経験していた。前便の乗員はスタビライザー・トリム・カットアウトスイッチを使用して電動トリムを切り離し、着陸に成功している。

つまりJT610は「新型機の未知の故障が初めて現れて即座に事故になった」という単純なケースではない。前便の異常、整備、AOAセンサー交換、情報の引き継ぎ、事故便の認知と操作、MCASの設計が一つの連鎖になっている。

CASE BRIEFING

インドネシアのKNKTは2019年10月、JT610の最終事故調査報告書を公表した。報告は事故原因をMCAS一つに限定せず、機体設計、AOAセンサー、整備、乗員、情報伝達など複数の寄与要因を挙げた。

事故機では、事故前に左AOAセンサーが交換されていた。この交換センサーには校正上の問題があり、装着後に実際の迎角と大きく異なる値を出した。前便ではその誤入力に関連する複数の異常が発生したが、乗員は電動トリムを切り離し、機体を安全に着陸させた。

事故便では、その前便の経験が完全な「再発防止情報」として機能しなかった。乗員は前便と同じ具体的な故障像を共有した状態で出発したわけではなく、事故後の分析で初めて二便が同じ異常経路で結び付けられた。

THE QUESTION

JT610では、前便から事故便までどの異常と判断がどの順番で重なったのか。

答えは、誤ったAOA入力が前便から存在し、その影響が複数の表示・警報・MCAS作動へ広がり、前便ではcutoutによって収束した一方、その教訓が事故便で同じ形の防護として再現されなかったという流れにある。

ただし、これを「前便パイロットは正しく、事故便パイロットは間違った」という人物比較へ縮めるべきではない。前便と事故便では乗員構成、情報、作業負荷、異常の進行、対応のタイミングが異なる。KNKTも事故を多要因として扱っている。

1｜事故の数日前から速度・高度系統の問題が続いていた

事故機PK-LQPでは、事故以前から速度・高度表示に関連する不具合が報告され、複数の整備が行われていた。航空機の整備では、症状から故障部位を切り分け、交換や試験を行う。しかし複数システムが同じセンサー情報を利用する場合、症状が一見別々に見えることがある。

AOAセンサーはその典型である。AOAそのものを通常操縦で直接参照しない乗員にとっても、その値はスティックシェーカー、速度・高度関連表示、飛行制御機能へ影響し得る。したがって一つのセンサー異常が、操縦席では複数の別トラブルに見える可能性がある。

KNKT報告は、事故機での整備履歴と、AOAセンサー交換後の挙動を詳細に検討した。ここから見えるのは、単なる「壊れたセンサーを交換しなかった」事故ではなく、交換したセンサー自体の校正、装着後の確認、症状の関連付けなど整備システム全体の問題である。

2｜10月28日の前便で何が起きたか

事故前日の10月28日、同じPK-LQPはデンパサールからジャカルタへ飛行した。離陸後、機長側のスティックシェーカー、速度・高度表示の不一致、機首下げ方向の自動トリムなどが発生した。これは翌日のJT610と重要な共通点を持つ。

前便では、乗員が電動トリムで機首上げ側へ戻す操作を行ったものの、自動トリムが再び生じた。最終的にstabilizer trim cutout switchを使用して電動トリムを切り離したことで、自動的な機首下げトリムは止まり、乗員は手動トリムを使いながら飛行を継続してジャカルタへ着陸した。

この事実は後から見ると決定的に見える。同じ機体で同じような異常が起き、切り離し操作で生還していたからである。しかし当時の運航現場で、「翌日の事故便にも同一のMCAS誤作動が起こる」という診断が確定していたわけではない。そもそも多くの乗員はMCASの詳細を通常訓練で把握していなかった。

3｜前便後の整備で何が残ったか

前便がジャカルタへ到着した後、整備担当者は報告された不具合に対応した。ここで問題になるのが、乗員から整備へ何が報告され、どの症状が記録され、整備側がどの故障を再現・確認できたかである。

航空安全では、機内で一時的にしか現れない異常を地上で再現できないことが珍しくない。だからこそ、乗員のtechnical log記載、故障コード、交換履歴、試験結果を組み合わせる必要がある。JT610では前便の異常の全体像が、次便を止める決定的な情報として機能しなかった。

KNKTは、整備手順や記録、AOAセンサーの問題、前便情報の扱いを寄与要因の一部として検討した。ここで責任を「整備員が見逃した」と一人へ集約すると、なぜシステムが再発リスクを捕捉できなかったのかという重要な問いを失う。

4｜JT610離陸直後――最初に現れた異常

10月29日朝、JT610が離陸すると、機長側スティックシェーカーが作動した。左右の速度・高度表示にも不一致があり、乗員は複数の情報を同時に処理する必要があった。

飛行機が離陸直後にあるという点も重要である。高度が低く、上昇、進路変更、通信、速度管理、フラップ操作など通常作業が多い。異常が起きても、乗員には原因分析だけへ集中する余裕はない。

この時点での根本原因は左側AOAセンサーの誤った値だった。しかし操縦席に「左AOAセンサーが約○度ずれている」と直接表示されるわけではない。乗員が見るのは、その異常が別のシステムを通じて現れた症状である。

5｜フラップ格納後、MCASの機首下げトリムが始まる

MCASはフラップ格納などの条件を満たすと作動可能になる。事故便では異常な高AOA入力が続いていたため、MCASは機体が高迎角状態にあると判断し、水平安定板を機首下げ方向へトリムした。

乗員は電動トリムで機首上げ側へ戻した。ここだけ見れば回復している。しかし異常AOAは消えていない。一定の条件が再び整うとMCASは再作動し、水平安定板をまた機首下げ側へ動かした。

FDR記録では、この自動機首下げトリムと乗員の機首上げトリムが何度も繰り返された。各サイクルで乗員は機体姿勢を維持し、同時に速度・高度・警報へ対応していた。これは「一回の強い自動入力」とは異なる負荷である。

6｜なぜrunaway stabilizerとすぐ認識できなかったのか

事故後、FAAとボーイングは異常な機首下げトリムに対して既存のrunaway stabilizer手順を使うよう運航者へ情報を出した。ではなぜJT610の事故便乗員は前便のようにcutoutへ移行しなかったのか。

その答えを「手順を知らなかった」で終えることはできない。事故時にはスティックシェーカー、速度・高度不一致、機首下げトリムが重なっていた。一般的なrunaway stabilizerの訓練シナリオと、AOA異常が複数の症状を同時に作る状況は同一ではない。

NTSBは後に、システム安全評価でパイロット反応を仮定する際、複数警報が認知と対応へ与える影響を考慮すべきだと指摘した。これはJT610乗員を免責するための議論ではなく、安全設計が人間の現実的な処理能力をどう扱うかという問題である。

7｜前便と事故便の違いを単純比較してはいけない

前便ではcutout switchを使って着陸できた。事故便では同じ操作へ至らず墜落した。この対比は重要だが、二つの便を「正解を知っていた人」と「正解できなかった人」に分けるのは危険である。

前便には追加乗員がコックピットにいたと報じられており、役割分担や状況認識が事故便と同一ではない。また異常発生のタイミング、機体状態、乗員の経験、どの情報を認識できたかも完全には同じでない。

航空事故調査では「もしこの操作をしていれば」という反実仮想は安全改善の手がかりにはなるが、それをそのまま原因の順位付けにするべきではない。重要なのは、同一型式・同一機体で同様の異常が起きたとき、安全な結果と破局的結果の間にどの防護層の差があったかを分析することである。

8｜AOA DISAGREE表示も問題になった

737 MAXには左右AOA値の不一致を知らせるAOA DISAGREE alertが想定されていたが、ソフトウェア実装上の問題で、特定のオプション条件と連動し、すべての機体で期待どおり表示されない状態が存在した。

この問題は「もし警報が出ていれば必ず事故を防げた」と断定できるものではない。しかし、故障したセンサーを早期に認識し、整備側へ情報を伝えるうえで不一致警報が持つ価値は大きい。事故後はAOA DISAGREE表示の扱いも改修対象となった。

ここでも一つの防護層が欠けたことと事故全体を一対一で結ばないことが大切である。安全システムは複数層で構成され、どれか一つが欠けても他が機能すれば事故を防げるよう設計する。その複数層が同時に弱くなったとき、単一センサー故障が重大事故へ拡大する。

9｜KNKTが示したのは「多要因」の事故だった

KNKT最終報告は、事故を一つのprobable causeだけで終える形式ではなく、複数のcontributing factorsを整理した。そこにはMCAS設計、安全評価、AOAセンサーの校正、整備、乗員間・整備間の情報、警報・表示、訓練などが含まれる。

この構成は、事故を「設計ミス」対「パイロットミス」という二択へ押し込めない。設計に欠陥があっても、整備や運航の防護が働けば事故にならない場合がある。逆に乗員が一部手順を完全に実行できなかったとしても、単一センサー故障が重大な自動制御へ進まない設計なら破局を防げる場合がある。

したがって安全上の問いは「誰が最後に間違えたか」ではなく、「どの層が同時に機能しなかったため、一つの故障が事故まで通過できたか」である。

10｜事故後すぐに分かったこと、まだ分からなかったこと

JT610事故後の初期段階で、FDRなどからAOA異常と反復する機首下げトリムの関係は重要な論点として浮かび上がった。ボーイングは運航者へbulletinを出し、FAAは2018年11月7日に緊急ADを発行した。

一方、その時点ではKNKT最終報告はまだ存在せず、AOAセンサーの校正や整備、MCAS安全評価、認証プロセス全体の検証も完了していなかった。つまり「事故の危険経路の一部」は認識されたが、「事故を成立させたすべての構造」が確定していたわけではない。

この区別が、第5記事の中心になる。なぜならET302までの約4か月は、「何も知らずに飛ばし続けた期間」でも、「原因が完全に分かり対策済みだった期間」でもないからである。

11｜JT610が残した最初の警告

JT610は737 MAXにとって最初の死亡全損事故だった。事故後、世界の運航会社は、AOA異常によって意図しない機首下げトリムが起き得ることを明示的に知らされることになった。MCASという名称も広く運航現場で認識され始めた。

それでも機体は世界中で運航を続けた。規制側とメーカーは、既存手順と追加情報によってリスクを管理できると判断し、設計変更を進めながら運航停止までは求めなかった。

後から見ると、この判断はET302によって厳しく問われることになる。しかし歴史を正確に追うには、2019年3月の結果を2018年11月の人々が完全に知っていたかのように書くべきではない。何が分かっていて、何が未確定で、どのリスクをどの防護で受け止めると判断したかを分けなければならない。

EVIDENCE STATUS｜前便という「ヒヤリハット」がなぜ事故防止に変わらなかったか

JT610の前便は、安全工学の観点では非常に重要なnear missだった。ほぼ同じ異常経路が発生しながら、乗員がcutout switchを使って着陸できたからである。通常、near missは重大事故より多く発生し、そこから危険なfailure pathを早期に見つけることができる。しかし有効な教訓に変えるには、現象を正確に記録し、整備・運航・設計へ伝え、必要なら運航を止める仕組みが必要になる。

前便後の情報は、翌日の乗員に「AOA異常がMCASを反復作動させた。cutoutで止めた」という現在から見れば明確な形で渡ったわけではない。事故当時、MCAS自体が一般的な乗員教育の中心ではなく、症状は複数の警報・表示不一致として現れた。整備側も個別故障の切り分けとして対応していた。つまり、現場で観測された事象が「型式共通の危険な制御経路」という抽象度へまだ変換されていなかった。

このギャップは、インシデント報告の価値が単にデータを保存するだけではないことを示す。異常の関連性を分析し、別部署・次のシフト・メーカー・規制当局へ意味のある形で伝える必要がある。

AOAセンサー交換を「部品交換ミス」だけで終えない

事故機の左AOAセンサーは交換されていたが、そのセンサーには校正上の問題があった。ここから「不良部品を付けた整備員が原因」と単純化すると、再発防止の範囲を狭めてしまう。

実際に問うべきなのは、交換品の出所・修理・校正、装着後試験、左右値の妥当性確認、AOA DISAGREE表示、整備文書、故障履歴との照合など、品質保証チェーン全体である。航空機整備は部品を物理的に交換する作業だけでなく、その部品が正しい特性で機体システムに統合されたことを確認する工程を含む。

さらに、センサーが誤った値を出しても、MCAS側で左右比較して異常を拒否できれば事故経路は途中で遮断できる。したがってセンサー品質問題は重要だが、単一部品の不具合を破局へ通した設計側の防護不足も独立して残る。

乗員操作と設計責任は排他的ではない

JT610では、乗員がより早くrunaway stabilizer手順へ移行できた可能性、速度・姿勢管理、crew resource managementなどが調査対象になった。これらを検討することは、設計上のMCAS問題を軽視することにはならない。

航空安全では、事故へ至るすべての回復機会を調べる。ある故障が発生した後に人間が回復できる可能性があれば、その手順・訓練も改善対象になる。同時に、危険な単一故障が人間の完璧な対応だけに依存しないよう設計を改善する。二つは代替関係ではなく、両方を強化するのが多層防護である。

前便データが示す「回復可能性」とその限界

前便が着陸できたことは、事故時仕様でも必ず制御不能になるわけではなかったことを示す。しかしそれは「設計は安全だった」という証拠ではない。安全性は、訓練された平均的な乗員が合理的な作業負荷の中で再現可能に回復できるかで評価する必要がある。

ある一便で熟練乗員が回復できたからといって、同じ故障が別の便でも高い確率で安全に収束するとは限らない。NTSBが人間性能仮定を問題にしたのは、この再現性の観点である。防護として人間を使うなら、その防護の成功率を現実的に見積もらなければならない。

タイムライン補足｜離陸後の時間余裕が短いことの意味

JT610の飛行時間は約13分だった。航空事故で13分は決して一瞬ではないが、離陸直後の上昇フェーズであることを考えると、乗員が使える認知資源は限られる。通常の離陸後手順、航空管制との交信、進路・高度・速度管理に加え、スティックシェーカー、表示不一致、トリム異常が同時に入る。故障原因の診断だけに集中できる試験環境とは違う。

このため「十数分もあったのだから原因に気付けたはずだ」という評価は、実際の作業負荷を無視する。安全評価では、時間の長さだけでなく、その時間中に何件のタスクと警報が競合していたかを考える必要がある。

保守性の論点｜再現しない故障をどう扱うか

地上整備で最も難しいのは、飛行中だけ現れ地上では再現しない間欠故障である。センサー値の不一致、配線、コネクタ、ソフトウェア条件が絡むと、BITEや故障コードだけで根本原因を一意に決められない場合がある。だから整備履歴の連続性と、乗員が感じた症状の詳細が重要になる。

JT610では前便の異常が翌便の出発を確実に止めるところまでエスカレーションされなかった。再発防止では、部品交換手順だけでなく、同じ機体で異常が連続した場合のno-go判定、メーカー技術支援への照会条件、センサー交換後の独立妥当性確認など、運用ルール側の防護も検討対象になる。

MYTH VS EVIDENCE｜「前便の第三パイロットが偶然MCASを知っていた」のか

前便にoff-duty pilotが搭乗していた事実は広く報じられたが、事故の説明をその人物の特別な知識だけへ依存させるのは危険である。前便が安全に着陸できた核心は、意図しないstabilizer trimを認識し、cutout switchで電動トリムを切り離したことにある。これは既存737のrunaway stabilizer手順に沿う操作であり、MCASの内部ロジックを完全に知っていなければ不可能な操作ではない。

したがって前便の教訓は「英雄的な一人が秘密を知っていた」ではなく、既存手順が一定条件では有効だったこと、しかしその有効性が翌便で再現される保証はなかったことにある。

事故解析補足｜「直前の整備」と「事故原因」を同一視しない

事故機ではAOAセンサー交換を含む整備履歴が重要な証拠になったが、「最後に交換した部品が事故原因」と短絡するのは適切ではない。整備で問われるのは、交換部品の校正・取り付け・試験、異常履歴の引き継ぎ、再発時のエスカレーションなど複数の管理層である。同時に、誤った一つのAOA入力が重大な自動トリムへ到達できた設計側の耐故障性も別に評価しなければならない。KNKT報告を読む際は、整備、設計、運航、乗員という複数層の寄与を分離し、どれか一つを他の要因の免責材料として使わないことが重要になる。

結論｜JT610は一回の故障ではなく、前便から続く防護層の破綻だった

JT610事故の起点には誤ったAOA入力があった。その入力はスティックシェーカーや表示不一致を生じさせ、フラップ格納後にはMCASを作動させた。乗員は電動トリムで繰り返し対抗したが、異常入力が残るためMCASは再作動し、水平安定板は機首下げ側へ動いた。

事故機は前日に同様の異常を経験し、別の乗員がcutout switchで電動トリムを切って着陸していた。にもかかわらず、その経験は翌便を止める確実な安全情報へ変換されなかった。ここに整備、記録、故障診断、設計情報、乗員訓練をまたぐシステム上の問題がある。

KNKTが事故を多要因として扱ったのはそのためである。JT610を理解した次の段階では、事故後に世界へどの情報が出され、FAAの緊急ADは何を求め、ボーイングはどの改修を計画し、それでもなぜ運航継続が選ばれたのかを追う必要がある。

FACT CHECK｜出典・参考資料

Komite Nasional Keselamatan Transportasi (KNKT), *Final Aircraft Accident Investigation Report: PT. Lion Mentari Airlines Flight JT610, Boeing 737-8 (MAX), PK-LQP*, 2019-10-25. https://knkt.go.id/Repo/Files/Laporan/Penerbangan/2018/KNKT.18.10.33.04-Final-Report.pdf
National Transportation Safety Board, *Assumptions Used in the Safety Assessment Process and the Effects of Multiple Alerts and Indications on Pilot Performance*, 2019-09-26. https://www.ntsb.gov/investigations/accidentreports/reports/asr1901.pdf
Federal Aviation Administration, *Boeing 737 MAX Reading Room / Grounding and Return-to-Service Records*, 2019–2020. https://www.faa.gov/foia/electronic_reading_room/boeing_reading_room
Joint Authorities Technical Review / FAA, *Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations*, 2019-10-11. https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019

RCF検証ノート

本稿はJT610についてKNKT最終報告を最優先Authorityとし、NTSBの安全勧告資料で複数警報と乗員反応の評価を補完した。前便のcutout操作と事故便の差を、個々の操縦士の能力比較として断定していない。AOAセンサー交換・校正、整備、MCAS作動、乗員操作を複数防護層の連鎖として扱った。事故後に判明した情報と事故当時乗員が利用できた情報を混同しないよう区別した。

最終確認：2026年9月20日

END ARTICLE 04 / 08

NEXT FILE

CASE087-05｜JT610後、なぜ737 MAXは飛び続けたのか｜警告・緊急AD・情報共有の4か月

次の記事では2018年10月29日から2019年3月10日までを独立した意思決定期間として扱い、事故後に分かったこと、FAA・ボーイングが実施したこと、設計改修がまだ機体へ実装されていなかったことを分けて検証する。

RELATED FILES

CASE087-03｜MCASの制御系――JT610で繰り返された自動トリムの技術背景
CASE087-05｜二事故間の対応――JT610後の規制・運航判断
CASE087-07｜認証構造――事故後に見直された安全評価の背景

Boeing 737 MAX――二つの事故と世界的運航停止第4回全8回 全8回を見る

ライオン・エア610便最初の737 MAX墜落事故で何が起きたのか