ClaudeがPerseveranceの火星走行を計画 — NASA JPLの約400m経路

Claudeは火星探査車のどこを担当したのか

担当したのは、走行ルートの下書きにあたる「ウェイポイント(経由点)」の作成です。NASAのジェット推進研究所(JPL)は2025年12月8日と10日、火星探査車Perseveranceの走行コマンドをClaudeに書かせ、探査車がその経路を走り切りました。人間ではなくAIが計画した走行が別の天体で実行されたのは、これが初めてだとされています。

車体を操縦したわけではありません。Claudeは周回衛星の画像と地形データから経路の案を作り、人間の運用チームが検証してから送信しました。計画を任せ、検証は人が持つ。この分担が、事例のいちばん参考になる部分です。

Anthropicの記事は走行距離を「約400メートル」と書き、NASAの発表は2回の走行を210mと246mと書いています。合計すると456mで、数字は食い違って見えます。400mは2日分をまとめた概数と読めますが、2つの記述の関係は説明されていません。日ごとの距離はNASAの発表値(210m・246m)が具体です。

人間のルート計画はどう進んでいたか

火星と地球の距離は平均で約2億2500万kmです。Anthropicの記事は地球と火星の距離を約3億6200万kmと書いており、信号が届くまでにはおよそ20分かかります。探査車を遠隔でリアルタイムに操縦する「ジョイスティック操作」は成り立ちません。

NASAによると、この方式は過去28年、複数の探査ミッションにわたって続いてきました。人間の「ドライバー」が地形と探査車の状態を読み、次の手順を繰り返します。

失敗の代償は大きく、2009年には探査車Spiritが砂地にはまって動けなくなりました。Perseveranceには自律航法機能のAutoNavがあり、経由点の間では障害物を避けられます。ただしAutoNavは探査車自身の視点でしか地形を見られず、遠くまで計画を立てることはできません。遠くを見通した経路の設計は、これまで人間の計画担当者の仕事でした。

2つは競合せず、別の層を受け持ちます。Claudeが全体の道筋を引き、AutoNavが足元の障害物を避ける、という重ね方です。

Claudeには何を渡し、どう走らせたか

JPLのチームは、Claude Codeの上に経路計画の工程を組みました。1回のプロンプトで答えを出させたのではなく、先に材料を渡しています。

• 長年の走行で蓄積したデータと運用上の経験
• 軌道周回機の高解像度画像(HiRISE)と、標高モデルから得た地形の傾斜データ
• 出力先の言語であるRover Markup Language(XMLベースの専用言語)

Claudeはこの文脈を踏まえ、画像を読み取る視覚機能で岩盤・露頭・危険な岩場・砂の波紋といった地形の特徴を見分けました。そのうえで約10メートルの区間をつなぎ、途切れのない経路とウェイポイントを書いています。書いた後は自分の案を見直し、修正案を出す反復も行いました。

NASAは、この手法が視覚と言語を扱う生成AI(視覚言語モデル)を使うものだと説明しています。AIが使った入力は、人間の計画担当者が使う画像やデータと同じです。人間とは別の特別なデータを与えたわけではありません。

取り組みを率いたのはJPLのRover Operations Center(ROC、探査車運用センター)で、Anthropicとの協働として進められました。NASAの発表は2026年1月30日付で、走行から約7週間後に出ています。

地形の読み方は、次のように役割が分かれます。

• HiRISE画像: 岩盤、露頭、危険な岩場、砂の波紋といった地表の特徴を見分ける材料
• 標高モデルの傾斜データ: 勾配がきつく、車体が滑ったり傾いたりしかねない場所を避ける材料
• 出力: 途切れのない1本の経路と、約10m刻みのウェイポイント

画像だけでは傾斜が分からず、標高データだけでは砂地や岩場の見分けがつきません。2種類を突き合わせて初めて、安全な通り道が引けます。

人間はどこで検証したのか

検証は2段階です。

機械の検証は「命令が探査車の側で成立するか」に強く、人のレビューは「入力に載らなかった現地の事情」に強い、という分担です。

エンジニアのレビューでは、直す点は小さいものにとどまりました。例として挙がっているのは、狭い通路の両脇にある砂の波紋です。Claudeが見ていなかった地上のカメラ画像のほうが、波紋をはっきり写していました。運用担当者は、Claudeの案より細かい位置で経路を分けています。

ここに、AIに計画を任せるときの勘所が出ています。Claudeの判断が間違っていたのではなく、見せていない情報があったことが修正の原因でした。入力に含まれなかった情報は、どんなモデルでも考慮できません。

時間は半分になるのか

エンジニアの見積もりでは、この方法でルート計画の時間は半分に縮み、走行のばらつきも減ります。ただし、これは実績ではなく見積もりです。2回の実証走行で得られた結論でもありません。

JPLのロボット工学者で、探査チームの一員であるVandi Vermaは「kilometer-scale(キロメートル規模)の走行」への意欲を語っています。パーセプション(岩や波紋を見る)、ローカライゼーション(自分の位置を知る)、計画と制御(最も安全な経路を決めて実行する)という自律航法の3つの柱を、生成AIで効率化できる見込みがある、という見立てです。

同じ発言には、探査車の大量の画像から興味深い地表の特徴を拾い、科学チームに知らせる用途も挙がっています。JPLの探査システム室の責任者は、地上だけでなく探査車やヘリコプター側のエッジ(現地の機器上)にも知能を載せる構想を語りました。ただし、どちらも今回の2回の走行で試された範囲ではありません。

仕事で計画をClaudeに任せるときの型に直すと

JPLの事例を、手元の開発で使える形に分けると次のとおりです。以下は事例から導いた一般化で、JPLが実際に使った設定ではありません。

Claude Codeでこの型を組むなら、プロジェクトのCLAUDE.mdに検証の手順を書いておく方法があります。

## 計画を出力するときのルール
- 計画案は plans/ に書き、実行はしない
- 書き終えたら `make simulate` を実行し、結果を計画の末尾に貼る
- シミュレーションで警告が出たら、直した案と直した理由を併記する
- 判断に使えなかった入力(未確認のログなど)があれば、一覧にして残す

最後の項目が、砂の波紋の教訓に対応します。見ていない資料を明示させておくと、レビュー担当者が「どの画像を足せば判断が変わるか」を探しやすくなります。検証をツール呼び出しの前後に自動で差し込む方法は、hooksでテストを自動実行する手順と、失敗時に操作を止めるonFailureの設定にまとめています。計画ファイルの置き場所を変える設定はplansDirectoryの解説で扱っています。Claude Code全体の設定はClaude Codeの完全ガイドから辿れます。

この事例から言えないこと

NASAもAnthropicも、今回の成果を限定的な実証として扱っています。Anthropicの記事は400メートルを「陸上トラック1周分」と表現し、「始まり」と表現しています。

言えないことを分けておきます。

• Claudeが探査車を自律で走らせたわけではない。計画はClaudeが書き、シミュレーションと人間の確認を経て送信された
• 2回の走行で、AIの計画が常に人間と同等だと示されたわけではない
• 時間半減は見積もりで、継続運用の実績ではない

一方で、通信に20分かかる環境でも検証を挟んだ運用が成立した点は、評価できる実績です。NASAは月の探査への応用にも触れています。地球から遠い場所ほど信号の遅れは長くなり、地球側で逐一確認する運用は難しくなります。その場合、検証の一部を探査機の側に置く設計が前提になります。