スタートアップ分析
Starcloud の宇宙データセンター構想を読む
Starcloud は、地上データセンターが抱える電力・冷却水・土地・許認可という制約を、軌道側の打ち上げ質量・通信帯域・軌道運用・デブリと再突入責任という別種の制約に置き換えようとしています。問うべきは「宇宙で計算するのは正しいか」ではなく、この制約の交換レートが本当に有利なのか、そしてその賭けのどこまでが Starcloud-1 で実証済みで、どこから先が未証明かです。
私はこの構想を全面肯定も全面否定もしません。私が取る立場は、データの投入と結果の回収を時間的に切り離せる計算——学習、バッチ推論、地球観測データ処理——に限れば、制約移動の理屈は物理的に通っており、Starcloud-1 の H100 実証は追う価値がある、というものです。ただし対話型・低遅延のワークロードには当面向かないと見ています。したがって日本企業が今すべきは宇宙クラウドの調達検討ではなく、自社の AI ワークロードを「境界を切れるかどうか」で棚卸ししておくことだと考えています。
この立場の境界も明記しておきます。対象は学習・バッチ処理に限り、対話系は除外します。実証は Starcloud-1 という1機分にとどまり、Starcloud-2 の電力生成量と通信帯域が公開されるまで、商用性の判断は保留します。この境界が公開情報によって覆されれば、朝令暮改します。
「境界を切れるかどうか」という線引きは、抽象的な思考実験ではなく、AI ワークロードを設計する際に常につきまとう問いだと考えています。学習やバッチ推論は、いつ計算が終わってもよく、結果をどこで受け取るかも柔軟です。一方、対話型の処理はユーザーが待っている間に応答を返す必要があり、遅延そのものが体験の一部になります。この違いは宇宙計算に限った話ではなく、地上のクラウド設計でも「どの処理を非同期化できるか」という形で常に問われてきた論点であり、Starcloud の構想はこの論点を軌道上という極端な環境に持ち込んだだけだ、というのが私の理解です。
Elon Musk と Jensen Huang の対談を扱った別記事では「宇宙での計算基盤」が抽象的な構想として語られていましたが、この記事はそれを Starcloud という具体企業の実証段階に接地させる試みでもあります。
この記事は、Starcloud 公式サイト、Y Combinator の会社紹介、Starcloud チームの公式ブログ、CEO Philip Johnston の動画ツアー、Google Project Suncatcher の発表を一次導線として、将来の価格やロードマップの日付を当てるためではなく、「どのワークロードを外に出せるか」を切り分けるための素振りとして書いています。
宇宙データセンターの概念図
前提: 2つの言葉を定義する
制約移動（constraint relocation） とは、地上データセンターの電力・冷却水・土地・許認可という制約を、軌道側の打ち上げ質量・通信帯域・軌道運用/保守/デブリ・再突入責任という別種の制約に置き換える設計思想を指します。この言葉を使うのは、Starcloud の主張を「安くなる」という曖昧な話ではなく、「制約の交換レートが有利かどうか」という検証可能な問いに変えるためです。どちらの制約が軽いかは自明ではありません。
境界を切れる計算 vs 境界を切れない計算 とは、入力データの投入と結果の回収を時間的に分離できる計算（学習・バッチ推論・地球観測データ処理）と、対話のように入出力が連続し低遅延を要する計算を区別する言葉です。この線引きが、どのワークロードが軌道上計算の候補になるかを判定する実務上の唯一の基準になります。以降、この記事ではこの2つの言葉だけを一貫して使います。
この線引きを実務で使う際に難しいのは、多くのワークロードが両方の性質を併せ持つ点です。たとえば学習パイプラインの中にも、途中で人間の判断を挟む工程があれば、その部分だけは境界を切れません。したがって「このシステムは境界を切れる」と一括りにするのではなく、工程単位で分解し、どこまでが非同期に切り出せるかを見極める作業が必要になると考えます。
制約の置き換えを一覧で見る
| 論点 | 地上データセンターで詰まりやすい点 | 軌道上で解くときの新しい問い |
|---|---|---|
| 電力 | 大規模 AI 計算が電力網と立地を強く縛る | 太陽光発電を高い稼働率で使えるか |
| 冷却 | 水、電力、地域環境への負荷が大きい | 放射冷却に必要な面積と質量を許容できるか |
| 土地 | 用地、送電、許認可、近隣合意が制約になる | 軌道、デブリ回避、再突入、保守を設計できるか |
| 通信 | 地上内の広帯域接続が前提になる | データ投入と結果回収の帯域を確保できるか |
| 運用 | 現地作業や部品交換が可能 | 軌道上での冗長化と交換単位をどう決めるか |
この置き換えは、境界を切れる計算にしか向きません。低遅延の対話処理は、当面は地上側に残ると考えるのが妥当です。IEA も、データセンターとデータ通信ネットワークを建物セクターの中で電力需要の伸びが目立つ領域として追跡しており、地上側の制約自体は一次情報でも裏付けられます。
StarCloud創業からの歴史タイムライン
電力: 太陽同期軌道は「無料だから安い」ではない
Starcloud の公式ブログは、dawn-dusk の太陽同期軌道を使うことで太陽光を長時間受けられる点を強調しています。ただし論点は「太陽光は無料だから安い」ではありません。太陽電池、構造物、打ち上げ質量、電力変換、バッテリー、冗長化まで含めた総コストで地上側と競争できるかが問いです。太陽同期軌道による連続受光は電力の「量」の問題を緩和しますが、それを運ぶ構造物と打ち上げ質量という新しい制約を生みます。制約移動という言葉が指しているのは、まさにこの交換です。
冷却: 深宇宙への赤外線放射という賭け
地上では水冷や空調で熱を外へ逃がします。軌道上では空気の対流が使えないため、ラジエーターから赤外線として熱を放射するしかありません。Philip Johnston は動画ツアーで、冷却媒体を「深宇宙への赤外線放射」と表現しています。この表現は印象的ですが、実務上の問いは明確です。GPU と電力系が出す熱を捨てるだけの面積を、打ち上げ可能な質量と展開機構で実現できるか。Starcloud が大型の展開型ラジエーターに注力する理由はここにあります。
これも制約移動の一例です。地上では水という資源の制約だったものが、軌道上では展開機構の面積と質量という制約に置き換わっています。どちらが軽いかは、まだ Starcloud-1 の1機分のデータでしか検証されていません。
通信: 結果だけを返せばよいわけではない
「計算結果だけを返せばよい」という説明は直感的ですが、境界を切れない計算には当てはまりません。学習データの投入、モデル更新、ログ、障害解析、再学習のための中間データまで考えると、通信帯域はボトルネックになりえます。
この論点は、AI クラスタのネットワーク層を扱うNexthopの記事で扱った、地上側でも通信がボトルネックになるという構造と対になっています。軌道側と地上側のどちらでも、「計算さえ速ければよい」という前提は通信の実態と合いません。後続ロードマップで光通信や衛星ネットワークが重要になるのはこのためで、Google の Project Suncatcher も衛星間リンクと通信制御を研究課題として掲げています。
Starcloud-1: 実証機として読む
Y Combinator の会社紹介によると、Starcloud は November 2025 に Starcloud-1 を打ち上げ、Nvidia H100 を搭載した初号機で LLM の学習や Gemini の実行に踏み出したと説明しています。Starcloud 公式の Starcloud-1 ページも、November 2025 launch、December 2025 running Gemini and nanoGPT workloads という順序でロードマップを示しています。
ここで重要なのは、「すぐに宇宙クラウドが買える」という話ではないということです。初号機は、地上グレードの GPU、熱、放射線、電力、通信、運用をひとつの小さな宇宙機で確かめるための実証機として読むべきです。
| 論点 | 読み方 |
|---|---|
| GPU | 地上用 GPU を軌道上に載せる設計と遮蔽の検証 |
| 熱 | 小型機で得た熱データが大型ラジエーター設計へつながるか |
| 電力 | 軌道上の発電・蓄電・電力変換が安定するか |
| 通信 | 実運用に必要な入力データ量と結果回収を扱えるか |
| ソフトウェア | 学習・推論・監視・再起動を遠隔で管理できるか |
動画で語られる「世界初」という表現は、マーケティング文としてではなく、どの制約をどの順番で外しているかを確認するための手がかりとして扱うほうが堅実です。
混同しやすい2点を整理する
Starcloud の話で混同しやすいのが宇宙太陽光発電です。宇宙で発電して地上へ送電する構想と、宇宙で計算して結果だけを返す構想は、似ているようでボトルネックが違います。Starcloud のホワイトペーパーや創業者インタビューで繰り返されるのは「電力を地上に送る」のではなく「電力を軌道上で計算に変える」という発想で、送電ロスを避けられる一方、データ通信・保守・軌道運用・デブリ・再突入設計という別の責任が生まれます。評価すべきは宇宙発電の成立性ではなく、打ち上げ質量あたりの計算能力、冷却面積、通信帯域、運用寿命、交換単位、法的・保険上の責任分界を含めた総合設計です。
もう1点、創業チームの補完性も見ておく価値があります。公式チームページと YC の創業者紹介からは、Philip Johnston（Co-Founder & CEO、衛星プロジェクトと経営の背景）、Ezra Feilden（Co-Founder & CTO、展開型太陽電池や大型展開構造の経験）、Adi Oltean（Co-Founder & Chief Engineer、SpaceX / Microsoft で衛星ネットワーク・OS・クラウド・機械学習インフラに関与）という役割の重なりではなく補完関係が読み取れます。GPU クラスタ、衛星構造、熱設計、製造を同時に扱う必要がある構想であることの裏付けです。
大手の動きは競争でなく先行学習として読む
Google は Project Suncatcher で、TPU を積んだ太陽光駆動の衛星ネットワークを使い、機械学習計算を宇宙で拡張する研究構想を公開しており、Planet との学習ミッションで試験衛星を打ち上げる計画も示しています。Amazon Leo（旧 Project Kuiper）や SpaceX Starlink は、宇宙データセンターそのものではなく低軌道通信インフラとして読むべきで、軌道上で計算するには計算ノードだけでなく、データを運ぶネットワーク、地上局、運用ソフトウェア、規制対応が必要になります。
この文脈での Starcloud の位置づけは「大手より確実に勝つ会社」ではなく、「地上グレード GPU を積んだ初期実証から、宇宙計算の制約を先に学んでいる会社」です。先行者優位は、打ち上げ回数、データ、顧客契約、運用実績に変換されて初めて意味を持ちます。AI IPOラッシュのメモで扱った、大型AI企業の資本配分を日付予想でなくメッセージとして読む姿勢と、この点は共通しています。
実証済み・実証中・未証明で並べ直す
ここまでの材料を、時系列やロードマップの日付ではなく「何がどこまで確かめられたか」の軸で並べ直します。
- 実証済み: H100 搭載機の軌道投入、Gemini / nanoGPT ワークロードの実行、太陽同期軌道による長時間受光という設計選択そのもの
- 実証中（Starcloud-1で検証中）: 熱・放射線環境での安定運用、遠隔でのソフトウェア管理、展開型ラジエーターの実運用データ
- 未証明（Starcloud-2以降）: 商用規模の電力生成量、通信帯域が実運用に足りるか、収益性の仮説、打ち上げ質量あたりの総コストが地上側と競争できるか
Starcloud 公式サイトには Starcloud-1 から Starcloud-4 までのロードマップページがあり、YC の紹介では second satellite を October 2026 に、Starcloud-2 ページでは太陽同期軌道でのフル稼働を 2027 年の節目として示しています。この種のロードマップは変わりやすいため、日付や GPU 型番を固定した事実として扱わず、上の3段階のどこが動いたかで進捗を測るのが安全です。
この並べ替えから抽出できるレバーは2つです。第一に、制約移動が有利かどうかを決めるのは電力や熱の物理そのものではなく、Starcloud-2 以降で公開される通信帯域と電力生成量という数字です。第二に、先行者優位は打ち上げ実績の回数でしか裏付けられず、Starcloud-1 の1機分では判断材料として不十分です。
日本企業への含意: 調達より先に棚卸し
この棚卸しを二次的な分析として整理するなら、最初に効いてくるのはおそらく価格でも性能でもなく、データ所在地と再実行可能性の2点だと考えます。境界を切れる処理であっても、データが越境してよいか、障害時に同じ計算をやり直せるかが曖昧なままでは、宇宙計算に限らずどの外部インフラへの委託判断も止まってしまうはずです。逆に言えば、この2点さえ社内で整理できていれば、宇宙クラウドという選択肢が現実になったときの意思決定は速くなります。
日本企業がすぐに「宇宙クラウド」を調達できるわけではありません。むしろ今すべきなのは、AI インフラ戦略のリスク管理として、自社ワークロードを境界を切れるかどうかで分類しておくことだと考えます。チャット UI、検索、制御系のように低遅延が必要な処理は地上クラウドやエッジ側に残る可能性が高く、学習、評価、バッチ推論、地球観測データ処理のように入力と結果の境界を切りやすい処理は、将来の候補になりえます。
調達を検討する段階になったら、最低限次を確認する必要があります。
- データ所在地と越境移転の扱い
- 地上局と通信経路の冗長性
- 障害時の再実行とデータ消失時の責任
- モデル、学習データ、ログの暗号化と鍵管理
- 軌道デブリ、再突入、保険、輸出管理の責任分界
- 価格単位と地上クラウドとの性能測定条件
ただし、価格表が出る前からできることがあります。それが、AI ワークロードを境界を切れる/切れないで棚卸ししておくことです。調達の意思決定はまだ先でも、この棚卸しは今日からできます。
データは脅しではなく、決断の材料だと捉えてもらえると嬉しいです。私自身の立場も、Starcloud-2 の電力生成量と通信帯域が公開されれば変わりえます。この素振りは、次のロードマップ更新があったタイミングでもう一度やり直そうと思っています。
参考リソース
- Starcloud 公式サイト
- Starcloud: Starcloud-1
- Starcloud: Roadmap
- Starcloud Team
- Starcloud Blog: How data centres in space sustainably enable the AI revolution
- Y Combinator: Starcloud
- Google: Project Suncatcher
- Amazon Leo
- IEA: Data Centres and Data Transmission Networks
- StarCloud: Building Data Centers in Space (YouTube)
本記事はネクサフローのAI研究シリーズの一部です。
