遠くで考え続ける探査機は、何を地球に持ち帰るのか

深宇宙へ、自分で航行して、自分で観測し、考え続ける探査機を送りたい。

僕が考えていたのは、観測装置の隣にLLMが載っているだけの機械ではない。大量のデータをその場で処理し、気になるものを見つけたら追加で観測する。過去の結果と照らして仮説を更新し、地球との通信が開いたら重要なものから送ってくる。人間が次の指示を出すまでの時間にも、探査が先へ進んでいるような機械だ。

いま使える計算機と光通信を組み合わせれば、かなり近いところまで行けるのではないか。最初はそう考えた。

ところが、構想を数字と論文に戻すと、問いの置き場所が変わってくる。計算機が賢いことと、探査機が長く生き残ることは別の問題だ。観測できる量と地球へ送れる量も違う。そして、送るものをAIが選ぶなら、その選び方が、地球にいる僕たちの知る宇宙を決めてしまう。

この記事では、実際に示された技術と、そこから組み立てる設計上の仮説を往復してみたい。完成した宇宙機の提案ではなく、「考え続ける」を実装可能な仕事へ分けていくための検討である。

自律性は、一つの能力ではない

まず、自律航行、自律観測、科学的な判断を分けたい。

航行では、現在位置と姿勢を推定し、安全な範囲で軌道や向きを変える。観測では、機器の設定を決め、取得し、校正や検出を行う。科学的な判断では、何が興味深いか、何を追加で調べれば仮説を区別できるかを考える。この三つでは、許される遅延も、間違いの影響も違う。

自律性そのものがLLMから始まったわけではない。Deep Space 1のAutoNavは、自律航法の先例である。EO-1の研究でも、機上での現象検出と、観測の優先順位や追加観測をつなぐ考え方が示されていた。¹²

だから、すべてを言語モデルに置き換える必要はない。むしろ、既存の制御と観測処理を足場にして、LLMが役に立つ場所を限定したほうが、何が新しくなったかを測りやすい。

仕事	必要な性質	この構想での担当候補
姿勢制御、電力保護、緊急退避	決められた時間内の動作と故障時の挙動	独立した制御系と安全系
校正、圧縮、対象検出	再現性、処理量、観測機器への適合	専用アルゴリズム、小型モデル、FPGAなど
観測候補の比較、計画案の作成	複数の制約と履歴の統合	制約ソルバーやLLMを含む計画系
仮説と証拠の整理	出典への追跡、矛盾の保持	構造化した台帳と、その更新を補助するLLM
実行の許可	最新の機体状態との整合	計画系から独立した検証器と実行器

これは採用済みの構成ではなく、検証の単位を作るための分担案だ。

LLMが「もう一度撮影するとよさそうだ」と判断しても、それだけでは姿勢を変えない。対象、時間帯、露光条件、必要電力、保存量、有効期限、期待する科学的な区別を、決められた形式の要求へ変換する。その要求を、別の仕組みが点検してから実行する。

自然言語の説明は人間のレビューには便利だが、電力上限を守った証明にはならない。説明と許可を分けることが、構想の最初の境界になる。

最初に直すべきだったのは、通信量の桁だった

大量に観測し、高速に送る。この二つをつなぐとき、Mbpsという数字だけを眺めていると感覚がずれる。

通信速度を $R$ Mbps、通信時間を $T$ 時間とすると、理想的に送れる量 $V$ は、十進表記のGBで次のようになる。

$$V = \frac{R \times 10^6 \times 3600T}{8 \times 10^9} = 0.45RT \quad \mathrm{GB}$$

1 byteは8 bitで、ここでは1 GBを $10^9$ byteとしている。したがって100 Mbpsを1時間なら45 GB、200 Mbpsを2時間でも180 GBである。構想の初期計算で置いていた4.5〜18 TBという値は、100倍大きかった。

この訂正は、小さな帳尻合わせでは済まない。4〜8 TBを毎日観測し、そのほとんどを地球へ送るという設計の前提が消えるからだ。

NASAのDSOCは、深宇宙光通信が現実の技術であることを示した。約3,100万kmから267 Mbpsを達成し、別の通信では約2億2,600万kmから25 Mbpsを実証している。ただし、この二つは異なる条件での実績であり、どこでも25〜267 Mbpsが出るという仕様ではない。³⁴

また、DSOCは2025年9月2日に実証を終了している。2024年12月3日には約4億9,400万kmからデータを受信したが、その距離記録に25 Mbpsという速度を組み合わせてよいわけではない。³

以下は、それぞれの速度が2時間維持されると仮定した算術上の比較だ。異なる距離の実証値を同じミッションの選択可能な速度として並べたものではない。

仮定する速度	2時間の理想量	さらに70%の計画余裕係数を掛けた量
25 Mbps	22.5 GB	15.75 GB
100 Mbps	90 GB	63 GB
267 Mbps	240.3 GB	約168.2 GB

70%は説明用に置いた仮定で、DSOCの測定結果ではない。公表レートがすでに有効データの速度を表している場合、符号化の損失を重ねて引かないようにも注意が要る。実設計では、捕捉や中断、運用時間など、何をこの係数に含めるかを決める必要がある。

25 Mbps・2時間・この余裕係数という条件なら、15.75 GBは4 TBの約0.39%、8 TBの約0.20%にすぎない。観測の99%以上がその日の通信枠には収まらない。

ここまで来ると、AIによる処理は便利な追加機能ではなくなる。どの観測を残し、どの表現で送り、何を捨てるかが、ミッションの中心になる。

速い回線にも、使えない日がある

通信量を一日単位で見ても、まだ足りない。地上局が使える時間、天候、太陽との位置関係、機体の姿勢、他の運用との競合がある。

DSOCの地上系には、送信側のビーコン設備や、Palomarの高感度な受信設備が含まれる。宇宙機にレーザーを載せれば、地球側は普段のインターネットのように待っていてくれる、という構図ではない。³

2017年のDSOC計画資料にも、地上の晴天条件と太陽離角による通信制約が現れる。これは当時の計画評価であり、その数値を現在の運用実績として扱うことはできない。ただ、平均速度とは別に「通信できない期間」を設計へ入れる必要性はよく分かる。⁵

ここからは、通信を待ち行列として考えるための独自の簡略モデルを置く。日末の未送信量を $Q_t$、その日に送信待ちへ追加する量を $A_t$、利用できる送信容量を $D_t$ とし、すべてGBで表す。

$$Q_{t+1} = \max(0, Q_t + A_t - D_t)$$

$A_t$ はセンサーが生成した全量ではない。機上で選別や加工を行ったあと、地球へ届けると決めた量だ。日内の到着順序や送信可能時間を無視した集約モデルなので、短時間のピークには別の評価が必要になる。

平均的な到着量が平均的な送信能力を上回れば、未送信量は増え続ける。保存装置を増やすとあふれる時期は遅くなるが、収支そのものは変わらない。

たとえば、毎日10 GBを送信待ちへ追加する。通信に成功した日は15.75 GB送れ、一日に最大一回の通信機会があると仮定する。その機会が利用できる割合を $p$ とすると、長期的な収支に余裕を持たせる条件は、単純化したモデルでは次のようになる。

$$15.75p > 10 \quad\Longrightarrow\quad p > 0.635$$

もし利用できるのが半分の日なら、平均送信容量は7.875 GB/日。送信待ちは平均2.125 GB/日ずつ増えていく。これは特定の地上局の天候予測ではなく、回線の稼働率が設計を逆転させる例だ。

しかも、平均の条件を満たすだけでは、有限の保存容量を保証できない。通信できない日が連続するかどうかが効いてくる。

30日間の通信停止なら、10 GB/日で300 GBがたまる。再開後に毎日15.75 GB送れても、新しい10 GBも毎日入るため、過去の分を減らせるのは5.75 GB/日だけだ。300 GBを解消するには約52.2日分、日単位なら53回の成功した通信機会が必要になる。

30日止まったあと、約53日かけて追いつく。その間にまた止まれば、回復はさらに延びる。

この計算から、保存容量だけでなく、通信再開後に観測量を落とす運用、送信待ちデータの優先順位変更、期限を過ぎたデータの扱いまで必要だと分かる。ここは、計画系が現実に役立つ余地でもある。

太陽からの距離と、地球からの距離を混ぜない

深宇宙という言葉には、異なる制約が一つに折り畳まれている。

太陽電池の入力を考える距離と、通信を考える距離は別だ。太陽から探査機までを $r$ AU、地球から探査機までを $d$ AUとする。地球を太陽から1 AUの円軌道上に置く近似なら、$r=3$ の探査機でも、配置によって $d$ はおよそ2〜4になる。

太陽光の強さを見積もるときは主に $r$ が効く。一方、地球との光行時間や通信リンクには $d$ が効き、太陽離角や地上局の条件も加わる。同じ「3 AU付近の探査機」でも、通信の難しさが一定にはならない。

NASAが示すPsycheの電力は、地球付近で約21 kW、小惑星Psyche付近では約2.3〜3.4 kWである。これはPsycheという宇宙機とミッションの値で、そのまま別の探査機の電力予算には使えない。それでも、遠方では発電量の中から推進、姿勢制御、観測、通信、計算、保温を分け合うという問題を具体的にしてくれる。⁶

LLMに使う数十Wだけを見て「十分小さい」と判断するのも早い。メモリや電源変換、他の電子機器、熱設計を含めて扱う必要があるし、通信と計算と推進を同時に行うのか、時間を分けるのかでも変わる。

性能の最大値を足し合わせるより、時刻ごとの運用表を作るほうが先なのだと思う。いま何を止めれば、次の観測を実行できるか。その判断を含めて、探査機の知性と呼べるかもしれない。

科学的に重要なものだけ送る、の難しさ

では、重要なデータだけを選べばよいのか。

ここで参考になるのが、Ocean Worlds Life Surveyorの顕微鏡観測を扱ったWronkiewiczらの研究である。論文は、特定の外惑星探査の構想で生じる、取得可能なデータと帰還可能なデータの大きな隔たりを背景にしている。そこで出てくる約10,000倍という規模は、何でもその倍率で可逆圧縮できるという意味ではない。⁷

研究では、科学的な有用性の推定に加え、観測の多様性を表す記述を用いて、地球へ送る候補を選ぶ。実験室や地上のフィールドで検証した機上処理の研究であり、海洋天体で生命を発見した実績ではない。また、想定や学習例から外れた動きが適切に評価されない例もあり、選別器そのものの見落としが課題になる。⁷

この話が気になるのは、AIが賢くなるほど選別を任せたくなるからだ。既知の特徴を上手に見つけることと、未知の現象を落とさないことは同じではない。

たとえば「生命らしい動き」を高く評価する処理系があったとして、その評価軸から外れた運動をする対象はどうなるのか。地球で見慣れたものを効率よく拾えるようにした結果、見慣れないものを効率よく捨ててしまう可能性がある。

この問題に対して、今回の構想では送信枠を一種類のスコアで埋めない案を考えたい。

送信枠の考え方	残したいもの	限界
既知の科学目標	目的に合う高得点の観測	既存の評価軸に偏る
多様性	似た観測ばかりにならない標本	特徴の表現自体に偏りがある
不確実性	判定が難しい候補	ノイズや故障も集まりうる
無作為な生データ標本	選別器が低評価した領域の点検材料	希少現象を必ず含むとは限らない
機器の健全性と校正	観測の意味を後から確かめる情報	直接の発見に見えにくい

割合はまだ決められない。対象の発生頻度、誤検出の費用、再観測できるかどうかで変えるべきだからだ。無作為抽出も、時間帯や機器状態に偏りが残らないように設計する必要がある。

重要なのは、無作為な標本に「無駄な通信」という名前を付けないことだと思う。選別後のデータしか地球へ届かなければ、選別器が何を見落としたかを評価する材料も失われる。低得点だったデータを少し残すことは、科学のためだけでなく、次の選別を改善するためにも必要になる。

そして、LLMが書いた説明は、観測の代わりにはならない。「未知の運動を見つけた」という文章だけでは、地球で別の研究者が再解析できない。元データへの識別子、校正条件、処理の版、抽出した特徴、捨てた情報の種類を、説明と一緒に残す必要がある。

考え続けるとは、文章を生成し続けることなのか

最初の構想では、LLMがずっと推論している姿を想像していた。けれど、宇宙機の電力と科学の再現性を考えると、連続的な文章生成を目標にする理由は薄くなる。

むしろ、考えが途切れないために必要なのは、次の推論で再開できる状態を持つことではないか。

たとえば、探査機の中に仮説の台帳を置く。各項目には、仮説の識別子、根拠となる観測、競合する説明、次に区別できる観測、必要な資源、再検討する条件を記録する。未解決の矛盾を、文章の滑らかさのために消さない。

新しい観測、機器の異常、通信計画の変更、定期的な見直しをきっかけに、計画系を起動する。前回から変わった部分を取り込み、観測案を更新する。何も変わっていない間は、計算を止めてもよい。

これは意識の有無についての主張ではない。長いミッションで判断の履歴を持ち越すための、ソフトウェア上の設計案だ。

また、台帳を更新することと、モデルの重みをその場で再学習することも分けたい。重みを変えれば、以前の試験で確認した振る舞いとの関係が変わる。まずは版を固定したモデルと追記可能な記録で運用し、モデル更新には別の検証と復旧手順を用意する、という順序が考えられる。

同じ履歴を渡しても出力が揺れるモデルなら、最終的に実行した要求と、許可・却下の理由を記録する。科学の履歴と、宇宙機の操作履歴が対応していないと、後から何が起きたかを説明できない。

安全を点検する計算にも、締め切りがある

LLMの提案を独立した検証器で点検する、と書くと安心できそうに見える。しかし、その検証器が時間内に終わるかという問題が残る。

強化学習による制御方策とRun Time Assurance（RTA）の計算時間を、商用計算機と耐放射線プロセッサで比較した研究がある。多くの処理は1秒未満で終わる一方、非線形の最適化を伴う一部のケースでは60秒の打ち切りに達している。対象は小さな制御用ネットワークと安全確保のアルゴリズムであり、LLMの推論速度や宇宙での寿命を測った研究ではない。⁸

ここから今回の構想に引き寄せて考えられるのは、「検証を挟んだ」という構成図だけでは不十分だということだ。

要求には有効期限が必要になる。検証中に機体の状態が変わったら、以前の状態に対する許可を使わない。検証が時間切れになった場合の既定動作も必要だ。姿勢を維持するのか、観測を延期するのか、安全な状態へ戻るのか。それぞれの状況で定めなければならない。

加えて、検証器に与える電池残量や姿勢推定が壊れていれば、形式に合った要求でも危険になりうる。検証器を別に置くことは出発点で、その入力の健全性と故障時の動作までが設計範囲になる。

LLMが使えなくなっても、電力保護、通信の回復、最低限の定型観測が続く構成にしたい。賢い部分の停止が、そのまま探査の終了になる設計は、この構想の目的と相性が悪い。

地上で動く部品を並べても、深宇宙の計算機にはならない

部品の名前を挙げると、構想が急に具体的に見える。耐放射線CPU、FPGA、商用GPU、大容量SSD。けれど、それらの組み合わせが数年間動くことは、個々の仕様表からは出てこない。

たとえば、NVIDIAが示すJetson AGX OrinのAI性能や電力モードは、機上処理を考えるための候補情報にはなる。しかしTOPSは、そのまま特定のLLMのtoken/sではない。モデルの規模、量子化、文脈長、メモリ帯域、実行系、同時に動かす観測処理によって結果は変わる。⁹

FPGAも同様だ。画像分類のFPGA実装研究には、限られた入力と小型ネットワークで高速処理を示すものがある。一方、その研究の開発ボード、回路、推定電力を、別の耐放射線FPGAやLLMへ移し替えることはできない。¹⁰

放射線については、累積する影響と、一つの粒子によって起きる事象を分けて考える必要がある。メモリの誤りだけでなく、ラッチアップや再起動、部品の損傷まで、対象部品と環境に応じた評価が要る。遮蔽を厚くすれば一律に解決するという問題でもない。¹¹

二台積むだけでも十分とはいえない。同じ電源や制御回路を共有していれば、共通の故障で両方を失う可能性がある。誤った更新を同時に適用しても同じだ。冗長性には、どこまで独立しているかという条件が付く。

この点は、以前考えた宇宙に置いた装置の99.99%は何の確率なのかという問いにつながる。一回の処理が成功する確率と、何年後にも処理を続けられる確率を混ぜない。再起動で回復する故障と、失われた部品を交換できない故障も分ける。

欲しいベンチマークは、最大のtoken/sだけではない。観測処理と同時に動かしたときの消費電力、期限超過、誤り検出、再起動からの復帰、保存中のデータへの影響まで含めて、ミッションがどこまで続くかを測りたい。

保存容量の数字にも、文脈がある

大容量の宇宙用保存装置の例として、NISARの仕様には寿命末期で9 Tbの容量が示される。小文字のbなので、十進換算では1.125 TBだ。9 TBではない。そして、地球観測衛星の仕様は、別の深宇宙ミッションの寿命保証にはならない。¹²

通信にも似た落とし穴がある。TBIRDは低軌道から200 Gbpsの光通信を示したが、低軌道の実績を深宇宙へそのまま延長することはできない。距離、光学系、指向、地上設備を含む別のリンクとして評価する必要がある。¹³

保存容量を考えるなら、まず「何日間、何を消さずに持つか」を決めたい。

先ほどの10 GB/日を30日残すだけなら300 GBである。一方、4 TB/日の生データを同じ30日残すなら120 TBになる。校正データ、ソフトウェア、重複保存、誤り訂正、故障領域の隔離、観測バーストの余裕は、この外側にある。

ここで、送信予定の量と保持したい量が違うことにも注意が要る。今日送らない生データでも、数日後の観測で意味が変わり、再解析したくなるかもしれない。すると、すぐ捨てる、一定期間残す、長く保護する、という保持方針が必要になる。

科学的な判断と保存装置の設計は、ここで直接つながる。あとで考え直せる範囲は、何を残していたかで決まるからだ。

まず作るなら、宇宙機より先に運用のシミュレーターを

ここまでを一つの検討ケースにするため、太陽から1〜3 AU、運用6年、通常の生データ20〜50 GB/日、地球への帰還目標10 GB/日と仮置きする。4〜8 TB/日は特別な短時間観測に限定する。

これらは推奨仕様でも、達成できると示した値でもない。矛盾を探すための入力である。観測機器の種類と軌道が決まっていないので、質量、推進剤、価格まで精密な表にする段階ではない。

先に作れるのは、観測、電力、計算、保存、通信を同じ時間軸で動かすシミュレーターだと思う。

まず、観測イベントと生データの発生を与える。通信は平均レートだけでなく、利用可能な窓と連続停止期間を与える。計算機には処理時間と電力の制約を置く。その上で、どの観測を残し、何を送るかを比較する。

比較対象は、LLMを使う方式だけでは足りない。同じ電力と通信量の予算で、固定ルール、小型分類器、従来の計画手法、LLMを含む計画手法を比べる。LLMにだけ詳しい履歴や広い計算予算を渡せば、モデルの寄与が分からなくなる。

検証したい問い	比較・故障の与え方	見る指標
LLMは追加観測を改善するか	同一イベントと資源予算で計画方式を比較	目的現象の回収率、不要観測、消費電力
未知の現象を捨てないか	学習時と異なる現象を保留した評価集合に入れる	未知群の回収率、生データの残存率
通信停止から回復できるか	連続停止と再開を与える	最大待ち量、データ損失、追いつく日数
計画系が止まっても続くか	時間切れ、再起動、不正な要求を注入	安全側への移行、定型観測の継続
地球で判断をやり直せるか	帰還したものだけで第三者が再解析	原データへの追跡、校正情報の欠落

これは今後の実験案で、ここに結果はまだない。特に「未知」は何でも作れる便利なラベルにしない。評価に使う未知群まで見て選別器を調整すれば、その群はすでに既知になってしまう。

運用シミュレーターで収支が閉じたあとに、実機の計算時間、熱、放射線、故障回復を測る。そこで得た数字を再びシミュレーターへ戻す。この往復を経て初めて、部品表に意味が出てくる。

地球に届くのは、探査機が残した宇宙になる

遠くで考え続ける探査機、という最初の像はまだ面白い。

ただ、その知性を、出力する文章の長さやモデルの大きさだけで測る気にはならなくなった。通信が止まる日を織り込み、計算が間に合わなければ延期し、仮説に合わない観測も残し、地球で別の解釈を試せるように証拠を届ける。そういう判断を続けられることに、具体的な価値がある。

すべてを持ち帰れない探査機は、必ず何かを選ぶ。

そのとき、すでに分かっている価値を上手に拾うだけでなく、まだ価値の分からないものを少し残しておけるか。僕が次に確かめたいのは、そこだ。

Sources

確認日は資料の参照日。以下の実証・研究と、本文の待ち行列モデルや設計案は区別している。

Footnotes

1. NASA/JPL, AutoNav — Deep Space 1 — ミッション技術解説。自律航法の先例。確認日：2026-09-29。 ↩

2. Castano et al. (2005), Learning Classifiers for Science Event Detection in Remote Sensing Imagery — 著者発表資料、Semantic Scholar収録PDF。EO-1の科学現象検出と自律観測。確認日：2026-10-01。 ↩

3. NASA/JPL, Deep Space Optical Communications (DSOC) — ミッション概要。267 Mbps、距離記録、実証終了日、地上設備。確認日：2026-10-01。 ↩ ↩² ↩³

4. NASA/JPL (2024), NASA’s Optical Comms Demo Transmits Data Over 140 Million Miles — 実証報告。約2億2,600万kmで25 Mbpsという個別条件の実績。確認日：2026-09-29。 ↩

5. Biswas et al. (2017), Status of NASA’s Deep Space Optical Communications Technology Demonstration — JPL発表資料、Semantic Scholar収録PDF。地上天候と太陽離角を含む当時の計画評価。確認日：2026-09-29。 ↩

6. NASA, Psyche Spacecraft — 宇宙機の解説。距離に応じた電力と宇宙機の構成。確認日：2026-09-29。 ↩

7. Wronkiewicz et al. (2024), Onboard Science Instrument Autonomy for the Detection of Microscopy Biosignatures on the Ocean Worlds Life Surveyor — The Planetary Science Journal, DOI:10.3847/PSJ/ad0227、著者公開版。科学的有用性、多様性、地上試験と選別の限界。確認日：2026-09-29。 ↩ ↩²

8. Dunlap et al. (2024), Space Processor Computation Time Analysis for Reinforcement Learning and Run Time Assurance Control Policies — 論文全文、arXiv:2405.06771v1。制御用ネットワークとRTAの計算時間評価。確認日：2026-10-01。 ↩

9. NVIDIA, Jetson Orin — 製品仕様。公称AI性能・電力モード。宇宙環境の適格性や特定LLMの速度を示す資料ではない。確認日：2026-09-29。 ↩

10. Resources and Power Efficient FPGA Accelerators for Real-Time Image Classification (2022) — 論文PDF、Semantic Scholar収録。限定された画像分類のFPGA実装。開発ボードと推定電力の結果であり、深宇宙LLMの実証ではない。確認日：2026-09-29。 ↩

11. NASA, 放射線影響に関する技術資料 — SEE関連資料、NTRS:20210024100、Small Spacecraft Technology: Structures, Materials, and Mechanisms。放射線影響と遮蔽の検討背景。確認日：2026-09-29。 ↩

12. NASA/JPL, NISAR Spacecraft and Subsystems — 宇宙機仕様。寿命末期9 Tbの記録容量。確認日：2026-09-29。 ↩

13. NASA NTRS (2024), TBIRD技術報告、20240009135 — 原資料レコード。低軌道200 Gbps光通信の実証。確認日：2026-09-29。 ↩