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｜出典・参考資料

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
Joint Authorities Technical Review / FAA, *Boeing 737 MAX Flight Control System: Observations, Findings, and Recommendations*, 2019-10-11. https://www.faa.gov/newsroom/finaljatrsubmittaltofaaoct2019
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
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
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の設計変更が認証側でどう扱われたか

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

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