マーズ・クライメイト・オービター事故の教訓

マーズ・クライメイト・オービター喪失事故に関する包括的調査報告書：システムエンジニアリングの崩壊と組織的教訓

宇宙開発におけるパラダイムシフトと予兆

1999年9月23日、アメリカ航空宇宙局（NASA）の火星探査機マーズ・クライメイト・オービター（Mars Climate Orbiter: MCO）が、火星周回軌道投入（MOI）のマニューバ中に消息を絶った。この事故は、表面的には「単位の混同」という初歩的なミスに起因するものとして広く知られているが、その深層には1990年代後半のNASAが直面していた組織構造の変革、予算縮小への圧力、そして複雑化するシステムエンジニアリングの管理不全が横たわっている。本報告書は、MCOの喪失に至る技術的、組織的、心理的要因を包括的に分析し、現代のプロジェクトマネジメントおよびシステムエンジニアリングに残された教訓を詳述するものである。

1.1 マーズ・サーベイヤー98計画の背景

マーズ・サーベイヤー98計画は、1996年のマーズ・グローバル・サーベイヤー（MGS）やマーズ・パスファインダーの成功を受け、火星探査を継続的かつ低コストで行うことを目的とした一連のミッションの一部であった。この計画は、MCOと着陸機であるマーズ・ポーラー・ランダー（Mars Polar Lander: MPL）の2つの探査機で構成されていた。MCOの主な科学的目的は、火星の気候、大気中の水蒸気や塵の分布、地表面の変化を観測することであり、惑星間天気予報衛星としての役割を担っていた。さらに、MCOはMPLおよび将来のサンプルリターン・ミッションのために、火星表面からのデータを地球へ中継する重要な通信インフラとしても機能する予定であった 1。

1.2 「Faster, Better, Cheaper」政策の影響

1992年にNASA長官に就任したダニエル・ゴールディンは、「Faster, Better, Cheaper（より早く、より良く、より安く：FBC）」というスローガンを掲げ、宇宙開発のコスト構造改革を断行した。これは、従来の「バトルスター・ギャラクティカ」と揶揄されるような、巨額の予算と長期間を要する大型旗艦ミッション（例：バイキング計画やカッシーニ計画）から脱却し、小型で安価な探査機を頻繁に打ち上げることで、科学的成果のリスク分散と効率化を図るものであった 4。

MCOとMPLの開発はこのFBC政策の最盛期に行われた。両探査機の開発費は、ロケット打ち上げ費用を含めても約1億9310万ドル（MCO単体では約1億2500万ドル）に抑えられた。これは、1992年に失敗したマーズ・オブザーバー（開発費約8億ドル）と比較すると劇的なコストダウンであった 7。しかし、この極端なコスト削減圧力は、開発スケジュールの短縮、人員の削減、そして最も重要な「検証プロセスの簡略化」という副作用をもたらした。MCOプロジェクトでは、従来NASAが請負業者に対して行っていた厳格な「監督（Oversight）」が、より緩やかな「洞察（Insight）」へと移行し、詳細な技術チェックが請負業者任せになる傾向が強まっていた 10。この管理体制の変化こそが、後の悲劇の温床となったのである。

技術的詳細：単位混同のメカニズムと「Small Forces」

MCOの失敗の直接的な原因（Root Cause）は、地上局のナビゲーション・ソフトウェアと探査機自体の制御データの間に存在した単位の不一致である。ここでは、その技術的詳細を物理学的およびソフトウェア工学的観点から深掘りする。

2.1 単位不一致の発生源：「Small Forces」インターフェース

問題の核心は、探査機の姿勢制御スラスタ（スラスター）の噴射データを処理する「Small Forces（微小推力）」と呼ばれるソフトウェアモジュールにあった。宇宙船の軌道決定においては、重力などの保存力だけでなく、スラスタ噴射や太陽光圧といった非保存力（Non-gravitational forces）を正確にモデル化する必要がある。

JPL側の仕様（メートル法）： ジェット推進研究所（JPL）のナビゲーションチームが使用する軌道決定ソフトウェアは、国際単位系（SI）であるニュートン・秒（N-s）で記述された推力データ（力積）を期待していた。これは「ソフトウェア・インターフェース仕様書（SIS）」において明確に規定されていた要件であった 1。

ロッキード・マーティン側の実装（ヤード・ポンド法）： 探査機の製造を担当したロッキード・マーティン社（コロラド州デンバー）が提供した地上支援ソフトウェア「SM_FORCES」は、スラスタの噴射結果をポンド力・秒（lbf-s）で出力するようにプログラムされていた。ロッキード・マーティン社内では伝統的にヤード・ポンド法が使用されていたが、NASAとの契約上はメートル法への変換が義務付けられていたにもかかわらず、その変換係数がコード内で欠落していたのである 2。

2.2 物理的影響の数学的解析

1ポンド力（lbf）は約4.45ニュートン（N）に相当する。したがって、ロッキード・マーティン側のソフトウェアが出力した数値（例：1 lbf-s）を、JPL側のソフトウェアはそのまま「1 N-s」として解釈してしまった。

表1：単位混同による数値的乖離の比較

この結果、ナビゲーションチームは、スラスタ噴射によって探査機に与えられた実際の速度変化（Delta-V）を、約4.45分の1に過小評価することになった。逆に言えば、探査機は地上チームが計算しているよりも約4.5倍大きな力で軌道を修正され続けていたのである 1。この誤差は、単発のマニューバであれば修正可能であったかもしれないが、後述するAMDイベントの頻度により、累積的な軌道偏位を引き起こすこととなった。

複合的要因：非対称な設計と想定外のAMD頻度

単位の混同単独でも重大な問題であったが、MCO特有の機体設計と運用上の制約が、このエラーの影響を劇的に増幅させることになった。ここには、コスト削減を至上命題としたFBC政策の弊害が色濃く反映されている。

3.1 太陽電池パドルの非対称設計と「バーベキュー・モード」の拒否

MCOはコスト削減と軽量化のため、機体の片側にのみ太陽電池パドルを持つ非対称な形状をしていた。これに対し、前任機であるマーズ・グローバル・サーベイヤー（MGS）は対称的なパドルを持っていた。非対称な形状は、太陽光圧（ソーラー・プレッシャー）の受圧中心と機体の重心との間に大きなズレを生じさせ、機体を回転させようとするトルク（回転力）を恒常的に発生させる要因となった 2。

さらに、当初の設計段階では、機体をゆっくりと回転させる「バーベキュー・モード（Barbecue Mode）」を採用することで、熱入力と太陽光圧の影響を均等化する計画があった。しかし、電力バジェットへの懸念や設計の簡素化を理由に、このモードは採用されず、常に一定の面を太陽に向ける固定姿勢（Inertial Pointing）が採用された 15。

3.2 AMDイベントの頻度増加と誤差の累積

非対称な形状で一定の姿勢を取り続けた結果、太陽光圧によるトルクが継続的に蓄積され、姿勢制御用のリアクション・ホイール（はずみ車）の回転数が限界に達する「飽和（Saturation）」が頻繁に発生した。これを解消するためには、スラスタを噴射してホイールの回転を落とす「アンギュラー・モメンタム・デサチュレーション（AMD：角運動量の飽和解消）」と呼ばれる操作が必要となる 14。

AMDイベント自体は姿勢制御のための操作であり、軌道変更を意図したものではないが、スラスタ噴射には不可避的に並進力（Translation Force）が伴う。これが「Small Forces」として軌道に影響を与える。MCOの設計上の特性により、AMDイベントの発生頻度は当初ナビゲーションチームが想定していたよりも10倍から14倍も多くなった 2。

この頻度の激増は致命的であった。単位換算ミス（4.45倍の誤差）を含む「Small Forces」データが、予想をはるかに上回る頻度で軌道計算モデルに組み込まれ続けたのである。これにより、軌道誤差は線形ではなく加速度的に蓄積し、最終的な破局へのカウントダウンが始まった。

運用上の死角：見過ごされた警告とコミュニケーション不全

MCOの失敗は、突然の事故ではなく、9ヶ月間の航行期間中に徐々に進行した「スローモーションの災害」であった。この間、いくつかの重要な警告サイン（レッドフラッグ）が存在したが、それらは組織的なバイアス、手続き上の不備、そして企業間のコミュニケーション断絶によって黙殺された。

4.1 「失われた4ヶ月」：電子メール依存とフォーマットエラー

ミッションの最初の4ヶ月間、ナビゲーションチームは本来使用すべき自動化された「Small Forces」処理システムを使用していなかった。これは、ロッキード・マーティンから送られてくるデータファイルのフォーマットにエラーがあり、JPL側のソフトウェアが読み込めなかったためである 1。

この期間、ナビゲーションチームはロッキードの技術者と電子メールで直接やり取りを行い、AMDイベントのデータを手作業で入力して計算していた 1。皮肉なことに、この「手動運用」の期間中は、エンジニアがデータを個別に確認・処理していたためか、あるいは初期段階でのAMD頻度が低かったためか、大きな軌道誤差は顕在化しなかった。しかし、4月頃にファイル形式のバグが修正され、自動化されたシステム（単位エラーを含んだままのSM_FORCES）が稼働し始めると、チェック機構をすり抜けた誤ったデータが直接ナビゲーション・ソフトウェアに流入し始めた。自動化が皮肉にもエラーの拡散を助長したのである。

4.2 ドップラー残差と「Line of Sight」の謎

火星への接近に伴い、JPLのナビゲーションチームは「ドップラー残差（Doppler residuals）」、特に視線方向（Line of Sight）のデータに説明のつかない微小なズレを検出し始めた。通常、宇宙機の位置と速度は、地球からの電波のドップラーシフトやレンジング（距離測定）データを用いて極めて高い精度で決定される。しかし、MCOの場合、計算モデルが予測する位置と、実際の追跡データが示す位置が一致しなかった 1。

表2：ナビゲーションデータの異常と対応

4.3 警告の棄却：2名のナビゲーターとISAフォーム

調査報告書によると、少なくとも2名のナビゲーターが、この軌道の乖離について深刻な懸念を表明していた。彼らは計算値と実測値の食い違いが、最終的な軌道投入高度に致命的な影響を与える可能性を指摘し、再計算や軌道修正の必要性を訴えた 11。

しかし、これらの懸念は公式な「ISA（Incident, Surprise, Anomaly）」報告書の提出という正規の手続きを経ていなかった、あるいはマネジメント層によって「単なる計算上のノイズ」や「重要ではない」と判断され、棄却（Dismissed）された 11。ナビゲーションチームは、この残差が何らかの未モデル化の力によるものだと疑ったが、それが「単位の根本的な間違い」であることまでは突き止められなかった。また、JPLとロッキード・マーティンの間には「壁」があり、JPL側がロッキードの内部データやコードを直接検証する権限や機会が制限されていたことも、原因究明を妨げた。

運命の分水嶺：TCM-5（第5回軌道修正マニューバ）の拒否

火星到着の数日前、ミッションの成否を分ける決定的な局面が訪れた。予定されていた第5回軌道修正マニューバ（TCM-5: Trajectory Correction Maneuver 5）を実施するか否かの議論である。このエピソードは、組織におけ