Anthropicが発表。なぜClaudeはNASA火星探査車を動かせたのか。社内の古いシステム開発が変わる理由

火星での400メートル。AIが物理世界をハックした日

2025年12月。

地球から3億6200万キロ離れた場所で歴史が動いた。

NASAの火星探査車Perseveranceが、AIの作成したルートで400メートルの自律走行を成功させた。

僕が昨日書いた正規表現は3文字でクラッシュしたというのに。

使われたのはAnthropicのAIモデルであるClaudeだ。

AIが初めて他惑星の物理ハードウェアを自律制御した。

これは単なる宇宙開発のニュースではない。

社内の古いシステムや独自仕様のコードベースをどう扱うかという問題への解答だ。

NASAの探査車Perseveranceを動かしたClaudeの実力

火星探査車の操縦は、地球上のラジコンとは次元が違う。

NASAの通信データによれば、電波が届くまでに約20分かかる。

地球から指示を出して、その結果の画像が返ってくるまでに40分を消費する。

リアルタイムの操作は物理的に不可能だ。

探査車の動きは事前に完全に計算されなければならない。

パンくずリストと呼ばれるウェイポイントを細かく設定し、一括で送信する。

これまでは人間の専門家が、衛星画像と探査車のカメラ映像を睨みながら手作業で計画を立てていた。

今回はそのミッションクリティカルな作業を、Claudeが代行した。

走行距離は400メートル。

陸上競技場のトラック1周分だ。

数字だけ見れば短く感じる。

火星の表面には無数の岩石が転がり、危険な砂地が広がっている。

探査車の着陸地点であるジェゼロ・クレーターは、かつて水が存在したとされる複雑な地形だ。

少しでもルートを誤れば、車輪がスタックして二度と動けなくなる。

実際に2009年、先輩探査車のSpiritは砂地に足をとられ、そのままミッション終了となった。

1回のミスが数十億ドルのプロジェクトを終わらせる。

そんな極限状態のタスクを、僕らが普段コードを書かせているのと同じClaudeがこなした。

探査車には数多くのカメラや科学機器が搭載されている。

それらを制御するため、NASAは独自のXMLベース言語であるRover Markup Languageを使用している。

当然、そんなマニアックな言語のデータはインターネット上にはほとんど存在しない。

一般的なAIの事前学習データには含まれていないはずだ。

それでもClaudeは、完璧な構文で探査車を制御するコマンドを生成した。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

火星探査における技術的ハードルは以下の通りだ。

* 地球からの距離は3億6200万キロ

* 通信の片道遅延は約20分

* リアルタイムの遠隔操作は物理的に不可能

* 砂地でのスタックは即ミッション終了を意味する

これらの制約をすべてクリアし、Claudeは自律的な計画を立案した。

人間が何日もかけて行っていた作業を、AIが圧倒的な速度と精度で代替した。

この事実は、AIの応用範囲がテキスト空間から物理空間へと完全に拡張されたことを証明している。

複数のAI導入事例を分析した統合知見（crossSourceFindings）でも、AIの物理制御への移行は2025年の最大トレンドとされている。

開発者目線で読み解く。独自ドメイン言語とコンテキストの暴力

なぜClaudeは、学習したこともないNASAの独自言語を書けたのか。

答えはコンテキストウィンドウの圧倒的な処理能力にある。

NASAのエンジニアは、長年の運用データ、過去の成功例と失敗例、そして独自言語の仕様書を丸ごとClaudeに読み込ませた。

事前学習で全てを知っている必要はない。

その場でルールを与えれば、Claudeは瞬時にそのドメインの専門家になる。

世の中の企業には、外部には絶対に公開されていない秘伝のタレのようなシステムが無数にある。

しんたろー：
結局、LLMの勝負はコンテキストウィンドウの広さと精度に行き着く。
Claude Codeに大量のファイル読ませても破綻しないのは、この基礎能力のおかげだ。

20年前に退職したエンジニアが残した謎の社内フレームワーク。

ドキュメントすら存在しないレガシーなデータベース。

APIすら用意されていない古い業務システム。

これまでは、AIは社内の独自仕様を理解できないと諦められてきた。

火星探査車の事例はそれを完全に覆した。

過去のソースコード、コミット履歴、社内Wikiの断片。

それらをコンテキストとして与えれば、AIは非公開の独自言語すら完璧にマスターする。

専用のAIモデルを何千万円もかけてファインチューニングする必要はない。

汎用のLLMに適切なコンテキストを与えるだけで、独自の業務ドメインに適応できる。

数十万トークンという巨大なコンテキストウィンドウが、これを可能にしている。

AIがレガシーシステム開発を変える理由は以下の通りだ。

* 独自仕様を瞬時に理解する

* 非公開言語の構文を学習する

* 過去のバグから安全な実装を推論する

* 大量のコンテキストを破綻せずに保持する

さらに驚くべきは、Claudeが物理世界の制約を理解したことだ。

ソフトウェアのバグなら、エラーを吐いてやり直せばいい。

火星では、車輪がスタックすれば物理的に終わりだ。

Claudeは過去のSpiritローバーの失敗データなどの文脈を読み込んだ。

その上でリスクを数値化し、安全マージンを計算してルートを導き出した。

テキスト生成やコード生成の世界から、AIエージェントは物理ハードウェアの制御という領域に完全に足を踏み入れた。

Claude Codeのようなツールを使えば、ソフトウェアの枠を超えた開発が可能になる。

工場の古いIoT機器の制御ロジック。

独自のプロトコルで通信するハードウェアの自動化。

仕様書と過去のログさえあれば、AIが自律的に制御コードを生成して実行する。

僕が普段使っているClaude Codeの挙動を見ても、この適応能力の高さは実感できる。

特定のディレクトリ内のコードベースを読み込ませると、プロジェクト独自のコーディング規約や命名規則を勝手に理解する。

このプロジェクトではこういう書き方をするんだな、という空気を読む能力が異常に高い。

NASAのエンジニアも、これと全く同じアプローチで火星探査車を動かした。

社内のレガシーシステムがAIで蘇る。実務へのインパクト

僕らの日々の開発にどう関係するのか。

社内の触りたくない古いシステムの自動化が一気に現実味を帯びてくる。

これまで、レガシーシステムの改修や自動化は人間のエンジニアの泥臭い作業だった。

仕様書がないなら、ソースコードを読んでリバースエンジニアリングするしかない。

その作業をまるごとAIエージェントに投げられる。

過去のコードベース全体をコンテキストとして渡し、このシステムの仕様を解析して新しい機能を追加するコードを書けと指示するだけだ。

しんたろー：
うちの構成だと、古臭い外部APIとの連携部分が常にネックになる。
ドキュメントごとAIに投げつけてラッパー書かせるのが一番手っ取り早い。

特に注目すべきは、独自マークアップ言語やドメイン固有言語への対応だ。

世の中には、特定の業務のためだけに作られたマイナーな言語が山ほどある。

それらを習得する学習コストは、開発者にとって大きな負担だった。

AIがそれを肩代わりしてくれる。

仕様書といくつかのサンプルコードを渡せば、AIは即座にその言語のネイティブスピーカーになる。

人間が新しい言語のシンタックスを覚える時間は、もう必要ない。

社内でAIに読み込ませるべきデータ資産は以下の通りだ。

* 過去のソースコードとコミット履歴

* 退職したエンジニアが残した社内Wiki

* システムの障害報告書と対応ログ

* 独自フレームワークの仕様書とサンプルコード

これらはすべて、AIに独自ドメインを学習させるための貴重なデータだ。

APIがないから自動化できない、という言い訳も通用しなくなる。

画面の操作ログや過去の入力データをコンテキストに含めれば、AIはGUIの操作手順すら推論してスクリプトを生成する。

火星の未開の地を自律走行できるAIにとって、社内の古い業務システムのハックなど造作もないことだ。

古いシステムを捨てるのではなく、AIのコンテキストとして再利用する。

AIエージェントの進化は、単なるコーディング支援の枠を越えた。

システム全体のアーキテクチャを理解し、未知の仕様に適応し、自律的に問題を解決する。

NASAが証明したこの事実は、すべての開発現場に波及する。

AIによる独自システム制御の疑問

Q1: Claudeはどのようにして火星探査車専用のコマンドを書けたのか？

NASAのエンジニアが、長年の運用データや経験をコンテキストとしてモデルに提供した。

これにより、Claudeは一般的なプログラミング言語だけでなく、NASA独自のXMLベース言語であるRover Markup Languageの仕様を完全に理解した。

事前学習データに依存せず、プロンプト実行時に与えられた膨大なコンテキストから独自の構文ルールを抽出し、正確なコマンドを生成している。

Q2: AIが生成したルートで探査車がスタックする危険性はないのか？

探査車にはAutoNavという自律ナビゲーションシステムが搭載されており、ウェイポイント間の障害物をある程度回避できる。

さらに、Claudeは単発のプロンプトで動くわけではない。

過去の失敗例を含む膨大な運用データをコンテキストとして考慮している。

リスクを数値化し、安全マージンを確保した上でルートを計画している。

Q3: この事例は一般的な開発業務にどう応用できるか？

社内独自のフレームワークやレガシーなシステムに直接応用できる。

過去のコード資産や運用マニュアルをClaude Codeなどにコンテキストとして読み込ませるだけでいい。

AIに独自言語でのコーディングやシステム操作を委任できる。

特殊なドメイン知識が必要な業務の自動化や、APIが整備されていない古いシステムの改修において、開発リソースを大幅に削減できる。

しんたろー：
宇宙開発のニュース見て自分のコードのリファクタリング思いつくのは職業病だ。
でも実際、レガシーコードの解読能力は今のAIが一番輝く領域だ。

まとめ

火星探査車を動かした技術は、僕らの手元にあるAIと全く同じものだ。

独自仕様やレガシーシステムは、もはやAI導入の障壁にはならない。

👉 ThreadPostでSNS運用を自動化する