「NASAでも起きた。『単位の違い』を見逃し、火星探査機を失った理由」

何が起きたか

NASAの火星探査機Mars Climate Orbiter（MCO）は、1998年12月11日に打ち上げられました。火星の気象を観測する周回衛星として、また同時期に着陸予定だったMars Polar Landerの通信中継役としての運用が計画されていました。

打ち上げから約9カ月半後の1999年9月23日、MCOは火星周回軌道へ入るためのエンジン噴射（Mars Orbit Insertion）を開始しました。信号は協定世界時09:04:52に途絶え、予測より49秒早いタイミングでした。その後、9月25日まで信号の再取得が試みられましたが、再びつながることはありませんでした。

事後の航跡解析では、実際の軌道は計画よりも大きく低く、火星に最も近づく高度（周回近点高度）は約57kmと推定されました。これは、探査機が生存可能とされていた最低高度80kmを下回る数値です。NASAの報告書は、探査機が大気圏内で失われたか、大気を抜けて太陽周回軌道へ戻った可能性があるとしています。

NASAのMars Climate Orbiter Mishap Investigation Board（事故調査委員会）は、この事故の根本原因を次のように特定しました。地上で航法計算に使うソフトウェア「SM_FORCES（Small Forces）」が出力するデータは、インターフェース仕様書（Software Interface Specification）でニュートン秒（N・s、メートル法）と定められていました。ところが実際にこのソフトウェアが出力していたのは、ポンド力秒（lbf・s、英単位系）のデータでした。探査機側の航法ソフトウェアは正しくメートル法で計算しており、食い違いが生じたのは地上ソフトウェアの側だけでした。

この結果、ポンド力秒のデータがニュートン秒として扱われ、実際の推力の影響が約4.45倍（1ポンド力＝約4.45ニュートン）過小に見積もられました。9カ月の巡航中、この誤差が軌道の推定へ少しずつ積み重なっていきました。

当時どこまで分かっていたか

この単位の食い違いは、軌道投入前から分かっていたわけではありません。NASAの報告書によると、1999年の春から夏にかけて、現場レベルでは航法解の間に食い違いがあることが認識され、非公式には報告されていましたが、解消されないままでした。火星への接近が近づくにつれ、複数の方式で計算した軌道解を比較したところ、ドップラーデータのみによる解は、他の方式よりも火星に近い軌道を一貫して示していました。この食い違いも、解消されないまま残っていました。

9月8日に計算された最後の軌道修正（TCM-4）は、9月15日に実行され、最初の近点高度を226kmとする計画でした。しかしTCM-4実行後からMars Orbit Insertionまでの1週間で、運用航法チームの軌道決定は近点高度が150〜170km程度まで下がっていることを示すようになり、さらにMars Orbit Insertionの約1時間前に、より精度の高い追跡データをもとにした計算では、近点高度は110kmまで下がっている可能性が示されました。生存可能とされる最低高度は80kmでした。

つまり、軌道投入の直前には「計画より近づきすぎている」という兆候そのものは把握されていました。しかし、なぜそうなっているのかという原因、すなわち地上ソフトウェアの単位の食い違いは、この時点ではまだ特定されていませんでした。単位の食い違いが実際に発見されたのは、信号が途絶えた後の9月27日から29日にかけて、運用航法チームが探査機側の技術者と共に速度変化の食い違いを検討する中でのことでした。

なぜ、単純な「単位ミス」だけでは説明が足りないのか

この事例を、

「NASAともあろう組織が、単位を間違えるという初歩的なミスをした」

だけで終わらせると、次の判断には活かしにくくなります。

まず押さえておく必要があるのは、単位に関するルールが「なかった」わけではないという点です。インターフェース仕様書は、地上ソフトウェアの出力をニュートン秒（メートル法）とすることを明確に定めていました。問題は、ルールが存在しなかったことではなく、そのルールどおりにデータが受け渡されているかどうかを、実際に検証する仕組みが機能していなかったことです。

NASAの事故調査委員会は、根本原因（単位の食い違い）とは別に、8つの寄与要因を挙げています。

1. 速度変化のモデル化の誤りを検出できなかったこと：地上ソフトウェアが生成するデータをもとにした軌道推定の誤りが、途中で気づかれないまま残っていた。
2. 運用航法チームが探査機の特性に十分習熟していなかったこと：開発段階を担当したチームと、運用段階を担当したチームが別であり、運用チームは設計審査にも参加していなかった。
3. 軌道修正マヌーバ（TCM-5）が実行されなかったこと：近点高度が想定より低いことへの緊急対応として使える手段は用意されていたが、準備・訓練が整わないまま実行されなかった。
4. システムエンジニアリングの過程が、開発から運用への移行に十分対応していなかったこと：単位の問題に気づく機会が複数あったにもかかわらず、それを組織横断で捉える仕組みが弱かった。
5. プロジェクトの各要素間のコミュニケーションが不十分だったこと：運用航法チームは自分たちの懸念を他チームへ十分に伝えられず、正式な問題管理の手続きよりも個別のメールでのやり取りに頼っていた。
6. 運用航法チームの人員体制が十分でなかったこと：当時、運用チームは複数のミッションを同時に担当しており、MCOの航法は実質的に少人数で担われていた。
7. 訓練が十分でなかったこと：運用チームは探査機の設計・運用について十分な訓練を受けておらず、仕様書に従うことの重要性についての訓練も不足していた。
8. 検証・妥当性確認の過程が、地上ソフトウェアに十分及んでいなかったこと：仕様書は作成されていたが、地上ソフトウェアがその仕様どおりに動作しているかを確認する、末端まで通した試験が行われていなかった。

つまりこの事例が示しているのは、「仕様が存在すること」と「実際に受け渡されるデータが、その仕様どおりであることを確認できていること」は、別だということです。高度な技術力を持つ組織であっても、チームやシステムの境界をまたぐ場所での検証が機能しなければ、こうした食い違いは見つからないまま進んでしまいます。

今後に活かすチェックポイント

1. 仕様（単位・形式）を定めるだけでなく、実際の受け渡しデータがその仕様どおりかを検証する工程があるか
   仕様書の存在と、仕様への準拠の確認は別の作業であることを意識する。
2. 想定と異なる兆候が出たとき、原因が分かるまで正式な手続きで追跡しているか
   今回で言えば、軌道解の食い違いが非公式な報告のまま解消されずに残っていた。
3. 開発チームから運用チームへの引き継ぎで、設計上の注意点や既知の懸念まで確実に伝わっているか
   開発段階の担当者と運用段階の担当者が異なる場合、この引き継ぎの質が特に重要になる。
4. 重要な判断を、独立した別の方法や別の担当者が確認できる体制になっているか
   複数の軌道解が食い違っていた際、それを解消する独立した確認の仕組みがあったかを振り返る。
5. 「これまで問題なく続いてきたから、今回も大丈夫」という前提を、個別の状況ごとに見直しているか
   長年の実績がある取り組みほど、慣れによる確認漏れが起きうる。

出典・本事例について

本事例は、NASA Mars Climate Orbiter Mishap Investigation Boardが1999年11月10日に公表したPhase Iレポートの記載にもとづき、失敗にまなぶ.com編集部が再構成しました。

参考資料：

• NASA, “Mars Climate Orbiter Mishap Investigation Board Phase I Report” (November 10, 1999)

探査機の正確な最終状態（大気圏内で破壊されたか、大気を抜けて太陽周回軌道へ戻ったか）は確定していません。約57kmという最接近高度は、信号が途絶えた後の事後推定値であり、運用中に確定していた数値ではありません。個別の担当者・チームの責任は評価していません。