衛星打ち上げ直後の山場：人工衛星の「生死」を分ける初期運用（LEOP）の舞台裏
前回は、人工衛星が宇宙へ旅立つ前に、地上でどれほど過酷な「環境試験」を行っているかをお話ししました。
太陽の灼熱と極寒、激しい振動、そして電子機器を狂わせる放射線。ありとあらゆる環境を考えて、衛星は設計され、そして試験されます。
それらすべての試練をクリアした衛星は、いよいよロケットに搭載され、宇宙へと打ち上げられます。
しかし、宇宙エンジニアにとって、ロケットの打ち上げ成功はゴールではありません。
むしろ、そこからが本当の戦いの始まりです。
人工衛星のニュースと言えば、火柱を上げて飛んでいくロケットの打ち上げシーンを思い浮かべる方が多いと思います。
中継画面の向こうで空高く飛んでいくロケットを見て人々が歓声を上げるその瞬間、実は僕たち宇宙エンジニアの「最も胃が痛くなる時間」が幕を開けます。
ロケットから人工衛星が切り離されてから、所定の軌道に入って機能の確認試験を開始するまでの数日間から数週間を、宇宙業界では「初期運用（LEOP：Launch and Early Orbit Phase）」と呼びます。
今回は、私が管制室のメンバーとして携わってきた、この初期運用の知られざる制限時間と、エンジニアたちのリスク管理の思想について解説します。
衛星運用室はどんな様子なのか？
衛星の運用室では、大きく2つの担当分野が存在します。
それが、「運用チーム」と「衛星チーム」です。
「運用チーム」は、文字通り運用に関わる物事のスペシャリストです。
衛星の現在位置の特定や衛星と通信する地上局との調整、今後の運用スケジュールの計画・策定を行うほか、実際の運用での衛星の操作も運用チームが行います。
「衛星チーム」は衛星のスペシャリストとして、衛星の状態に関する判断や、緊急時の運用方針策定などを行います。
衛星チームは、衛星全体のことを総括する「衛星システムエンジニア」と、衛星のある部分に特化した、より深い知識を持つ「サブシステムエンジニア」に分かれます。
「サブシステムエンジニア」には、例えば通信機器のエンジニアや推進機器のエンジニア、中には衛星全体の熱制御のエンジニアなど、個々の分野の専門家が揃います。
私は、「衛星システムエンジニア」として数機の静止衛星の運用に立ち会ってきました。
通常時は、運用チームが事前準備された手順書に従いながら運用を行い、衛星チームが衛星の状態を確認しながら問題がないか、確認を続けます。
ここで重要なのは、「どれほど緊急事態であっても、衛星チームが直接コマンドを送信することはない」という点です。
ひとたび異常が確認されれば、衛星チームが状態を判断し、緊急処置の方針を策定して手順書を作成しますが、最終的にそれを衛星へ送信するのは運用チームの役割です。
あえて「操作」と「判断」の権限を明確に分ける。
単独の思い込みによる誤操作を構造的に防ぐための、組織としての相互牽制の仕組みがここにあります。
タイムリミットは数時間：ロケット分離直後の「生存シークエンス」
初期運用の中で、最も緊迫し、管制室が最も多忙を極めるのは、衛星がロケットから分離されてからの「最初の数時間」です。
この間、エンジニアには一瞬の停滞も許されません。
なぜなら、衛星の「命の期限」が刻一刻と迫っているからです。
ロケットから切り離された直後の人工衛星は、まだ自力で電力を生み出すことができません。
内部のバッテリーに蓄えられた限られた電力だけで動いている状態です。
もしこのバッテリーが尽きる前に「ある状態」を確立できなければ、数百億円の衛星は二度と起動しない、文字通りの「宇宙ゴミ」になってしまいます。
映画やドラマだと、初めて衛星からのデータがモニターに映し出された瞬間、管制室に「入感しました！」という声が響き、みんなで立ち上がって拍手やハイタッチをする……そんなシーンが描かれますよね。
でも、現実はまったく違います。拍手なんて起きません。
予定時刻になり、衛星から送られてくるデータ（テレメトリ）が無機質に画面をダーッと流れ始めた瞬間。
管制室を包むのは、小さな安堵と、すぐさま次に切り替わる極度の緊張感です。
「よし」という心の声もそこそこに、淡々と、各サブシステムの担当者へ「衛星の健康状態の確認指示」が飛び交います。
そして、「衛星の生死を分ける」重要イベントの数々が息つく間もなく進んでいきます。
推薬（燃料）配管の真空抜きと充填
宇宙空間で安全にエンジンを点火するため、燃料が通る配管内に残る空気を排出し、燃料を満たす制御を行います。姿勢の安定化と太陽電池パドルの展開
衛星は、ある程度の回転を付けた状態でロケットから放出されます。
そのため、まずは先ほど推薬を充填したスラスターを噴射して、自分の姿勢を安定化させる必要があります。
その後、折りたたまれていた大きな太陽電池パドルを宇宙空間で広げ、発電可能な状態にします。太陽指向姿勢への移行
広げた太陽電池パドルが太陽の光を正確に捉える、太陽指向姿勢に本体の向きをコントロールします。
この「太陽指向姿勢」が確立されて初めて、衛星は自力での持続的な発電が可能になり、バッテリー切れの恐怖から解放されます。
無事に太陽を捉え、電力が安定したことを示すデータが管制室のモニターに表示されたとき、私たちはようやく最初の深い安堵を覚えます。
興味深いのは、これらの「生死を分ける運用」は、万が一のことを考えて地上からのコマンド（指示）がなくても、衛星が自律的に実行できるようにあらかじめプログラムされているという点です。
宇宙空間では、アンテナの向きが合わなかったりして、地上との通信が一時的に途絶えるリスクが常にあります。
また、異常が発生しうるのは衛星だけでなく、地上局や地上局との通信経路、管制室内さえ同じです。
異常発生の危険性は常に、どこにでもあります。
そのため、万が一通信が途切れても、衛星自身が自動でバックアップのシークエンスを動かして生存を図る設計になっているのです。
一方で、衛星と地上局が通信できている状態であれば、衛星の状態が想定通りであることを都度エンジニアが確認しながら進められるよう、手順書に従いながらの運用を行います。
静止軌道への旅路と、「見えない兆候」を追うエンジニア
激動の数時間が終わり、電力が確保されると、運用は少し落ち着いたフェーズへと移行します。
ここからは、衛星を本来の定位置である「静止軌道（高度約36,000km）」へと導く、数日間の旅が始まります。
（この仕組みの詳しい話は、第2回の衛星ディープダイブ『エンジンから見る設計思想の差』で取り上げましたので、ぜひご覧ください！）
この期間の主なイベントは、1日に1回程度行われる「遠地点（軌道上で地球から最も遠い点）でのエンジン噴射」による軌道遷移と、定期的な衛星のヘルスチェックです。
スケジュールだけを見れば、打ち上げ直後のバタバタに比べると平和な時間のように思えるかもしれません。
確かに、すでに正常に動作しているシステム（例えば通信システムなど）のエンジニアは管制室を離れ、万が一異常が発生した際の緊急対応や、「エンジン噴射」といった重要なイベントへの参加がメインとなります。
しかし、これは単に「暇になったから」ではありません。運用という長期戦において、エンジニアの認知リソースを枯渇させないための「メリハリをつけた人員配置（リソースの最適化）」です。
ただし、管制室の衛星システムエンジニアたちの緊張の糸が切れることはありません。
衛星全体を知り尽くす衛星システムエンジニアたちの仕事は、画面に送られてくる膨大な数値データ（テレメトリ）を整理し、衛星の状態に「わずかな異常の兆候」がないか、継続的にモニタリングし続けることです。
発生電力の傾向、姿勢制御の様子など、一見正常に見えるデータの裏に隠されたリスクを早期に発見するため、24時間体制で目を光らせています。
この「静止した緊張感」こそが、運用の本質と言えます。
運用訓練が教えてくれた本質：極限状態でもエラーを防ぐ「運用の仕組みづくり」
本番の極限状態で、私たちが「拍手もせず淡々と」任務を遂行できるのはなぜか。
それは、本番を迎えるまでに、これでもかというほど過酷なシミュレーション訓練（リハーサル）を積み重ねているからです。
訓練では、実際の運用を模擬して打ち上げ直後やエンジン噴射の手順を本番通りに行います。
そして恐ろしいことに、運用室にいる人員には内容が一切知らされないまま、何らかの「意地悪な異常（フォールト）」が仕込まれるのです。
私が今でも鮮明に覚えているのは、ある訓練での「ヒーター暴走事件」でした。
宇宙空間を生きる衛星には、機器が冷えすぎるのを防ぐためのヒーターが備わっています。
その制御に使われるセンサが故障し、ヒーターが常に「OFF」に制御される異常が設定されたのです。
発見がわずかに遅れたこともあり、画面上のデータを見ると、ある機器の温度が危険なトレンドを描いて下降し続けていました。
「温度が下降を続けています。このままだと、あと少しで下限を下回りそうです」
そんな報告に、管制室に焦りが走ります。データの推移から「あとどれくらいで下限を超えるか」は推定できますが、その瞬間にそれ以上の正確な情報を把握することはできません。
とにかく素早く、かつ絶対に間違えることなく、ヒーターをONにするための処置を検討する必要がありました。
私たちは熱制御エンジニアと状況を精査し、どの機器のどのヒーターがOFFを続けているのか、詳細な状態を確認します。
並行して、事前に用意してあった「手順テンプレート」を引っ張り出しました。
宇宙の運用では、その場の思いつきでコマンドを打つことは絶対に許されません。
非定常な運用であっても、必ず手順書に落とし込む必要があります。
テンプレートの空欄に対して、その時の状況に応じた適切なコマンドや期待されるテレメトリの値を慎重に検討します。
一分一秒を争う極限のプレッシャー。つい「早くコマンドを打って止めたい」という衝動に駆られます。
それでも、「プロセスを飛ばす」という新しいリスクを作る行動は絶対に行いません。
コマンドやテレメトリの値に誤りがないかを徹底的にダブルチェックし、運用者へ渡します。
運用者が衛星への送信準備を進めている間にも、これから行う運用手順全体に問題がないか、もう一度「トリプルチェック」を行います。
さらに、送信準備が完了した段階で改めて、送るコマンドの内容に指示との差異がないか「最終チェック」を行います。
そして、運用者に送信のGOを出し、コマンドが送信されます。
結果は、機器の温度が警告範囲（レッドゾーン）に突入する一歩寸前、まさに「ギリギリの許容範囲内」で収まりました。あと少し対応が遅れていれば、機器の健全性に致命的な影響が出かねない状態でした。
衛星の運用では、様々なことが「仕組み化」されています。
手順に従う運用、運用者と技術者が分けられていることによる監視・ダブルチェック体制などがこれにあたります。
このような「仕組み化」は、極限状態でも「焦りによる新たなリスクの発生」を防ぐためだと考えています。
一見遠回りに見えて、実は最も早く、確実に安全へと辿り着く唯一の手段がこの「仕組み化」なのです。
過酷な運用訓練とは、エンジニア個人の精神力を鍛える場ではなく、この「危機のなかでも破綻しない運用の仕組み」の強度を徹底的にテストし、磨き上げるための場だったのです。
結び：システムを機能させる「設計」と「運用」の二重奏
衛星が本来の静止軌道にたどり着くと、アンテナを展開して「最終形態」となります。
そして、衛星のすべてのチェックアウト（機能確認と動作確認）を完了したとき、ようやく「初期運用」の全行程が幕を閉じます。
そこから先、人工衛星は社会のインフラとして、何年もの間、宇宙で淡々と働き続けます。
ロケットの打ち上げは、ニュースの主役であり非常に華やかです。
しかし、その裏側にあるのは、劇的なドラマではなく、エンジニアたちが築き上げた徹底的に考え抜かれた「設計」と、それを支える、システム化された「運用プロセス」の二重奏です。
通信途絶を見越してあらかじめ組み込まれた「自律生存の設計（自動シーケンス）」
人間の焦りという不確実性を排除し、プロセスを厳格に守る「手順書文化」
重大な故障に至る前にリスクを摘み取る「24時間体制の予兆監視」
宇宙という、一歩間違えればすべてを失う絶対的な不確実性の世界で、数百億円のプロジェクトを成功させ続ける。
それを支えているのは、エンジニアたちの精神論ではなく、こうした「失敗することを前提に、それを何重もの網で受け止める現実的なリスク管理の仕組み」なのです。
何年間も宇宙の過酷な環境で生き続ける衛星の姿こそが、私たちが構築したリスク管理の仕組みが正しく機能していることの、何よりの証明なのです。
また、これまでの話で頻繁に出てくる「衛星の姿勢制御」について、衛星の設計の本質である「ライフサイクル設計」の考え方と照らし合わせながらディープダイブする記事もあわせてどうぞ！
（本記事は、画像や文章の一部に生成AIを使用しています。）
