アポロ11号の1202警報でも着陸は続いた　ハミルトン氏が残した設計の教訓

月面着陸の船、着陸船「イーグル」のコンピューターが、降下中に突然警報を鳴らした。1969年7月20日のことだ。もし止まっていたら、着陸は失敗していたかもしれない。

ところが、機械は止まらなかった。再起動し、重要度の低い作業を手放して、着陸の計算を続けたのだ。壊れる前提で設計するという選択は、ソフトウェアにもハードウェアと同じ厳しさを求めた一人の人物から生まれた。

マーガレット・ハミルトン氏（Margaret Hamilton）は、アポロ計画の搭載ソフトウェアを書いたチームを率いた。ソフトウェア工学という分野そのものの土台づくりにも関わった人物である。

この記事のポイント

• ハミルトン氏はMITの計器研究所でソフトウェア工学部門を率い、アポロの誘導ソフトウェアを作った。
• 「ソフトウェア工学」という言葉を広め、コードにもハードウェア並みの厳しさと責任が必要だと訴えた。
• アポロ11号の着陸中に誘導コンピューターが過負荷になったが、優先順位と再起動の仕組みで重要な作業が続いた。
• 宇宙飛行士の操作ミスへの警告は一度退けられたが、アポロ8号で現実になった。
• 今のAIや自律システムにとっても高い基準になるが、そのまま当てはめるには限界もある。

ルールがない時代にルールを書いた技術者

ハミルトン氏がプログラミングを始めた1950年代後半、ソフトウェアはハードウェアの陰にあった。事務作業のように見られることも多く、「ソフトウェア工学」という言葉を使う人はほとんどいなかった。

ハミルトン氏は、この言葉をあえて使った。コードにも、回路や構造物と同じ重みを持たせたかったからだ。

計画を立て、レビューを受け、専門職として責任を負う。そういう扱いを求めたのである。

アポロにたどり着くまでには、二つの仕事があった。

1. 天気予測：MITで、気象モデルのためのソフトウェアを書いた。
2. SAGE防空システム：冷戦期に航空機を追跡した「半自動式地上防空システム（SAGE）」のプログラムを担当した。
3. アポロ：計器研究所で、司令船と着陸船の誘導コンピューター用の飛行ソフトウェアを書くチームを率いた。

彼女の遺産は、一つの考え方にある。何かは必ず間違うと考える。間違ったときにどう動くかを先に決めておく。「そんなことは起きないはず」という理屈を、設計の根拠にしない。

この姿勢は、長年のシミュレーションと失敗の分析から生まれた。今も、安全が命に関わるソフトウェアの土台になっている。

図2：マーガレット・ハミルトンのキャリア進展と主要プロジェクト

アポロ11号と1202警報：想定外に備える設計

1969年7月20日。着陸船イーグルは、「静かの海」に向けて降下していた。そのとき、誘導コンピューターが1201と1202の警報を出し始めた。

原因は、ランデブーレーダーにあった。降下中のレーダーの設定が、不要な信号を大量にコンピューターへ送っていたのだ。その信号が、着陸の計算に必要な処理時間を食いつぶしていった。

コンピューターの余力は、尽きかけていた。

ソフトウェアは固まらなかった。再起動し、重要度の低い作業を手放して、肝心な誘導の作業を続けた。

地上では、誘導担当のスティーブ・ベイルズ氏（Steve Bales）とソフトウェア担当のジャック・ガーマン氏（Jack Garman）が警報コードを見分けた。続けても安全だと判断し、「GO」を出した。

そのあと、ニール・アームストロング船長は手動に切り替えた。岩だらけの地帯を避けて飛び、燃料がごくわずかになったところで着陸した。

事前の設計が本番でどう働いたかを、表にまとめる。

警報は、コンピューターを過負荷にする計画の一部ではなかった。過負荷は本物のトラブルだった。それでも、システムはこうした状況を乗り切り、はっきり知らせるように作られていた。

世間では、一人の英雄や一行のコードが着陸を救ったように語られることがある。

しかし、本当に役立つ教訓は、もっと全体の話だ。長年かけて故障の起こり方を調べた人が大勢いた。

ソフトウェア、乗員、管制官が、負荷のかかる場面で協力できるよう準備していた。だから着陸は成功したのである。

誤りを防ぐという方法：シミュレーションから検証の文化へ

ハミルトン氏は、幼い娘のローレンさんの話をよくした。ときどき娘を研究所に連れて行くと、娘はシミュレーターで遊んでいた。

あるとき、模擬ミッションの飛行中に、発射前用のプログラムP01を選んでしまった。シミュレーションは止まった。

ハミルトン氏は、本物のリスクだと見た。宇宙飛行士が同じミスをすれば、航法データが消えてしまう。そこで、ソフトウェアに防御を加えることを提案した。

NASAは断った。訓練を受けた宇宙飛行士はそんな間違いをしない、というのが理由だった。ハミルトン氏は代わりに、文書に注意書きを加えた。

1968年12月のアポロ8号で、ジム・ラベル飛行士が飛行中にP01を誤って選んでしまった。航法データは失われた。ハミルトン氏のチームは管制センターと協力してデータを復元し、乗員は飛行を続けられた。

ミッションは無事に帰還したが、この出来事は彼女の主張の正しさを示した。のちにソフトウェアは、こうした誤りを防ぐように変更された。

この話は、防御策がすでにあったかのように語られがちだ。実際にはなかった。

本当の教訓はもっと鋭い。信頼できる警告が退けられ、現実が決着をつけたのだ。

こうした経験から、ハミルトン氏は仕事の原則をいくつか引き出した。

• 人の誤りを前提にする：操作する人は、間違ったキーを押す。最悪のタイミングで押すこともある。
• 穏やかに失敗させる：故障は、機能を減らすだけにとどめる。ミッションを終わらせてはいけない。
• テストを設計の一部にする：検証は最初から形づくるもので、最後の関門ではない。
• あらゆる層の誤りに備える：人も、センサーも、コード自体も間違うことがある。

アポロのあと、ハミルトン氏はこの考え方を事業にした。

1976年にHigher Order Softwareを共同で設立し、のちにHamilton Technologiesを立ち上げた。そこで「ユニバーサル・システムズ・ランゲージ」と、「事前開発」と呼ぶ手法を作った。

誤りを後から見つけるのではなく、設計の段階で防ぐことをねらったものだ。

こうした考え方の多くは、のちの防御的プログラミング、形式手法、耐障害アーキテクチャに通じている。

彼女の貢献は、技術であると同時に文化でもあった。間違う場合に備えることを、当たり前に、むしろ必須にしたのだ。

AI時代に生きる、安全最優先の教訓

検証にこだわったハミルトン氏の姿勢は、今のAIの安全性や説明責任をめぐる議論にも重なる。テクノロジー業界は、事故の報告やレビューの仕組みを整え始めている。

アポロの技術者たちも、同じような習慣を開発の流れに組み込んでいた。失敗が許されない状況だったからだ。

重大な場面で使うAIに、彼女のやり方を当てはめるなら、次のことが求められる。

• 失敗の形をはっきりさせる：導入前に、失敗とは何かを定義する。
• 穏やかに機能を落とす：確信が持てないときや過負荷のとき、システムができることを絞る。
• 人が介入できる道を残す：人が手を出せる経路を、はっきり用意し、テストしておく。
• 不確かさを正直に扱う：統計的な誤りは設計の前提であり、言い訳ではない。
• 事故から学ぶ：失敗を記録し、設計に戻す。

ただし、このたとえには本物の限界がある。

こうした違いのせいで、ハミルトン氏の方法をそのまま使うのは難しい。ただ、目的の価値が下がるわけではない。むしろ、中身を見にくいシステムほど、テスト、監視、代替手段の習慣が強く必要になる。

根本の責任は変わらない。負荷がかかる前に、システムが負荷の下でどう動くかを理解しておくことだ。

ロープメモリーから、機械が設計するシリコンへ

アポロのプログラムは、コアロープメモリーに収められていた。

作業員が、小さな磁気コアに電線を手で通したり巻きつけたりして、1ビットずつ物理的に刻んだのだ。一度織り上げたコードは、ほとんど変えられなかった。

この制約が、規律を生んだ。あとからの変更は時間もお金もかかる。だから、製造の前にコードを正しくしておく必要があった。

レビューは、省けるものではなかった。

今は、ソフトウェアとハードウェアの関係が変わっている。ソフトウェアが、自分が動くチップの設計を手伝うようになった。AIモデルも、計算によるチップ設計に加わっている。

その違いは、くっきりしている。

ハミルトン氏の仕事が示したのは、複雑なシステムを「ハードウェアの問題」と「ソフトウェアの問題」にきれいに分けられないことだ。故障は、その境目をまたぐ。厳しさは、システム全体に及ばなければならない。

厳しさが働く場所は動いたが、その必要性は変わらない。人が命令を織り込むにせよ、モデルが回路の案を書くにせよ、システムが実際に何をするのかを確かめるのは、結局人の仕事である。

評価と、残された課題

ハミルトン氏が広く評価されるまでには、時間がかかった。よく知られた写真では、自分の背丈ほどに積まれたアポロのソースコードの印刷物の横に立っている。

2016年には、バラク・オバマ大統領から大統領自由勲章を授与された。

彼女の物語は、テクノロジー分野で活躍する女性の象徴として語られることがある。その役割は本物で、意味も大きい。

ただ、そう要約すると、彼女の考えの中身が見えにくくなる。その中身とは、肝心なときに人を裏切らないシステムをどう作るか、ということだった。

彼女の仕事には、まだ終わっていない部分がある。重要なソフトウェアは今も、規制や検証が追いつかない速さで作られがちだ。

自律システムは、車、医療、インフラへと広がっている。そこで受け継がれるのが彼女の基準なのか、名声だけなのか。答えはまだ出ていない。

重要なシステムを作る人、買う人、監督する人にとって、彼女のやり方から引き出せる実践的な手順がある。

1. 失敗の形を先に書き出す：導入の前に、どう失敗しうるか、そのときどう動くべきかを一覧にする。
2. 操作ミスをわざと試す：ユーザーが、間違ったタイミングで間違ったボタンを押す場面を試す。
3. 退けられた警告を未解決の項目として残す：リスクを「起こりにくい」と判断したら、その理由を記録し、あとで見直す。
4. 人が引き継げるようにしておく：人が操作を引き継げるようにして、その練習もしておく。
5. ヒヤリとした事例も含めて学ぶ：すべての失敗を、設計とテストに戻す。

ちょっと立ち止まって

毎日頼っているシステムを一つ思い浮かべてみてほしい。銀行のアプリでも、車の運転支援でも、職場で使うAIツールでもいい。何かがおかしくなったとき、それがどう動くのかを、あなたは知っているだろうか。

ハミルトン氏の問いは、「ちゃんと動くか」だけではなかった。「動かなくなったとき、何が起きるのか」だった。信頼しているものほど、この問いを向けてみる価値があるのかもしれない。

図8：安全性重視設計の適用可能性：従来型ソフトウェアとAIシステムの比較（出典：Software engineering and AI safety literature synthesis）

図12：マーガレット・ハミルトンの受賞・表彰の歴史（出典：Hamilton biography and awards documentation）

図4：アポロ11号誘導コンピュータのシステムアーキテクチャと優先度スケジューリング（1202アラーム対応メカニズム）

図6：ハミルトンの誤り防止設計プロセス - シミュレーションから検証文化への体系的アプローチ

図10：コンピュータ技術の進化とソフトウェアエンジニアリングの適応（1960s-2020s）