Google TPU宇宙進出！Starship1800回発射が必要な軌道AIの現実

• 事実と背景：GoogleがPlanet Labs製衛星に自社TPUを搭載し軌道打ち上げを実施。宇宙空間でのAI計算実証を開始した。
• 技術的変革：15分バースト駆動と81機編隊のレーザー通信構想。放射線エラーは推論に耐えるがメガスケール学習に強い懸念。
• 現場への影響：2035年の軌道AI実現にはStarship 1,800回飛翔が必要。地上エンジニアはノイズ耐性と省電力設計の強化が急務となる。

深夜の障害対応で、データセンターのPDU（電源分配ユニット）が跳んでラック丸ごと沈黙した悪夢を覚えているだろうか。地上でのメガワット級、さらにはギガワット級に膨れ上がるAIデータセンターの電力枯渇問題は、いまや我々開発者のアーキテクチャ選択を直接脅かす物理的な障壁となっている。こうした背景の中でGoogleが始動させた「Project Suncatcher」は、自社開発のAIアクセラレータであるTPU（Tensor Processing Unit）を宇宙空間へと打ち上げ、太陽光エネルギーが事実上無制限に得られる軌道上にコンピュートノードを構築しようという、一見すると壮大なムーンショットである。

しかし、今回のプロトタイプ実証において、GoogleがTPUの駆動時間を「15分間のバースト実行」に制限している点に、私はエンジニアとして強烈な現実の厳しさを突きつけられた思いがする。大気が存在しない宇宙空間では、地上のように空冷ファンを回すことも、水冷ジャケットで冷媒を循環させることもできない。熱の移動は「輻射（ラジエーション）」のみに依存するため、1kWという、地上基準では標準的なサーバーラックの足元にも及ばない電力消費ですら、チップの熱暴走（サーマルスロットリング）を引き起こす致命的な熱溜まりとなるのだ。

GoogleはPlanet Labsとタッグを組み、来年には2機の衛星を高度な光レーザー通信リンクで結び、協調分散処理を行わせる計画だ。最終的には81機の衛星を高密度な編隊飛行（フォーメーションフライト）で飛ばし、超低レイテンシのインターコネクトを宇宙空間で再現するという。これは地上でいうところのInfiniBandやRoCE v2によるクラスター構成を、数百キロメートル上空で物理的なノードごと相対移動させながら維持することを意味する。分散システムにおけるクロック同期やパケットロスの課題を日々泥臭く解いている身からすれば、このアーキテクチャが内包する複雑性の高さには眩暈すら覚える。

宇宙空間で半導体を動かす際の最大の敵は、熱だけではない。銀河宇宙線や太陽高エネルギー粒子が引き起こす「シングルイベントアップセット（SEU）」、すなわち放射線によるメモリや論理回路のビット反転（Bit Flip）である。GoogleがJoule誌に寄稿した査読付き論文によれば、粒子加速器を用いた過酷な放射線照射テストの結果、TPUのロジック回路において約100万分の1（1 in a million）という割合で計算エラーが発生することが確認されたという。

この「100万分の1」という数値を、我々現場のエンジニアはどう評価すべきだろうか。結論から言えば、LLMのトークン生成や画像認識といった「推論（Inference）」ワークロードであれば、このエラー率は十分に許容範囲内である。確率的に動作するニューラルネットワークにおいて、テンソル積のわずかな計算ノイズは出力の表現力をわずかに揺らす程度であり、量子化（Quantization）による精度低下と同等以下の影響で収まるからだ。

しかし、問題は「大規模分散学習（Training）」である。何千ものTPUを何ヶ月も同期させ、巨大なパラメータの勾配（Gradient）を計算し続けるメガスケールな学習ランにおいて、100万分の1のエラーは致命的なスパゲッティコード以上の破滅をもたらす。AllReduce処理の最中に1つのノードで勾配ベクトルが突然NaNに化ければ、モデル全体が不可逆的に崩壊する。チェックポイントからのリカバリを繰り返す無限ループに陥り、貴重な計算資源が無駄に消費される未来は容易に想像がつく。GoogleのTravis Beals氏が「メガスケール訓練においては依然として問題だ」と認めている通り、宇宙データセンターは当面、推論専用のエッジノードとして機能せざるを得ないのが客観的な事実である。

Googleのホワイトペーパーが突きつけた最も衝撃的な試算は、技術的スペックではなく「物流の数字」にある。2035年までに軌道上コンピュートを経済的に成立させるためには、ロケットの打ち上げコストを1kgあたり約200ドルまで引き下げる必要があると結論づけられている。そして、Falcon 1以来SpaceXが達成してきた年間約20%のコスト削減「学習曲線」を維持するためには、同社の超大型ロケットStarshipが今後10年間で累計37万トンのペイロードを軌道に運ばなければならないという。

Starshipが1回のミッションで200トンの物資を運べると仮定しても、これは実に「1,800回」の打ち上げを意味する。年間にして180回、つまり2日に1回以上のペースで巨大ロケットを打ち上げ続ける計算だ。現在までにStarshipが試走した回数を考えれば、これは正気の沙汰とは思えないスケジュールである。イーロン・マスクは2029年までに1時間単位での打ち上げを目指すと豪語しているが、規制審査や発射台のターンアラウンド時間を考慮すれば、このロードマップに懐疑的にならざるを得ない。

GoogleはSpaceXの株式を推定940億ドル分（Bloomberg報道）保有する大株主でありながら、自らの研究論文で相手のボトルネックを冷静に暴露してみせた。以下の表は、地上と宇宙におけるコンピュート基盤のトレードオフをまとめたものである。

地上での電力量制限というデッドロックを避けるための回避策として宇宙を選ぶか、あるいは輸送コストというハードルに押し潰されるか。この冷酷な二項対立が、AIインフラの次世代の姿を決めることになる。

宇宙データセンターというSFめいたトピックを、我々開発者は単なる他人事のニュースとして消費してよいのだろうか。私はそうは思わない。宇宙という「リソースが極度に制約され、ノードが頻繁に瞬断し、計算結果にノイズが混入する極限環境」に向けたソフトウェアアーキテクチャの模索は、そのまま地上の開発現場における実践的な処方箋となるからだ。

我々が今すぐ取り組むべき処方箋の筆頭は、完璧なインフラ環境を前提とした「甘いコード」からの脱却である。ネットワークの瞬断やノード障害を前提としたレジリエントな分散キューイング、チェックポインティングの軽量化、そしてモデルの量子化（INT4/INT2化）による徹底的なメモリ・電力フットプリントの削減。これらは宇宙でTPUを走らせるための技術であると同時に、地上のエッジデバイスや電力逼迫地域のリージョンで安定したAIサービスを提供するための必須スキルに他ならない。

最後に、我々エンジニア自身に痛烈な問いを投げかけたい。我々はこれまで、無制限に拡張されるクラウドの潤沢なインフラに甘え、計算効率の悪さを暴力的なリソース投入でカバーしてはこなかっただろうか。1,800回のロケット打ち上げを必要とするような極限の外部依存へと逃避する前に、我々にはコードとアルゴリズムの側で解決すべき課題が山積みになっているのではないか。明日からの開発において、あなたの書くその1行は、極限の制約下でも耐えうる堅牢性と美しさを持っているだろうか。