737 MAXとは｜二つの墜落事故と世界的運航停止の全体像

2018年10月29日、インドネシアのライオン・エア610便（JT610）がジャカルタを離陸して約13分後、ジャワ海へ墜落した。搭乗していた189人は全員死亡した。使用機は就航から日が浅いボーイング737-8、一般に737 MAX 8と呼ばれる機体だった。その約4か月半後の2019年3月10日、エチオピア航空302便（ET302）がアディスアベバを離陸して約6分後に墜落し、157人が死亡した。二つの事故で失われた命は346人に達した。

同じ新型機で短期間に起きた二つの事故には、単なる「偶然の類似」では説明できない共通点があった。いずれも離陸後まもなく角度センサー（Angle of Attack: AOA）に関係する異常が生じ、操縦席には複数の警報や不一致表示が現れ、水平安定板のトリムが機首下げ方向へ繰り返し動いた。その背景にあったのが、737 MAXに導入されたManeuvering Characteristics Augmentation System、MCASだった。

しかし、737 MAX事故を「MCASというソフトウェアが暴走した事故」とだけ説明すると、本質の半分以上を失う。事故調査やその後の公的レビューが扱ったのは、センサー故障、MCASの設計、パイロットへの情報提供、操縦席の警報、人間が複数の異常へ同時に対処することを前提にした安全評価、整備、運航会社の訓練、FAAの型式証明、ボーイングへの認証業務の委任、最初の事故後の暫定対策、そして二度目の事故後の設計変更までを含む「システムとしての失敗」だった。

このCASEでは、誰か一人、あるいは一つの装置だけを原因に固定しない。二つの事故に共通する技術的な経路と、それぞれの事故固有の要素を分け、さらに「事故が起きた理由」と「事故が防げなかった理由」を分離して追う。

CASE BRIEFING

737 MAXは、737 Next Generation（737NG）の後継として開発された737シリーズの派生型である。新世代のCFM LEAP-1Bエンジンを搭載し、燃費や運航経済性を向上させる一方、従来型737との共通性を大きく維持することが商品・認証・訓練上の重要な前提になっていた。機体の空力特性変化に対応するため、飛行制御系にはMCASが追加された。

MCASは自動操縦装置そのものではない。特定の条件で、水平安定板トリムを機首下げ側に作動させ、操縦桿に必要な力の変化を調整するための飛行制御機能だった。事故時の仕様では、MCASが一度の作動判断に使用するAOA入力は一方のセンサーに依存していた。このセンサー入力が誤ると、実際には失速に近づいていないのに、高い迎角だとシステムが判断する経路が生まれた。

重要なのは、誤った入力が単に画面表示を間違わせるだけではなかったことである。AOAは複数の警報や表示へ影響し、さらにMCASの作動条件にも関わった。乗員は一つの故障だけに対処していたのではなく、スティックシェーカー、速度・高度表示の不一致、警報、トリム作動などを同時に処理しなければならなかった。

THE QUESTION

737 MAXで何が起き、なぜ二つの事故の後に世界規模の運航停止へ至ったのか。

答えを先に要約すると、二事故は「一つのセンサー故障」と「一つのソフトウェア」だけで生じたわけではない。単一のAOA入力に依存し得るMCAS、繰り返し可能な機首下げトリム、乗員が異常を素早く認識して既存手順で対応するという安全評価上の仮定、警報と情報提供、整備・訓練・運航、認証と監督の問題が重なった。最初の事故後には緊急耐空性改善命令と運航情報が出たが、システム設計自体は直ちには改修されず、二度目の事故が発生した。二事故の類似性が明確になると各国当局は運航を止め、FAAも2019年3月13日に米国での運航を禁止した。その後、機体は約20か月にわたる再評価と改修を受け、2020年11月にFAAが運航再開への道を開いた。

CASE PATH

このシリーズは八つの焦点で進む。第1記事は事件全体の地図を作る。第2記事では737 MAXの設計背景とMCAS導入の理由を扱う。第3記事ではAOA入力から水平安定板トリムまでの制御系を分解する。第4記事でJT610を前便から事故便まで再構成し、第5記事ではその事故後からET302までの約4か月に何が行われたかを追う。第6記事はET302と調査機関間の見解差、第7記事はFAA・ODA・安全評価を含む認証構造、第8記事は改修・訓練・再認証を扱う。

1｜最初の事故――ライオン・エア610便

2018年10月29日朝、JT610はジャカルタのスカルノ・ハッタ国際空港からパンカルピナンへ向けて出発した。事故機PK-LQPは737 MAX 8で、商業運航開始からまだ数か月だった。離陸直後から、機長側と副操縦士側で速度や高度などの表示に食い違いが生じ、機長側ではスティックシェーカーが作動した。スティックシェーカーは失速に近い迎角を知らせるため操縦桿を振動させる装置だが、このとき実際の機体迎角を正しく示していたわけではない。

KNKTの最終報告によれば、事故機では左側AOAセンサーが誤った値を出していた。MCASはその入力を用い、フラップ格納後に機首下げ方向の水平安定板トリムを繰り返し指令した。乗員は操縦桿で機首上げを維持しながら、電動トリムで機首上げ側へ戻す操作を複数回行った。しかし、条件が再び成立するとMCASは再作動した。

この事故には重要な前日譚がある。前日の同じ機体でも、同種の表示異常と機首下げトリムが発生していた。前便の乗員は水平安定板トリムのカットアウトスイッチを使用し、電動トリムを切り離して着陸した。つまり、事故機は事故便以前に「似た異常を経験しながら生還した」履歴を持っていた。整備ではAOAセンサー交換を含む作業が行われたが、問題は事故便で再発した。

KNKTは、設計だけでなく、AOAセンサーの校正、整備、情報伝達、乗員行動、訓練など複数の寄与要因を挙げている。ここが重要である。JT610を「MCASが勝手に機首を下げたため墜落した」と一文で終えると、なぜ誤入力が防げなかったのか、なぜ前便の情報が次の防護につながらなかったのか、なぜ乗員に複数の警報が集中したのか、という防護層の問題が消えてしまう。

2｜MCASは何をしようとしていたのか

737 MAXでは、737NGより大径のLEAP-1Bエンジンを機体に統合する過程で、特定の高迎角・高荷重条件における操縦力の変化が設計上の論点になった。MCASは速度トリムシステムの拡張として導入され、特定の手動飛行条件で水平安定板を動かし、操縦特性を整える役割を持った。

事故機に搭載されていた当時のMCASは、左右二つのAOAセンサーを同時比較して作動判断をする方式ではなかった。ある飛行では片側のAOAセンサーを入力として使用する。そこに誤信号が入った場合、システム自身が「これは物理的にあり得ない入力ではないか」と二つのセンサーを比較して拒否する十分な冗長判断がなかった。

さらに、MCASの権限は開発過程で変化していた。JATRや後の公的レビューは、初期設計から作動範囲や水平安定板への指令量が変化した一方、認証側がその変更の全体像を十分に共有・評価できたかという問題を扱った。これは「MCASという機能が存在したこと」そのものと、「事故時の仕様・安全評価・情報伝達が適切だったか」を分ける必要がある理由である。

パイロットは電動トリムスイッチを使ってMCASによるトリムを止め、逆方向へ戻すことができた。またスタビライザー・トリム・カットアウトスイッチで電動トリム系統を切り離すこともできる。ただし事故では、それらの手段を知っていれば必ず容易に回復できる、という単純な状況ではなかった。警報の同時発生、飛行フェーズ、速度、操縦力、クルーの認知負荷、手順の理解などが相互作用した。

3｜「パイロットならすぐ対応できる」という仮定

NTSBが二事故後に焦点を当てたのは、単にMCASのプログラムロジックだけではなかった。安全評価の中で、異常が起きた際にパイロットがどのように反応すると想定されていたか、という人間性能の扱いだった。

航空機の安全設計では、故障が起きたときに乗員がそれを検出し、診断し、正しい手順を実行できるかを考慮する。ところが実際の操縦席では、故障は教科書どおり一つずつ整然と現れるとは限らない。JT610とET302では、AOA異常が複数の表示・警報・制御挙動を同時に引き起こした。NTSBは、複数の警報や表示が乗員の認識・優先順位付けに与える影響をより現実的に評価する必要があると指摘した。

この論点は「パイロットが手順を知っていたか」という個人能力論だけではない。設計者が想定した人間の反応時間や診断過程が、実際の高負荷環境でも成立する前提だったのか、というシステム安全の問題である。事故後の再設計では、単にパイロットへMCASを説明するだけでなく、MCASそのものの作動条件・権限・センサー比較、警報、訓練など複数の層が変更された。

4｜最初の事故後、何が分かっていたのか

JT610後、ボーイングは737 MAX運航会社へ運航情報を送り、FAAは2018年11月7日に緊急耐空性改善命令を発行した。主眼は、AOA入力異常が機首下げ方向のトリムを繰り返し生じさせ得ること、そしてその場合には既存のrunaway stabilizerに関する手順を用いることだった。

これは「何も対策されなかった」ということではない。事故後に情報提供と規制措置は実施された。一方で、その時点で737 MAXは運航を継続した。MCASの設計変更が航空機へ実装される前に、既存手順と追加情報でリスクを管理する判断が採られたのである。

この判断を後知恵だけで評価すると、分析を誤る。2018年11月時点ではJT610調査は進行中で、事故原因の全体像は確定していなかった。他方、異常AOAと反復する機首下げトリムという重大な危険経路が存在することは認識され、FAAの緊急ADにも反映されていた。したがって第5記事では、「全部分かっていたのに放置した」か「当時は何も分からなかった」かという二択を避け、当時判明していたこと、未確定だったこと、対策されたこと、残ったリスクを時系列で分ける。

5｜二度目の事故――エチオピア航空302便

2019年3月10日、ET302はアディスアベバからナイロビへ向けて離陸した。離陸直後から左右AOA値の大きな不一致、スティックシェーカー、速度・高度表示の相違などが生じ、MCASによる機首下げトリムが作動した。乗員は電動トリムで対抗し、やがてスタビライザー・トリム・カットアウトスイッチをCUTOUT側へ動かした。

それでも状況は収束しなかった。高速状態では操縦桿の力や手動トリムホイールを回すための力が大きくなる。NTSBはET302最終報告に対するコメントで、乗員による手動電動トリムの使用、推力・速度管理、カットアウトスイッチを再びNORMALへ戻した行動などを人間性能・運航の観点から分析すべきだと主張した。

EAIBは最終報告で、誤ったAOA入力とMCASによる反復する機首下げ指令を事故原因の中心に位置付けた。一方、NTSBとフランスBEAはMCASの寄与を否定していないが、乗員行動や人間工学的分析を十分に扱う必要があるという立場を示した。したがってET302については、「公式調査報告が一つあるから原因は一文で確定した」と扱わない。確定した飛行データと、調査機関ごとの解釈を分ける必要がある。

6｜なぜ世界中で止まったのか

ET302の事故直後、各国の航空当局・航空会社は737 MAXの運航を相次いで停止した。米国FAAは当初直ちには運航停止とせず、継続して情報を評価したが、2019年3月13日にEmergency Order of Prohibitionを発出し、米国での737 MAX運航を禁止した。

この決定で重要なのは、単に「二件目だから止めた」ということではない。二つの事故に類似する挙動があり、衛星情報や事故現場から得られる初期情報などを踏まえ、同一型式に共通する安全上の問題の可能性が高まった。単独事故なら個別機・整備・運航の問題かもしれない。しかし、短期間に同じ型式で類似した制御挙動を伴う全損死亡事故が二件発生すれば、型式全体の安全性を再評価する必要性が急速に高まる。

運航停止は「事故原因がすべて確定した」ことを意味しない。原因確定を待たず、許容できない共通リスクの可能性に対して予防的に機体を止める規制措置である。その後の調査と再認証では、MCASだけでなく、飛行制御コンピュータ、AOA DISAGREE警報、電気配線、手順、整備、訓練などが検証対象になった。

7｜認証制度は何を見落としたのか

737 MAXはまったく新しい型式としてゼロから認証されたわけではなく、737の既存型式証明を変更する形で認証された。FAAは認証業務の一部をOrganization Designation Authorization、ODAという制度を通じてメーカー組織へ委任している。委任制度自体は737 MAXだけに特有の仕組みではなく、複雑な航空機認証を処理するため長年用いられている。

問題は「Boeingが勝手に自分で認証した」という単純な話ではない。DOT OIGやJATRなどのレビューは、FAAが関与していた一方で、MCASの設計変更や安全上の意味が認証の過程でどの程度共有されたか、FAAがどの項目を保持しどの項目を委任したか、変更型式の審査で統合された飛行制御システム全体をどう評価したか、という具体的な弱点を指摘した。

また安全評価では、MCASの意図しない作動に対して乗員が認識し、通常の操縦入力や手順で対応できるという前提が重要だった。だが事故は、一つの異常が複数の警報と制御挙動を同時に生じさせると、人間の認知・診断負荷が想定より複雑になることを示した。これは認証制度の手続きだけでなく、安全解析のモデルそのものに関わる問題だった。

8｜運航再開は「ソフトを直した」だけではない

FAAは約20か月にわたって737 MAXを再評価し、2020年11月18日に運航禁止命令を解除した。しかし、この日からすべての737 MAXが自動的に営業運航へ戻れたわけではない。各機は必要な設計変更、整備、検査を受け、航空会社は訓練・運用要件を満たす必要があった。

改修後のMCASでは、左右二つのAOAセンサー入力を比較し、不一致が大きい場合にはMCASを作動させない方向へ設計が改められた。単一の高AOA入力だけで事故時のような反復作動が続く構造を改め、作動回数と権限にも制限が加えられた。飛行制御コンピュータの監視、AOA DISAGREE表示、関連手順や訓練も変更対象となった。

EASAはFAAの判断をそのまま採用しただけではなく、独自の飛行試験やシミュレータ評価を行ったうえで2021年1月に欧州での運航再開を認めた。EASAの要求には飛行制御ソフトウェア、配線、整備点検、運航マニュアル、乗員訓練などが含まれた。したがって「MCASのコードを修正したので復帰した」という理解は不十分である。復帰を成立させたのは、設計・監視・手順・訓練・整備という複数の防護層を組み直すことだった。

9｜このCASEで区別する三つの問い

737 MAXを理解するには、三つの問いを混ぜないことが重要である。

第一は、事故機で直接何が起きたか。これはAOA入力、警報、MCAS、水平安定板トリム、乗員操作、速度・推力など、飛行データと事故調査で追える。

第二は、なぜその危険経路が機体に残ったか。これは設計判断、安全解析、認証、情報共有、訓練、整備を扱う。

第三は、事故後にどのようにリスクが是正されたか。これはgrounding、再設計、再認証、訓練、各国当局の独立審査を扱う。

「MCASが作動した」は第一の問いの一部でしかない。それを第二の問いである「なぜその設計が許容されたのか」や、第三の問いである「何を変えれば再び飛ばせるのか」への答えとして使うと、議論が短絡する。

同様に、「パイロットが別の操作をしていれば助かった可能性がある」という反実仮想も、それだけで設計や認証の問題を消さない。航空安全は、一人の操縦者が完璧に振る舞うことを最後の防護層として固定するのではなく、単一故障や人間の誤りが直ちに破局へ連鎖しないよう複数の層を設計する考え方に立つ。

10｜346人という数字の先にあるもの

二つの事故は合計346人の死亡という結果を残した。この数字は重大だが、数字だけを強調すると、事故をセンセーショナルな物語へ変えてしまう危険もある。航空事故調査の目的は、誰かを物語上の悪役にして終えることではなく、同じ経路を再び成立させないため、どの防護層が機能しなかったかを特定することにある。

KNKT、EAIB、NTSB、FAA、JATR、DOT OIG、EASAなどの資料を並べると、737 MAX問題は一つの組織の一つの判断だけでは説明できないことが分かる。同時に、「複雑だから誰にも責任はない」という結論にもならない。各資料は、特定の設計判断、認証プロセス、情報共有、整備、訓練、運航判断について具体的な問題を示している。

このCASEで行うのは、それらを同じ重さの主張として混ぜることではない。事故調査報告、規制当局の記録、独立レビュー、監査報告、議会調査を役割ごとに分け、確定した事実と評価を区別することである。

EVIDENCE STATUS｜全体像で確定できること、確定しないこと

CASE全体を俯瞰すると、いくつかの事実は複数の公的資料で強く一致している。JT610とET302はいずれも737 MAX 8で発生し、離陸後早期にAOA異常と関連する複数の警報が現れ、MCASによる機首下げ方向のstabilizer trimが事故シーケンスへ入った。二事故後、FAAは型式共通の安全問題として運航停止を命じ、return-to-serviceではMCAS入力・権限・警報・訓練を含む設計変更を要求した。ここは本CASEの骨格として高い確度で扱える。

一方、「二事故の原因は完全に同一だった」とまでは言えない。JT610では交換AOAセンサーの校正と整備履歴が重要であり、ET302ではAOA異常の物理的起点や乗員行動の評価をめぐってEAIBとNTSB/BEAに差が残る。また認証制度上の問題も、事故機の直接故障と同じ階層ではない。設計・認証上の弱点は事故の防護層を薄くしたが、直接の飛行シーケンスとは分けて記述する必要がある。

この区別は、737 MAXを単純な企業不祥事やパイロットエラーの物語へ変えないために重要である。技術故障、運用、人間、認証、事故後対応を別の層として保持し、その間を証拠で接続することがCASE087の編集方針になる。

結論｜737 MAX事故は「一つの失敗」ではなく、連鎖として読む

737 MAXの二事故には、誤ったAOA入力とMCASによる機首下げトリムという明確な共通経路がある。しかし、その経路だけで346人が死亡する事故へ至った理由を理解するには、MCASがなぜその仕様になったのか、操縦士へ何が知らされていたのか、複数警報下の人間性能が安全評価でどう仮定されたのか、FAAとODAの認証プロセスがどう機能したのか、最初の事故後に何が行われたのかを追う必要がある。

さらにET302では、最終報告の一部分析をめぐってNTSBやBEAが異論を示している。したがってこのCASEは、単一の「真相」を提示する構成ではなく、確定事実、調査機関の結論、異論、後の是正措置を層として分ける。

次に確認するのは事故そのものではない。737 MAXがどのような設計上・市場上の要求から生まれ、なぜMCASという機能が必要とされたのかである。事故の数秒・数分を理解する前に、まず機体が事故前にどのような設計思想のもとで成立したのかを押さえる必要がある。

FACT CHECK｜出典・参考資料

1. 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
2. Aircraft Accident Investigation Bureau of Ethiopia (EAIB), *Aircraft Accident Investigation Report B737-MAX 8, ET-AVJ, Ethiopian Airlines Flight 302*, 2022-12-23. https://bea.aero/fileadmin/user_upload/ET_302__B737-8MAX_ACCIDENT_FINAL_REPORT.pdf
3. 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
4. Federal Aviation Administration, *Summary of the FAA’s Review of the Boeing 737 MAX — Return to Service*, 2020-11-18. https://www.faa.gov/sites/faa.gov/files/2022-08/737_RTS_Summary.pdf
5. U.S. Department of Transportation Office of Inspector General, *Weaknesses in FAA’s Certification and Delegation Processes Hindered Its Oversight of the 737 MAX 8*, 2021-02-23. https://www.oig.dot.gov/library-item/38302
6. European Union Aviation Safety Agency, *EASA declares Boeing 737 MAX safe to return to service in Europe*, 2021-01-27. https://www.easa.europa.eu/en/newsroom-and-events/press-releases/easa-declares-boeing-737-max-safe-return-service-europe

RCF検証ノート

本稿では、二事故の死者数、JT610の事故シーケンス、ET302の事故シーケンス、MCASの基本的な作動経路、2019年3月のgrounding、2020年以降のreturn-to-service要件を公的資料で照合した。JT610についてはKNKT最終報告を主軸にし、ET302についてはEAIB最終報告を用いる一方、同報告の解釈に対するNTSB・BEAの異論が存在するため、事故原因を単一の確定文へ統合していない。認証問題についてはDOT OIG/JATR等の評価を組織帰属付きで扱い、「Boeingが完全に自己認証した」という単純化を採用していない。

最終確認：2026年9月20日

END ARTICLE 01 / 08

NEXT FILE

CASE087-02｜737 MAXはなぜMCASを搭載したのか｜LEAP-1B・機体特性と設計の背景

事故時のMCASを理解するには、まず「なぜその機能が737 MAXに入ったのか」を分けて考える必要がある。次の記事では737NGからMAXへの設計変更、LEAP-1Bの統合、操縦特性、MCASの初期目的と開発中の拡張を追う。

RELATED FILES

• CASE087-03｜MCASは何をしていたのか――事故時の制御ロジックを技術面から補完する
• CASE087-04｜ライオン・エア610便――最初の事故を時系列で再構成する
• CASE087-07｜737 MAXの認証――設計が認証プロセスでどう評価されたかを扱う

737 MAXはなぜMCASを搭載したのか｜LEAP-1B・機体特性と設計の背景

737 MAX事故を説明するとき、「大きなエンジンを付けたため機首が上がりやすくなり、それを無理に押さえるためMCASを入れた」という説明が広く使われる。方向として完全な誤りではないが、それだけでは設計の関係を単純化しすぎる。737 MAXの成立には、燃費改善を求める市場、従来737との共通性、LEAP-1Bエンジンの機体統合、特定の飛行領域で求められる操縦特性、既存のSpeed Trim Systemを拡張したMCAS、そして型式証明・乗員訓練の考え方が重なっていた。

重要なのは「エンジンが大きいから自動的に危険になった」という話ではないことである。航空機ではエンジン位置、ナセル形状、主翼・胴体との干渉、速度、迎角、推力などによって空力モーメントが変化する。設計者はそれを機体形状、制御系、運用制限など複数の手段で調整する。MCASは、そのうち特定の高迎角領域における操縦特性を整えるために導入された飛行制御機能だった。

事故につながった問題は、「MCASという補助機能を使ったこと」そのものより、開発中にその作動範囲と権限がどのように変化し、どのセンサーを入力にし、故障時にどのような安全前提を置き、認証当局と乗員へどの情報が共有されたかにある。

CASE BRIEFING

737は1960年代に設計された機体を起点としながら、長期間にわたり改良を重ねたシリーズである。737 Classic、737 Next Generation、そして737 MAXへと世代が進んでも、完全に別設計の旅客機へ置き換えるのではなく、既存の設計・運航・整備・訓練との連続性を活用してきた。

2010年代、航空会社は燃料費や環境性能を重視し、エアバスA320neoのような新エンジン搭載型への関心を強めていた。ボーイングは737の次世代派生型としてMAXを開発し、CFM InternationalのLEAP-1Bを採用した。737の脚長や機体配置には長年の設計制約があり、新しいエンジンを単純に旧型と同じ位置へ置けばよいわけではなかった。

この機体統合によって空力特性は737NGと完全に同じではなくなった。特定の高迎角・高荷重条件で機首上げ方向のピッチングモーメントが増える傾向が設計上認識され、ボーイングは空力的な変更と制御系の補助を組み合わせた。その制御機能がMCASである。

THE QUESTION

737 MAXの設計変更とMCAS導入は、どのような技術的背景から生じたのか。

結論から言えば、MCASは「通常飛行中に常時737 MAXを安定化する装置」でも、「失速を自動的に防ぐ装置」でもない。NTSBの資料によれば、開発時に確認された高AOA・中Mach域での機首上げモーメントに対応し、操縦特性を改善するため、既存の速度トリム系統の機能として導入された。開発が進むとMCASは低Mach域にも拡張され、作動時に水平安定板へ与えるトリム権限も当初より大きくなった。

その変更を「設計上必要だったから」で終わらせず、なぜ安全評価・センサー冗長性・乗員への情報・認証の更新が十分追随しなかったのかを見ることが、事故を理解するうえで重要になる。

1｜737 MAXは「完全な新型機」ではない

737 MAXは737という既存型式系列の派生型として開発された。これは単なる名称上の話ではない。航空機の型式証明、航空会社の運航、パイロットの型式資格、整備設備、部品、訓練など、多くの資産を従来型と共有できることには大きな経済価値がある。

航空会社から見れば、新機種導入で必要になる訓練時間やシミュレーター、整備体制、予備部品が少ないほど移行コストを抑えられる。メーカーにとっても、既存顧客が導入しやすい。しかし「共通性が高いこと」は安全性とは別の評価軸であり、共通性を維持するために設計上どの変更が行われ、どの変更を新たなリスクとして評価すべきかが重要になる。

ここで注意すべきなのは、「共通性を求めたこと自体が事故原因」と短絡しないことである。航空機の派生型設計では共通性は一般的な価値であり、適切な安全評価と認証が伴えば直ちに問題ではない。737 MAXで問われたのは、変更された飛行制御機能が既存機との連続性の中でどう扱われたか、その変更の安全上の意味が十分に統合評価されたかである。

2｜LEAP-1Bを737へ載せるという設計課題

MAXで採用されたLEAP-1Bは、737NGで用いられたCFM56系より大径のファンを持つ。737は初期設計から地上高が比較的低く、主脚長にも構造上・運用上の制約がある。新しいエンジンを主翼下へ統合するには、ナセル形状や取付位置を調整し、地上とのクリアランスを確保しながら空力と構造を成立させる必要があった。

エンジンの位置やナセルは、単なる「重い部品の置き場所」ではない。迎角が高くなったとき、ナセル自体も揚力や空力モーメントへ寄与する。NTSBがまとめた技術資料では、MAX開発中に高AOA・中Mach域で機首上げ方向のピッチングモーメントが確認され、ボーイングは空力変更とMCASを含む安定性増強策を用いたと説明されている。

このため、「エンジンが前方にあるから必ず機首が上がる」という静的なてこ比だけで説明するのも正確ではない。問題は飛行状態に応じて変化する空力特性であり、設計評価は速度・Mach・迎角・荷重倍数などを含む飛行包絡線全体で行われる。

3｜MCASの目的は何だったのか

MCASという名前には「Maneuvering Characteristics Augmentation System」、すなわち操縦特性を補強するシステムという意味がある。NTSB資料では、MCASはSpeed Trim Systemの拡張として、特定条件で水平安定板へ機首下げ方向のトリムを与え、機首上げ傾向を減らし、操縦桿力の特性を整える機能として説明されている。

通常の安定した巡航で常に作動するものではない。事故時仕様では、手動飛行で自動操縦が接続されておらず、フラップが格納され、AOAがMachに応じたしきい値を超えたときに作動条件が成立した。作動すると水平安定板をaircraft-nose-down、機首下げ方向へトリムする。

MCASが作動することと、機体がすでに失速していることは同義ではない。システムはセンサーから得た迎角を条件としていたが、事故ではそのセンサー値自体が誤っていた。制御系は「入力が真実か」を独立して知ることができない。したがって安全設計では、入力センサーの故障をどう検出するか、単一故障が危険な出力へ直結しないかが重要になる。

4｜開発途中でMCASは変わった

MCASを理解するうえで重要なのは、最終仕様が最初から固定されていたわけではないことだ。JATR、NTSB、DOT OIG、議会調査などは、開発過程でMCASの作動範囲や権限が変化したことを扱っている。

FAAが後年まとめた規則資料では、調査機関が、MCASの水平安定板移動量が初期の約0.55度から最大約2.5度へ増え、作動する条件も高高度中心から比較的低高度・低速領域へ拡大した点を問題の一部として取り上げたことが整理されている。数値だけを切り取って「5倍強くなった」と表現するのは乱暴だが、機能の安全上の意味が開発途中で大きくなったことは重要である。

設計変更が起きること自体は異常ではない。航空機開発では試験結果に基づき制御則を修正する。しかし、変更が起きたなら、その変更を反映して危険度評価、故障解析、認証文書、当局への情報、乗員への情報を更新する必要がある。737 MAX問題では、この「設計変更に安全評価と認証の理解が十分追随したか」が後のレビューで焦点になった。

5｜なぜ単一AOA入力が大きな論点になったのか

737 MAXには左右二つのAOAセンサーがある。それでも事故時のMCASは、左右を常時比較して一致を確認してから作動する設計ではなかった。各飛行で使用される側のセンサー入力に基づきMCASが作動し得たため、その一つが誤った高迎角値を出すと、MCASの作動条件が誤って成立する経路が存在した。

ここで「センサーは二つあるのに、なぜ一つしか見なかったのか」という疑問が生じる。安全性は単純な部品数では決まらない。二つのセンサーがあっても、ある機能が一つの入力に依存し、その機能の誤作動が重大な機体運動を生み得るなら、システムとしては単一故障への耐性を評価する必要がある。

設計者側の安全評価では、意図しないMCAS作動が生じても、パイロットが操縦桿や電動トリムで認識・対抗し、必要ならrunaway stabilizer手順に移行できることが防護層として期待されていた。つまりセンサー故障を直接二重化で封じるだけでなく、人間の認識と操作を含めてリスクを許容範囲に抑える考え方があった。

事故は、その人間を含む防護層が現実には想定どおり単純ではないことを示した。

6｜パイロットはMCASをどこまで知っていたのか

737 MAXの初期運用では、多くのパイロットが通常の差分訓練でMCASの詳細を教えられていなかった。事故後、この点は大きな批判対象になった。ただし、ここでも「MCASという単語を知らなかったから事故が起きた」と一対一に結びつけるのは慎重であるべきだ。

設計思想上は、MCASが異常作動した場合でも、乗員はそれを特別な新システムの故障として診断しなくても、既存のスタビライザー・トリム異常として認識し、既存手順で安全を確保できるという前提があった。したがってボーイング側は、通常の乗員操作に新しい独立手順を必要としない機能として扱っていた。

問題は、実際の故障状況が「きれいなrunaway stabilizer」だけとして現れなかったことである。AOA異常はスティックシェーカーや速度・高度の不一致など複数の症状を生み、そこへMCASの機首下げトリムが加わった。乗員は短時間に複数の異常を処理する必要があり、システム名を知らなくても既存手順へ即座に到達できるという前提が現実の認知負荷を十分表していなかった。

NTSBが後に「multiple alerts and indications」を問題にした理由はここにある。

7｜「737らしく飛ぶ」ことと安全評価

派生型航空機では、従来型との操縦特性の連続性に価値がある。パイロットが同じ型式系列として予測可能な操縦感覚を得られることは、運航上の利点でもある。MCASは特定領域で操縦桿力の特性を整え、737 MAXが規定された操縦性要件を満たすための一手段だった。

しかし、操縦特性を「ソフトウェアで737らしく見せかけた」という表現は正確ではない。MCASは飛行制御系の一部であり、航空機に制御則を使って所望の操縦特性を実現すること自体は現代航空機で珍しくない。重要なのは、その制御則が故障した場合の安全性を含めて設計・認証されているかである。

問題の焦点は、通常作動時のMCASが操縦感覚を整えることではなく、誤ったAOA入力によって意図しない作動が起きたときの危険性、反復作動、乗員対応の仮定、センサー冗長性、警報、そしてそれらを認証プロセスがどう評価したかだった。

8｜認証側へ伝わった情報は十分だったのか

FAAは航空機の設計すべてを自ら計算・試験するわけではない。メーカーが設計と適合性証明の多くを実施し、FAAは審査・監督し、一部業務をODAとして委任する。737 MAXでもこの仕組みが使われた。

DOT OIGは、FAAとボーイングが当時の認証プロセスに沿って手続きを進めていた一方、MCASに関する重要な情報共有や、変更されたシステムを把握するためのガイダンスと監督に弱点があったと指摘した。JATRも、個別コンポーネントの変更だけでなく、統合された飛行制御システムをより包括的に評価する必要性を示した。

したがって、「FAAは何も見ていなかった」も「認証されたのだから安全評価は完全だった」も正しくない。認証活動は実際に行われていたが、後のレビューでは、そのプロセスがMCASの進化と統合リスクを十分把握できなかった点が問題とされた。

9｜市場競争と納期をどう扱うべきか

737 MAX開発をめぐっては、エアバスA320neoとの競争、顧客獲得、開発期間、コスト、訓練要件への圧力がしばしば語られる。米下院運輸・インフラ委員会多数派スタッフの調査報告は、開発・認証における生産スケジュールやコスト圧力、組織上の問題を強く批判した。

ただし、ここは証拠の扱いに注意が必要である。「競争が激しかった」という背景事実から、特定の技術判断が「安全を意図的に犠牲にした」と動機まで断定することはできない。内部文書や調査報告が示した具体的な判断・コミュニケーションは検証できるが、組織や個人の心理を一つの意図へ還元するのは別問題である。

このCASEでは、経済的・競争的背景を設計選択の文脈として扱うが、技術的因果と動機推測を混ぜない。事故を理解するには「誰が悪かったか」という結論を先に置くより、どの変更がどの安全評価に結びつき、どの情報がどこで失われたかを追う方が再現性が高い。

10｜MCAS導入自体と事故仕様を分ける

事故後の議論では、MCASという名前が737 MAX全体の問題を代表するようになった。しかし、MCAS導入の技術目的と、事故を可能にした仕様は分けるべきである。

技術目的は、特定飛行領域の操縦特性を補強することだった。事故につながった仕様上の問題には、単一AOA入力への依存、作動権限、反復作動、安全評価での乗員対応仮定、警報や情報提供などが含まれる。だからこそ運航再開時には、MCASを完全に削除するのではなく、センサー比較、作動制限、飛行制御コンピュータの監視、警報、訓練などを改めたうえで機能を残す判断がなされた。

この事実は、「MCASは存在するだけで危険だった」という説明が不十分であることを示す。同じ名前の機能でも、入力検証、権限、故障時挙動、防護層が変わればシステム安全性は大きく変わる。

11｜次に見るべきなのは制御ブロック

ここまでの設計背景を一言でまとめるなら、737 MAXは「大きなエンジンを載せたため危険になった」のではない。新しいエンジンを既存737系へ統合したことで特定飛行領域の空力・操縦特性が変化し、それを満たすための手段の一つとしてMCASが導入された。その機能が開発中に拡張され、事故時仕様では一つのAOAセンサー入力を起点に水平安定板へ大きな影響を与え得る一方、安全評価は乗員による迅速な認識・対応を重要な防護層としていた。

では、実際にセンサーからどのような信号が入り、MCASはどの条件で作動し、水平安定板は何をし、パイロットのトリム操作やcutout switchはどこで介入するのか。

次の記事では「設計思想」から離れ、AOAセンサー→Flight Control Computer→MCAS→stabilizer trim→pilot inputという制御系として分解する。これによって、事故で何が自動化され、何が人間の操作に残されていたかを具体的に見られる。

EVIDENCE STATUS｜「エンジン」と「MCAS」の因果をどこまで言えるか

737 MAXの解説では、LEAP-1Bの大径化と搭載位置の変更がそのままMCAS導入の唯一原因だったように説明されることが多い。しかし公的技術資料が示しているのは、より限定された関係である。MAXの空力設計では高AOA・特定Mach域で機首上げ方向の特性が変化し、ボーイングは空力的変更とMCASを組み合わせて操縦特性を整えた。したがって新エンジン統合は重要な背景だが、単純な「重い／大きいエンジンが前にあるから機首が上がる」という静力学だけでは不十分である。

また、MCASが必要だったことと、事故時MCASの安全性は別問題である。操縦特性補強機能を設ける設計判断そのものが直ちに不適切だったと公的資料は結論していない。事故後のFAA/EASAはMCASを完全削除せず、入力比較・権限制限・反復制限を加えて残した。これは機能目的と安全実装を分離して考える必要があることを示す。

MYTH VS EVIDENCE｜MAXは「不安定な機体をソフトで無理に飛ばした」のか

この表現も強すぎる。EASAは改修後の独自飛行試験で、MCASがなくても航空機そのものが直ちに制御不能になるような「本質的不安定性」を示すものではないと説明している。MCASは特定領域の操縦特性・操舵力特性を満たすためのaugmentationであり、常時姿勢を支えるfly-by-wire安定化装置とは役割が異なる。

ただし、「機体は飛べるのだからMCASは安全上重要でなかった」という逆方向の単純化も誤りである。認証上要求される操縦特性を満たす機能としてMCASは機体設計の一部であり、その故障が危険なstabilizer trimを生じさせ得るなら、システム安全上は重大な機能である。事故の教訓は、補助機能の名称や通常時の目立たなさではなく、故障時の最大権限とfailure pathで重要度を評価する必要があることだ。

設計変更管理という論点

開発中にMCASの作動範囲や権限が増えたことは、それ自体よりも「変更管理」の観点で重要である。制御則のパラメータを変えれば、関連するhazard analysis、sensor dependency、pilot response assumption、documentation、certification involvementも再評価対象になる。複雑な開発では、一つのチームにとっては局所的なパラメータ変更でも、システム全体では安全分類を変えるほどの意味を持つことがある。

737 MAXは、この種の変更が組織間インターフェースを通過するときに、設計・安全・認証の最新状態を一致させる構成管理がどれほど重要かを示す例になった。第7記事で扱うODAやFAAの問題も、単純な権限委任だけでなく、この「変更情報を誰がいつ知るか」と密接につながっている。

設計上の確認ポイント｜「同じ737」であることの意味

737 MAXの共通性は、機体構造だけでなく、パイロット資格、整備、運航手順、部品供給、航空会社の投資回収まで広い範囲に価値を持つ。したがって「共通性を求めた＝安全を軽視した」とは言えない。問題は、共通性を維持しながら追加した新機能が、従来機の前提と矛盾しないかを検証できたかである。MCASはまさにその境界に位置した。従来737との操縦・訓練上の連続性を支える一方、事故時には従来機にはない自動トリム経路を持ったため、乗員がどこまで新機能を知るべきか、安全評価でどの程度「従来手順で対処可能」とみなすかが重要になった。

結論｜MCASは「大径エンジンの帳尻合わせ」という一文では説明できない

737 MAXでLEAP-1Bを採用したことは、機体統合と空力特性へ影響した。特定の高迎角領域で現れた操縦特性に対し、ボーイングは空力的変更とMCASを用いた。したがってエンジン変更とMCASに技術的な関係はある。

しかし、事故の因果を「大きなエンジン→機首上げ→MCAS→墜落」と一直線に描くと、安全問題の核心が消える。事故を成立させたのは、誤ったAOA入力がMCASへ届き、機首下げトリムを繰り返し生じさせ得る仕様、その危険を人間の対応を含む防護層で抑える安全評価、警報・情報提供、認証プロセスなどの組み合わせだった。

設計上の目的と、故障時の安全性は別である。MCASがなぜ必要とされたかを理解したうえで、次はその機能が具体的にどの信号を使い、どのように水平安定板へ作用したのかを確認する。

FACT CHECK｜出典・参考資料

1. 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
2. Joint Authorities Technical Review / FAA, *Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations*, 2019-10-11. https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019
3. U.S. Department of Transportation Office of Inspector General, *Weaknesses in FAA’s Certification and Delegation Processes Hindered Its Oversight of the 737 MAX 8*, 2021-02-23. https://www.oig.dot.gov/library-item/38302
4. U.S. House Committee on Transportation and Infrastructure, Majority Staff, *The Design, Development & Certification of the Boeing 737 MAX: Final Committee Report*, 2020-09. https://www.govinfo.gov/content/pkg/GOVPUB-Y4_T68_2-PURL-gpo144993/pdf/GOVPUB-Y4_T68_2-PURL-gpo144993.pdf
5. Federal Aviation Administration, *Summary of the FAA’s Review of the Boeing 737 MAX — Return to Service*, 2020-11-18. https://www.faa.gov/sites/faa.gov/files/2022-08/737_RTS_Summary.pdf

RCF検証ノート

本稿では、MCAS導入目的と事故時仕様を分けるため、NTSBのシステム安全資料、JATR、DOT OIG、FAA return-to-service reviewを優先した。LEAP-1Bの採用と高迎角時の操縦特性に技術的関係があることは確認できるが、「大型エンジンを前へ出したからMCASが必要になった」という一文だけでは空力と制御の関係を過度に単純化するため採用していない。市場競争・コスト圧力については米下院多数派スタッフ報告の評価として帰属させ、特定個人・組織の動機を独自に断定していない。

最終確認：2026年9月20日

END ARTICLE 02 / 08

NEXT FILE

CASE087-03｜MCASは何をしていたのか｜AOAセンサーと水平安定板の仕組み

次の記事では、MCASを「ソフトウェア」という抽象語で扱わず、センサー入力、作動条件、水平安定板、操縦桿、電動トリム、cutout switchまでを制御系として追う。

RELATED FILES

• CASE087-01｜二つの事故と運航停止――事件全体の位置づけ
• CASE087-03｜MCASの制御ロジック――設計背景を機構へ落とし込む
• CASE087-07｜737 MAXの認証――MCASの設計変更が認証側でどう扱われたか

MCASは何をしていたのか｜AOAセンサーと水平安定板の仕組み

MCASを「機首を勝手に下げるソフト」とだけ理解すると、737 MAX事故の制御系を正しく捉えられない。事故で起きたのは、センサー入力、飛行制御コンピュータ、水平安定板トリム、パイロットの電動トリム、操縦桿、cutout switchが相互に関係する一連の挙動だった。どこか一つだけを切り取ると、なぜ乗員が一時的に機首を戻せたのに再び機首下げが生じたのか、なぜ前便は着陸できたのに事故便では回復できなかったのかが分からない。

MCASはManeuvering Characteristics Augmentation Systemの略で、737 MAXの特定飛行条件における操縦特性を整えるための機能だった。事故時仕様では、手動飛行、自動操縦OFF、フラップ格納、AOAがMachに応じたしきい値を超えるという条件が揃うと作動し、水平安定板をaircraft-nose-down、機首下げ方向へ動かした。

ここで最も重要なのは、MCASが「機体の本当の迎角」を直接知っていたわけではないことである。システムが知るのはセンサーが出す値だけだ。センサーが故障や誤校正で高いAOAを出せば、実際には失速に近づいていなくても条件が成立し得る。事故はこの入力依存性と、そこから先の制御権限が組み合わさったとき何が起きるかを示した。

CASE BRIEFING

737 MAXには左右二つのAOAセンサーがあり、機首付近のベーンが気流に対する機体の角度を検出する。AOAは失速余裕や警報などに関係する重要な量だが、通常のパイロットが直接AOA値を見ながら飛行することが主目的のセンサーではない。複数システムがこの情報を利用する。

事故時MCASは、一度の飛行で片側AOAセンサーの値を作動判定に使う構造だった。左右を比較して不一致なら作動禁止するというロジックは事故時仕様にはなかった。そのため選択された側のAOA値が異常に高ければ、MCASはそれを実際の高迎角として扱い得た。

MCASの出力先はエレベーターではなく水平安定板トリムである。737の尾翼では、パイロットが操縦桿で動かすエレベーターと、水平安定板全体の角度を変えるトリムが別の役割を持つ。水平安定板が大きく機首下げ側へトリムされると、パイロットは操縦桿を引いてエレベーターで対抗しても、大きな操舵力を必要とするようになる。

THE QUESTION

MCASはどの入力を使い、何を動かし、故障時にどのような制御ループを作ったのか。

事故時の基本経路は、AOAセンサー → Flight Control Computer → MCAS作動判定 → stabilizer trim motor → 水平安定板の機首下げトリムである。パイロットは操縦桿によるエレベーター操作、操縦桿上の電動トリムスイッチ、そしてセンターペデスタルのstabilizer trim cutout switchを使って介入できた。

ところがMCASは、パイロットが電動トリムで機首上げ側へ戻した後でも、異常な高AOA入力が続き条件が再成立すると再び作動し得た。この「戻す→再作動→また戻す」という反復が事故時の重要な特徴だった。

1｜AOAセンサーは何を測るのか

Angle of Attack、迎角は、翼や機体が相対風に対してどの角度で向いているかを表す。迎角が増えると一般に揚力は増えるが、一定範囲を超えると翼上面の流れが大きく剥離し、失速へ近づく。したがってAOAは飛行安全上重要な状態量である。

737 MAXの機首左右にはAOAベーンがあり、外気流に応じて向きを変え、その角度を電気信号として機内システムへ送る。左右二つがあるのは、単に表示を二系統にするためだけではない。航空機ではセンサー故障を前提にし、複数情報を比較したり、異常を検知したりすることが安全設計上重要になる。

JT610事故機では左側AOAセンサーが実際より大きく外れた値を出していた。ET302でも離陸直後から左右AOAに大きな差が生じた。これによりスティックシェーカー、速度・高度表示差など複数の異常が生じた。つまりAOAの誤入力はMCASだけへ影響したわけではない。

2｜MCASが作動する条件

事故当時のMCASは常時作動していたわけではない。NTSB資料では、手動飛行、自動操縦未接続、フラップ格納、AOAがMach数に応じたしきい値を超える場合に作動するよう設計されていたと説明されている。

この条件はMCASの目的と対応する。通常の離着陸でフラップを使用しているときや、自動操縦が機体を制御しているときに常時介入する機能ではない。特定の手動飛行領域で操縦特性を補強するための機能だった。

問題は、AOAが「本当に高い」かどうかをMCAS自身が独立判断していなかったことにある。事故時仕様では、一方のAOAセンサーから高い値が来れば、その値がしきい値を超えたという条件だけでMCASが作動し得た。左右差が大きいことを理由にMCASを禁止する事故後仕様の防護はまだ存在しなかった。

3｜水平安定板とエレベーターは何が違うのか

機体のピッチ、つまり機首上げ・機首下げを制御する尾翼には、水平安定板とエレベーターがある。エレベーターはパイロットの操縦桿操作に応じて比較的素早く動き、ピッチ姿勢を制御する。一方、水平安定板全体の角度を変えるトリムは、継続的に必要な操舵力を減らし、機体を釣り合わせるために使われる。

この二つが逆方向へ働く状況を考えると重要性が分かる。水平安定板が機首下げ側へ大きくトリムされた状態で、パイロットが操縦桿を引いてエレベーターを機首上げ方向へ使えば、一定範囲では対抗できる。しかしトリム量が増えるほど、操縦桿に必要な力が増え、エレベーターだけで対抗し続けるのは難しくなる。

したがって事故時の核心は「MCASがエレベーターを奪った」ことではない。水平安定板のトリム位置を機首下げ側へ動かし、その結果としてパイロットがエレベーターで対抗するために必要な力と余裕を悪化させたことである。

4｜パイロットの電動トリムはMCASを止められた

パイロットは操縦桿上のトリムスイッチを使い、水平安定板を電動で機首上げまたは機首下げ方向へ動かせる。事故時MCASが作動している最中でも、パイロットが電動トリムを入力すればMCASのトリム指令を止め、逆方向へ戻すことができた。

JT610のFDRでは、MCASによる機首下げトリムと、乗員による機首上げ電動トリムが何度も交互に現れた。これは乗員がまったく機体へ介入できなかったわけではないことを示す。同時に、異常なAOA入力が残る限り、一定条件後にMCASが再作動し、再び機首下げトリムを加えた。

この反復性が危険を増幅した。一回の誤作動なら、乗員が戻した後に状態を整理できる可能性がある。しかし戻しても再び同じ方向へ自動トリムされると、乗員は「何がこの動きを起こしているのか」を診断しながら継続して対抗しなければならない。

5｜cutout switchは何を切るのか

737のセンターペデスタルにはstabilizer trim cutout switchがあり、電動による水平安定板トリムを切り離すために使える。runaway stabilizer手順では、意図しない連続トリムが止まらない場合にこのスイッチをCUTOUT側へ移すことが重要な対応となる。

JT610の前便では、乗員がcutout switchを使用し、電動トリムを止めて飛行を継続し着陸した。この事実から「事故便も同じ操作をすれば簡単に助かった」と結論づけるのは慎重であるべきだが、cutoutが機能上重要な防護だったことは明らかである。

ET302では乗員がcutout switchをCUTOUTへ移した。しかしその後も機体は高速となり、手動トリムホイールを回して水平安定板を十分に戻すことが難しい状態になった。最終的にスイッチはNORMAL側へ戻され、その後電動トリムが再び機首下げ方向へ動いた。NTSBはこの一連の行動と、推力・速度・手動電動トリムの使い方を人間性能の観点から分析すべきだと指摘している。

つまりcutout switchは「押せばすべて解決する非常ボタン」ではない。切れば電動トリムは止まるが、その時点の水平安定板位置が不利なら、パイロットは手動でトリムを戻す必要がある。速度が高いと空気力が大きくなり、手動ホイールを回す力も大きくなり得る。

6｜なぜ反復作動できたのか

事故時仕様のMCASでは、一回の作動後にAOAがしきい値より下がる、またはパイロットがトリム入力するなどで作動が終わっても、条件が再成立すれば再び作動し得た。異常センサーが高AOAを出し続ける場合、この再判定は危険な反復ループを作る。

制御系の観点で見ると、入力異常が持続しているのに、出力側で一度パイロットが補正しても、システムは入力の正当性を再評価せず同じロジックを再実行する。パイロットの機首上げトリムが「この自動機能は誤っている」という恒久的な拒否信号にはならない。

事故後の改修では、この点が大きく変えられた。左右AOAを比較し、一定以上の不一致がある場合にMCASを抑止すること、一つの高AOA事象に対するMCASの作動を制限すること、パイロットが十分な権限を持てることなどが設計要件に組み込まれた。

7｜「操縦桿を引けば止まる」は半分だけ正しい

一般の説明で誤解されやすいのが、操縦桿とトリムの関係である。パイロットが操縦桿を引けばエレベーターは機首上げ方向へ働き、一定範囲でMCASの機首下げ効果に対抗できる。しかし事故時のMCASによるトリム指令そのものを、操縦桿を引く操作だけで恒久停止できるわけではなかった。

従来の737には、操縦桿を反対方向へ動かすと一部の電動トリムを止めるcolumn cutout機能がある。しかしMCASは特定の条件下でこの通常の保護と同じ動作関係ではなかった。事故後、この点も議論の対象となった。

したがって「パイロットはただ操縦桿を引けばよかった」という説明は不正確である。エレベーターで姿勢を保ちつつ、トリム位置を適切に戻し、必要なら電動トリムを切り離すという複数の操作が必要になる。さらに事故時には警報と表示不一致が同時に起き、パイロットは原因診断も並行して行っていた。

8｜複数警報が制御系の理解を難しくした

AOAセンサーの異常はMCASだけの問題ではなかった。JT610とET302ではスティックシェーカー、速度・高度の不一致、その他の表示異常が乗員へ現れた。人間は一つの明確な警告に反応するより、複数の矛盾する情報から何が根本故障かを推定するときに認知負荷が高くなる。

NTSBは2019年の安全勧告で、航空機のシステム安全評価が、複数の警報・表示と、それらがパイロット性能へ及ぼす影響をより現実的に考慮すべきだとした。ここでの論点は、パイロットが訓練不足だったかどうかだけではない。設計・認証側が「一定時間内に正しい行動を取る」と仮定するなら、その前提が実際の警報環境でも成立するかを評価する必要がある。

制御工学でいうフィードバック系に人間を含めるなら、人間は理想的な遅延ゼロの制御器ではない。表示を認識し、故障候補を絞り、手順を想起し、他の乗員と役割分担し、機体姿勢・速度を保ちながら操作する。その時間と誤認可能性を無視できない。

9｜事故後MCASはどう変わったか

FAAのreturn-to-service reviewとEASAの要件では、MCASの入力と出力の両方に防護が追加された。左右二つのAOAセンサー値をFlight Control Computerが比較し、差が大きければMCASを抑止する。単一の異常入力がそのまま事故時と同様のMCAS作動へ進む経路を遮断した。

またMCASの作動は、一つの高AOA事象に対して繰り返し機首下げトリムを積み重ねる事故時の挙動から変更された。システムが指令できるトリム量にも制約が設けられ、パイロットが操縦桿で機体を制御する能力を維持するよう再設計された。

さらにAOA DISAGREE警報、飛行制御コンピュータの監視、配線、手順、シミュレータ訓練などもパッケージとして改修された。EASAが「complete package」と表現したように、MCASコードの一箇所だけを修正したのではない。

10｜制御システムとして見た事故経路

事故時の経路をPLCや制御系に近い考え方で簡略化すると、次のように整理できる。

1. Input：AOAセンサーが実際より高い値を出す。
2. Condition：手動飛行、フラップ格納、AOAしきい値超過などのMCAS条件が成立する。
3. Logic：Flight Control Computer内のMCASが作動を決定する。
4. Output：stabilizer trim motorが水平安定板を機首下げ側へ動かす。
5. Human feedback：パイロットが操縦桿と電動トリムで機首上げ側へ対抗する。
6. Reset/retrigger：異常AOAが残り、再作動条件が成立する。
7. Accumulation：機首下げトリムが再び加わり、操縦力・作業負荷が増える。
8. Isolation option：cutout switchで電動トリムを切り離す。
9. Residual state：切り離した時点のトリム位置と速度によって、手動トリムの困難さが変わる。

この整理で分かるのは、事故が一つの「誤出力」ではなく、異常入力が持続する状態で自動制御と人間の補正が競合するループだったことだ。

11｜フェイルセーフの観点で何が不足していたのか

単一センサーが故障しても、危険な制御出力へ直結しないことは安全制御の基本的な考え方である。航空機ではシステムごとに許容される故障確率や冗長性設計は異なり、単純に「二重化すればよい」とは限らない。しかし、故障が重大なハザードへつながるなら、入力妥当性、クロスチェック、出力権限、異常時の抑止、乗員への明確な告知などの防護が必要になる。

事故時MCASでは、単一AOA入力、反復可能な作動、乗員対応を重要な防護として置く安全評価が組み合わさっていた。事故後は、入力比較、出力制限、作動回数制限、監視、訓練という複数層へ分散させる方向で改修された。

この違いはフェイルセーフ設計の本質に近い。故障を「起こさない」だけではなく、起きても危険側へ一方向に連鎖しにくくする。さらに人間が介入するなら、異常を認識しやすく、操作が一貫して有効である必要がある。

EVIDENCE STATUS｜MCASをPLC的に見ると何が危険だったのか

産業制御に置き換えるなら、事故時MCASには「一つのアナログ入力を重要インターロック条件へ使い、その入力異常を独立クロスチェックせず、条件が残る限り強いアクチュエータ出力を再要求し得る」性質があったと考えると理解しやすい。ただし航空機では、パイロットが別系統のフィードバック制御器として介入するため、純粋な自動制御だけで閉じたループではない。

安全設計上の論点は、入力異常を検出できないこと、出力権限が大きいこと、再トリガできること、人間の介入を前提にしていることが同時に存在した点にある。一つずつなら許容可能でも、組み合わせると単一故障から危険な連鎖が成立する。この「組合せ故障」はFMEAだけでなくsystem-level hazard analysisが必要になる典型である。

インターロックとしての左右AOA比較

改修後の左右AOA比較は、単純化すればMCAS出力許可に対するpermissive条件の追加とみなせる。二つの入力が大きく不一致なら、どちらが正しいかを無理に多数決せず、MCASという自動出力を禁止する。センサーが二つしかないため真値を特定できなくても、安全側へ機能を退避させる考え方である。

これはフェイルセーフ設計でよくある「異常時は高度な自動機能を失っても、基本操縦能力を残す」という戦略に近い。MCASが使えなくなっても通常の飛行制御そのものが失われるわけではないので、誤作動より機能停止を選べる。

出力制限という第二の防護

入力比較だけでは完全ではない。二つのセンサーが同時に似た誤りを出す可能性、比較ロジック自体の故障などを考えれば、出力側にも制限が必要になる。改修後MCASで権限・作動回数を制限したのは、そのための第二層と見られる。

安全系で重要なのは「一つの防護が失敗したら終わり」にしないことである。入力妥当性、ロジック、出力リミット、人間のoverride、警報、訓練が直列に重なれば、どこか一つの不具合が直ちに事故へ到達しにくくなる。737 MAX改修はまさにこの多層化だった。

技術補足｜stabilizer trimは「姿勢指令」ではなく釣り合いを変える

水平安定板トリムを理解する際、MCASが「機首角度を何度にしろ」と直接姿勢を指令する制御だと考えると誤解しやすい。MCASが動かすのはstabilizer trimであり、尾翼が作る力の釣り合いを変える。その結果、操縦桿を中立に近づけたときに機首が下がる傾向や、操縦桿を引くために必要な力が変わる。パイロットはエレベーターで瞬間的に対抗できるが、トリムが大きくずれていると継続的な操舵力が必要になる。

この違いは、事故終盤に高速化すると問題が悪化した理由にも関係する。速度が上がれば尾翼に働く空気力も増え、ミストリム状態で必要な操舵力や手動トリムホイールの負荷が大きくなる。したがって同じstabilizer角度でも、低速時と高速時では回復の難しさが同じではない。

技術補足｜なぜ「センサー三つで多数決」にしなかったのか

事故後に左右二つのAOAを比較する設計へ変わったため、「最初から三つのAOAセンサーを載せて多数決にすればよかった」という疑問も出る。三重化は強力な手段だが、重量、配線、電源、共通原因故障、整備、既存機体との設計互換性などのコストがある。重要なのは、必要な安全性をどのアーキテクチャで達成するかであり、必ず三重化が唯一解ではない。

改修後MAXでは、二つのAOAが大きく違えば高度な自動機能であるMCASを停止し、基本操縦を残す設計を選んだ。これは「どちらが正しいか決める」より「不一致時は危険な自動判断をしない」フェイルセーフ志向である。

技術補足｜単一AOA入力が「単一点故障」になる条件

センサーが一個であること自体が直ちに危険なのではない。重要なのは、その一入力の誤りがどこまで検出されず、どの出力権限へ到達できるかである。事故時MCASでは、使用側AOAの誤値が作動条件を満たすと、独立した第二AOAとの比較で拒否される経路がなく、stabilizer trimという大きな操縦影響へ到達できた。したがって安全解析では「AOAセンサー故障率」だけでなく、誤入力検出、出力制限、乗員への表示、手動overrideまで含むend-to-endのfailure pathを見る必要がある。

結論｜MCAS事故は「センサー誤り→ソフト暴走」より長い制御ループだった

MCASはAOA入力を使い、特定条件で水平安定板を機首下げ方向へトリムする機能だった。事故時仕様では片側AOA入力を作動判定に用い、誤った高AOAが入ると意図しない作動が起き得た。パイロットは電動トリムで対抗できたが、異常入力が残ればMCASは再作動し得た。cutout switchで電動トリムを止めることはできたが、その時点の機体速度やトリム位置次第では手動回復が難しくなる。

したがって、事故は「センサーが壊れた」「ソフトが暴走した」「パイロットが止められなかった」のどれか一つではない。入力故障、ロジック、出力権限、再作動、人間の補正、警報、速度・空気力が一つの時間軸上で相互作用した。

次の記事では、この抽象化をJT610の実際の時系列へ戻す。事故機の前便で何が起き、どの整備が行われ、事故便でMCASと乗員操作がどのように繰り返されたのかをKNKT最終報告に沿って追う。

FACT CHECK｜出典・参考資料

1. 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
2. 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
3. Joint Authorities Technical Review / FAA, *Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations*, 2019-10-11. https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019
4. Federal Aviation Administration, *Summary of the FAA’s Review of the Boeing 737 MAX — Return to Service*, 2020-11-18. https://www.faa.gov/sites/faa.gov/files/2022-08/737_RTS_Summary.pdf
5. European Union Aviation Safety Agency, *EASA declares Boeing 737 MAX safe to return to service in Europe*, 2021-01-27. https://www.easa.europa.eu/en/newsroom-and-events/press-releases/easa-declares-boeing-737-max-safe-return-service-europe

RCF検証ノート

本稿ではMCASを自動操縦装置・失速防止装置と誤認させないことを優先し、NTSBとKNKTの技術記述を基礎にした。事故時MCASの入力、作動条件、水平安定板トリム、パイロット電動トリム、cutout switchの関係を相互作用として整理した。ET302の乗員操作についてはEAIBとNTSBの評価差があるため、乗員が特定操作をしなかったことを独自の「事故原因」と断定していない。事故後仕様はFAA/EASAのreturn-to-service資料で再確認した。

最終確認：2026年9月20日

END ARTICLE 03 / 08

NEXT FILE

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

次の記事では、前日の同型機トラブル、AOAセンサー交換、事故便離陸後の警報、MCASの反復作動、乗員の対抗操作を一つの時系列に戻す。

RELATED FILES

• CASE087-02｜MCAS導入の設計背景
• CASE087-04｜JT610の事故時系列
• CASE087-08｜改修後MCASとの比較

ライオン・エア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｜出典・参考資料

1. 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
2. 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
3. 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
4. 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｜認証構造――事故後に見直された安全評価の背景

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

2018年10月29日にライオン・エア610便が墜落した後、737 MAXはただちに世界で運航停止になったわけではない。ボーイングは運航会社へbulletinを出し、FAAは11月7日に緊急耐空性改善命令（Emergency Airworthiness Directive）を発行した。それでも機体は運航を続け、約4か月後の2019年3月10日、エチオピア航空302便が墜落した。

この期間だけを見ると、「最初の事故でMCASの危険が分かっていたのに、なぜ飛ばし続けたのか」という疑問が自然に生じる。一方で、「最初の事故では原因がまだ確定していなかったのだから運航継続は当然だった」と片づけるのも粗い。2018年11月時点で、誤ったAOA入力が意図しない機首下げトリムを生じさせ得ることは規制文書で明示されていた。つまり危険経路の一部は既に認識されていた。

問題は、その危険をどの手段で受け止めると判断したかである。設計そのものを即時変更して全機を止めるのではなく、既存のrunaway stabilizer手順を再確認させ、運航情報を追加し、ソフトウェア改修を準備しながら飛行を継続する。2018年11月から2019年3月までの737 MAXは、こうした暫定的リスク管理の下に置かれていた。

CASE BRIEFING

JT610後、FAAとボーイングはAOA異常に関連して意図しない水平安定板トリムが起き得ることを運航者へ通知した。FAAのEmergency AD 2018-23-51は、誤った高AOA入力が反復する機首下げトリムを生じさせ、適切に対処しなければ機体制御喪失につながり得ると警告した。

この時点でMCASというシステム名や機能は、事故以前より広くパイロットへ知られるようになった。ボーイングは運航マニュアルbulletinなどを通じて、意図しない機首下げトリムが発生した場合に既存のrunaway stabilizer non-normal procedureへ従うよう情報を提供した。

一方、事故調査は継続中で、KNKTの最終報告は翌2019年10月まで公表されない。AOAセンサーの校正、整備、MCASの設計・安全評価、認証、警報、乗員行動など事故全体の構造はまだ確定していなかった。

THE QUESTION

JT610後からET302までに、何が判明し、何が対策され、何が未解決のまま残ったのか。

この問いに答えるには、四つに分ける必要がある。

1. 認識された危険：誤AOA入力が意図しない反復機首下げトリムを生じさせ得る。
2. 即時対策：bulletin、Emergency AD、runaway stabilizer手順の再周知。
3. 準備中の恒久対策：MCASソフトウェアや表示・訓練の変更。
4. 残存リスク：設計改修がまだ各機へ実装されず、危険時の最終防護を乗員認識・手順へ大きく依存していた。

この構造を押さえると、「何もしていなかった」と「完全に対策済みだった」のどちらも正しくないことが分かる。

1｜事故直後、FDRが示した反復する機首下げトリム

JT610のFDR回収により、事故機で水平安定板が機首下げ方向へ自動的に動き、それに乗員の機首上げトリムが繰り返し対抗していたことが調査で明らかになった。誤ったAOA入力がMCASを作動させた可能性は、事故後比較的早い段階から重要な焦点になった。

ここで注意すべきなのは、FDRに「MCAS」というラベル付きの一行があるわけではないことである。調査側はセンサー値、トリム指令、操縦入力、システム設計情報を組み合わせて、どのロジックがどの動きを作ったかを解析する。

事故直後には最終的なcontributing factorsの全体像は未確定だったが、「AOA異常と意図しない機首下げトリム」という危険経路は、運航者へ直ちに知らせるべきほど具体的になっていた。

2｜ボーイングの運航情報――既存手順を使うという考え

ボーイングは737 MAX運航者へOperations Manual Bulletinを出し、誤ったAOA入力に関連する意図しない機首下げトリムが発生した場合、既存のrunaway stabilizer手順を用いるよう説明した。

この対策の前提は明確である。MCASの詳細ロジックをその場で診断しなくても、乗員が「意図しないスタビライザー・トリム」と認識し、電動トリムを止め、必要に応じてcutout switchで電動系を切り離せれば危険を管理できるという考え方だ。

前日のJT610事故機が実際にcutoutで着陸していたことも、この考えに一定の現実性を与える。一方、翌日の事故便では同じ防護が成立しなかった。したがって「手順が存在する」ことと「事故時環境で確実に実行できる」ことは同じではない。

3｜FAAのEmergency ADは何を警告したか

2018年11月7日、FAAはEmergency ADを発行した。ADは法的強制力を持つ耐空性指令であり、単なるメーカー推奨文書ではない。FAAは、誤ったAOA入力によって水平安定板が機首下げ方向へ繰り返しトリムされる可能性を説明し、適切に対処されなければ機体制御喪失につながるとした。

ここで「FAAはMCASの危険を知らなかった」とは言えない。少なくともこの時点で、AOA関連の意図しない反復トリムが重大な危険であることは公的文書へ明記された。

しかし同時に、FAAは全737 MAXのgroundingを命じなかった。ADは手順・マニュアルの更新によって危険を緩和可能と判断する枠組みだった。つまり規制当局は、機体を直ちに飛行不能とするのではなく、乗員が既存手順で対応できることを重要な安全層として残した。

4｜「MCASを知らなかった」状態は事故後に変わった

JT610以前、多くの737 MAXパイロットにとってMCASは通常訓練で詳細に扱われる主要システムではなかった。事故後、bulletinとADによってMCASに関連する異常と対応が運航現場へ広く伝わった。

この変化は重要である。ET302乗員は、JT610以前の乗員と同じ情報環境にいたわけではない。エチオピア航空にもボーイングやFAA由来の情報が提供され、NTSBは後のコメントで、運航会社へ複数の文書・連絡が送られたことを具体的に指摘している。

だからET302を「MCASの存在を誰も知らないまま同じ事故が繰り返された」と説明するのは正確ではない。二度目の事故では、MCAS関連の異常について業界全体の知識は増えていた。それでも事故は起きた。ここに、情報提供だけでは十分な防護にならなかったという重い意味がある。

5｜なぜ直ちに全機改修ではなかったのか

航空機で安全上の問題が見つかった場合、規制当局には複数の選択肢がある。飛行を完全に禁止する、運航制限を設ける、検査を義務付ける、部品を交換する、手順変更で暫定的に対応する、一定期限までに設計変更を求める、などである。

どの措置を選ぶかは、故障の発生確率、結果の重大性、検出可能性、既存の防護、改修の準備状況などで決まる。JT610後には、誤作動が起きてもrunaway stabilizer手順で対処できるという防護が重視された。

この判断は、後にNTSBやJATRなどが問題視する「パイロットの迅速な対応を安全評価へどう組み込むか」という論点と直接つながる。人間の操作を防護層として使うこと自体が誤りなのではない。問題は、複数警報が同時に発生する現実の状況で、その対応をどれほど確実な層として評価できるかである。

6｜ソフトウェア変更は計画されていた

JT610後、ボーイングはMCASソフトウェア変更を進めた。事故時仕様の単一AOA入力依存や反復作動などを改める方向で修正作業が行われた。

しかしET302が2019年3月10日に墜落した時点で、その改修は世界の運航中737 MAXへ実装されていなかった。ここが二事故間の期間を理解するうえで重要である。「改修計画が存在した」ことと「事故機へ改修が実装済みだった」ことは別である。

設計変更には開発、検証、認証、ソフトウェア適合性確認、運航者への導入などが必要で、重大システムを数日で書き換えて配布することはできない。それでも、危険度が高いと判断されれば、改修完了まで運航を止める選択肢もある。2018年11月時点ではその判断は採られず、暫定手順で運航が続けられた。

7｜リスク評価と「一件の事故」の重み

商業航空では、単一の全損死亡事故が起きたからといって、同型機が必ず即時groundingされるわけではない。事故原因が個別機の整備、運航環境、テロ、天候など型式共通性の低い要因かもしれず、利用可能な証拠に基づき判断する必要がある。

JT610では新型機の飛行制御機能が事故経路へ関与した可能性が早くから浮上したため、通常以上に重大な問題だった。しかし当時は、既存手順による対応が有効な防護として評価され、同型機を即時停止するほどの「制御不能な共通危険」とまでは規制判断されなかった。

この判断が適切だったかは、後の監査・議会調査・技術レビューで厳しく検討された。ただし歴史記述では、後のET302を知っている現在の視点から「二件目は当然予見できた」と断言するのではなく、当時の証拠とリスク評価の構造を示す必要がある。

8｜2019年3月10日、暫定防護が破れた

ET302では、離陸直後にAOA不一致とスティックシェーカーが発生し、MCASによる機首下げトリムが作動した。乗員は電動トリムで対抗し、cutout switchも使用した。それでも飛行は回復しなかった。

この事実は、JT610後の暫定対策について二つのことを示した。第一に、運航者へ情報が提供され、cutout手順が周知されていても、実際の事故環境では危険を確実に封じ込められない可能性があった。第二に、同じ型式で類似したAOA/MCAS経路を伴う死亡事故が二件発生したことで、「個別事故」ではなく「型式共通の設計問題」というリスク認識が急速に強まった。

これが世界的groundingへつながる。

9｜各国はFAAより先に止め始めた

ET302事故後、中国、欧州など各地の当局・航空会社が737 MAXの運航停止を始めた。FAAは当初、利用可能なデータに基づき継続運航可能との立場を維持したが、追加情報を評価し、2019年3月13日にEmergency Order of Prohibitionを発行して米国内の運航も停止した。

ここは「FAAだけが安全を無視して最後まで飛ばそうとした」という物語にするべきではない。各当局はそれぞれの法的権限とリスク基準で判断し、情報は時間とともに増えた。一方、米国が設計国当局であり、世界最大級の737 MAX運航市場を抱えていたことから、FAAの判断が強く注目されたのも事実である。

groundingは原因確定の宣言ではない。調査が完了するまで「共通の危険が排除されたと確認できない」ことを理由に運航を止める予防措置である。

10｜二事故間の期間が後の認証改革へつながった理由

二事故間の約4か月は、737 MAX問題の制度的評価で重要な期間になった。最初の事故から得られた情報が、メーカー、FAA、運航会社、パイロットへどのように伝わり、どの程度のリスクとして扱われたかを検証できるからである。

DOT OIGや米下院調査は、MCASの安全評価・情報共有・FAAの監督などを検証し、認証プロセス上の弱点を指摘した。JATRも、人間要因、統合システム評価、changed-product ruleの適用、delegationを含む改善を勧告した。

つまり「JT610後に何が行われたか」は単なる事故対応史ではない。最初のシグナルを航空安全システムがどう受け取り、暫定対策をどの程度信頼し、恒久対策までの期間をどう管理したかという、リスク管理のケーススタディになった。

11｜二つの極端な説明を避ける

二事故間をめぐっては、二つの極端な説明がある。

一つは「危険は完全に分かっていたのに、利益のために何もしなかった」という説明。実際にはbulletin、Emergency AD、訓練・マニュアル更新、ソフトウェア改修作業などが行われているため、「何もしなかった」は事実に反する。

もう一つは「原因は何も分かっていなかったから、運航継続に問題はなかった」という説明。これも、FAA ADが誤AOAによる反復機首下げトリムと機体制御喪失リスクを明記していた以上、正確ではない。

事実に近いのは、その中間ではなく、より具体的な記述である。重大な危険経路は認識され、手順ベースの暫定対策が採られ、設計改修は進められていた。しかし恒久改修前の機体は運航を続け、その暫定防護がET302で十分に機能しなかった。

EVIDENCE STATUS｜なぜ「groundingしなかった判断」を一語で評価できないか

規制当局がgroundingを選ぶかどうかは、単に事故の重大さだけで決まらない。型式共通性、故障発生頻度、検出可能性、既存手順の有効性、追加措置によるリスク低減、代替設計の準備状況などを組み合わせて判断する。JT610後、FAAは異常AOAと反復トリムを重大なunsafe conditionとしてADへ記載した一方、既存手順で制御可能と評価し、即時groundingではなく手順改訂を選んだ。

この判断の妥当性は、ET302後の結果を見れば厳しく再検討されるべき対象になった。しかし「FAAが利益を優先したから」と動機だけで説明するには別の証拠が必要である。公的レビューが確認したのは、リスク評価、人間性能仮定、情報共有、認証監督などの具体的な制度上の弱点である。

暫定対策と恒久対策の設計思想

安全対策では、危険を認識してから恒久改修が完了するまでの「暫定状態」をどう管理するかが重要になる。製造設備なら、ソフト改修まで設備停止にする、速度を落とす、追加監視を置く、手動運転へ切り替える、といった選択肢がある。航空機でも同様に、運航停止、運用制限、点検、手順、訓練などを組み合わせる。

737 MAXでは、JT610後の暫定対策は主として「異常時に乗員が既存runaway stabilizer手順を実行する」ことへ依存した。恒久対策としてMCASソフト変更が進められたが、その間も運航は継続された。結果として、暫定対策の信頼性評価が事故後の重要論点になった。

ET302は同じ失敗の単純再現ではない

ET302乗員は、JT610以前より多くの情報を持つ環境にいた。cutout switchも実際に使用した。それでも事故になった。この点は、「情報を出せば危険は管理できる」という想定の限界を示す。

一方でET302では高速化、推力、手動トリム、cutout switchの再投入などJT610と異なるシーケンスもある。したがって二事故を完全に同じ失敗のコピーとみなすこともできない。共通する設計failure pathと、各事故固有の運航・人間要因を分ける必要がある。

二事故間における情報の非対称性

メーカー、FAA、運航会社、個々のパイロットが持っていた情報は同じではない。設計者はMCASの詳細ロジックを知る。規制当局は認証資料を持つ。航空会社はbulletinとADを受け取る。乗員は訓練・マニュアル・運航通知を通じて必要情報を得る。この情報階層で、どこまで詳細を下流へ渡すべきかはhuman factorsと運用設計の問題になる。

JT610後、MCASの存在と対応は以前より明確に伝えられたが、事故時の複雑な警報環境を乗員がどのように認識するかまで情報だけで保証することはできなかった。設計変更なしに説明だけで安全余裕を回復できるかという問題が残った。

時系列補足｜2018年11月から2019年3月までに積み上がった材料

二事故間には、単に時間が経過しただけではなく、調査データ、運航情報、設計変更案、パイロット教育が少しずつ増えていった。事故直後はFDR/CVR解析と残骸調査が中心で、11月には運航者向けbulletinとFAA ADが出た。その後、ボーイングはMCAS変更を準備し、航空会社や当局との技術調整が進んだ。しかし、この間に全世界のMAXへ恒久改修が実装されたわけではない。

この「知識は増えているが、機体の物理的状態は事故時仕様のまま」という非対称性が重要である。乗員側の情報防護は強化されたが、機械側のfailure pathは残った。安全余裕を人間側の改善でどこまで補えるかという判断が、ET302で実地に試されることになった。

リスクコミュニケーションの論点

メーカーから航空会社へ情報を出すだけでは、個々の乗員が同じレベルで理解できるとは限らない。運航会社はbulletinを自社マニュアルや訓練へ落とし込み、パイロットは日々多数の改訂情報を消化する。重大情報ほど、単なる文書配布ではなく、訓練シナリオ・理解確認・手順改訂を通じて定着させる必要がある。

737 MAXでは、事故前にMCASがほぼ意識されない機能だったところから、事故後数週間で緊急に新しい異常対応知識として現場へ追加された。この急激な情報更新が、どの程度実際の操縦技能へ変換されたかもhuman factorsの一部である。

「暫定対策で運航継続」の一般的な難しさ

安全上の不具合が見つかったとき、恒久改修まで全システムを止めると社会的・経済的影響が大きい。一方、暫定対策を選ぶなら、その対策が現場条件でどれほど確実に実行できるかを厳しく見積もる必要がある。手順依存の対策は導入が速いが、人間の認知・訓練・作業負荷のばらつきを含む。

JT610後の判断は、この典型的トレードオフだった。設計改修より早く展開できる手順変更を採用したが、その信頼性評価が二事故後に再検討された。ここから得られる教訓は、暫定対策の存在そのものではなく、その残余リスクを定量・定性的にどう評価し、いつ運航停止へ切り替えるかの基準を持つことである。

判断補足｜Emergency ADが意味したもの

Emergency ADは「安全上の問題が解決した」という証明ではなく、既存機を当面運航するために遵守を義務づける暫定的なリスクコントロールだった。ADで手順を再確認させることと、MCASのfailure pathそのものを設計変更で除去することは安全工学上の層が異なる。したがって二事故間を評価する際は、規制当局が危険を認識していなかったか否かだけでなく、認識した危険に対して選んだmitigationの強度、その有効性を裏付けるhuman-factors前提、恒久改修までの残余リスク管理を分けて検討する必要がある。

結論｜4か月は「無対策」でも「解決済み」でもなかった

JT610後、航空業界はMCAS関連の危険を初めて明示的に共有した。ボーイングはbulletinを発行し、FAAはEmergency ADで反復する機首下げトリムとその対応を義務付けた。したがって二事故間を無対策期間と呼ぶのは正確ではない。

一方、その対策は事故時仕様のMCASを各機から除去・改修するものではなく、主として乗員の認識と既存手順を最後の防護層として利用する暫定策だった。恒久的なソフトウェア変更は準備されていたが、ET302事故時にはまだ実装されていなかった。

二度目の事故は、このリスク管理が十分ではなかったことを現実の結果として突き付けた。次の記事ではET302の飛行シーケンスを追いながら、事故後に公表されたEAIB最終報告と、NTSB・BEAが示した異論を分離する。「公式報告があるから議論は終わった」とも、「異論があるから何も分からない」ともしない。

FACT CHECK｜出典・参考資料

1. 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
2. Federal Aviation Administration, *FAA Updates on Boeing 737 MAX*, 2019–2021. https://www.faa.gov/newsroom/faa-updates-boeing-737-max-0
3. 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
4. U.S. Department of Transportation Office of Inspector General, *Weaknesses in FAA’s Certification and Delegation Processes Hindered Its Oversight of the 737 MAX 8*, 2021-02-23. https://www.oig.dot.gov/library-item/38302
5. Joint Authorities Technical Review / FAA, *Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations*, 2019-10-11. https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019
6. National Transportation Safety Board, *US Comments on Draft Aircraft Accident Investigation Report — Ethiopian Airlines Flight 302*, 2022-03. https://www.ntsb.gov/investigations/Documents/US%20comments%20ET302%20Report%20March%202022.pdf

RCF検証ノート

本稿は、JT610後に「何も対策されなかった」という主張と「危険はまだ何も分かっていなかった」という主張の双方を退け、FAA ADと運航情報に記録された当時の認識を基準にした。ET302乗員が事故前に利用可能だったMCAS関連情報についてはNTSBコメントも照合した。運航継続判断の動機について利益優先などを独自に断定せず、規制措置・暫定防護・未実装の恒久改修という検証可能な事実に限定した。

最終確認：2026年9月20日

END ARTICLE 05 / 08

NEXT FILE

CASE087-06｜エチオピア航空302便｜二度目の墜落事故と最終報告をめぐる争点

次の記事ではET302の飛行データと事故シーケンスを確認し、EAIB最終報告、NTSBコメント、BEAコメントを「同じ結論」に混ぜず、どこが一致しどこが争点なのかを分けて扱う。

RELATED FILES

• CASE087-04｜JT610――最初の事故で確認された共通経路
• CASE087-06｜ET302――二度目の事故と調査機関間の見解差
• CASE087-07｜認証制度――二事故後の制度レビュー

エチオピア航空302便｜二度目の墜落事故と最終報告をめぐる争点

2019年3月10日、エチオピア航空302便（ET302）はアディスアベバのボレ国際空港を離陸し、ケニア・ナイロビへ向かった。機体はBoeing 737-8 MAX、登録記号ET-AVJ。離陸直後から機長側のスティックシェーカーが作動し、左右のAOA値には大きな不一致が生じた。数分後、機体は高速のまま地表へ衝突し、157人全員が死亡した。

約4か月前のJT610と同じ型式で、離陸後にAOA異常、スティックシェーカー、MCASによる機首下げトリムという共通する経路が現れた。これにより737 MAXの問題は一つの航空会社・一つの機体固有の事故ではなく、型式共通設計に関わる可能性が急速に高まった。

しかしET302には、事故後の調査でさらに難しい問題が残った。エチオピアのAircraft Accident Investigation Bureau（EAIB）は2022年12月に最終報告を公表したが、米NTSBとフランスBEAは分析の一部、とくに人間要因・乗員行動・AOAセンサー損傷の説明などについて異論を示した。NTSBは自らの最新コメントが最終報告へ適切に添付されなかったとも公表している。

したがってET302を扱う際には、「最終報告に書かれているからすべて確定」とすることも、「調査機関が争っているから原因不明」とすることも避ける必要がある。飛行データで確認できる事実と、それをどう因果評価するかという解釈を分ける。

CASE BRIEFING

ET302事故の調査は、事故国であるエチオピアのEAIBがICAO Annex 13に基づいて主導した。機体の設計・製造国である米国からNTSB、フランスからBEAなどがaccredited representativeとして参加した。

この仕組みでは、事故調査の最終報告を発行する責任は調査主導国にある。他国の参加機関は技術支援やコメントを行うが、最終的な文書の内容は主導機関が決める。意見が一致しない場合、Annex 13の手続きではコメントの扱いが重要になる。

ET302では、この「報告書の本文」と「参加機関の異論」の両方が公的資料として残った。そのため読者は、一つの文書だけでなく、EAIB、NTSB、BEAの立場を照合できる。

THE QUESTION

ET302では何が起き、どの部分が事実として一致し、どの部分で調査機関の解釈が分かれたのか。

一致している大枠は明確である。離陸後に異常なAOA入力が発生し、機長側のスティックシェーカーなど複数の異常が現れ、MCASが機首下げトリムを作動させた。乗員は電動トリムで対抗し、後にstabilizer trim cutout switchをCUTOUTへ移した。機体は高速度となり、手動トリムで状態を回復することが困難になった。後にcutout switchが再びNORMALへ戻され、機首下げ方向の電動トリムが再度入った。

争点は、この一連の中で各要素へどの因果的重みを置くか、AOA異常の物理的起点をどう説明するか、乗員の速度・推力・トリム操作をどこまで分析・原因評価へ含めるかである。

1｜離陸直後からAOA値が大きく分かれた

ET302は現地時間午前8時38分ごろ離陸した。離陸直後、左右AOAセンサーの値が大きく分かれ、機長側のスティックシェーカーが作動した。速度・高度などにも不一致が現れ、乗員は低高度の上昇中に複数の異常へ直面した。

ここはJT610と重要な共通点を持つ。ただしセンサー異常の物理的原因は同じとは限らない。JT610では交換された左AOAセンサーの校正問題が調査で明確になった。一方、ET302のAOAセンサーがなぜ異常値を出したかについては、NTSBとEAIBの評価に差がある。

NTSBはコメントで、利用可能な証拠はAOAベーンへの異物・鳥などの衝突損傷を支持すると主張した。EAIB最終報告の扱いはそれと完全に同じではないため、本稿では「鳥衝突が確定原因」とは書かない。

2｜最初のMCAS作動と乗員の対抗

フラップ格納後、異常に高いAOA入力を受けたMCASが作動し、水平安定板を機首下げ方向へトリムした。乗員は操縦桿を引き、電動トリムで機首上げ方向へ戻す操作を行った。

この点でもJT610と類似する。MCASの機首下げ指令に対し、パイロットの電動トリムは一時的にそれを止め、水平安定板を戻すことができる。しかし異常AOAが残れば、事故時仕様では条件再成立後にMCASが再作動し得た。

ET302乗員はJT610後に発行された情報をまったく知らない状態ではなかった。運航会社にはボーイングのbulletinやFAAのEmergency ADが提供されていた。これが二つの事故を比較する際の重要な違いである。

3｜cutout switchを使った後も問題は終わらなかった

ET302乗員はstabilizer trim cutout switchをCUTOUTへ移し、電動トリムを切り離した。これはJT610後の手順で示された重要な対応だった。

しかし、この時点で水平安定板はすでに機首下げ側へトリムされ、機体速度も上昇していた。電動トリムを切ると自動トリムは止まるが、水平安定板が望ましくない位置にあれば手動トリムホイールで戻す必要がある。高速では水平安定板へ作用する空気力が大きく、手動ホイールを回す力が非常に大きくなり得る。

EAIB最終報告は、この状況で乗員が手動トリムを十分使えなかった背景を機体側の問題として強く扱った。NTSBは一方、手動トリム系統自体が機械的に故障していたことを示す証拠はないとし、速度・空気力、乗員操作、訓練の観点をより詳しく分析すべきだとした。

4｜推力と速度がなぜ争点になったのか

ET302では離陸後にautothrottleが高い推力を維持し、機体速度が増加した。速度が上がると空力荷重が増え、操縦桿を引く力や手動トリムホイールを回す力も大きくなり得る。

NTSBはコメントで、airspeed unreliableやrunaway stabilizerの手順に沿うならautothrottleを解除し、推力を手動で下げる操作が想定されると指摘した。またFDRでは手動電動トリムの使用が限定的だったとして、人間性能の観点からその理由を分析すべきだと主張した。

これは「パイロットのせいだった」という意味ではない。NTSB自身もuncommanded MCAS inputsをprobable causeへ含めることに同意している。争点は、事故を再発防止へつなげるためには、設計故障だけでなく、なぜ乗員が利用可能な手順・操作をその通り実施できなかったのかも分析する必要がある、という点である。

5｜なぜcutout switchをNORMALへ戻したのか

事故の終盤、乗員はstabilizer trim cutout switchを再びNORMAL側へ戻した。これにより電動トリムが再び使用可能になった。その後、機首下げ方向の電動トリムが入り、機体は急激な降下へ向かった。

なぜ乗員がスイッチを戻したのか、利用可能な証拠だけで心理を断定することはできない。手動トリムで水平安定板を十分戻せず、電動トリムを使う必要を感じた可能性などが考えられるが、推測は事実と区別すべきである。

NTSBは、緊急ADとbulletinがcutout switchを飛行中そのままCUTOUTに維持するよう指示していた点を挙げ、この行動を人間要因の観点から分析すべきだとした。EAIBとの見解差が大きい箇所の一つである。

6｜EAIB最終報告は何を中心原因としたか

EAIB最終報告は、異常なAOA入力と、それによって作動したMCASの反復機首下げ指令を事故の中心的原因として位置付けた。報告は737 MAXのMCAS設計、AOA入力への依存、乗員が受けた複数警報・操縦困難などに重点を置く。

この大枠について、NTSBやBEAもMCASの事故への寄与自体を否定していない。したがって「EAIBだけがMCASを問題視し、他国はパイロットエラーだと言っている」という対立構図は誤りである。

実際の相違はより細かい。MCAS・AOA異常を事故原因へ含めることに加え、乗員の推力管理、電動トリムの使用、cutout後の行動、訓練や人間性能をどの程度分析し、安全勧告へ反映するべきかという点で評価が分かれた。

7｜NTSBは何に異議を唱えたのか

NTSBは2022年3月の詳細コメントで、EAIBドラフトが人間性能・乗員行動を十分に分析していないと主張した。具体的には、manual electric trimの使用、airspeedと手動トリム力の関係、autothrottleと推力、cutout switchをNORMALへ戻した理由、運航会社の訓練などを挙げた。

またNTSBは、AOAベーンへの衝突損傷が異常入力の根本原因として証拠に支持されるとの立場を示した。EAIB最終報告の記述がこの評価を十分採用していない点にも異論を述べた。

2022年12月27日、NTSBはEAIB最終報告に自らが要求した最新コメントが添付されず、古いコメントへのリンクが含まれていたとして、最新コメントを独自に公開した。この手続き上の問題も、ET302の報告を読む際には無視できない。

8｜BEAも「MCASかパイロットか」という二択にはしていない

フランスBEAも調査参加機関としてコメントを公表した。BEAはMCASと関連警報が事故に重要な役割を果たしたことを認めながら、乗員行動や人間要因をより深く分析し、そこから安全上の教訓を引き出す必要があるという立場を示した。

ここでも、設計原因と運航・人間要因を競合する説明として扱わないことが大切である。複雑な事故では、設計故障が最初の異常を作り、人間がその異常へ対応し、機体状態がさらに変化し、その後の操作可能性が狭まる。原因は時間軸上で相互作用する。

「MCASが悪いならパイロット分析は不要」「パイロット操作に改善余地があれば設計問題は小さい」という二択は、安全調査の目的に合わない。

9｜確定事実と解釈を分ける

ET302について、比較的強い確度で書ける事実には次がある。

• 離陸直後に左右AOA値が大きく不一致になった。
• 機長側スティックシェーカーが作動した。
• MCASによる機首下げ方向トリムが発生した。
• 乗員は電動トリムで対抗した。
• 乗員はstabilizer trim cutout switchをCUTOUTへ移した。
• 機体速度が高くなり、手動トリムが困難な状況になった。
• その後cutout switchがNORMALへ戻された。
• 再び機首下げ方向の電動トリムが生じた。

一方、異常AOAの物理的起点をどう確定するか、乗員行動をprobable cause/contributing factorへどう位置付けるか、特定の手動トリム困難を設計・訓練・速度管理のどこへ重く置くかは、調査機関間で解釈差がある。

この区別を明示することが、読者に「何が分かっているか」と「何が議論されているか」を同時に示す。

10｜二度目の事故がgroundingを決定的にした

ET302の事故直後、各国当局は737 MAXを相次いで運航停止にした。二つの事故の類似性が判明するにつれ、単一航空会社・単一整備組織に閉じた問題ではなく、型式設計に共通する危険である可能性が強まった。

FAAも2019年3月13日にEmergency Order of Prohibitionを発行し、米国内の737 MAX運航を停止した。ここから737 MAXは約20か月にわたる再設計・再評価へ入る。

ET302は、JT610後に採られた手順中心の暫定対策が十分ではなかったことを示した。同時に、事故後の分析は「設計を直せば終わり」ではなく、認証、人間性能、訓練、運航、警報の評価へ広がった。

11｜事故報告書に異論があることは「調査失敗」ではない

事故調査では、同じFDR・CVR・残骸・試験データを見ても、因果関係の重み付けや安全勧告の焦点で専門家が異なる結論を持つことがある。Annex 13の仕組みは参加国のコメントを扱う手続きを設けている。

ET302では、その違いが公的文書として可視化された。これは読者にとって不便だが、むしろ証拠評価の透明性という意味では重要である。最終報告を絶対視せず、同時に参加機関のコメントを「真の最終結論」として置き換えもしない。各文書がどの権限・立場で何を主張しているかを分ける必要がある。

RCFでは、EAIBを事故調査のfinal report authorityとして尊重しつつ、NTSB/BEAの正式コメントをdisputed claim layerとして併記する。

EVIDENCE STATUS｜調査機関の不一致をどう読むか

EAIB、NTSB、BEAの見解差は、事故の基本事実がすべて争われているという意味ではない。FDR/CVRに基づく主要な飛行シーケンス、異常AOA、MCAS作動、cutout操作、高速化、最終的な制御喪失という大枠には広い共通認識がある。相違は主として、各要素をどの程度因果評価へ組み入れるか、その根拠をどう解釈するかにある。

事故調査報告で「probable cause」や「contributing factor」と位置付けることは、単なる時系列記述より強い評価である。そのため、同じ事実を認めていても原因文の書き方は機関間で異なり得る。RCFではこの違いを、どちらかを勝者として選ぶのではなく、主張主体を明示して並べる。

手動トリムが「使えなかった」のか「使われなかった」のか

ET302で特に重要な表現差がここにある。高速時に手動トリムホイールを回す力が大きくなり、乗員が実際に困難へ直面したことは重要である。しかし、これを「手動トリム系統が機械的に故障していた」と表現するのか、「系統は機能していたが空力荷重と運航状態のため実用上極めて困難だった」と表現するのかで意味は大きく変わる。

NTSBは、FDR等からmanual electric trim system自体の故障を示す証拠はないとし、速度とair loads、乗員の電動トリム使用、訓練を分析するよう求めた。したがって本稿では、手動トリム困難を事実として扱いつつ、機械故障が確定したとは書かない。

AOAセンサー損傷の起点

NTSBはAOAベーンへの物体衝突を支持する証拠を挙げたが、EAIB最終報告はその説明を同じ確度で採用していない。この違いは事故の主要な設計問題を否定するものではない。センサーが鳥で壊れたとしても、単一センサー故障がMCAS反復作動へ進んだ設計問題は残るからである。

逆に、AOAセンサーの物理的故障原因が確定しなくても、飛行中に異常値が発生したこと自体はFDR等から強く支持される。安全設計は原因不明のセンサー故障も含め、入力が不正になり得ることを前提にする。

CVR/FDRが教えることと教えないこと

飛行記録は機体状態や多くの操作を高い精度で示すが、乗員が「なぜその操作を選んだか」という心理を直接記録するわけではない。CVRに会話が残っていても、すべての判断過程が言語化されるわけではない。

そのため、cutout switchをNORMALへ戻した理由などについて、調査者は機体状態・手順・会話・訓練情報から推論する必要がある。ここに解釈差が生じる余地がある。RCFでは、記録された操作と、その動機についての推定を文法上も分ける。

人間要因補足｜高負荷時に「正しい手順」が実行される条件

手順書に正しい操作が書かれていることと、実際の事故環境でその操作が再現されることは別である。ET302では離陸直後にスティックシェーカー、速度・高度不一致、MCAS作動、管制通信、上昇・進路管理が重なった。さらに機体が高速化すると、操縦桿や手動トリムへ必要な力そのものが変化した。

人間要因分析では、乗員が「知っていた／知らなかった」だけでなく、どの情報が目立ったか、タスク優先順位、二人の役割分担、手順へのアクセス時間、物理的操作力、訓練で経験した故障像との一致度を見る。NTSBがEAIBへ追加分析を求めたのは、こうした条件を事故再発防止へ反映するためである。

事故原因文と安全勧告は別の目的を持つ

probable causeの文は事故を説明するが、安全勧告は将来事故を減らすための行動につなげる。ある要素を「主原因」と呼ばない場合でも、改善余地があるなら安全勧告対象にできる。逆に主原因とされた設計欠陥を直すだけで、他の回復機会を改善しなくてよいわけではない。

ET302でNTSB/BEAが人間要因を強く求めたのは、MCAS責任を薄めるためと決めつけるべきではない。事故時の設計failure pathを是正した後でも、将来別のstabilizer trim故障が起こる可能性はある。そのとき乗員が速度・推力・trimを適切に管理できる訓練を整備することには独立した安全価値がある。

Annex 13コメントの意味

国際航空事故調査では、設計・製造国、運航国、登録国などが調査へ参加し、ドラフト報告へコメントできる。最終報告主導国がすべてのコメントを採用する義務があるわけではないが、採用しない重要コメントの扱いには透明性が求められる。

ET302でNTSBがコメント公開を行ったことは、事故調査の権限争いとしてのみ見るべきではない。読者が最終報告本文だけでは見えない技術的反論を確認できる資料になっている。本CASEでは、この手続き上の文脈を示すことで「NTSBコメント＝EAIB報告の訂正版」という誤解も避ける。

Known / Unknown｜事故後も残る不確実性

Knownとして扱えるのはFDR/CVR、残骸、試験で支持されるシーケンスである。UnknownまたはDisputedとして残すべきなのは、AOAベーン損傷の正確な起点、特定の乗員判断の心理的理由、各因子の最終的な因果重みである。不確実性を明示することは記事の弱さではない。むしろ、証拠が示す範囲を超えて断定しないことが事故調査記事の品質条件になる。

証拠評価補足｜一致点と不一致点を同じ重さで扱わない

EAIB、NTSB、BEAの見解が異なるからといって、事故シーケンス全体が不明という意味ではない。FDRが示す異常AOA、MCASに整合するstabilizer movement、乗員のtrim操作など、複数当事者が概ね共有する事実がある。その上で、AOAベーン損傷の起点や乗員行動の評価、因果要因として何をどこまで強調するかに差がある。記事では「合意された観測事実」「そこからの技術的推論」「調査機関ごとの評価」の三層を分けることで、見解差を過大にも過小にも扱わない。

結論｜ET302では「共通経路」と「評価差」の両方が残った

ET302はJT610と同様、異常AOA入力からMCASの機首下げトリムへ進む共通経路を持っていた。乗員は電動トリムで対抗し、cutout switchも使用したが、機体は高速化し、手動トリムが困難な状況へ進み、最終的に制御を失った。

この共通経路は737 MAXの型式共通問題を明確にし、世界的groundingを決定づけた。一方、事故の全因果をどう表現するかではEAIB、NTSB、BEAに差が残る。特に乗員行動、人間要因、AOAセンサー損傷、手動トリムの評価は同一ではない。

したがってET302を「MCASだけで説明できる事故」または「パイロットエラーだった事故」のどちらかへ固定するのは、公開された公的証拠に忠実ではない。次の記事では、なぜそもそも単一AOA入力・MCAS権限・乗員対応仮定が認証プロセスを通過したのか、FAAとODAの構造へ移る。

FACT CHECK｜出典・参考資料

1. Aircraft Accident Investigation Bureau of Ethiopia (EAIB), *Aircraft Accident Investigation Report B737-MAX 8, ET-AVJ, Ethiopian Airlines Flight 302*, 2022-12-23. https://bea.aero/fileadmin/user_upload/ET_302__B737-8MAX_ACCIDENT_FINAL_REPORT.pdf
2. National Transportation Safety Board, *US Comments on Draft Aircraft Accident Investigation Report — Ethiopian Airlines Flight 302*, 2022-03. https://www.ntsb.gov/investigations/Documents/US%20comments%20ET302%20Report%20March%202022.pdf
3. National Transportation Safety Board, *NTSB Releases Comments on Ethiopia’s Investigation of the Boeing 737-8 MAX Accident*, 2022-12-27. https://www.ntsb.gov/news/press-releases/Pages/NR20221227.aspx
4. Bureau d’Enquêtes et d’Analyses (BEA), *Accident to Boeing 737 ET-AVJ near Bishoftu — investigation page and BEA comments*, 2023-01. https://bea.aero/en/investigation-reports/notified-events/detail/accident-to-the-boeing-737-registered-et-avj-and-operated-by-ethiopian-airlines-on-10-03-2019-near-bishoftu-investigation-led-by-eaib-ethiopia/
5. Federal Aviation Administration, *FAA Updates on Boeing 737 MAX*, 2019–2021. https://www.faa.gov/newsroom/faa-updates-boeing-737-max-0

RCF検証ノート

本稿ではEAIB最終報告を事故調査主体のAuthorityとしながら、NTSB・BEAの正式コメントを独立した異論として保持した。MCASの寄与自体について三機関が全面対立しているかのような表現は避け、主な相違が人間要因、乗員操作、AOA異常の起点、分析の十分性にあることを分離した。AOAベーンへの鳥・異物衝突説はNTSBの評価として帰属させ、確定事実へ昇格していない。

最終確認：2026年9月20日

END ARTICLE 06 / 08

NEXT FILE

CASE087-07｜737 MAXの認証はなぜ問題になったのか｜FAA・ODA・安全評価の構造

次の記事では「Boeingが自己認証した」という一言を使わず、FAA、ODA、changed-product certification、安全評価、MCAS情報共有を工程として分解する。

RELATED FILES

• CASE087-03｜MCASの技術構造――認証対象となった制御機能
• CASE087-05｜JT610後の暫定対策――認証後のリスク管理
• CASE087-07｜FAA・ODA・安全評価――制度上の防護層

737 MAXの認証はなぜ問題になったのか｜FAA・ODA・安全評価の構造

737 MAX事故をめぐる議論では、「Boeingが自分で自分の飛行機を認証した」という表現がしばしば使われる。問題意識としては、メーカーへ認証業務が委任され、FAAの監督が十分だったのかという疑問を指している。しかし制度を正確に理解するには、この表現をそのまま事実として使うべきではない。

737 MAXの型式証明にはFAAが関与し、FAAがすべての評価をメーカーへ丸投げしたわけではない。一方で、米国の航空機認証制度ではOrganization Designation Authorization（ODA）などの仕組みにより、メーカー組織内の認定された担当者・組織がFAAに代わって一部の適合性確認や認証業務を行う。これは737 MAXだけの特例ではなく、大規模な航空機認証を処理するため長年用いられてきた制度である。

二事故後のJATR、DOT OIG、米議会などの調査が問題にしたのは、委任制度の存在そのものではなく、どの業務をFAAが保持し、どの業務を委任し、MCASの設計変更・危険度・統合影響がFAAへどの程度共有され、変更型式の認証で全体システムを十分評価できたかである。

したがって本稿では、「自己認証」という短い言葉を結論に使わない。型式証明、amended type certificate、changed-product rule、ODA、安全評価、human factorsという具体的な工程に分ける。

CASE BRIEFING

737 MAXはゼロから新しい型式証明を取得した航空機ではなく、既存737系列の型式証明を変更する形で認証された。2017年3月、FAAは737-8 MAXに対するamended type certificateを発行した。

派生型認証では、既存設計のすべてを現行基準で一から証明し直すのではなく、変更された部分とその影響を特定し、どの基準を適用するか判断する。この考え方は長く運用されてきたが、JATRは737 MAX事故後、複雑で統合されたシステム変更を評価する際に、個別変更だけを狭く見ると全体リスクを見落とし得ると指摘した。

同時にFAAは、認証作業の一部をBoeing ODAへ委任していた。DOT OIGは、FAAが認証プロセスには関与していた一方、delegationと監督、MCASに関する情報共有、ガイダンスに弱点があったと評価した。

THE QUESTION

737 MAXの型式証明・委任・安全評価のどこが、事故後に問題視されたのか。

主な論点は五つに整理できる。

1. MCASの設計が開発途中で拡張されたこと。
2. その変更の安全上の意味がFAAへ十分共有・再評価されたか。
3. 単一AOA入力と反復作動を含むfailure pathが適切に評価されたか。
4. パイロットが迅速に対応するという安全仮定が現実的だったか。
5. ODAへの委任とFAA監督が、複雑な統合システムの変化を把握する構造になっていたか。

これらは「FAAがいた／いなかった」という二択ではなく、認証システム内部の情報流と責任分界の問題である。

1｜型式証明とは何を確認する仕組みか

民間航空機を商業運航へ使うには、その設計が適用される耐空性基準を満たすことを認証当局へ示す必要がある。米国ではFAAが型式証明を発行する。メーカーは設計データ、解析、試験、適合性資料などを準備し、当局または委任された認証担当者が基準への適合を確認する。

これは「FAAが飛行機を設計する」仕組みではない。設計責任はメーカーにあり、認証当局は申請された設計が規則に適合しているかを確認する。複雑な旅客機では数十万点規模の部品・ソフトウェア・要求が関わるため、当局の職員だけで全項目を直接審査するのは現実的ではない。

そのため委任制度が存在する。重要なのは、委任しても最終的な認証権限・監督責任が規制当局から消えるわけではないことだ。

2｜ODAは「メーカーが自由に判子を押す制度」ではない

Organization Designation Authorizationでは、FAAが承認した組織が一定範囲の認証機能を代行する。Boeing ODAの担当者は企業内に所属するが、指定された認証機能を行う際にはFAAの規則と承認された手順に従う必要がある。

この制度の利点は、技術知識を持つ大規模メーカー組織の能力を活用し、FAAが重点項目へ資源を集中できることである。一方、潜在的なリスクとして、企業の開発・日程・コスト目標と、認証上の独立した判断との間に緊張が生じ得る。

事故後の調査では、Boeing ODA内部のエンジニアが十分な独立性を持てたか、FAAが委任された活動をどのように監督したか、重要な設計変更がFAAの直接関与領域から外れていなかったかが検証された。

したがって「自己認証」という言葉の代わりに、FAAが法的認証主体で、認証機能の一部をBoeing ODAへ委任していたと書く方が正確である。

3｜737 MAXはamended type certificateで認証された

737 MAXは737NGなど既存737系列との連続性を持つ派生型であり、既存型式証明を変更するamended type certificateとして認証された。この方式では、変更された設計部分とその影響を評価し、適用する基準を決める。

問題は、現代の航空機システムが高度に統合されていることである。一つの機能変更がセンサー、飛行制御、警報、人間操作へ広く影響する場合、「変更した部品だけ」を局所的に評価しても全体安全性を見失う可能性がある。

JATRは事故後、737 MAXのflight control systemをより統合された観点で評価する必要があったと指摘し、changed-product ruleの適用やsystem-level reviewを改善するよう勧告した。

4｜MCASは開発途中で機能が拡張された

MCASは当初から事故時と同じ仕様だったわけではない。開発試験の中で、作動する飛行領域が拡張され、水平安定板への指令権限も増えた。

設計変更自体は航空機開発では正常なことである。試験で新しいデータが得られれば制御則を変える必要がある。しかし、安全上重要なのは、変更に応じてsystem safety assessment、hazard classification、故障影響解析、認証当局への情報、乗員手順などが適切に更新されることだ。

DOT OIGは、FAAがMCASの進化について完全な理解を持つうえで情報ギャップがあったと評価した。後年のFAA規則資料も、調査機関がMCASの権限増加や作動条件拡張が十分開示・評価されなかった点を指摘したことを整理している。

5｜安全評価では「一回の作動」をどう見ていたか

システム安全評価では、故障が起きた場合の結果を分類し、その重大性に応じた設計保証を求める。MCASの意図しない作動についても、どの程度のハザードで、パイロットがどう対処できるかが評価された。

事故後の調査で問題になったのは、MCASの反復作動が危険を積み重ねる可能性が、安全評価で十分扱われていたかである。調査資料では、単一のMCAS作動を前提とした評価と、実際に異常AOAが続いて反復作動する事故シーケンスとのギャップが指摘された。

この違いは非常に大きい。一回の機首下げトリムならパイロットが戻して終わると評価できても、戻した後に再び同じ自動トリムが入り、しかも警報が複数同時に出るなら、乗員の認知負荷と累積トリム量は別の問題になる。

6｜人間を「故障検出器」としてどう扱ったか

737 MAXの安全評価では、意図しないMCAS作動が起きても、パイロットが異常を認識し、操縦桿や電動トリムで対抗し、必要に応じてrunaway stabilizer手順を使えることが重要な防護層だった。

この考え自体は航空設計で異例ではない。人間は航空機システムの一部として異常を検出し、手順で回復する。しかし、人間を安全評価へ含めるなら、反応時間、情報提示、警報数、作業負荷、訓練を現実的に評価する必要がある。

NTSBは二事故を受け、複数の警報・表示が同時に発生する状況でのパイロット性能を安全評価へ反映するよう勧告した。つまり問題は「パイロットを信用したこと」ではなく、想定した反応モデルが実際の事故環境を十分表していたかである。

7｜AOA DISAGREEと情報設計

事故ではAOAセンサーの異常が重要な起点だった。ところが737 MAXのAOA DISAGREE alertは、当初すべての機体で期待どおり表示される状態になっていなかった。ソフトウェア上、AOA indicator optionとの関係で表示条件が制約される問題があった。

この警報があれば事故を必ず防げたとは断定できない。しかし、左右AOAが大きく食い違うという根本異常を乗員と整備が認識するための情報として重要だった。

認証では、単に「機能が規則を満たすか」だけでなく、異常時に乗員へどの情報がどの優先度で提示されるかもhuman factorsの一部になる。NTSBのmultiple alerts勧告は、この情報設計全体へつながっている。

8｜FAAはMCASを知らなかったのか

「FAAはMCASの存在すら知らなかった」という言い方も正確ではない。FAAは737 MAX認証へ関与し、MCASを含む設計資料も認証プロセスの対象だった。

問題は、MCASの最終的な作動権限や条件、故障時の全体影響について、FAA内の関係者がどこまで最新・統合された理解を持っていたかである。DOT OIGは、FAAがBoeingのMCAS安全評価に関する重要情報を十分に把握できなかった点や、認証ガイダンス・delegation oversightの弱点を指摘した。

したがって「知らなかった／知っていた」という一語ではなく、情報が存在していても、必要な担当者へ適切な粒度とタイミングで届き、再評価へ結び付いたかを見る必要がある。

9｜議会調査が指摘した組織上の圧力

米下院運輸・インフラ委員会多数派スタッフの最終報告は、737 MAX開発・認証に関し、技術的欠陥だけでなく、スケジュール・コスト・生産圧力、内部コミュニケーション、FAAとの関係を強く批判した。

この報告は重要な一次的公的調査資料だが、事故調査報告やFAA監査とは役割が異なる。多数派スタッフによる議会調査であり、政策的・評価的な言葉も含む。そのため、企業文化や利益動機に関する結論は「委員会報告がこう評価した」と帰属させる必要がある。

一方、内部文書や具体的な意思決定記録が存在する場合は、それ自体を事実として検討できる。RCFでは、評価と証拠を同じ文法で混ぜない。

10｜JATRが求めたのは統合システムとしての再評価

FAAが招集したJoint Authorities Technical Reviewには、FAAだけでなくNASAや複数国・地域の航空当局が参加した。JATRは737 MAXのflight control systemと認証を技術的にレビューし、設計変更、human factors、delegation、changed-product certificationなど幅広い勧告を行った。

特に重要なのは、個別機能をバラバラに認証するのではなく、統合された飛行制御システムとして安全を評価する考えである。AOAセンサー、MCAS、警報、スタビライザー、パイロットが相互に作用するなら、それらを個別部品の適合性だけでなく「一つの機能連鎖」として評価する必要がある。

この考え方は、事故の実際の姿とも一致する。事故はMCASコードだけ、AOAセンサーだけ、パイロットだけで起きたのではなく、その間のインターフェースで拡大したからである。

11｜認証制度の問題と機体の安全性を混同しない

認証プロセスに弱点が見つかったからといって、認証されたすべての機体が危険だという意味にはならない。逆に、認証手続きに従っていたからといって、設計安全性が自動的に保証されるわけでもない。

737 MAXでは、事故という実結果が設計と認証の前提に重大な問題があったことを示し、その後の監査・レビューでプロセス上の弱点が具体化された。制度評価は事故原因分析を補強するが、制度の欠陥そのものが直接水平安定板を動かしたわけではない。

この区別を保つと、原因の層が整理できる。直接的な事故経路はAOA入力と飛行制御。設計レベルではMCASの仕様と防護。組織・制度レベルでは安全評価、情報共有、認証監督。その各層が別の再発防止策を必要とする。

12｜事故後に何が制度面で変わったか

二事故後、FAAは737 MAXの運航再開審査で従来より広範な独自レビューを行い、各機のairworthiness certificate発行をFAA自身が保持するなど、通常の委任とは異なる追加措置も採った。議会ではAircraft Certification, Safety, and Accountability Actなど認証制度改革が進められた。

また、human factors、ODA監督、safety management、情報開示、変更型式認証の考え方などが改善対象になった。これらは「737 MAXだけを直した」だけではなく、次の航空機認証で同種の情報ギャップを繰り返さないための制度的対応である。

ただし制度改革が完了したから将来の事故がなくなるわけではない。認証制度は設計技術の変化に応じて継続的に更新される必要がある。

EVIDENCE STATUS｜認証で「誰が何を承認したか」を追う難しさ

大型航空機認証は一枚の承認書で完結する作業ではない。数多くのcompliance finding、試験、解析、software/hardware assurance、flight test、manual、training assessmentなどがあり、それぞれでFAAが直接関与する項目とODAへ委任される項目が異なる。そのため「MCASはFAA承認だった／Boeing自己承認だった」という二値表現では、実際の責任分界を表せない。

重要なのは、最終的なtype certificateをFAAが発行したという法的事実と、個々の適合性確認の多くが委任制度を通じて実施されたという運用実態を同時に保持することである。事故後レビューが問題にしたのは、その境界で安全上重要な情報が十分に上位へエスカレーションされたかだった。

hazard classificationと設計保証レベル

航空機システムでは、故障結果がminor、major、hazardous、catastrophicなどどの重大度に分類されるかによって、求められる設計保証や故障確率の厳格さが変わる。もし故障結果を軽く見積もれば、冗長性・検証・独立性に要求される厳しさも変わり得る。

737 MAX事故後の調査では、MCAS故障の危険度評価が、実際に起こり得る反復作動や複数警報を十分含んでいたかが問われた。ここで人間の対応を前提に「重大結果まで進まない」と評価すると、その人間反応仮定自体が安全解析の一部になる。

changed-product ruleの利点と限界

既存型式の派生型を毎回ゼロから最新基準で認証し直すことには、膨大なコストと時間が必要になる。変更部分と影響範囲へ重点を置くchanged-product ruleは合理的な制度設計でもある。しかしシステム統合が深い現代航空機では、一見局所的な変更が旧設計の前提へ影響する場合がある。

JATRが求めたのは制度を単純に廃止することではなく、変更の影響範囲をよりシステムレベルで評価し、古い設計前提と新しい制御機能の組み合わせを見落とさないことである。

規制当局とメーカーの距離

航空機認証では、メーカーの専門知識なしに当局が詳細設計を評価することはできない。一方で、規制当局がメーカーの分析へ過度に依存すると独立監督が弱くなる。この距離の取り方がdelegation制度の核心である。

737 MAX後の改革は、委任を全面廃止するというより、FAAが安全上重要な項目を特定して保持し、ODA内の技術者が不当な組織圧力を受けず認証判断を行える仕組み、重要設計変更をFAAへ適時通知する仕組みを強化する方向に進んだ。

制度補足｜委任が必要でも、独立性をどう確保するか

現実には、FAAがすべてのボルト、コード、解析を自ら審査する体制は成立しない。高度な専門知識はメーカー側に集中し、認証業務の委任は効率だけでなく技術能力活用のためにも必要になる。したがって事故後の政策課題は「委任をゼロにする」ことではなく、重要項目を当局が保持し、委任先が企業内圧力から独立して判断できる構造を作ることである。

具体的には、重大なhazard classification変更や飛行制御権限の拡大をFAAへ必ずエスカレーションする条件、ODA unit membersの独立性、監督データ、内部異議申立て経路などが重要になる。これは電気設計で、実装担当と安全承認者を完全に同一役割へしない考え方に近い。

設計Authorityと認証Authorityの違い

メーカーは設計Authorityとして、要求、設計変更、解析、試験を管理する。FAAは規制Authorityとして、適用基準への適合を承認する。この二つのAuthorityが情報上同期していなければ、メーカー内部では最新仕様が分かっていても、認証側が古い危険度前提で評価し続けることが起こり得る。

737 MAXのMCAS問題は、単なる「書類不足」ではなく、このAuthority同期の問題として読むと理解しやすい。設計変更が安全解析へ反映され、その解析が認証担当へ届き、パイロット文書・訓練にも波及する一貫したconfiguration controlが必要だった。

事故後レビューが同じ方向を向いた点

JATR、DOT OIG、NTSB、議会調査は役割や表現が異なるが、いくつか共通した方向を持つ。MCASを統合システムとして評価すること、human factorsを現実的に扱うこと、FAAとODAの情報共有・監督を強化すること、変更設計の安全上の意味を適時再評価することだ。

複数の独立資料が同方向の改善を示す場合、その論点は一つの政治的評価だけに依存しない。RCFでは、評価語を各資料へ帰属させつつ、共通する技術・制度論点を横断的に整理する。

認証補足｜適合確認と安全判断は同じではない

認証では、個々の要求事項への適合を確認する作業と、変更された機体全体として危険が許容範囲に収まるかを判断する作業が重なる。書類上の試験項目を満たしていても、変更機能の権限拡大や人間との相互作用が安全解析へ十分戻されなければ、システムレベルのリスクを見落とし得る。MAX後のレビューで統合的なsystem safety assessmentが強調されたのは、この差を埋めるためである。

結論｜問題は「自己認証」という一語ではなく、情報と責任の流れにあった

737 MAXはFAAが認証した航空機であり、Boeingが法的に完全な自己認証を行ったわけではない。一方、FAAはODAを通じて認証機能の一部をBoeing組織へ委任していた。二事故後のレビューは、この委任と監督、変更型式認証、MCASの設計変更情報、安全評価、人間性能の仮定に具体的な弱点があったと指摘した。

つまり核心は「誰が判子を押したか」だけではない。設計変更が起きたとき、その安全上の意味が適切に再分類され、FAAへ共有され、統合システムとして評価され、パイロットへの情報・訓練まで一貫して反映される仕組みだったかである。

次の記事では、事故と認証レビューを経て、737 MAXがどのように改修され、FAAとEASAが何を条件に運航再開を認めたのかを見る。運航復帰は「MCASのコードを直したから」だけではなく、設計・監視・配線・手順・訓練・整備を含む多層的な改修だった。

FACT CHECK｜出典・参考資料

1. Joint Authorities Technical Review / FAA, *Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations*, 2019-10-11. https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019
2. U.S. Department of Transportation Office of Inspector General, *Weaknesses in FAA’s Certification and Delegation Processes Hindered Its Oversight of the 737 MAX 8*, 2021-02-23. https://www.oig.dot.gov/library-item/38302
3. U.S. House Committee on Transportation and Infrastructure, Majority Staff, *The Design, Development & Certification of the Boeing 737 MAX: Final Committee Report*, 2020-09. https://www.govinfo.gov/content/pkg/GOVPUB-Y4_T68_2-PURL-gpo144993/pdf/GOVPUB-Y4_T68_2-PURL-gpo144993.pdf
4. 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
5. Federal Aviation Administration, *Summary of the FAA’s Review of the Boeing 737 MAX — Return to Service*, 2020-11-18. https://www.faa.gov/sites/faa.gov/files/2022-08/737_RTS_Summary.pdf

RCF検証ノート

本稿では「Boeingが自己認証した」という短縮表現をMISLEADING_OVERSIMPLIFICATIONとして扱い、FAAが法的認証主体でありつつODAへ一部認証機能を委任した制度構造を記述した。DOT OIGとJATRの指摘は、それぞれ監査・技術レビューの評価として帰属させた。米下院多数派スタッフ報告の組織文化・圧力に関する評価は、事故調査の確定事実と同一視していない。

最終確認：2026年9月20日

END ARTICLE 07 / 08

NEXT FILE

CASE087-08｜737 MAXはどう改修され運航復帰したのか｜MCAS変更・訓練・再認証

最終記事では、左右AOA比較、MCAS作動制限、飛行制御コンピュータ、AOA DISAGREE、配線、訓練、整備、FAA/EASAの再審査を一つのcorrective-action packageとして確認する。

RELATED FILES

• CASE087-02｜MCAS導入前史――認証対象となった設計背景
• CASE087-03｜事故時MCAS――改修前の制御構造
• CASE087-08｜運航復帰――改修後の防護層

737 MAXはどう改修され運航復帰したのか｜MCAS変更・訓練・再認証

2019年3月、二度目の死亡事故を受けて737 MAXは世界中で運航停止となった。米国FAAが運航禁止命令を解除したのは2020年11月18日。約20か月の間、機体は商業運航から外れ、事故調査、設計変更、ソフトウェア検証、飛行試験、シミュレータ評価、乗員訓練の見直し、整備・配線の確認、各国当局による独立審査が行われた。

この復帰を「MCASのソフトウェアを修正した」と一文で表現すると、実際に行われた安全対策を大幅に省略する。事故時の中心的危険経路はMCASにあったが、FAAとEASAは飛行制御システム全体、人間要因、AOA警報、配線、整備、訓練まで範囲を広げた。

改修の基本思想は、単一のAOAセンサー異常が事故時と同じように反復する機首下げトリムへ直結しないこと、MCASがパイロットの操縦能力を奪うほどの権限を持たないこと、異常を乗員が認識しやすいこと、そして乗員が実際の故障シナリオをシミュレータで経験することだった。

CASE BRIEFING

FAAは2019年3月13日に737 MAXの米国内運航を禁止した。以降、ボーイングはMCASと関連システムを変更し、FAAは設計解析、ソフトウェアレビュー、シミュレータ、飛行試験、Joint Operations Evaluation Boardなど複数の工程で検証した。

2020年11月18日、FAAはEmergency Order of Prohibitionをrescissionし、Airworthiness Directive、Flight Standardization Board reportなど必要文書を公表した。ただしこれは「その日から全機が自由に飛べる」という意味ではない。各機について必要なソフトウェア・配線・整備作業を完了し、運航会社が訓練要件を満たし、FAAの要求する手続きを終える必要があった。

EASAはFAAの審査へ参加しつつ、自らも独立した飛行試験とシミュレータ評価を実施した。2021年1月27日、欧州での運航再開を承認し、software、wiring、maintenance、manual、trainingを含むパッケージを義務付けた。

THE QUESTION

grounding後に何が変更され、どの条件で737 MAXは再び飛行可能と判断されたのか。

答えは、一つの修正ではなく、入力の妥当性確認、MCASの権限制限、飛行制御コンピュータ監視、警報、配線、整備、運用手順、シミュレータ訓練、規制当局の独立審査という複数防護層を組み直したことである。

これらの対策は事故時のfailure pathへそれぞれ別の場所で介入する。センサー異常が起きてもMCASへ通さない、通っても出力を制限する、異常を乗員へ知らせる、乗員が手順を実行できるよう訓練する、機体ごとに改修を確認する。安全性は一つの「完璧な部品」ではなく、この重なりで作られた。

1｜左右AOAを比較するようになった

事故時MCASの重要な弱点は、一回の飛行で片側AOAセンサーの値に依存して作動し得たことだった。左右二つのセンサーが存在していても、MCAS作動判断で常時比較して不一致を拒否する構造ではなかった。

改修後はFlight Control Computerが左右AOA入力を比較し、差が一定範囲を超える場合、MCASを作動させない方向へ変更された。これにより一つのセンサーが異常に高い値を出しても、それだけで事故時と同様のMCAS機首下げトリムへ進む経路を遮断する。

この変更は「センサー故障をなくした」わけではない。センサーは今後も故障し得る。フェイルセーフの考え方は、故障ゼロではなく、単一故障が危険な出力へ直結しないことにある。

2｜MCASは同じ高AOA事象で反復作動しないよう制限された

事故時は、パイロットが電動トリムで機首上げ側へ戻しても、異常AOAが残り条件が再成立するとMCASが再び機首下げトリムを指令し得た。JT610ではこの反復が何度も観測され、ET302でも複数回のMCAS関連トリムが事故シーケンスへ入った。

改修後は、一つの高AOA事象に対するMCASの作動を制限し、事故時のように繰り返し機首下げトリムを積み重ねない設計へ変更された。

これは制御ロジック上非常に重要である。異常入力が長時間固定されても、出力を無制限に再実行しない。異常が一つの事故へ拡大する「反復ループ」を切る防護になっている。

3｜MCASの権限も制限された

事故では、水平安定板が機首下げ側へ進むにつれ、パイロットが操縦桿を引いて対抗する力が増えた。したがってMCASが指令できるトリム量と、パイロットのエレベーター権限の関係も重要な設計要件になった。

改修後は、MCASが水平安定板へ与えられる指令量を制限し、パイロットが操縦桿によって機体のピッチを制御する能力を維持するよう設計が見直された。FAAのreturn-to-service reviewは、MCAS変更だけでなく、stabilizer trim systemとpilot authorityを含む統合評価を行った。

安全制御の観点では、これは「自動系が人間を上書きし続けない」という権限設計に相当する。自動化が故障した場合でも、人間が最終的な操縦権限を維持できることを確認する。

4｜Flight Control Computerの監視も強化された

737 MAXはデジタルflight control computerを使用し、MCASを含む飛行制御機能を実行する。運航再開審査では、MCAS単独ロジックだけでなく、コンピュータ間の監視、センサー入力処理、ソフトウェアの安全性が検証された。

FAAは変更されたflight control computer softwareを審査し、故障や不整合が危険な制御出力へ進まないことを評価した。航空機ソフトウェアは一般的なアプリ更新とは異なり、要求、設計、コード、試験結果、構成管理まで厳格に追跡される。

「パッチを当てた」という表現では、こうした検証工程が抜け落ちる。

5｜AOA DISAGREE警報が標準的な防護へ組み込まれた

事故前、AOA DISAGREE alertはすべての737 MAXで期待どおり表示されないソフトウェア上の問題があった。左右AOAが大きく異なることは、センサー異常を乗員が把握するうえで重要な情報である。

改修ではAOA DISAGREE表示を利用可能にし、左右センサーの不一致を乗員へ知らせる防護が整備された。これはMCAS自体を止める入力比較とは別の層である。

入力比較は自動制御側で異常を封じる。AOA DISAGREEは人間へ異常を知らせる。同じセンサー故障に対し、自動系と人間系の二つの防護を置く構造になっている。

6｜配線まで改修対象になった理由

EASAは737 MAX全体のflight control systemを独自にレビューし、MCASだけでなく水平安定板トリム関連の配線配置も問題として扱った。最終的な欧州ADでは、コックピットからstabilizer trim motorへ至る特定配線の物理的分離なども要求された。

これは二事故で配線短絡が原因だったという意味ではない。事故調査とは別に、return-to-service reviewを機会として、関連システムに潜在する別のsingle failure riskも確認した結果である。

運航再開審査が「事故原因の修理」だけでなく、「同じ機能領域に他の危険な単一故障がないか」まで広げられた例といえる。

7｜パイロット訓練はシミュレータを含む形へ変わった

事故前の737 MAX差分訓練では、多くのパイロットがMCASの詳細を学ばず、タブレット等による差分教育で移行できる場合があった。事故後、FAAと各国当局はMAX固有の飛行制御変更と異常対応を訓練へ組み込んだ。

EASAは、737 MAXの全パイロットに一度限りの特別訓練としてシミュレータを含む訓練を義務付け、その後のinitial/recurrent trainingにも反映させた。FAAのFlight Standardization Boardも訓練要件を改訂した。

ここで重要なのは、訓練がMCASという用語を暗記することではない。AOA異常、複数警報、stabilizer trim、速度管理など、実際のfailure scenarioで機体を制御する能力を確認することにある。

8｜運航マニュアルと手順も更新された

事故後、flight manual、checklist、operational proceduresにはMCASと関連異常への情報が追加・改訂された。事故前の設計思想では、MCASは既存737の操縦に新しい乗員手順をほぼ要求しない機能として扱われていた。

二事故は、その前提では異常時の理解が不十分になることを示した。改修後はシステムの存在、故障時の挙動、関連警報、手順を乗員が明示的に理解する方向へ変わった。

これは「ソフトウェアを安全にする」だけでなく、human-machine interfaceを再設計する一部である。

9｜各機は整備・検査を終えなければ戻れなかった

FAAが2020年11月18日にgrounding orderを解除しても、航空会社の737 MAXが同日一斉に営業運航へ戻ったわけではない。各機はFAA ADが要求するソフトウェア更新、配線作業、整備・試験などを完了する必要があった。

長期間保管された航空機は、通常の整備状態とは異なる。運航復帰には保管解除に伴う点検も必要である。EASAは各機について、必要変更の実装と長期保管からの復帰を確認するため、旅客を乗せないoperational readiness flightも要求した。

つまりreturn to serviceは「型式として安全性が確認された日」と「個々の機体が営業便へ戻る日」を分ける必要がある。

10｜FAAは約20か月、何を再審査したのか

FAAのreturn-to-service summaryは、二事故後の審査がMCASだけに限定されなかったことを示している。設計変更、software、system safety assessment、pilot training、maintenance、operational proceduresなどが対象になった。

FAA Administrator自身も改修後MAXを操縦し、国際当局と協力して審査を進めた。さらにFAAは、一定期間、個々のMAXのairworthiness certificate発行を自ら行うなど、通常以上の直接関与を維持した。

2020年11月18日の措置は「安全だと宣言した」というより、規制上必要と判断した変更・訓練・整備条件を満たせば運航へ戻せるという判断である。

11｜EASAは独自審査を行った

EASAは設計国当局であるFAAの審査へ参加しながら、独自のflight testsとsimulator sessionsを行った。EASAは、FAAやBoeingの結論へ自動的に依存せず、自らの四つのreturn-to-service条件が満たされたかを評価したと公表している。

EASAが2021年1月に示したパッケージには、flight control software、AOA disagree alert、wiring separation、manual updates、pilot training、AOA system tests、operational readiness flightが含まれる。

この範囲を見ると、737 MAX復帰が「アメリカでOKになったから欧州も追認した」という単純な流れでなかったことが分かる。主要当局は協力しながらも、それぞれの法的責任で判断した。

12｜改修後も「安全は監視で維持される」

航空機の認証は、ある日を境に安全性が永久固定される仕組みではない。運航開始後も故障報告、service difficulty、incident、maintenance dataなどを監視し、必要ならADや設計変更を追加する。

EASAも運航再開時に、737 MAXの運航を継続監視すると明言した。FAAも同様に運航データと安全情報を監視する。

これは事故前にも存在した制度だが、737 MAX事故は「認証時に想定した安全性」と「運航現場で得られる新しい証拠」を結び付ける重要性を改めて示した。

13｜2024年のMAX 9ドアプラグ事案とは分ける

737 MAXという名称から、2024年1月のAlaska Airlines 737-9のdoor plug脱落事案を二事故のMCAS問題と同じ系列として混同しやすい。しかしこれは別の安全問題である。

機種系列は同じでも、MCASのAOA/flight-control failure pathと、door plugの製造・品質管理・構造に関する問題は技術的に異なる。本CASEの範囲はJT610・ET302と、それに対応した2019–2021年のgrounding/return-to-serviceである。

後年別問題が発生したことを理由に「MCAS改修は無意味だった」とするのも、逆にMCAS改修が完了したから「MAX全体の安全課題は終わった」とするのも不適切である。安全問題はfailure modeごとに分けて評価する必要がある。

14｜事故前と事故後の防護層を比較する

事故前仕様と改修後仕様を防護層で比べると、違いが明確になる。

事故前

• MCAS作動判定が一方のAOA入力に依存し得る。
• 異常AOAが続けば反復作動し得る。
• MCAS権限が事故時に大きなトリム影響を与え得る。
• 多くの乗員がMCASの詳細を通常訓練で扱っていない。
• AOA DISAGREEが期待どおり全機で表示されない問題があった。

改修後

• 左右AOAを比較し、大きな不一致ではMCASを抑止。
• 一つの高AOA事象でのMCAS作動を制限。
• パイロットの操縦権限を維持するようMCAS出力を制約。
• AOA DISAGREE表示を含む異常情報を改善。
• シミュレータを含むMAX固有訓練を実施。
• 配線・整備・運用手順まで改修パッケージへ含める。

一つの防護層が完璧になったのではなく、複数の層が同じ単一故障の連鎖を別々の場所で遮断するよう再構成された。

EVIDENCE STATUS｜「安全になった」をどう検証するか

運航再開時の規制判断は、将来事故が絶対に起きないという保証ではない。認証当局が判断するのは、変更後設計が適用基準を満たし、特定されたunsafe conditionが必要な対策で是正されたかである。したがって「FAAが安全宣言したから絶対安全」「事故歴があるから永遠に危険」という二つの極端を避ける必要がある。

改修後MAXの評価で見るべきなのは、事故failure pathが同じ単一故障から再現できるかである。左右AOA不一致でMCASを抑止し、作動しても反復・権限を制限し、パイロット操縦権限を維持する。さらに警報・訓練・整備を加える。この多層性が、事故時仕様との決定的な差になる。

同じ故障を複数の層で止める意味

たとえば一方のAOAセンサーが異常高値を出した場合、改修後は第一に左右比較でMCAS作動を止める。もし比較機能の別故障などで自動機能が作動しても、出力権限・回数の制限が第二層になる。乗員にはAOA不一致などの情報が与えられ、訓練された手順が第三層になる。

安全工学では、独立性のある防護層を重ねることで、一つの防護の失敗が即事故にならないようにする。737 MAXのreturn-to-service packageは、まさに事故時に不足していた独立性を増やす方向だった。

FAAとEASAで完全に同じ要求だったわけではない

FAAとEASAは協力したが、審査の法的主体は別で、EASAは独自の追加評価・要求を行った。配線配置、training、operational readiness flightなど、欧州ADの具体的要求はEASAの判断として適用された。

この違いは「どちらかが正しい」という対立ではない。国際航空では設計国当局の認証を基礎に相互承認を行いつつ、各当局が自国・地域の法令に基づき追加条件を課すことがある。MAXでは事故の重大性から、その独立審査が特に可視化された。

改修後の安全性を支えるのは継続監視

return to serviceはプロジェクトの終点ではなく、運航データ収集の再開点でもある。実機で多数の飛行時間が積み上がれば、認証試験では見えなかった故障傾向やmaintenance issueが現れる可能性がある。そこでservice difficulty report、incident、AD、manufacturer bulletinなどによる継続監視が必要になる。

737 MAX問題が残した制度的教訓の一つは、認証時の安全モデルを運航実績で更新することの重要性である。事故前の安全評価が実運航の複雑さを十分表さなかった部分を、今後はデータで早期検出しなければならない。

運航復帰後の確認ポイント｜改修は「同じ事故経路」を断てているか

改修の有効性を考えるとき、最も直接的な問いは「JT610/ET302と同じ単一AOA異常から、同じMCAS反復トリムが再現できるか」である。改修後は左右AOA比較が最初の遮断点になり、仮にMCASが作動しても反復・権限制限が次の遮断点になる。さらにパイロット側には警報と訓練がある。事故時のように一つの異常入力が長く通過し続ける経路は複数箇所で切られている。

この観点は、単に「改修項目が多い」ことより重要である。各改修が同じhazardへ独立した防護として効いているかを確認することで、設計の多層性を評価できる。

乗員訓練を設計変更の一部として扱う理由

航空機の安全性は機体だけで完結しない。運用手順と訓練が型式設計の使用条件を構成する。特にstabilizer trim異常のように人間の迅速な介入を期待する場合、訓練は単なる付帯サービスではなく、安全ケースの一部になる。

MAX復帰でシミュレータ訓練が重視されたのは、事故前に机上の差分教育で済ませていた範囲を見直し、複数警報とtrim異常を実際の操縦負荷として経験させるためである。これにより「手順を読んだことがある」状態から「時間圧のある状況で操作できる」状態へ近づける。

結論｜737 MAXは「MCAS修正」ではなく、多層防護を再構成して戻った

737 MAXの運航復帰は、事故時MCASのコードを部分修正しただけでは成立しなかった。左右AOA比較、反復作動制限、出力権限制限、flight control computer監視、AOA DISAGREE、配線、マニュアル、整備、シミュレータ訓練という複数の対策が組み合わされた。

FAAは約20か月の再審査を経て2020年11月18日に米国のgrounding orderを解除した。EASAは独自試験を含む評価を行い、2021年1月に欧州でのreturn to serviceを承認した。いずれも、各機・各運航者が必要作業を完了することを条件としている。

二事故から得られる最も一般化可能な教訓は、複雑な安全システムを一つの装置・一人の操縦士・一つの組織の失敗だけで説明しないことである。単一センサー故障が破局へ進まない入力設計、自動系の権限、明確な警報、人間の現実的能力を反映した安全評価、独立した認証監督、運航後の監視が重なって初めて防護になる。

737 MAXは、その複数層が十分に機能しなかったために二つの事故を経験し、その複数層を作り直すことで運航へ戻った。この「事故→grounding→再設計→再認証」という過程まで含めて初めて、CASE087の全体像が完結する。

FACT CHECK｜出典・参考資料

1. Federal Aviation Administration, *Summary of the FAA’s Review of the Boeing 737 MAX — Return to Service*, 2020-11-18. https://www.faa.gov/sites/faa.gov/files/2022-08/737_RTS_Summary.pdf
2. Federal Aviation Administration, *FAA Updates on Boeing 737 MAX*, 2019–2021. https://www.faa.gov/newsroom/faa-updates-boeing-737-max-0
3. European Union Aviation Safety Agency, *EASA declares Boeing 737 MAX safe to return to service in Europe*, 2021-01-27. https://www.easa.europa.eu/en/newsroom-and-events/press-releases/easa-declares-boeing-737-max-safe-return-service-europe
4. European Union Aviation Safety Agency, *Airworthiness Directive 2021-0039R2 — Return to Service*, 2021-02-17. https://ad.easa.europa.eu/ad/2021-0039R2
5. 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検証ノート

本稿はFAAのreturn-to-service reviewとEASAのAD・公式説明を主軸に、改修項目をMCAS単独ではなく多層対策として検証した。左右AOA比較、MCAS作動制限、訓練、配線、整備について公的資料で確認した。2024年737-9 door-plug事案は同じMAX系列でもfailure modeが異なるため、本CASEの事故因果へ混入させていない。運航再開日は型式レベルの規制判断と個別機の営業復帰日を区別した。

最終確認：2026年9月20日

END ARTICLE 08 / 08

RELATED FILES

• CASE087-01｜二つの事故と世界的grounding――CASE全体の俯瞰
• CASE087-03｜事故時MCAS――改修前のfailure path
• CASE087-07｜FAA・ODA・安全評価――再認証の制度背景