1969年、アポロ11号で人類が初めて月面に降り立とうとする数分前、船内に警報音が響きました。コンピュータが表示したのは「1201」と「1202」というコード。これはシステムの処理能力が限界を超えたことを告げる、絶体絶命のサインでした。この危機を救ったのは、マーガレット・ハミルトンが率いたチームによるソフトウェア設計でした。彼女たちが設計したシステムは、正しく動くだけでなく、予期せぬエラーが起きても止まらないという、現代のエンジニアにとっても究極の目標といえるレジリエンス（回復力）を備えていました。「システムが落ちなければ、ロケットも落ちない」。今回は、アポロ11号計画を救った技術的背景と、ハミルトンが確立した設計思想、現代のエンジニアが学びたいヒントをまとめていきます。
- もくじ
1. 「落ちないシステム」がアポロ11号を救った
1-1. 月面着陸直前に鳴り響いた1201／1202アラーム！
1969年7月20日、人類史上初の月面着陸を目前にしたアポロ11号の着陸船「イーグル」が、高度数千メートルの地点で降下していたとき、事件は起きます。突然、船内のディスプレイに「1202」というアラームコードが表示され、続いて「1201」が点灯しました。これらは「エグゼクティブ・オーバーフロー」と呼ばれる重大なエラーを意味していました。
具体的には、「アポロ誘導コンピュータ（Apollo Guidance Computer＝AGC）」が処理すべきタスクの量が、その処理能力の限界を超えた過負荷状態に陥っていました。当時のAGCは、現代のスマートフォンと比較にならないほど非力なものでした。
トラブルの原因は、司令船とのドッキングに使用するランデブーレーダーのスイッチが誤ってAUTOモードでオンになっていたことでした。そのため、不要なデータ信号がAGCへ流れ込み、過負荷状態になってしまったのです。着陸という最も重要な局面で「よりによって！」といいたくなるなる事態になってしまったのです。
The Apollo Lunar Surface Journal and Apollo Flight Journal（NASA）
1-2. コンピュータ過負荷でも致命的問題を避けた
絶体絶命の過負荷状態にありながら、なぜ、AGCはダウンしたり、フリーズしたりしなかったのでしょうか。止まらなかった理由はマーガレット・ハミルトンが率いたチームによるソフトウェア設計にあり、なかでも「優先度付きスケジューリング」という設計思想にありました。
AGCのリアルタイムOSである「EXECUTIVE」は、すべてのタスクに優先順位を割り当てて管理していました。システムが過負荷を検知すると、低優先度のタスクを自動的にキャンセルし、高優先度のタスクにリソースを集中させる仕組みになっていたのです。
今回のケースでは、過負荷の原因となっていたレーダー由来の不要なデータ処理（これは低優先度でした）が切り捨てられ、一方で着陸に不可欠な航法計算や姿勢制御、エンジン制御といった重要タスク（高優先度）が守り抜かれたことになります。賢い優先順位付けによって、AGCは「一部の仕事を諦めて全体を守る」という選択を行い、致命的な停止を免れることができたのです。
1-3. イーグル着陸を支えた設計思想
重要タスクだけを生かす設計は、決して偶然の産物ではありません。ハミルトンたちは「予期せぬ問題は必ず発生する」という前提に立って、システムが部分的に異常をきたしても、最重要機能だけは継続させる「フォールトトレラント（故障耐性）」な設計を徹底していました。
また、エラーが発生した際に人間が状況を把握し、介入できるようにする「Priority Displays（優先表示）」というインターフェースも実装しました。これは、緊急時に通常画面を上書きして警告を表示し、宇宙飛行士に「今、最も重要な情報」を提示する仕組みです。これは現代では広く知れ渡っていて、SF映画などでよくお目にかかるピンチの表示方法です。
ハミルトンのチームは、レーダーのノイズやセンサー異常といった干渉を想定して、テストを繰り返していました。こうした不完全さを前提にした堅牢な設計があったからこそ、燃料残量がわずか30秒という極限の状態でも、イーグルは無事に月面へ降り立つことができたのです。
1-4. 管制官と宇宙飛行士が「GO」できた理由
アラームが鳴り響く緊迫した管制室で、着陸続行の「GO」を判断したのは、当時20代の管制官ジャック・ガーマンと、飛行管制官ジーン・クランツたちでした。彼らが冷静に判断できた背景には、ソフトウェアとその設計者たちへの深い信頼がありました。
ガーマンたちは事前訓練において、ハミルトンのチームから、1201や1202といったアラームは、低優先度タスクの削除を意味していて航法自体には影響しないと詳しく説明を受けていました。ソフトウェアは正しく動作しており、「現在、負荷が高くても、重要な仕事は継続している」とシグナルを出していると判断して、管制官は「GO」を出すことができたのです。
アームストロング船長もその判断を信じ、手動制御を併用しながら無事に着陸を果たしました。これは、単なるコードの優秀さだけでなく、開発者と運用者の間で設計思想が共有されていたことが命綱となったといって良いと思います。
1969年のアポロ11号のミッションの模様は2019年に公開された映画『アポロ11 完全版（Apollo 11）』で見ることができます。それまで一般公開されていなかったアーカイブフィルムのみで構成されているドキュメンタリー映画です。
2. マーガレット・ハミルトンと「ソフトウェア工学」
2-1. マーガレット・ハミルトンの美学
マーガレット・ハミルトンのキャリアは、MITリンカーン研究所で防空システム「SAGE（セージ）」の開発から始まりました。SAGEは敵機の襲来をレーダーで検知するシステムであり、彼女はそこで「ノイズの中なかからいかに異常を正確に検知するか」という課題に没頭しました。
彼女の美学は、ソフトウェアは人間のミスをカバーし、異常を自ら回復できるものであるべきだという信念に貫かれています。彼女は人間は必ず間違えるという現実を設計の核に据え、あらゆる異常入力を想定した防御的プログラミングを追求しました。
アポロ計画においても、彼女はこの哲学を持ち込み、宇宙線による影響やハードウェア故障さえも前提とした、徹底的にタフなコードを書き上げていきました。
Margaret Hamilton Reflects on Life, Career, and SAGE（MIT Lincoln Laboratory）
2-2. 「ソフトウェア工学」の誕生
1960年代当時、ソフトウェア開発はまだまだ職人技の世界で、体系的な方法論は存在しませんでした。プログラムを書くことはハードウェアのおまけのような扱いで、開発環境もドキュメント化が不十分な状態でした。
ハミルトンはこの状況に危機感を抱き、自分たちの仕事を他のハードウェア開発と同等の厳密な規律を持つ「工学」として定義しようとしました。そこで彼女が造語したのが「ソフトウェア工学（Software Engineering）」という言葉です。そして、ソフトウェア工学において厳密な仕様策定、コードレビュー、テストの標準化を推進しました。彼女のこの先見の明が、後にCI/CDやユニットテストといった現代の開発プロセスの原型となり、ソフトウェアを職人技から工学へと進化させることになります。
2-3. 「完全なシステム」を目指す
ハミルトンが提唱したソフトウェア工学の究極の目標は、エラー検出から自動回復までを一貫して行う「完全なシステム」の構築でした。彼女は、正常な動作を記述するだけでは不十分であり、異常が発生した際にシステムがどう振る舞うかを設計することこそが最も重要だと主張しました。
アポロのAGCでは、非同期処理と優先スケジューリングを用いることで、緊急時でもシステムを自律的にリカバリさせる機構を組み込みました。これは「man-in-the-loop」という概念にも通じています。機械が完璧でないことを前提に、人間が適切にバックアップや介入を行えるようサポートする設計です。
このように、エラーを排除しようとするのではなく、エラーを「システムの一部」として織り込むアプローチこそが、彼女の目指した工学の本質だったといって良いと思います。
2-4. 後年の評価と大統領自由勲章
ハミルトンの功績が世界的に再評価されたのは、2000年代以降のことです。2016年、彼女は当時のバラク・オバマ大統領から、アメリカにおける民間人の最高名誉である「大統領自由勲章」を授与されました。
なぜ今、彼女の評価が高まっているのか。それは、現代の自動運転、航空制御、クラウドインフラなど、社会の根幹を支える「超信頼性システム」が、すべて彼女の確立した「エラー前提の設計思想」を基盤にしているからです。
彼女が50年以上前に提唱した概念は、ソフトウェアが社会インフラとなった現代において、より一層その重要性を増しています。彼女はまさに、現代デジタル文明の礎を築いた「ソフトウェアの母」として最先端で活躍する女性たちの象徴になっています。
Apollo code developer Margaret Hamilton receives Presidential Medal of Freedom（MIT News）
3. アポロ誘導コンピュータとフォールトトレラント設計
3-1. Apollo Guidance Computer（AGC）とは？
アポロ誘導コンピュータ（AGC）は、当時としては極めて革新的な初の集積回路（IC）を採用したコンピュータでありながら、現代の基準から見れば驚くほど制約の多いハードウェアでした。そのメモリ容量は、固定記憶（ROM）が36キロワード、書き換え可能なメモリ（RAM）にいたってはわずか2キロワード（約4KB）しかありませんでした。
この限られたリソースで、月の軌道計算から姿勢制御、着陸操作といった複雑なリアルタイム処理を同時にこなさなければなりませんでした。AGCの処理速度は現在の電卓以下という極限の環境でしたが、ハミルトンのチームは効率的なタスクモデルを構築することで、ミッションのすべてを司る「脳」としての役割をこの小さな箱に持たせたのです。
3-2. EXECUTIVEとPriority Displays
AGCの動作を支えていた中核ソフトウェアが、リアルタイムOSの「EXECUTIVE」です。これは「優先度付きスケジューリング」を採用した非同期処理システムで、常に最も優先順位の高いタスク（例えば宇宙飛行士への表示を行うジョブなど）を優先して実行する仕組みでした。
また、人間と機械の協調を象徴する機能が「Priority Displays（優先表示）」です。これはコンピュータが過負荷などの異常を検知した際、現在行っている表示を中断して、人間が今すぐ判断すべき「警告」を最優先で画面に出す仕組みです。
コンピュータが「今は非常に忙しいので、本当に大事なこと以外は話しかけないでほしい」と人間に伝えつつ、人間をシステムのエラー回復プロセスの一部（割り込み可能な人間インターフェース）として組み込んでいたことになります。
3-3. 「防御的設計」とは
ハミルトンが徹底したのは、「すべてが完璧に進む」という楽観を捨てた「防御的設計」です。これは、ハードウェアの故障、センサーのノイズ、あるいは人間の操作ミスといった異常な入力は必ず発生するという前提に立ち、それによってシステム全体が崩壊しないようにあらかじめ対策を講じる設計手法です。
アポロ11号のケースでは、ランデブーレーダーのスイッチ設定ミスにより不要なデータがAGCに流れ込み続けましたが、防御的設計のおかげでシステムは「何かがおかしい」と即座に検知しました。そして、主要な航法タスクを守るために、余計なデータ処理を切り捨てる「自己防衛」に入ったのです。このように、エラーを完全に防ぐのではなく、エラーが起きても「重要な機能だけは維持し続ける」フォールトトレラント（故障耐性）な設計が、アポロ11号の安全を支えました。
3-4. 「未知の障害を想定する」
ハミルトンのチームは、マニュアルに書かれた手順を実装するだけでなく、現場で起こりうるあらゆる「未知の障害」を想定してテストを繰り返しました。地上シミュレータを使って、レーダー信号の洪水やセンサー異常など、意図的に過酷な状況を作り出し、システムが正しく回復できるかを磨き上げたのです。
彼女たちは、正常に動作する「成功ルート」を作るのと同じ熱量で、何万通りもの「失敗するルート」を想定し、そのすべてから生還するためのコードを書き込んでいました。実際のアポロ11号で起きたアラームの組み合わせはシミュレーションでも完全には再現されていませんでしたが、それでもシステムが適切に対処できたのは、こうした「未知の敵を想定した設計」が根底にあったからに他なりません。
4. 「職人技」から「工学」への進化、現代エンジニアへの示唆
4-1. 「バグゼロ」幻想を捨てる
現代のエンジニアもつい「完璧なコードを書けばバグは出ない」という幻想を抱きがちですが、ハミルトンの教訓は「エラーは前提である」ということです。複雑なシステムにおいて、すべてのバグを排除することは事実上不可能です。
大切なのは、バグゼロを夢見ることではなく、バグや予期せぬデータに遭遇したときに「システムが止まらず、安全に振る舞う」ように設計しておくことです。アポロ11号の成功が示すように、「エラー上等」のマインドで、異常時でも致命的なクラッシュを回避する仕組みを組み込むことが、真の信頼性を生みます。
4-2. フェイルセーフ／フォールトトレラント設計を取り入れる
現代のシステム開発において、ハミルトンが実践した二つの設計思想は欠かせません。
フェイルセーフ
故障が発生した際、被害を最小限にするために「安全な状態」へ移行する設計です。例えば、電力が途絶えたら自動的にブレーキがかかるエレベーターのような考え方です。
フォールトトレラント
システムの一部が故障したり過負荷になったりしても、重要な機能を維持したまま運用を続ける設計です。アポロのAGCが低優先度タスクを捨てて着陸計算を守り抜いたのは、まさにこの具体例です。
これらは現代のクラウドシステムやマイクロサービスにおける「冗長化」や「自動復旧」の基礎となっており、障害を前提とした構成を初期段階から取り入れることが重要です。
4-3. 「エラー処理ファースト」の開発プロセス
多くの開発現場では、まず正常な機能（正常系）を作り、エラー処理は後回しにされがちですが、アポロの教訓はその逆でした。ハミルトンは、異常シナリオからコードを構築するエラー処理ファーストも実践していました。
「データが欠落したら？」「通信が途切れたら？」という異常系を設計の核に据え、回復策を機能と同等に扱う。このプロセスは現代の「テスト駆動開発（TDD）」にも通じるものであり、開発の初期からエラーハンドリングを習慣化することで、結果としてシステムの堅牢性と開発の生産性を格段に向上させることができます。
4-4. 「ソフトウェア工学」のマインドセット
「落ちない」システムを支えるのは、魔法のような「天才の閃き」ではありません。ハミルトンが示した、ソフトウェアを工学として扱うという規律、すなわち地道なコードレビュー、徹底的なテスト、そして詳細なドキュメント化の積み重ねということです。
エンジニアは、自分たちの仕事を個人のスキルに依存する職人技ではなく、体系的な理論に基づいた工学であることを自覚する必要があります。エラーを恐れて回避するのではなく、エラーを前提とした仕組みで責任を果たす。このマインドセットこそが、ハミルトンが残した最大の財産であり、現代を生きるエンジニアが成長するためのヒントとなると思います。
5. まとめ
アポロ11号の着陸時のピンチを救ったのは、マーガレット・ハミルトンが確立した「エラーを前提とする」ソフトウェア工学の思想でした。1201／1202アラームという危機に際し、優先度付きスケジューリングが重要処理を守り抜いた事実は、現代のエンジニアにも「不完全さを前提に、いかに堅牢なシステムを築くか」という普遍的な教訓を教えてくれます。職人技を超えた工学的な思考こそが、未来の「落ちない」システムを支えていくのではないでしょうか。
