現実世界のCASE FILE 現実世界のCASE FILE

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

航空機の設計・認証レビューを行う技術者を表した再現イメージ。
RCF generated illustrative reconstruction; not documentary evidence 出典 GENERATED_BY_WORKFLOW

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|運航復帰――改修後の防護層
  1. 01 737 MAXとは|二つの墜落事故と世界的運航停止の全体像
  2. 02 737 MAXはなぜMCASを搭載したのか|LEAP-1B・機体特性と設計の背景
  3. 03 MCASは何をしていたのか|AOAセンサーと水平安定板の仕組み
  4. 04 ライオン・エア610便|最初の737 MAX墜落事故で何が起きたのか
  5. 05 JT610後、なぜ737 MAXは飛び続けたのか|警告・緊急AD・情報共有の4か月
  6. 06 エチオピア航空302便|二度目の墜落事故と最終報告をめぐる争点
  7. 07 737 MAXの認証はなぜ問題になったのか|FAA・ODA・安全評価の構造
  8. 08 737 MAXはどう改修され運航復帰したのか|MCAS変更・訓練・再認証

RSS FEED

RSSで更新を受け取る

RSSリーダーへ次のURLを登録すると、新着記事を確認できます。

フィードを直接開く