Googleの宇宙データセンターが軌道へ到達、しかし拡張にはStarship打ち上げ1,800回が必要
Googleの宇宙データセンターは10月1日、同社が4基のAIチップを軌道に投入したことで、研究論文の段階を越えた。しかし、この実験はさらに大きな課題も浮き彫りにした。Googleの経済モデルは、SpaceXが10年以内にStarshipを約1,800回打ち上げられることを前提としている。
この推計は、すべてのミッションが200メートルトンを搭載すると仮定した場合、年間およそ180回の打ち上げに相当する。Starshipが初めて地球周回軌道に到達したのは、Googleの衛星打ち上げの数日前に過ぎない。そのため、Googleの想定する経済性を成立させるには、SpaceXは開発途上のロケットを産業規模の輸送ネットワークへと変貌させなければならない。
この小型衛星だけで、その問いに答えが出るわけではない。GoogleのTensor Processing Units（TPU）が、放射線、打ち上げ時の振動、極端な温度変化に耐えられるかを検証するものだ。また、地上のデータセンターで利用できる空気冷却なしに、これらのチップを動作させられるかも調べる。
Googleはこの広範な取り組みをProject Suncatcherと呼ぶ。提案されているシステムでは、太陽光で動くコンピューティング衛星を低軌道に配置し、光リンクで接続する。豊富な太陽エネルギーが魅力となる一方、実用化への障壁には打ち上げコスト、排熱、通信、保守、軌道上での調整が含まれる。
SpaceXは、この計画に不可欠な供給者であると同時に、最も大きな依存先でもある。Googleはチップ、ソフトウェア、衛星設計を社内で改善できる。しかし、打ち上げ事業者が前例のない規模で再利用を実現しない限り、安価な軌道輸送を自力で生み出すことはできない。
Googleの宇宙データセンターは、軌道上クラウドではなく4基のチップから始まる
Googleが打ち上げたのはハードウェア実験であり、地上データセンターの稼働中の代替手段ではない。
MVPと呼ばれる最初のProject Suncatcher宇宙機は、SpaceXのTransporter-18ライドシェアミッションでカリフォルニアから打ち上げられた。軌道ミッションの概要によると、Falcon 9はこれをほかの129基のペイロードとともに運んだ。
この衛星は、地球観測企業Planetとのパートナーシップを通じて製造された。Googleは、4基のTPUを含むコンピューティングハードウェアを提供した。TPUは、機械学習のトレーニングと推論向けにGoogleが開発した独自アクセラレーターである。
冷蔵庫ほどの大きさの宇宙機は、太陽光パネルから約1キロワットを受け取る。この電力供給は、商用AI施設に必要な規模とは大きく隔たっている。大規模な地上システムでは、広範なネットワーク、ストレージ、冷却、電力設備に支えられた数千基のアクセラレーターが使われる。
MVPはGeminiワークロードを実行し、ハードウェアが軌道上でどのように動作するかを検証する。報道によれば、この衛星は蓄積した熱を放出するために停止するまで、プロセッサーを約15分間動かせる。この動作パターンは、継続的に利用可能なコンピューティングサービスというより、科学機器に近い。
このミッションにより、Googleの当初の予定は前倒しされた。同社は以前、2027年初頭にPlanetとともに2衛星による学習ミッションを行うとしていた。既存のPlanet宇宙機にチップを統合したことで、Googleはより早く軌道上データを収集できた。
Googleによると、この衛星は打ち上げ時の物理的ストレスと、宇宙空間に存在する熱環境および放射線環境を評価する。こうした測定により、地上シミュレーションでは完全には再現できない証拠をエンジニアに提供できるはずだ。
「宇宙データセンター」という表現は、顧客ワークロードを処理する成熟した施設を想起させる可能性があるため、この区別は重要だ。MVPはコンパクトな実験室に近い。その役割は、Googleがより大規模な衛星アーキテクチャに踏み切る前に、故障モードを特定することにある。
それでも、この打ち上げはProject Suncatcherの位置づけを変えた。このプロジェクトには、シミュレーションだけでなく、実際の軌道環境にさらされたハードウェアが存在する。その証拠は、前提を裏付けることも、予想外の不具合を明らかにすることも、Googleにシステムの再設計を迫ることもあり得る。
この試験は、SpaceXにとって重要な時期にも行われた。Starshipは9月28日に初めて地球周回軌道へ到達し、26基のStarlink衛星を展開した。上段機はエンジンを1基失い、予定より早く帰還したが、このミッションは必要な能力を実証した。
Googleの衛星はStarshipでは打ち上げられていない。ミッションを担ったのはFalcon 9だった。しかし、Falcon 9には、Googleが完全な軌道上コンピューティングネットワークに必要と見込むペイロード経済性と搭載容積がない。
だからこそ、この小規模な実験は直ちに、はるかに大きなインフラの問題を示している。4基のチップならライドシェアミッションに相乗りできる。高密度なコンピューティングシステムを搭載する数千基の衛星には、根本的に異なる打ち上げ運用が必要になる。
Project SuncatcherがStarshipの経済性を必要とする理由
Project Suncatcherは、反復、再利用、そして莫大な累積ペイロード量によって打ち上げ価格が下がることに依存している。
Googleの研究では、2030年代半ばまでに低軌道への輸送コストが1キログラム当たり200ドルに近づく可能性があると推計している。この推計は、SpaceXの過去の打ち上げ価格と累積ペイロード質量に基づく学習曲線から導かれた。
学習曲線は、製造経験と単位コストの低下を結び付けるものだ。Googleの研究者は、SpaceXでは累積打ち上げ質量が倍増するたびに、1キログラム当たりの価格がおよそ20%下がったと推定している。
このパターンをStarshipまで延長すると、プロジェクトで最も驚くべき数字が導かれる。SpaceXは、想定された軌道を維持するために、さらに約37万メートルトンを軌道へ輸送する必要がある。
1ミッション当たり200メートルトンとすると、これはStarshipの打ち上げ約1,800回に相当する。10年間で平均すると、年間およそ180ミッションが必要になる。初期数年はこの平均を下回る可能性が高く、その後の運用ではさらに速いペースが求められる。
これらの数値はGoogleの軌道上コンピューティングに関する論文に基づく。研究者らは、自らの研究が完全な経済的実現可能性調査ではないと強調している。むしろこの計算は、打ち上げ価格が事業性を支配しなくなるために何が起きなければならないかを示している。
Googleが軌道への輸送コストを地上データセンターの継続的なエネルギー費用と比較しているため、200ドルという閾値は重要だ。その打ち上げ価格であれば、効率的な衛星の生涯調整後の輸送コストは、地上の電力コストの大まかな範囲に入る可能性がある。
この比較には限界がある。実際のサービスが競争力を持つかどうかを決めるいくつかの費用が除外されている。衛星は設計、製造、保険、運用、接続、冗長性を通じた修理、そして最終的な交換を必要とする。
この論文は、機体設計の大きな変化をまたいで過去の価格改善が継続できるとも仮定している。Falcon 9とStarshipでは、生産システム、運用パターン、リスクプロファイルが同一ではない。以前のロケットから引いた傾向が、Starshipの将来の性能を保証することはできない。
Googleの分析はこの不確実性を認めている。この推計は、高頻度の再利用、累積輸送量、技術的な実行力、市場競争、規制条件に依存するとしている。したがって、価格予測は条件付きの結果であり、提示された商用オファーではない。
同社は、より低い輸送量のシナリオも検討している。ペイロードの増加が中心推計を約70%下回った場合でも、打ち上げ価格は1キログラム当たりおよそ300ドルに達する可能性がある。この結果は、1,800回の打ち上げシナリオを完全に満たさなくても、軌道上での経済性を改善し得る。
しかし、打ち上げ価格の低下だけでは需要は生まれない。SpaceXには、繰り返されるStarshipミッションを満載できるだけのペイロードを持つ顧客が必要だ。軌道上コンピューティングはそのような顧客の一つになり得るが、それは安価な打ち上げによって初めてコンピューティングシステムの実現性が生まれる場合に限られる。
ここには循環依存がある。宇宙データセンターは、拡張するために安価な打ち上げ能力を必要とする。Starshipは、予測されたコスト曲線を下げるために膨大な打ち上げ需要を必要とする。
Googleは単にロケットの低価格化を待っているわけではない。Project Suncatcher自体が、それらのロケットを低価格化するために必要な質量の一部を供給する可能性がある。この可能性により、GoogleとSpaceXの関係は通常のベンダー契約ではなく、相互依存の関係となる。
したがって、この打ち上げ回数は単なる目を引く統計ではない。4基のチップによる実験と、将来の軌道上ネットワークの経済性を結び付ける仕組みなのである。
Googleと打ち上げ頻度という現実の対決
中心的な対抗相手は他のクラウド事業者ではない。SpaceXの打ち上げ目標と、年間180ミッションという運用頻度との隔たりだ。
Starshipの初の軌道飛行は重要な節目だったが、一度軌道に到達することと、年間数百回を運用することは異なる。SpaceXは安全に打ち上げを繰り返し、機体の両段を再利用し、整備作業を減らし、複数の打ち上げ拠点を維持しなければならない。
9月のミッションは、その隔たりを示した。Starshipはペイロードの展開に成功したものの、上段機のエンジン1基が停止した。SpaceXは計画された飛行も短縮し、約3時間後に機体を帰還させた。
開発飛行は問題を発見するために設計されている。エンジンの問題が、機体やGoogleの研究を無効にするわけではない。しかし、それは信頼できる運用頻度をペイロード能力だけから推測できない理由を示している。
年間180回飛行するシステムは、平均するとほぼ2日に1回の打ち上げとなる。この平均には、検査、ペイロード統合、天候遅延、規制当局の承認、発射台の保守、異常への対応に必要な時間も含まれなければならない。
この数値はまた、すべての飛行が200メートルトンを輸送できることを前提としている。実際のペイロードは、機体構成、軌道、回収計画、ミッション要件に左右される。平均ペイロードが低ければ、同じ累積質量を輸送するためにさらに多くの打ち上げが必要になる。
SpaceXは、はるかに高い長期的な飛行頻度を示している。Elon Muskは、最終的にはStarshipを年間数千回飛ばすことに言及している。このような発言は同社の意欲を示すものではあるが、運用システムがすでに存在する証拠にはならない。
最近の進展は、Starshipが商用打ち上げ機となり得るという見方を強めている。その軌道ミッションでは26基のStarlink V3衛星を展開し、ブースターは海岸付近で模擬着陸を完了した。SpaceXは、使い捨てハードウェアではなく迅速な再利用を前提に機体を開発している。
StarlinkはSpaceXに社内需要源をもたらす。同社はStarshipの運用を磨きながら、自社の通信衛星を打ち上げられる。この垂直統合はFalcon 9が飛行経験を積む助けとなり、Starshipの初期運用頻度も支え得る。
軌道上データセンターは異なる要求を課す。コンピュート衛星は、熱管理ハードウェア、大型太陽電池アレイ、光通信機器、高価なプロセッサーを搭載する。単にブロードバンド衛星コンステレーションに加わるのではなく、精密な軌道フォーメーションに到達しなければならない。
GoogleはSpaceXの投資家でもあり、一部の利害は一致している。しかし、投資によって技術的な依存関係がなくなるわけではない。Googleのスケジュールは、同社が設計も制御もしていない輸送システムに結び付いたままである。
他の打ち上げ事業者が、いずれこのリスクを下げる可能性はある。Blue Origin、Rocket Lab、そして将来の大型打ち上げ競合企業は、価格を引き下げるかもしれない。現時点で、Starshipが目指すペイロード量と完全再利用の組み合わせに匹敵する、実証済みの代替手段はない。
Falcon 9はプロトタイプ向けとしては依然信頼できるが、Googleのモデルは、大規模展開には不向きとなる輸送量の制約を示している。そこには不都合な移行期がある。既存のロケットはアイデアを検証できる一方、未完成のロケットがそれを経済的に成り立たせなければならない。
最初、1,800回の打ち上げという試算は、元記事の見出しとURLで1,600回と誤記されていました。公開された訂正により、論文に基づく数値が1,800回であることが確認されました。
この訂正は、課題の規模を改めて浮き彫りにするため重要です。追加の200回は、必要とされる平均打ち上げ頻度で見れば1年以上に相当します。
決定的な証拠は予測ではなく、実運用から得られるでしょう。SpaceXは、より短いターンアラウンド時間、機体の繰り返し再利用、確実なペイロード輸送、打ち上げ拠点の能力拡大を示さなければなりません。それまでは、Googleのコスト曲線は技術的知見に基づくシナリオにとどまります。
81基のAI衛星クラスターは1台のコンピューターのように動作しなければならない
低コストの輸送が解決するのは最初の問題にすぎません。分散AIには、精密な編隊飛行とデータセンター級の通信も必要です。
Googleが提案するアーキテクチャは、81基の衛星からなるグループを用います。例示的なクラスターは平均高度約650キロメートルを周回し、半径1キロメートル以内に収まります。
衛星は近隣の衛星との間隔をおよそ100〜200メートルに保ちます。この配置は、すべての宇宙機が軌道速度で地球を周回する間も安定していなければなりません。
機械学習のワークロードでは、アクセラレーター間で頻繁なデータ交換が発生します。大規模モデルの学習では、プロセッサーが低遅延でデータや中間結果を同期させる必要があります。接続が遅い、あるいは一貫性に欠けると、高価なチップが情報待ちになる可能性があります。
地上のデータセンターは、光ファイバーと専用スイッチでこの問題を解決しています。Project Suncatcherは、こうした固定接続を、精密に指向されたレーザービームでデータを送る自由空間光通信リンクに置き換えます。
Googleは短い実験室内の伝送経路で、一方向あたり毎秒800ギガビットを実証しました。双方向の容量は毎秒1.6テラビットに達しました。この試験は基盤となる通信コンセプトを裏付けるものですが、移動する軌道編隊全体を再現したものではありません。
実際のコンステレーションでは、衛星が位置を変えながら複数のビームを正確に指向しなければなりません。システムは、振動、温度変化、部品劣化、軌道デブリ回避、クラスター内の障害に対応する必要があります。
Googleは、軌道運動の予測と編隊制御を支援するために機械学習モデルを提案しています。このアプローチにより、隣接衛星を通信可能な範囲に維持できる可能性があります。一方で、すでに複雑な物理システムにソフトウェア保証の要件が加わります。
地上との接続も別の制約です。衛星間帯域幅があっても、入力と出力を地球と軌道の間で移動させる必要はなくなりません。大気の乱流、雲、ビーム追尾、地上局の可用性は、光通信を制限する可能性があります。
このアーキテクチャに適するワークロードもあれば、適さないものもあります。すでに軌道上で収集されたデータを処理すれば、地球へ送信する量を削減できます。衛星画像の解析は、元データがプロセッサーの近くで生成されるため、分かりやすい例です。
大規模な地上学習ジョブは、より難しいケースです。データセットは地上のストレージシステムに由来する可能性があります。そのデータをアップロードし、数千個のプロセッサーを協調させ、出力を取得する過程で、豊富な太陽エネルギーの利点の一部が失われかねません。
推論ワークロードは、より扱いやすい可能性があります。推論とは、学習済みモデルを実行して回答、分類、予測を生成することです。こうしたタスクは、長期間の学習実行より小規模で、同期要求も低くなり得ます。
Googleの放射線試験は、この違いを裏付けています。同社の研究者によれば、Trillium TPUは恒久的な故障を起こさず、5年間のミッションに相当する電離放射線量に耐えました。ただし、高エネルギー粒子は依然として一時的な計算エラーを引き起こす可能性があります。
ある研究者はTechCrunchに対し、一般的な推論では約100万回の演算に1回程度のエラーが発生する可能性があると語りました。同じ割合でも、数千個のチップが数カ月に及ぶ学習実行を協調させる場合には、より大きな懸念になります。
ソフトウェアは一部の誤った計算を検出し、再実行できます。冗長なプロセッサーで故障した能力を置き換えることもできます。どちらの対応もエネルギー、ハードウェア、または時間を消費し、経済性を弱めます。
したがって、提案されたクラスターは、単にサーバーラックを地球上空に置くものではありません。ネットワーク、電力供給、冷却システム、物理的配置が常に動いている分散スーパーコンピューターです。
このシステムレベルで見るProject Suncatcherは、従来のクラウドリージョンを移設するというより、軌道力学の制約を中心に新しいコンピューティングプラットフォームを設計することに近いものです。
冷却と修理が事業性を失わせる可能性
最も厳しいリスクは熱の排出と保守です。宇宙には日光がある一方、空気、水、技術者は存在しないためです。
太陽エネルギーはProject Suncatcherにとって最大の魅力です。Googleによれば、適切な低軌道にある衛星は、地上の同等の場所に設置したパネルの最大8倍の太陽エネルギーを受け取れます。
日光へのアクセスは、地上の送電網に関する一部の制約を回避します。地球上の新しいデータセンターは、送電網の増強、発電契約、許認可、地域の承認を何年も待つことがあります。軌道上のシステムなら、プロセッサーのすぐそばで直接電力を生成できます。
しかし、チップに入った電力は最終的に熱になります。地上では、施設は空気、水、冷媒、ポンプ、冷却塔、熱交換器によって熱を移動させます。真空には、熱を運び去る空気がありません。
宇宙機は代わりに、プロセッサーからラジエーターへ熱を伝導しなければなりません。これらの表面は赤外線放射としてエネルギーを放出します。必要な面積は、発生する熱量とハードウェアが許容できる温度に応じて増加します。
GoogleのMVPはこの制約を浮き彫りにしています。4個のチップは、冷却のためにシステムが停止するまで短時間しか稼働できません。15分間の実験から継続的な商用運用へ拡大するには、はるかに大型、または高効率の熱制御ハードウェアが必要です。
ラジエーターは質量と表面積を増やします。質量の増加は打ち上げ要件を高め、大型構造物は展開と衝突回避を複雑にします。技術者が放射線対策として使用する保護シールドにも、同じような負担があります。
独立した熱設計評価は、複数の軌道コンピューティング提案に共通するこのトレードオフを指摘しています。従来型のAIアクセラレーターは必要な性能を提供しますが、放射線耐性を備えた宇宙機部品として設計されたものではありません。
チップを遮蔽すると重量が増えます。露出させたままにすれば、エラーや故障の可能性が高まります。冗長ハードウェアは信頼性を向上させますが、予備のプロセッサーを軌道へ送ると、再び質量、電力、冷却の要件が増加します。
保守も同様に厳しい問題です。地上施設では、技術者が故障したドライブ、ネットワーク機器、電源、アクセラレーターボードを日常的に交換します。軌道上のクラスターは、定期的な有人保守訪問に依存できません。
Googleの論文は、最も単純な対応として冗長な容量配備を提案しています。これは、システムが当初必要とする以上の能力を打ち上げ、その後に障害を迂回することを意味します。
冗長性はサービスを稼働させ続けますが、利用効率を変えます。予備ハードウェアにも製造費と打ち上げ費がかかります。一部の部品は、別の部品が故障するまで遊休状態のままとなる可能性があります。
衛星の寿命も別の制約を生みます。Googleは5年間にわたる放射線被ばくを評価しています。地上施設ではプロセッサーを段階的に交換できますが、衛星ではコンピューティング、電力、冷却、通信が寿命の限られた1つの資産にまとめられる可能性があります。
急速なAIハードウェアの世代交代は、このモデルを複雑にします。現在のプロセッサーを搭載して打ち上げた衛星は、放射線によってミッションが終わるよりはるか前に、新しい地上チップより効率が低くなる可能性があります。交換にはサーバーの入れ替えではなく、別の打ち上げが必要です。
古い機器の軌道離脱も、システム設計の一部でなければなりません。81基の衛星クラスターが管理可能であるためには、故障ユニットが安全に軌道を離脱できる必要があります。大規模な配備は、衝突とデブリに関する懸念を増幅させます。
これらの問題は、軌道コンピューティングが不可能だと示すものではありません。一度のチップ試験の成功だけでは、商用サービスを実証できない理由を示しています。Googleは、エラー率、持続的な熱性能、電力の可用性、部品劣化を時間をかけて測定しなければなりません。
MVPミッションが価値を持つのは、失敗からも有益な知見が得られるからです。温度限界や放射線パターンを今発見する方が、クラスター全体を配備した後に見つけるより低コストです。
Googleの公開上の説明は、適切に慎重な姿勢を保っています。同社のProject Suncatcher更新情報は、この衛星を初期試験と位置づけ、冷却を重要な研究課題として挙げています。
この慎重さは、研究プログラムを短期的な軌道クラウド能力に関するより積極的な主張から切り分けています。この試験は証拠を提供しますが、継続的なワークロード、競争力のあるコスト、実行可能な保守戦略をまだ確立したわけではありません。
宇宙コンピューティングが拡張可能かを決める3つのシグナル
次に必要な証拠は、成功した実験を、再現可能なコンピューティング、再利用可能な打ち上げ、そして1基の衛星を超える信頼できる道筋へ結び付けるものです。
第1のシグナルは、MVPの継続運用データです。Googleは、TPUの稼働頻度、熱の蓄積速度、放射線が推論精度へ与える影響を開示する必要があります。
短時間のセッションが成功すれば、従来型アクセラレーターが軌道上で稼働できることを確認できます。冷却を予測可能な形で伴う長時間セッションは、より強い証拠になります。頻繁な停止や説明できないエラーは、高密度な軌道クラスターの根拠を弱めます。
読者は、Googleがハードウェア健全性の測定だけでなく、Gemini推論の結果を公表するかも注目すべきです。動作するチップは必要ですが、有用なワークロード性能の方が意味のある節目です。
第2のシグナルは、Googleが計画する複数衛星ミッションに向けた進展です。2基以上の宇宙機があれば、単一衛星では再現できない光通信リンク、協調、分散ワークロードを試験できます。
Googleは以前、Planetとともに2基のプロトタイプ衛星を2027年初頭に打ち上げることを目標としていました。更新されたスケジュール、設計、ミッション目標は、MVPからの学びがその計画にどう影響するかを示すでしょう。
複数衛星による実証では、接続の安定性、ビーム追尾の精度、軌道運動がワークロード協調へ与える影響が明らかになるはずです。これらの測定は、Project Suncatcherをシステムとして検証し始めるものです。
第3のシグナルは、Starshipの実際の打ち上げ頻度と再利用実績です。SpaceXが回収したハードウェアを繰り返し飛行させ、ターンアラウンド時間を短縮し、ペイロード運用を拡大できれば、Googleの経済性はより信頼できるものになります。
1回の軌道ミッションでは、コスト曲線は確立されません。信頼性の高い商用飛行が連続すれば、関連する証拠になります。さらに孤立した飛行マイルストーンへ到達することよりも、両段を再利用する方が重要です。
ペイロード能力も、設計目標から実運用上の性能へ移行する必要があります。Googleの1,800回という打ち上げ計算は、1回あたり200トンを前提としています。実証された能力がそれより低ければ、必要なミッション数は変わります。
これらのシグナルはまとめて評価すべきです。より優れたチップでも、輸送費が手頃でなければ補えません。安価な輸送でも、プロセッサーから熱を取り除くことはできません。優れた冷却でも、分散学習に必要な帯域幅を生み出すことはできません。
競合他社も有用な比較材料を提供するでしょう。SpaceXは独自の軌道コンピューティングネットワークを提案しており、Starcloudなどのスタートアップは異なるアーキテクチャを試験しています。その結果は、Googleのクラスター設計が特に保守的なのか、あるいは楽観的なのかを明らかにする可能性があります。
初期の商用利用は、Googleが描く最大のビジョンとは異なる可能性もある。送信前にセンサーや画像データを解析するなど、宇宙空間で完結する処理は地上回線の帯域をあまり必要としない。そのため、より現実的な初期市場となり得る。
一方、地上のユーザー向け汎用クラウドコンピューティングには、より厳しい要件がある。顧客は、信頼性の高いアクセス、予測可能なレイテンシー、安全なデータ処理、迅速なハードウェア交換、明確なサービスレベル保証を期待する。軌道上のインフラは、移動に伴うオーバーヘッドを抱えながら、こうした期待を満たさなければならない。
最も重要な結論は、Googleに正確に1,800回の打ち上げが必要だということではない。この数字は、Starship、衛星設計、市場の発展に伴って変化する前提に基づくモデルから導かれている。
重要なのは、この試算が何を明らかにしているかだ。Googleの宇宙データセンターには、ロケット、宇宙機工場、光ネットワーク、熱工学、自律運用、AIハードウェアにまたがる産業システムが必要となる。
Project Suncatcherは現在、その連鎖の一つを検証し始めている。この衛星は、Googleのチップが実際の宇宙環境に耐えられるかどうかを示せる。しかし、SpaceXが年間数百回の打ち上げを実現できるかどうかまでは判断できない。
この実験が注目に値するのは、投機的なアイデアを測定可能なエンジニアリング計画へと変えているからだ。同時に、なお残る道のりの長さも、いっそう見過ごしにくくしている。
GoogleがMVPから何を報告するのか、複数衛星によるミッションが予定どおり進むのか、そしてStarshipが再利用可能な商業ミッションをどの程度の頻度で飛行するのかに注目したい。この3つのシグナルが、軌道上のAIがインフラになりつつあるのか、それとも野心的な研究プロジェクトにとどまるのかを示すだろう。
