1969年7月20日、人類は初めて月面に降り立ちました。
アポロ11号の船長ニール・アームストロングが月面に残した足跡は、宇宙開発の歴史に刻まれています。その歴史的な瞬間を支えていたのは、ロケットエンジンや宇宙飛行士の操縦技術だけではありませんでした。
月着陸船の内部では、一台の小さなコンピューターが飛行を制御していました。そのソフトウェアを開発したチームを率いていたのが、数学者でありコンピューター科学者のマーガレット・ハミルトンです。
2026年9月30日、ハミルトンは90歳で亡くなりました。マサチューセッツ工科大学（MIT）は10月7日、彼女の生涯と功績を振り返る追悼記事を発表しています。
1969年、アポロ計画のソースコードの印刷資料と並ぶマーガレット・ハミルトン
1969年、アポロ計画のソースコードと並ぶマーガレット・ハミルトン。写真：Draper Laboratory / The Planetary Society（CC BY 3.0）。
彼女が取り組んだのは、まだ「ソフトウェアエンジニアリング」という考え方が十分に確立されていなかった時代の仕事でした。
コンピューターの記憶容量は、わずか数十キロワード。プログラムは今のように簡単に書き換えられず、製造された固定メモリの内容を宇宙で変更することもできませんでした。
そんな環境で、彼女たちは何を作り、どんな困難に直面し、どのように乗り越えていったのでしょうか。
今も残されているアポロ11号のソースコードとNASA、MITの記録から、当時の技術者たちの仕事をたどります。
「ソフトウェアエンジニア」という職業が確立される前に
ハミルトンがMITで働き始めたのは1959年のことです。
1936年にアメリカのインディアナ州で生まれた彼女は、大学で数学を学び、1958年にアーラム大学を卒業しました。その後、ボストンへ移り、MITで気象予測のためのプログラム開発に携わるようになります。
当時、コンピューターは大学や軍事研究機関、大企業などに置かれた特別な設備でした。個人が自由に使えるものではなく、プログラムを書く仕事も、ハードウェアの設計と同じようには評価されていませんでした。
1961年、MITの計装研究所はNASAからアポロ計画の誘導システム開発を任されます。ハミルトンが計画に参加したのは1965年でした。
その後、彼女は宇宙船の搭載ソフトウェアを開発するチームを率いる立場になり、1968年には司令船・機械船のソフトウェア部門を統括する副責任者となりました。アポロ計画のソフトウェア開発には、400人以上が関わっていたといいます。
宇宙船のプログラムを作るには、計算式を正しく実装するだけでは足りません。
宇宙飛行士が操作を間違えるかもしれない。センサーが予期しない信号を出すかもしれない。コンピューターに処理しきれないほど仕事が集中するかもしれない。
そうした状況まで想定しながら、安全に飛行を続けられる仕組みを考える必要がありました。
ハミルトンは、ソフトウェアの開発もハードウェアと同じように設計や検証を必要とする工学だと考え、「ソフトウェアエンジニアリング」という言葉を使って、その考え方を広めていきます。
最初から周囲に理解されていたわけではありません。それでも、彼女たちがアポロ計画で積み重ねた仕事は、ソフトウェアを工学として捉える考え方を広めるうえで、大きな役割を果たしました。
アポロ11号を動かした、小さなコンピューター
アポロ宇宙船には、Apollo Guidance Computer（AGC）という誘導コンピューターが搭載されていました。
月へ向かう司令船にも、月面へ降りる月着陸船にも、それぞれ専用のAGCがありました。
アポロ誘導コンピューターの操作・表示装置DSKY
アポロ誘導コンピューターの操作・表示装置。画像：Wikimedia Commons。
その記憶容量は、今のコンピューターと比べると驚くほど小さなものでした。
| 項目 | アポロ誘導コンピューター（Block II） |
|---|---|
| 基本発振周波数 | 2.048 MHz |
| 派生するタイミング信号 | 1.024 MHz |
| 書き換え可能メモリ | 2,048ワード |
| 固定メモリ | 36,864ワード |
| データ形式 | 15ビットのデータと1ビットのパリティ |
| 主なプログラミング方式 | AGCアセンブリ言語、インタプリタ命令 |
データ部分だけを現代のバイト単位に換算すると、書き換え可能メモリは3,840バイト、固定メモリは69,120バイトに相当します。ただ、記憶方式やアドレスの扱いが現在とは異なるため、単純にパソコンの容量と比較できる数字ではありません。
この小さなコンピューターで、宇宙船の姿勢や進む方向を計算し、エンジンの噴射を制御し、宇宙飛行士に必要な情報を表示していました。
さらに、プログラムの保存方法にも大きな制約がありました。
アポロのソフトウェアは、「コアロープメモリ」という特殊な固定記憶装置に格納されていたのです。
アポロ誘導コンピューターで使われたコアロープメモリ
アポロ誘導コンピューターで使われたコアロープメモリ。画像：Wikimedia Commons。
磁性体の小さなコアに導線を通すか、通さずに迂回させるか。その違いで情報を記録する仕組みで、製造には細かな配線作業が必要でした。
今ならプログラムを修正して保存すれば済む変更でも、当時は記憶装置の製造工程にまで影響します。修正の時期によっては、飛行スケジュールにも関わる問題でした。
それでも技術者たちは、宇宙飛行中に問題が起きた場合の対処法まで考えていました。
1971年のアポロ14号では、故障した中止スイッチの影響を回避するため、地上から送られた手順に従って、宇宙飛行士が書き換え可能なメモリへ命令を入力した例があります。
固定メモリそのものを変更することはできなくても、残された手段を使って問題に対応していたのです。
4歳の娘が発見した、宇宙船の重大な弱点
ハミルトンの仕事を語るうえで、娘のローレンが偶然見つけた問題は外せません。
当時4歳だったローレンは、母親が働くMITの研究所で、アポロ宇宙船のシミュレーターに触れる機会がありました。
ある日、ローレンが操作したことで、飛行中のシミュレーターに打ち上げ前のプログラム「P01」が呼び出され、システムが正常に動かなくなってしまったのです。
ハミルトンは、同じことが本番の宇宙飛行でも起こるかもしれないと考えました。
そこで、飛行中に誤ったプログラムを実行できないよう、ソフトウェア側で防ぐ仕組みを提案します。
ところが、提案は採用されませんでした。十分な訓練を受けた宇宙飛行士が、そのような操作を間違えるはずはないと考えられていたためです。
しかし1968年、アポロ8号の飛行中に、宇宙飛行士のジム・ラヴェルが誤ってP01を実行し、航法データが失われる問題が発生しました。
ハミルトンたちは復旧に協力し、その後、同じ問題を防ぐための変更がプログラムへ組み込まれました。
どれほど訓練を積んだ人でも、操作を間違えることはあります。
だからこそ、間違えた人を責めるのではなく、間違いが起きても危険な状態にならない仕組みが必要になります。
人間は間違える。その前提でシステムを作る。
ハミルトンが大切にしていた防御的プログラミング（Defensive Programming）は、こうした考え方に根ざしています。
入力内容の検証、操作ミスの防止、異常発生時の復旧。現在のソフトウェアでも大切にされている仕組みですが、アポロ計画では、それが宇宙飛行士の命に直結する問題でした。
アポロ11号のソースコードを、今でも読むことができる
アポロ計画の技術を知る手がかりは、当時の証言や写真だけではありません。
宇宙船に搭載された誘導コンピューターのプログラムも、資料からデジタル化され、現在はGitHubで公開されています。
公開されているのは、司令船用の「Comanche055」と月着陸船用の「Luminary099」です。MIT Museumなどが保存していた印刷資料をもとに転記され、現代の開発者による補正や注記も含まれています。
月着陸船のプログラムを開くと、こんな名前のファイルが見つかります。
BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc
THE_LUNAR_LANDING.agc
LUNAR_LANDING_GUIDANCE_EQUATIONS.agc
FRESH_START_AND_RESTART.agc
EXECUTIVE.agc
WAITLIST.agcこれらは現在の公開リポジトリで使われているファイル名です。1969年当時のプログラムが、そのまま同じファイル構成で管理されていたわけではありません。
中でも目を引くのが、エンジンの点火処理に関係するBURN_BABY_BURNという名前です。
開発者のドン・アイルズは、この名前について、当時のラジオDJ、マグニフィセント・モンタギューが使っていた「Burn, baby! Burn!」というフレーズに言及しています。
一方、開発に関わったピーター・アドラーは、当時の社会運動などで使われていた同じ言葉について語っています。由来についての証言は一致していないため、どちらか一方が正しいとは断定できません。
人類を月へ送り届けるという重い責任を背負った開発現場にも、当時の社会や文化が入り込んでいたことが伝わってきます。
ここに残されたコードは、すべてハミルトン自身が書いたものではありません。
彼女は開発チームを率い、多くの技術者がそれぞれの機能を担当していました。アポロのソフトウェアは、一人の天才が作り上げたものではなく、たくさんの専門家が協力して完成させたシステムです。
ソースコードに残された設計の工夫
公開されたソースコードには、月面着陸の計算処理だけでなく、コンピューターの起動や再起動、仕事の管理に関するプログラムも含まれています。
例えば、EXECUTIVE.agcはコンピューターが実行する仕事の管理に関係するもので、FRESH_START_AND_RESTART.agcには再起動のための処理が含まれています。
月面着陸を目指すコンピューターに、どうして再起動の仕組みが必要だったのでしょうか。
その理由がよく分かる出来事が、1969年7月20日の月面着陸直前に起きています。
月面まであとわずか――突然の「1202」警報
月着陸船イーグルが月面へ向けて降下していたとき、誘導コンピューターが突然、警報を出しました。
表示された数字は「1202」。
着陸まで、あと数分という場面でした。
この警報は、コンピューターが新しい仕事を実行するために必要な「Core Set」という作業領域を確保できなくなったことを知らせるものでした。
原因は、ランデブーレーダーに関連する信号や設定によって、余分な処理が繰り返し要求されていたことでした。その影響で、限られた処理資源が圧迫されていたのです。
さらに「1201」という警報も発生します。こちらは「VAC」と呼ばれる、別の作業領域が不足していることを示していました。
コンピューターが処理しきれないほどの仕事を抱えてしまった状態です。
それでもイーグルは、月面への降下を続けました。
このような状況に備えて、開発チームがソフトウェアを設計していたためです。
月面に着陸したアポロ11号の月着陸船イーグル
月面に着陸したアポロ11号の月着陸船イーグル。写真：NASA、撮影：ニール・アームストロング。原画像・利用条件。
Wikimedia Commons
すべての処理を平等に扱わない
アポロの誘導コンピューターには、宇宙船の姿勢や進路を計算したり、エンジンを制御したり、宇宙飛行士に情報を表示したりと、さまざまな仕事がありました。
しかし、そのすべてが同じくらい大切というわけではありません。
月面へ降下している最中なら、飛行を制御するための計算を優先する必要があります。限られた能力の中で、安全な着陸に必要な仕事を続けるためです。
アポロのソフトウェアには、それぞれの仕事に優先順位を付ける仕組みがありました。
さらに、処理が限界を超えた場合には再起動し、必要な状態を復元しながら、選択したプログラムを再開できるようになっていました。
1201・1202警報が発生したときの流れ
- ランデブーレーダーに関連する余分な仕事が繰り返し要求される。
- コンピューターの作業領域が不足し、1201・1202警報が発生する。
- ソフトウェアが再起動を行う。
- 月面降下に必要なプログラムを選択して再開する。
- 余分に要求された仕事は、すべてをそのまま再開するわけではない。
これは、MIT計装研究所の開発担当者ピーター・アドラーによる回想をもとに、処理を簡略化したものです。実際には、再起動と必要な仕事の選択的な復旧を組み合わせています。
地上の管制チームは警報の内容を判断し、着陸の続行を許可しました。
この場面では、ハミルトンだけでなく、月面降下プログラムを担当したドン・アイルズ、動力飛行プログラムを担当したピーター・アドラー、警報の判断に関わったNASAのジャック・ガーマンや管制チームなど、多くの技術者が関わっていました。
1969年7月20日、アポロ11号との交信を担当したNASAの管制室
1969年7月20日、アポロ11号との交信を担当したチャールズ・デューク、ジム・ラヴェル、フレッド・ヘイズ。写真：NASA（S69-39601）。原画像・利用条件。
Wikimedia Commons
事前に作り込まれていたソフトウェアと、地上での冷静な判断。その両方があったからこそ、着陸を続けられたのです。
詳しい経緯は、NASAのApollo Lunar Surface Journalに掲載された開発担当者の回想にも残されています。
1969年7月20日、イーグルは無事に月面へ着陸しました。
何の問題も起きなかったから成功したのではありません。
問題が起きたときにも飛行を続けられるよう、あらかじめ設計されていたことが、成功を支えていました。
女性技術者として歩んだ、アポロ計画の時代
1960年代のアメリカでは、科学技術の分野、とりわけ工学研究の指導的な立場に就く女性は少数でした。
ハミルトンも、そんな時代にキャリアを築いた一人です。
1965年にアポロ計画へ参加した彼女は、やがてソフトウェア開発チームを率いる立場になりました。MITの追悼記事によれば、1968年には司令船・機械船のソフトウェア部門を統括する副責任者となり、アポロのソフトウェア開発には400人以上が関わっていました。
彼女たちが向き合っていたのは、技術的な難しさだけではありません。
当時は、ソフトウェアの開発そのものが、ハードウェアほど重要な工学分野として認められていませんでした。
ハミルトンは、ソフトウェアにも設計や検証が必要であり、その仕事を正式なエンジニアリング分野として扱うべきだと考えていました。
プログラムは、機械に命令を与えるためだけのものではありません。複雑なシステムを安全に動かすには、何が起きる可能性があるのか、問題が起きたときにどう対処するのかまで考えて設計する必要があります。
今では当たり前に思える考え方ですが、ソフトウェア開発という仕事そのものが新しかった時代に、その重要性を理解してもらうのは簡単ではありませんでした。
「失敗しない」よりも、「失敗に備える」
アポロ計画で培われた経験は、月面着陸の成功で終わりませんでした。
ハミルトンはその後も、ソフトウェアの不具合を開発の早い段階で見つけ、防ぐための研究を続けます。
1976年にはHigher Order Softwareを設立し、その約10年後にはHamilton Technologiesを設立しました。複雑なシステムの信頼性を高めるため、開発手法やツールの研究を進めていきます。
彼女が取り組み続けたのは、優れたプログラムを書くことだけではありません。
人間の誤操作や予期しない出来事が起きても、それが取り返しのつかない事故につながらないようにすることでした。
これは今の技術開発にも通じる考え方です。
航空機や医療機器、自動運転システム、金融システムなど、コンピューターの不具合が大きな被害につながる分野はたくさんあります。
コンピューターの処理速度や記憶容量は、アポロ計画の時代から大きく進歩しました。それでも、設計者が想定していなかった問題が起きることはあります。
システムが複雑になれば、考えなければならない組み合わせも増えていきます。
半世紀以上前にアポロの技術者たちが向き合っていた課題は、今のソフトウェア開発ともつながっています。
月面に残った足跡と、地上に残されたソースコード
1969年に撮影された、有名な写真があります。
マーガレット・ハミルトンが、アポロ計画のソフトウェアを印刷した大量の書類と並んで立っている写真です。
積み上げられた書類は、彼女の背丈ほどもあります。
そこに記録されているのは、宇宙船を動かすための命令と、何度も繰り返された検討や修正、実験の積み重ねです。
写っている書類は、ハミルトン一人が書いたものではありません。MITの説明によれば、司令船と月着陸船のソフトウェア開発チームが作り上げた成果です。
ハミルトン自身も、アポロ計画を振り返り、やり直しの機会がなかった当時の状況について語っています。
それでも彼女は、自分たちを幸運だったと振り返っていました。
先駆者になる以外に選択肢はありませんでした。
2009年にMIT Newsへ語った言葉の一部です（原文は英語、筆者訳）。
Massachusetts Institute of Technology
当時の技術者たちには、今のような開発環境も、豊富なライブラリも、インターネット上の技術情報もありませんでした。
多くの問題に前例がなく、自分たちで解決策を探す必要がありました。
それでも彼女たちは、限られた資源の中でシステムを作り、起こり得る問題に備え、何度も検証を重ねました。
そして、人類を月へ送り届けたのです。
ハミルトンの功績は、アポロ11号の成功に貢献したことだけではありません。
コンピューターがどれほど進歩しても、人間は間違えます。予期しないことも起こります。だからこそ、そうした事態を想定し、技術によって備える必要があります。
月面には、宇宙飛行士たちが残した足跡があります。
地上には、彼女たちが作り上げたソフトウェアの記録が今も残されています。
そして、その記録に込められた設計の考え方は、現在のソフトウェア開発にも受け継がれています。
マーガレット・ハミルトン氏のご冥福をお祈りします。
