1996年6月4日、南米フランス領ギアナのクールー宇宙センター。世界中のメディアと科学者が見守る中、欧州宇宙機関（ESA）の新型ロケット「アリアン5」が、轟音と共に飛び立ちました。しかし、未来への挑戦はわずか40秒後に悪夢へと変わります。順調に上昇していたはずのロケットは突然、制御不能となり、高度約3,700メートルで爆発してしまったのです。この事故による損害額は当時のレートで約370億円以上と報道され、後に「ソフトウェア史上最悪の失敗」の一つとして歴史に刻まれることになります。そして何より衝撃的だったのは原因が複雑な問題ではなく、たった数行の「ソフトウェアのバグ」と報じられたことでした。今回はこの歴史的な失敗を振り返ってみたいと思います。
- もくじ
1. 期待の新型ロケットを襲った「40秒の悪夢」
1-1. 新型ロケット「アリアン5（Ariane 5）」
1990年代、世界のロケット市場は転換期を迎えていました。通信衛星や放送衛星が大型化の一途を辿り、より重い荷物（ペイロード）を、より安く、効率的に宇宙へ送ることが求められていたからです。当時、欧州の「アリアン4」は信頼性の高い傑作機として知られていましたが、この大型化トレンドに対応するためには限界が見えてはじめていました。
そこでESAは、長い歳月と総額70億ドル（当時のレートで約7000億円以上）という巨額の投資を行って、次世代の大型ロケット「アリアン5」を開発しました。
アリアン5は、アリアン4の単純な後継機としてではなく、全く新しい設計思想に基づいた夢の「モンスターマシン」として開発されました。能力が大幅に強化され、積載能力はアリアン4をはるかに凌駕するものでした。
1996年6月4日の記念すべき初飛行には、ESAの重要な科学ミッションである「クラスター（Cluster）」計画の4基の衛星が搭載されていました。これらの衛星は地球の磁気圏を観測し、太陽風との相互作用を解明するために使われる予定で、多くの科学者たちの「希望の星」でした。アリアン5は欧州が宇宙大国としての地位を不動のものにするための切り札として、一身に期待を背負っていたといってよいでしょう。
1-2. 打ち上げ成功、そして制御不能
打ち上げ当日の天候は良好でした。カウントダウンがゼロになり、メインエンジンと固体ロケットブースターが点火されると、アリアン5は空気を震わせながら順調にリフトオフ（離陸）しました。最初の30秒間、飛行は完璧に見えました。管制室のモニターには正常なテレメトリデータが表示されていたとされています。しかし、その静寂は打ち上げから約37秒後に唐突に破られることになりました。
ロケットの頭脳であるフライトコンピュータに対し、姿勢制御を司る慣性基準装置（SRI）から異常データが送られ始めたのです。コンピュータは「機体が90度以上傾いている」と誤認し、姿勢を立て直そうとしてエンジンのノズルを限界まで傾けようとしました。
この急激な操舵により、音速で飛行中の機体は凄まじい空気抵抗にさらされました。打ち上げ39秒後、過大な負荷に耐えきれなくなった固体ロケットブースターがメインステージから引きちぎられるように分離し、機体の崩壊が始まりました。そして40秒後には、なんと異常を検知した自動自爆システムが作動。アリアン5は巨大な火球となり、搭載されていた4基の衛星と共に爆散してしまいました......。
1-3. 史上最も高くついた「バグ」
この事故による直接的な経済損失は、ロケット本体と搭載されていた高価な衛星を含め、約3億7000万ドルから5億ドル（当時のレートで約370億円以上）にのぼると推計されています。事故がもたらしたのは経済的損失だけではなく、欧州の宇宙開発技術に対する世界からの信頼の低下でした。
そして、事故直後に発足した調査委員会による報告が世界中に衝撃を与えることになります。
原因は、事故当初に疑われていたハードウェアの破損や推進系のトラブルではなく、「慣性基準装置（SRI）内のソフトウェア例外」、つまり、プログラムの書き間違い（バグ）にあったと判明したからです。
たった一つの数値変換処理の不備が、数百億円規模のプロジェクトを灰にしたこの事件は、後に「史上最も高くついたバグ」「3億7000万ドルのバグ」と呼ばれ、ソフトウェア工学において、小さなコードのミスが、物理世界で壊滅的な被害をもたらすことを示す最も有名なケーススタディとなってしまいました。
2. ソフトウェアのバグと技術的原因
2-1. 仕様変更に伴うリスクとソフトウェア再利用
なぜ、優秀なエンジニアたちが集うESAで、このような致命的なミスが起きたのでしょうか。その根本原因の一つは、ソフトウェア開発における「再利用」の落とし穴にあったとされています。
アリアン5の開発において、エンジニアたちはコスト削減と開発期間の短縮のため、傑作機として実績があるアリアン4のソフトウェアを可能な限り流用する方針を採りました。とくに、ロケットの姿勢や位置を計算する「慣性基準装置（SRI）」のプログラムは、アリアン4で長年問題なく稼働していた実績があったため、ほぼそのままの形でアリアン5に搭載されたようです。
「実績のあるコードを使うのだから、一から作るよりも安全だ」という判断は、一般的なソフトウェア開発の常識からすれば間違いではありません。しかし、ここには重大な見落としがありました。
なぜなら、アリアン5は、アリアン4とは全く異なる物理的特性を持っていたからです。とくに打ち上げ初期の加速性能や水平方向への速度は、アリアン4に比べてはるかに高負荷な特性があったとされています。
アリアン4の機体での条件では正しく作動していたコードですが、アリアン5という新しい環境に置かれた瞬間、時限爆弾へと変貌してしまうことになりました。仕様変更に伴うリスク評価よりも、過去の成功体験への依存が優先されてしまったといえるのかもしれません。
2-2. 致命的なオーバーフロー
事故を直接引き起こしたのは、プログラミングにおける「オーバーフロー（桁あふれ）」と呼ばれる現象だったと指摘されています。
問題が発生したのは、ロケットの「水平バイアス（BH）」という値を計算するプログラムの箇所でした。ここでは、64ビットの浮動小数点数で計算された数値を、メモリ保存のために16ビットの符号付き整数に変換する処理が行われていました。
アリアン4の飛行軌道であれば、この水平バイアスの値が16ビット整数の最大値である「32,767」を超えることはありませんでした。しかし、アリアン5はアリアン4よりもはるかにパワフルだったため、初期の加速や水平方向への速度が桁違いに速く、打ち上げから約37秒後、計算された速度の値は「32,767」という限界を軽々と超えてしまったのです。
小さなバケツに大量の水を注げばあふれ出すように、16ビットの変数では巨大な数値を受け止めきれず、システムは「オペランド・エラー（演算例外）」を発生させました。これで慣性基準装置（SRI）は機能を停止。さらに最悪だったのはその後の挙動とされています。停止したSRIは、デバッグ用の診断データをメインコンピュータに送信しましたが、メインコンピュータはこのデータを「ロケットの飛行データ（姿勢情報）」だと誤認してしまったのです。
「機体が猛烈な勢いで傾いている」と判断したメインコンピュータは、必死に姿勢を修正しようとしてエンジンのノズルを限界まで動かしました。その結果、機体は急激な負荷に耐えきれずに破壊され、自動自爆へと至ることになったのです。
2-3. 検証不足が明らかにした「盲点」
さらに衝撃的だったのは、エラーを引き起こしたコードは、アリアン5の飛行中には全く必要のない機能だったということでした。
実は問題となった水平バイアスの計算処理は、ロケットが発射台で待機している間に慣性基準装置（SRI）の調整を行うためのものでした。アリアン4の運用では、万が一カウントダウンが中断された際に素早く再開できるよう、離陸後も計算を継続する仕様になっていました。しかし、アリアン5の運用手順では、離陸後の再開は想定されていませんでした。つまり、この機能は必要ありませんでした。
不要なコードが、想定外の数値を受け取り、システム全体を巻き込んで自爆したのが事故の真相でした。
なぜ事前のテストでこれが見つからなかったのでしょうか。調査委員会の報告によれば、SRI単体のテストは行われていましたが、アリアン5の実際の軌道データを完全に再現した環境では実施されていなかったようです。開発チームは、アリアン4で実証済みということに信頼を置きすぎて、新しい環境下での過酷な統合テストや、実機と同じ条件でのシミュレーションを省略していたのでした。
3. 生成AI時代は「昨日動いたコードは今日も正しいか？」と気をつける
3-1. 教訓1：仕様変更と「前提条件」の見落とし
アリアン5の爆発は、単なる宇宙開発の失敗談ではありません。ここには、Webサービスや業務システム開発に携わる現代のエンジニアにも通じる、普遍的な教訓が詰まっているように思えます。
最大の教訓は、「コードの再利用」に潜むリスクです。再利用自体は開発効率を高める素晴らしい手法で、最近では生成AIを活用するなどして積極的に活用されています。そこには必ず「文脈（コンテキスト）の確認」が必要です。
アリアン4のコードは、アリアン4という「前提条件」では正しく動作していました。しかし、アリアン5という新しい環境に置かれた瞬間、その正しさは失われることになりました。
私たちが日常的に行う「以前のプロジェクトのコードをコピー＆ペーストする」あるいは「ライブラリをアップデートする」といった行為も同じでしょう。「入力値の範囲は変わっていないか？」「負荷の規模は同じか？」という前提条件の再確認を怠れば、古いコードが時限爆弾になってしまうこともあり得ます。コード自体にバグがなくても、仕様（環境）との不整合がバグになってしまうわけです。
3-2. 教訓2：なぜ「テスト」で防ごうとしなかったのか？
アリアン5の事例は、「正常系のテスト」だけでは不十分だということを教えてくれます。
開発時のテストでは、SRIがエラーを起こした場合の挙動について十分なシミュレーションが行われていなかった可能性が高いと思われます。とくにアリアン5の実際の軌道データを流し込んでSRIを動かすという統合的なテストが行われていれば、このオーバーフローは離陸前に100%検出できていたはずだという指摘もあるほどです。
「単体テストで合格だったから大丈夫」と安心していないでしょうか。個々の部品が正常でも、それらが組み合わさり、想定外のデータが流れてきたときにどう振る舞うかは分かりません。実環境を模した、あるいは限界値を超えたデータを投入する「異常系テスト」や「統合テスト」の重要性が高いことをアリアン5の事故は教えてくれています。
3-3. 教訓3：「レビュー」の形骸化の罠
最後に、コードレビュー（設計レビュー）の問題です。実際のところ開発者たちはオーバーフローの危険性を全く認識していなかったわけではない、といわれています。
事実、該当するコードには7つの変数があり、そのうち4つにはオーバーフローを防ぐ保護コード（ガード処理）が入っていたとされています。しかし、問題となった「水平バイアス（BH）」を含む残りの3つには保護がありませんでした。なぜ保護しなかったのでしょうか？
それは「アリアン4の物理的な性能限界」を根拠に、「この変数がオーバーフローすることは物理的にあり得ない」と判断されていたからです。さらに、当時のコンピュータの計算能力（CPU負荷）を考慮し、不要なチェック処理を省いてパフォーマンスを稼ぎたい――という意図もあったとされています。
この判断自体は、当初の時点では論理的だったと言って良いと思います。しかし、ロケットがアリアン5に変わったとき、この「保護しなくてよい理由」は崩れ去っていたことになります。レビューにおいて「なぜ保護しないのか？」という指摘が環境の変化に合わせて再評価されていなかったことになります。レビューが形骸化することの恐ろしさといってよいでしょう。
「昔決めたルールだから」「今までうまく行っているから」で思考停止せず、常に「今の状況でもその判断は正しいか」と問い続ける姿勢がこれからの時代のエンジニアには求められている気がします。
4. まとめ
1996年のアリアン5爆発事故は、約370億円という巨額の損失とともに、私たちに重い教訓を残してくれました。原因は単純なことの組み合わせでしたが、その背景には「コード再利用時の前提条件の不一致」「実環境を想定したテストの欠如」「変化に対応しきれなかった設計判断」という、組織的・プロセス的な問題が横たわっていました。生成AIが進歩し、技術が進化しても、私たち人間が「仕様」と「環境」の関係を正しく理解し、謙虚に検証し続けることの重要性は変わらないのだと思います。
