宇宙で使われているプログラミング言語は何か

この記事でわかること

• NASAのPerseveranceは約350万行、ISSは250万行のコードで動いている
• 火星探査車はC言語とVxWorks上で動作し、CPUは200MHzのRAD750
• スペースシャトルはNASA専用言語HAL/Sで約42万行書かれていた
• 1996年アリアン5爆発は16ビット変換オーバーフローで3.7億ドル損失
• JPLの「The Power of 10」は再帰禁止・動的メモリ禁止など厳格な10ルール
• NASAは2023年にメモリ安全な言語を推奨し、Rust採用への関心が高まっている

NASAの火星探査車「Perseverance」のソフトウェアは約350万行のコードで動いている。国際宇宙ステーション（ISS）の制御システムは250万行。人類が宇宙に送り出すハードウェアは、膨大なソフトウェアによって支えられている。では、宇宙ではどんなプログラミング言語が使われているのか。

宇宙開発の主要プログラミング言語

宇宙開発で使われる言語には、「信頼性」という地上とは次元の異なる要件がある。バグがシステムを落とせば、数十億ドルのミッションが消える。宇宙では「動けばいい」は通用しない。

言語	主な用途	採用理由
C	組み込みシステム、フライトソフトウェア	ハードウェア直接制御、高速実行
C++	地上管制システム、シミュレーション	オブジェクト指向による大規模開発
Ada	欧州宇宙機関（ESA）のフライトソフトウェア	安全性検証、型システムの厳密さ
Python	データ解析、ミッション計画	科学者が扱いやすい
MATLAB	軌道計算、制御系設計	数値計算に特化
HAL/S	スペースシャトルのフライトソフトウェア	NASA専用に設計された言語

HAL/S——NASAが宇宙のためだけに作った言語

スペースシャトルのフライトソフトウェアは、HAL/S（High-order Assembly Language / Shuttle）という専用言語で書かれていた。インターロック社が1970年代にNASAのために開発したこの言語は、地上では一切使われない「宇宙専用」の存在だ。

HAL/Sの特徴は、リアルタイム処理のための組み込みスケジューラと、数学的な表記に近い構文にある。変数名に上付き文字や下付き文字が使えるため、物理学の方程式をほぼそのままコードに変換できた。

スペースシャトルのソフトウェアは約42万行のHAL/Sで構成され、1行あたり約1,000ドルの開発コストがかかったとされる。バグ密度は1,000行あたり0.1件未満という驚異的な品質を達成していた。

火星探査車はC言語で動く

NASAのジェット推進研究所（JPL）が開発する惑星探査車は、主にC言語で書かれている。Curiosity（2012年着陸）もPerseverance（2021年着陸）も、VxWorksというリアルタイムOSの上でC言語のフライトソフトウェアが動いている。

C言語が選ばれる理由は明快だ。ハードウェアを直接制御でき、実行時のオーバーヘッドが最小限で、数十年にわたる信頼性の実績がある。宇宙の放射線環境では、ガベージコレクションのような予測不能なタイミングで動く処理は致命的になりうる。

探査車	着陸年	主要言語	コード行数	CPU
Spirit / Opportunity	2004年	C	約55万行	RAD6000 (20MHz)
Curiosity	2012年	C	約250万行	RAD750 (200MHz)
Perseverance	2021年	C	約350万行	RAD750 (200MHz)

Perseveranceに搭載されたRAD750プロセッサは200MHzで動作する。2000年代初頭のスマートフォン以下の性能だが、宇宙線に対する耐放射線性を持つ。このCPU上で350万行のCコードが火星の地表を走り回っている。

Pythonの宇宙進出

フライトソフトウェアはCやAdaの領域だが、ミッション計画やデータ解析ではPythonが主流になりつつある。2019年に人類史上初のブラックホール画像を生成したEvent Horizon Telescopeの画像処理パイプラインはPythonで書かれていた。

NASAのジェット推進研究所ではPythonが公式のスクリプト言語として採用されており、軌道計算やテレメトリ解析に使われている。宇宙の最前線で、Jupyter Notebookが動いているという事実は少し愉快だ。

宇宙開発のソフトウェアテスト：失敗から学んだ教訓

宇宙空間でのソフトウェアバグは、地上のバグとは次元が異なるコストを伴う。歴史的な事故事例から、宇宙ソフトウェア開発の教訓を振り返る。

年	事故	原因	損失
1996年	アリアン5ロケット爆発	64ビット浮動小数点を16ビット整数に変換するオーバーフロー	3.7億ドル
1999年	火星気候探査機MCO喪失	ヤード・ポンド法とメートル法の単位変換ミス	1.25億ドル
2004年	火星探査車Spiritの不具合	フラッシュメモリのファイルシステム不整合	修復に2週間

アリアン5の事故は特に教訓的だ。問題のコードはアリアン4から再利用されたものだった。アリアン4では問題なく動作していたが、アリアン5の飛行特性は異なり、変数の範囲が変わった。「テスト済みのコード」が環境変化で致命的バグになった事例として、ソフトウェアエンジニアリングの教科書に載っている。

これらの失敗を踏まえ、現代の宇宙ソフトウェア開発では「フォーマルメソッド」（数学的な正当性証明）が重視されている。JPL（NASAジェット推進研究所）のコーディング標準「The Power of 10」は、再帰禁止、動的メモリ確保禁止など、極めて制約の厳しい10のルールを定めている。

宇宙と地上で異なるプログラミングの「常識」

宇宙開発のソフトウェアエンジニアリングには、地上の開発者が当たり前だと思っている「常識」が通用しない領域がある。

再起動が最終手段ではない：地上のサーバーなら「再起動すれば直る」が許されるが、火星探査車を再起動するには地球からの指示に片道20分かかる。自律的なエラーリカバリーが必須だ。

アップデートが命がけ：火星探査車Curiosityは、2012年の着陸後も定期的にソフトウェアアップデートを受信している。しかし、アップデートの転送速度は最大で約2Mbps、通常は数百Kbps。数MBのパッチを送るだけで数時間かかる。しかもアップデートに失敗すれば、数十億ドルの探査車が文鎮になるリスクがある。

テストカバレッジの哲学が異なる：一般的なWebアプリケーションのテストカバレッジ目標は80%程度。NASAのミッションクリティカルソフトウェアでは、100%のブランチカバレッジが要求される。さらに、形式手法（formal methods）による数学的な正当性証明が加わる。1行のコードに対して、10〜20行のテスト・検証コードが書かれる世界だ。

動的メモリ確保の禁止：malloc()やnewは宇宙ソフトウェアでは原則禁止だ。メモリリークやフラグメンテーションがリアルタイム制御を不安定にするリスクがあるためだ。すべてのメモリは起動時に静的に確保される。

次世代の宇宙言語はRustか

NASAは2023年、ソフトウェア安全性ガイドラインでメモリ安全な言語の使用を推奨し始めた。これを受けて、宇宙開発におけるRust言語への関心が高まっている。

CとRustは実行速度で互角だが、Rustのコンパイル時メモリ安全保証は宇宙の要件に適合する。火星での「segmentation fault」は誰にも直せない——この事実が、Rustの宇宙進出を後押しするかもしれない。

200MHzのCPUで350万行のCコードが火星を走る世界で、次にコードを書くのは人間だろうか、それともAIだろうか。

違和感を大切にする

業界の常識に対して違和感を覚える瞬間は、自分の視点を磨く貴重な機会だ。

多数派の答えにすぐ同調せず、自分の言葉でその違和感を言語化する時間を取る。

違和感を深めることが、オリジナリティの源になっていく。