宇宙で「Ctrl+Z」は効かない。1行のバグが数百億円をゴミに変える、ソフトウェア設計の執念

前回は、海外ベンダーとの泥臭い交渉や、
目に見えない電波との戦いである「電磁適合性（EMC）」
についてお話ししました。

書類が完璧でも、物理現象が牙をむく宇宙開発の厳しさを感じていただけたかと思います。

しかし、物理的な「器」が完成し、
過酷な環境試験を突破しても、まだ安心はできません。
最後に待ち構えているのは、目に見えない「論理」の迷宮
――ソフトウェアです。

地上のスマホアプリなら、バグがあれば
「とりあえずアップデート（修正パッチ）」を送ることもできます。

しかし、宇宙ではその常識は通用しません。
今回は、いかにして衛星エンジニアがソフトウェアの
「動作」を保証していくのか。
現場のエンジニアが守り抜く、検証の舞台裏をお届けします。

宇宙で「とりあえずアップデート」が許されない理由

現代のソフトウェア開発では
「アジャイル（素早く作って直す）」が主流ですが、
人工衛星において「とりあえず」という言葉は禁句です。

なぜなら、人工衛星へのソフトウェア書き換え（パッチ当て）は、
いわば「動いている心臓のバイパス手術」だからです。

衛星は、ソフトウェアをアップデートしている間も、
そして再起動した後も、何一つ変わらず
地上と通信したり、自分自身の姿勢や温度を制御したり
動作し続けなければなりません。

もしアップデートしたソフトに、わずか1行でもバグがあり、
再起動した瞬間に動作がフリーズしたらどうなるか。
地上からの命令（コマンド）は一切届かなくなり、
数百億円の結晶は、永遠に沈黙するだけの
「宇宙ゴミ」へと姿を変えます。

宇宙に「Ctrl+Z（元に戻す）」ボタンは存在しないのです。

実例：16進数の海で見つけた「消えた1バイト」

「宇宙へ行ったら、二度とやり直せない」

この絶対的な恐怖が骨の髄まで染み込んでいるからこそ、
私たちは打ち上げ前の「地上の試験」で、病的なまでの
慎重さを発揮することになります。

私が経験した、あるソフトウェアの動作確認での出来事です。

当時、ソフトウェアチームはある機器との通信機能の実装に難航しており、
チーム全員が神経を尖らせて検証を続けていました。

衛星システムエンジニアとして機材の操作や
インタフェース機能の動作確認に立ち会っていた私は、
提供された新しいソフトウェアを検証機に組み込み、走らせ始めます。

モニターに通信データが流れ始め、
試験室には「まずは動いた……」という、
重い安堵の空気が流れました。

しかし、私はその空気に浸ることなく、解析画面を睨み続けていました。

「本当に、データの中身まで正しいのか？」

16進数（Hex）の数値が滝のように流れる画面を
食い入るように見つめます。
その中で、ある特定のコマンドの末尾が、
常に「0」で固定されていることに気づいたのです。

「……1バイト、足りない気がする…」

すぐさま横にいるソフトウェアチームに懸念を伝え、
確認をお願いしました。

ソフトウェアチームの確認の結果、ソフト自体はエラーを吐かずに
「動いて」いました。
しかし、コマンドを生成・送信するロジックを詳細に解析した結果、
通信の末尾1バイトが欠落している不具合が判明したのです。

もしこれを見逃したままシステムを統合していれば、
致命的なインターフェース不整合を引き起こし、
衛星の「脳」をパニックに陥れていたでしょう。

「動いた」という安堵を捨て、冷徹に「16進数の生データ」という現物だけを疑う。
この執念こそが、宇宙ゴミを作らないための最後の防波堤になります。

宇宙流・トラブルシュート：「現物主義」の一問一答

もし不具合が見つかったとき、私たちはどうやって
真犯人を突き止めるのか。
ここにも宇宙流の「現物主義」があります。

複雑に絡み合ったソフトウェアのどこに原因があるか分からないとき、
私たちはまずソフトウェアを検証機に書き込み、
様々な考えられうるパターンで動作させてみます。

そうして、「どの組み合わせで論理が崩れるのか」
つぶさに記録していくのです。

それはまるで、複雑に絡み合った論理の糸を、
一つずつ解きほぐしていく作業です。
「この変数を変えれば正しく動くか？」
「では、この設定で異常検知を外すとどうなるか？」

シミュレーション上の推測ではなく、実機で機能を一つずつ剥ぎ取っていく消去法によって、
目に見えない論理の矛盾を、物理的な挙動として炙り出すのです。

結び：エンジニアが信じるのは「言葉」ではなく「記録」

宇宙エンジニアが信じるのは、
開発者の「直しました」という言葉でも、
設計書の「正しいはず」という論理でもありません。

「実機で、過酷な条件で、何度動かしても正常だった」という
冷徹な試験結果だけです。

デジタルのシミュレーションを過信せず、本番と全く同じ手順で
実機と同じ作りの検証機（EM：エンジニアリングモデル）に書き込み、
「真実」を確認します。

また、問題があったら修正した箇所以外に
悪影響（デグレード）が出ていないかを確認する
「退行試験」を、丁寧に、しかし執拗に繰り返します。

宇宙ビジネスにおける「品質保証」とは、決して華やかなプログラミング技術の優劣ではありません。
それは、「人間は必ず間違える」という謙虚な絶望から出発し、
目に見えない論理の隙間に潜むリスクを、実機という現場で
一つずつ、確実に潰していく執念の結晶なのです。

次回からは、少し趣向を変えて、この「衛星たちが提供するサービス」、
特に皆さんが絶対に毎日使用している「測位」をテーマに
お話をしたいと思います。

ちなみに、私たちはこの『目に見えない論理の闇』に
どう立ち向かっているのか？
実は、衛星まるごとの試作機が存在しない宇宙開発において、
私たちは机の上にむき出しの基板をスパゲッティのように並べた
「机上の人工衛星（フラットサット）」という独自の戦場を作り上げています。
機器という点をつなぎ、インターフェスという線でつなぎ、
「宇宙流ゼロトラスト」で戦う「インタフェース試験」について
ディープダイブ版でお話しします。

（本記事は、画像や文の一部に生成AIを使用しています。）