Mars Climate Orbiter：単位の取り違えで消えた火星探査機

何が起きたか

横にスクロール

Mars Climate Orbiter（マーズ・クライメート・オービター）は、火星の気候や大気を観測するためにNASAが送り出した探査機だ。1998年12月に打ち上げられ、約9か月に及ぶ航行を経て、1999年9月に火星へ到達した。その任務は、火星の大気や気候、そして水の痕跡を軌道上から観測し、あわせて後続の着陸機との通信を中継することにあった。数年をかけて設計・製造された機体は、地球から遠く離れた火星まで、ほぼ計画どおりに飛んできていた。計画では、エンジンを噴射して減速し、火星の重力にとらえられて周回軌道へ入る「軌道投入」を行うはずだった。探査機は噴射しながら火星の裏側へ回り込み、地球との通信がいったん途切れる。そして再び姿を現す——はずだった。

しかし探査機は二度と応答しなかった。管制室は通信の回復を待ち続けたが、予定の時刻を過ぎても電波は返ってこなかった。後の解析で、探査機は計画よりはるかに低い高度で火星の大気に接近していたことが判明する。想定より低い軌道は、機体が耐えられる範囲を超えていた。こうしてMars Climate Orbiterは、火星に着く直前で失われた。開発から打ち上げまでを含む損失は3億ドル規模にのぼる。事故後に設けられた調査委員会は、その根本原因を単位換算の見落としにあると結論づけた。

失敗の原因は、隕石でも設計不良の部品でもなかった。地上と探査機のソフトウェアが、同じ数値を「違う単位」として扱っていた——ただそれだけである。人命こそ失われなかったが、単純な取り違えが巨額の資産と数年がかりの計画を一瞬で無に帰した点で、この事故はソフトウェア工学の教訓として繰り返し語られる事例となった。

技術的な根本原因

航行中、探査機はときおり小さなスラスタ（推進器）を噴射して姿勢を整える。この噴射はごくわずかながら探査機の速度を変えるため、地上の航法チームは、噴射のたびに生じる力積（インパルス、力と時間の積）を計算し、探査機の位置と速度の予測に反映させていた。

問題は、この力積を計算する地上ソフトと、それを受け取って軌道を推定する航法ソフトのあいだにあった。地上ソフト（Lockheed Martin製）は、力積をヤードポンド法、すなわちポンド重・秒（lbf·s）で出力していた。ところが航法ソフト（JPL製）は、同じ数値をSI単位のニュートン・秒（N·s）だと想定して読み込んでいた。両者のあいだで単位の取り決めが共有されておらず、境界での変換も行われていなかったのだ。どちらのソフトも、単体で見れば正しく動いていた。破綻が起きたのは、二つをつなぐ継ぎ目でだけだった。

1ポンド重は約4.448ニュートンに相当する。つまり、地上ソフトが出力した数値は、航法ソフトが思い込んでいた大きさの約4.448倍の力積を表していた。噴射一回あたりの差はわずかでも、長い航行で何度も繰り返されれば、誤差は着実に積み上がる。航法ソフトはスラスタの効果を実際より小さく見積もり続け、その結果、探査機が本当はどこを飛んでいるかの推定が、真の軌道から少しずつずれていった。

やっかいなのは、この誤差が一度の派手な異常として現れず、静かに育っていった点だ。航行中の軌道決定は、地上から届く観測データと予測モデルを突き合わせ、繰り返し補正していく作業である。もし二つの系統の数値を独立に照らし合わせる仕組みがあれば、約4.448倍という無視できない開きは、もっと早く気付けたかもしれない。だが実際には、片方の単位系がもう片方の前提と噛み合っているかどうかを、誰も正面から検証していなかった。

火星に近づいたとき、この蓄積した誤差が牙をむいた。航法チームの計算上は安全な高度を通過するはずが、実際にはずっと低い高度で大気へ突入する軌道になっていた。単位という、コード一行にも現れない「暗黙の前提」の食い違いが、探査機を失わせたのである。打ち上げから9か月、順調に見えた航行の裏で、破滅は最初の一歩から静かに仕込まれていた。

教訓

第一の教訓は、システム間のインターフェース契約を明示し、検証することだ。二つのソフトが数値をやり取りするなら、その数値がどの単位・どのデータ形式なのかは、口約束ではなく仕様として文書化され、両者のコードで一致していなければならない。プログラム同士の境界では、人間の常識は通用しない。値に単位の情報を持たせ、異なる単位が紛れ込んだら受け渡しの時点で弾く——現代の開発で使われるそうした型設計は、単位を持たない裸の数値を信じ込む設計への処方箋だ（プログラミングの設計原則にも通じる）。

第二に、単位変換は境界で一元化する。もし地上ソフトの出力を受け取る一点に、「ここでポンド重・秒をニュートン・秒へ変換する」という明示的な処理が置かれていれば、事故は防げたはずだ。変換の責任があいまいなまま両者に散らばると、「相手がやっているはず」という思い込みの隙間へ事故が落ちる。逆に、変換を一箇所へ閉じ込めておけば、後から単位を見直すときも、確認すべき場所はそこだけで済む。

第三に、独立した検証とチーム間のコミュニケーションが要る。実は航行中、探査機の軌道が予測とわずかに食い違う兆候は観測されており、担当者のあいだで議論も起きていた。しかし、その違和感が単位の不一致という根本原因へ結び付けられることはなかった。数値の食い違いに気付く機会は複数あったのに、組織の壁がそれを見逃させた。個々のエンジニアはそれぞれの職務を果たしていた。抜け落ちていたのは、部門をまたいで前提をすり合わせる一手間だけだった。技術の失敗は、しばしば組織の失敗でもある。

こうした「境界での取り決めの食い違いが破滅を招く」構図は、Mars Climate Orbiterに限らない。仕様と実装のギャップがロケットを失わせたAriane 5の事例も、根は近いところにある。

まとめ

Mars Climate Orbiterを失わせたのは、高度な技術の限界ではなく、単位という基本的な取り決めの取り違えだった。地上はヤードポンド法、探査機はSI単位——たったそれだけの不一致が、長い航行のあいだに軌道推定を狂わせ、3億ドル規模の探査機を火星の入り口で消し去った。最先端の科学を積み上げた機体が、単位というごく基本的な取り決めの違いで失われた——その落差こそ、この事故が長く語り継がれる理由だ。教訓は明快だ。システムの境界では、単位もデータ形式も暗黙にせず、契約として明示し、一元的に変換し、独立に検証する。これは宇宙開発だけの話ではない。単位や形式を型に明記し、境界で必ず変換を通すという構えは、いま日常的に書くコードにもそのまま応用できる普遍的な備えだ。ほかの事例から学べる教訓は工学の大惨事から辿れる。