Satlytの軌道AIソフトウェア、SpaceXとGoogleが退けたオープン路線を選択

Satlytの軌道AIソフトウェアは、創業者Rama Afullo氏が提案した軌道上分散コンピューティング構想をSpaceXとGoogleが社内で退けた後、宇宙へ進出しようとしている。Satlytは現在、800万ドルのシードラウンドを調達し、複数の衛星ミッションで同社ソフトウェアを搭載する枠を確保した。

Satlytのソフトウェアが、GoogleのProject Suncatcher向けハードウェアとともにSpaceX経由で軌道に到達したことで、この逆転劇は異例なほど明白になった。両社はいずれも現在、軌道コンピューティング戦略を支援しているが、Afullo氏が選んだものとは異なるアーキテクチャを追求している。

Satlytは、多くのメーカーの宇宙機で動作するソフトウェア層を提供したい考えだ。SpaceXは対照的な道を示す。すなわち、打ち上げ、衛星、通信接続、コンピューティングハードウェア、そして運用環境の大部分を1社が統制するモデルである。

この違いは、同じロケットを共有したという偶然以上に重要だ。地球上空のコンピューティング層を誰が支配するのかを巡る初期の競争、つまり垂直統合された宇宙機の所有者か、異種混在フリートをつなぐ独立プラットフォームか、という構図を示している。

Satlytの軌道AIソフトウェアは構想段階を超えた

直近の変化は、Satlytが却下された社内提案ではなく、資金、飛行実績、実際のワークロードを手にしたことだ。

Afullo氏は、2024年にSpaceXのStarlink事業に加わる前、Googleのクラウド組織で働いていた。同氏はTechCrunchに対し、両社の内部で軌道コンピューティングを提案したと語った。いずれも当時はその構想を退けた。

その後、同氏はカリフォルニア州SunnyvaleとケニアのNairobiを拠点とするSatlytを共同創業した。同社は、衛星がデータをローカルで処理し、将来的には宇宙機間でコンピューティングタスクを共有できるようにするソフトウェアを開発している。

Satlytの800万ドルのシードラウンドは、Houston拠点のNon Sibi Venturesが主導した。同投資家のパートナーには元NASA宇宙飛行士のBernard Harris氏が含まれ、その経験が同社による技術面・商業面の提案評価を支えた。

今回の資金調達は出来事の一部にすぎない。Satlytによれば、同社ソフトウェアはすでに2つの実証ミッションで飛行しており、実験室での試験を超えた、制約の多いコンピューティング環境での経験を得ている。

直近で報告された展開では、衛星向けコンピューティングシステムを開発するインド企業TakeMe2Spaceが製造したハードウェアが使われている。このミッションでは、3種類の顧客ワークロードが宇宙機に持ち込まれる。

NASAは宇宙におけるクラウドコンピューティングのプロトコル試験に費用を負担している。軌道監視に取り組むStellerianは、画像処理を評価する計画だ。TakeMe2Spaceは、自社衛星が外部企業のソフトウェアをホストできることを示したいとしている。

これらの顧客は、需要の重要な3層を表している。政府機関は技術検証を求め、商業事業者はより高速な分析を求め、宇宙機メーカーはより柔軟な製品を求めている。

この組み合わせにより、Satlytは単純なソフトウェア実証より厳しい試験に臨むことになる。同社プラットフォームは、電力、メモリ、温度、通信に関する1機の宇宙機の制約の中で、異なるワークロードを支えなければならない。

同社はまた、Momentusが運用する衛星に量子化済みのGemma 3モデルを搭載した。量子化はモデルの数値精度を下げることで、より少ないメモリと計算能力での実行を可能にする。

Gemma testingによると、この10億パラメータのモデルは、テレメトリー、アプリケーションログ、ソフトウェアエラーをローカルで分析した。効率的なモデル実行向けに設計された推論フレームワーク、llama.cppを通じて動作した。

2件の障害注入テストでは、システムは診断ペイロードを1,319バイトから469バイト、1,318バイトから464バイトへ削減した。削減率はそれぞれ64.4%と64.8%だった。

このモデルは、利用可能な技術的文脈から短い診断と推奨アクションも生成した。この結果は信頼性の高い自律宇宙機運用を確立するものではないが、搭載AIの即時的な用途を示している。

すべての生ログを地球に送信する代わりに、衛星は限られたダウンリンク時間帯を使う前にエラーを要約できる。地上管制は、より小さく、より有用なメッセージを受け取ることになる。

したがってSatlytの進展は、巨大な軌道上データセンターという遠い構想だけではなく、実用的なワークロードに基づいている。同社はすでに軌道へ向かうハードウェア上で、ソフトウェア診断、テレメトリー分析、画像処理から始めている。

ここに本稿の中心的な緊張関係がある。SpaceXとGoogleは厳格に統制されたシステムを通じて軌道コンピューティングを追求できる一方、Satlytは共有ソフトウェアが他社の機器をまたいで機能できることを証明しなければならない。

直近の市場は巨大な宇宙データセンターではなく、搭載処理にある

Satlytは価値を生み出すためにフルスケールの軌道クラウドを必要としないが、衛星事業者がソフトウェアを独立した購買判断として扱う必要はある。

現在も大半の衛星は地上局に大きく依存している。画像、センサー測定値、運用データ、エラーログを収集し、予定された通信時間帯に選別した情報を送信する。

このモデルはボトルネックを生む。特に接続時間が短い場合や帯域幅が競合する場合、宇宙機は地球へ経済的に送信できる量を超えるデータを生成し得る。

搭載処理は、意思決定の一部をセンサーに近づける。衛星は使用できない画像を破棄し、不審な物体を優先し、障害を要約し、送信前に観測データを圧縮できる。

この考え方は地上のエッジコンピューティングに似ている。エッジコンピューティングはデータ発生源の近くで分析を実行し、すべてを中央集約型クラウドへ送る必要を減らす。

宇宙では、このトレードオフはさらに厳しい。遠隔地の地上デバイスなら数分以内にネットワーク接続を回復できるかもしれない。宇宙機は、限られた通信範囲、厳格なエネルギー予算、放射線、そして物理的な修理手段がない状況に直面する。

だからこそ、Satlytの診断事例は重要である。エラーレポートを60%以上削減することは、軌道上AIクラスターの構想に比べれば控えめに聞こえるかもしれない。しかし、それは事業者がすでに直面しているコストに対処するものだ。

同社によると、ローカル分析は地上処理の作業を減らし、異常への対応を短縮できる。正確な金銭的節約額は、衛星、ミッション、人員配置モデル、通信契約によって異なる。

画像処理も、もう一つの即時的な用途を提供する。地球観測衛星は、雲に覆われたフレームをダウンリンク前に識別したり、対象条件を含む画像を優先したりできる。

宇宙監視のワークロードも同じ論理に従う。衛星は潜在的な物体や異常な動きに関する画像をフィルタリングし、最も関連性の高いデータを先に送信できる。

こうしたアプリケーションに、軌道上の倉庫規模のデータセンターは必要ない。制約のあるコンピューター上で予測可能に動作し、厳しいリソース予算の範囲で有用な出力を生む小規模モデルが必要となる。

この区別はSatlytの主導投資家も惹きつけた。Non SibiのパートナーであるKent Lucas氏はTechCrunchに対し、同社が成功するために巨大な宇宙データセンターは必要ないと語った。衛星数の増加だけでも、同社の到達可能な市場は拡大し得る。

この主張はもっともだが、なお複数の前提に依存している。より多くの宇宙機が汎用プロセッサを搭載し、事業者が第三者ソフトウェアを許可し、ミッション設計者がAIワークロードに希少な電力を割り当てなければならない。

Afullo氏は、高度なプロセッサが衛星で一般的になると予想している。同氏は、この10年の終わりまでに衛星の20%に到達するという野心的な目標を掲げている。

この目標は独立した予測ではなく、あくまで同社の志向である。衛星フリートには大きな差があり、多くの宇宙機は慎重に検証された単一ミッション向けの専用コンピューターを使用している。

それでも、この機会は幅広い軌道クラウドの物語より理解しやすい。Satlytは、衛星が最大規模のAIワークロードを共有し始める前に、有用な搭載処理を販売できる。

開発者はこの段階を、ソフトウェア移植性の試験と見なすべきだ。中心的な問いは、1つの運用層が、多様なプロセッサ、ペイロード、通信システム、宇宙機の安全要件を支えられるかどうかである。

企業の購買担当者は、レトリックではなく成果に注目すべきだ。ダウンリンク量の削減、異常対応の迅速化、より価値の高い画像は、基盤システムが巨大なデータセンターにならなくても測定可能な利点である。

こうした実用的な指標は、既存の宇宙機企業が圧力に直面する理由も説明する。顧客が移植可能なソフトウェアを評価するなら、ハードウェア提供者は衛星上で動くアプリケーションに対する支配力の一部を失う。

SpaceXがiPhoneを構築する一方、SatlytはAndroidを構築したい

主な競争は規模におけるSatlyt対SpaceXではない。オープンなソフトウェア層と、閉鎖的で垂直統合されたコンピューティングスタックとの競争である。

Afullo氏は、この違いを説明するために馴染み深い比喩を用いる。SpaceXが軌道上データセンターのiPhoneになるなら、SatlytはAndroidになりたいという。

この比較は完全ではないが、戦略的な分岐を捉えている。Appleはハードウェア、オペレーティングソフトウェア、サービス、流通を、厳格に管理された1つのシステムの下で組み合わせている。Androidは多くのメーカーのデバイスを支えている。

SpaceXはすでに、ほとんどの潜在的競合企業より物理スタックの多くを統制している。ロケットを製造し、打ち上げインフラを運用し、衛星を製造し、通信コンステレーションを管理し、接続サービスの顧客に提供している。

この統合は調整コストを削減できる。エンジニアはハードウェアとソフトウェアを一体で最適化し、一貫したインターフェースを維持し、関係のない宇宙機ベンダー間で標準を交渉することなく迅速に動ける。

ただし、それは依存も生む。独自の軌道プラットフォーム上で構築する顧客は、1社の打ち上げスケジュール、技術ロードマップ、価格、インターフェース、アクセス判断に縛られる可能性がある。

Satlytは反対の賭けに出ている。衛星を製造する計画はない。同社ソフトウェアは、異なる事業者が所有する宇宙機を横断して稼働し、それらのコンピューティングリソースを共有サービスへ変えることを意図している。

同社は自らの役割をVMwareやSnowflakeになぞらえている。VMwareはアプリケーションを特定の物理サーバーから切り離し、Snowflakeはクラウドインフラ全体にわたるマネージドデータ層を顧客に提供した。

軌道上で、この抽象化ははるかに難しい。地上のクラウドサーバーは比較的標準化されたプロセッサ、ネットワーク、電源、ストレージシステム、保守慣行を利用している。

衛星は、放射線、熱サイクル、限られたエネルギー、断続的なリンク、軌道運動にさらされるカスタム機械だ。障害を起こしたプロセスを再起動するだけでも、ミッションレベルの影響を持ち得る。

そのためオープンな軌道プラットフォームは、異なるコンピューターに同じパッケージをインストールする以上のことを行う必要がある。安全制御を弱めたり、不可欠な宇宙機機能を妨げたりせずに、ハードウェアの違いへ対応しなければならない。

このプラットフォームには、作業をスケジューリングする安全な方法も必要となる。第三者アプリケーションが、航法、通信、主ペイロードに必要な電力、メモリ、ネットワーク容量を消費してはならない。

こうした課題は、垂直統合を支持する根拠を強める。SpaceXはコンピューティングハードウェア、衛星間リンク、運用環境、電力システムを、1つの協調的な製品として設計できる。

しかし、統合が顧客による閉鎖系の選好を保証するわけではない。衛星メーカーや事業者は、複数の打ち上げ事業者、プロセッサ、モデル、分析ベンダーへのアクセスを望む可能性がある。

独立したソフトウェア層の価値は、多様性が増すほど高まる。互換性のある宇宙機が1機増えるごとに、Satlytが衛星コンステレーションの資金を負担せずとも、活用可能なコンピューティング資源の候補は広がる。

これは、地上でソフトウェアプラットフォームの成長を後押ししてきたネットワーク効果と同じだ。ハードウェア基盤が大きくなれば開発者を引き付け、アプリケーションが増えれば、そのプラットフォームはハードウェアベンダーにとっても魅力を増す。

軌道上には、難しいコールドスタートの問題がある。開発者が投資するには互換性のある衛星が必要だが、宇宙機メーカーがSatlytにリソースを割り当てるには有用なアプリケーションが必要になる。

同社は初期ミッションで、具体的なワークロードによってこの問題の解決を試みている。NASAが検証用ユースケースを、Stellerianがアプリケーションを、TakeMe2Spaceがホスティング用ハードウェアを提供する。

Googleのアプローチは、もう一つの対照例となる。Project Suncatcherは、豊富な太陽エネルギーで駆動するGoogle Tensor Processing Units、すなわちTPUを搭載した相互接続衛星を構想している。

このプログラムの初期段階は、Google自身のコンピューティングハードウェアに焦点を当てている。Planetと共同で開発されたプロトタイプは、TPUが打ち上げ時の力、放射線、宇宙空間の熱環境にどう反応するかを測定する目的で設計された。

Googleは、プロトタイプが軌道に到達したことを確認した。SpaceXのTransporter-18ミッションで2026年10月1日に打ち上げられたこの衛星は、通信を確立し、試験プログラムを開始した。

つまりGoogleは、同社の専用チップが宇宙で生き残り、動作できるかを検証している。一方Satlytは、ソフトウェアによって多様な軌道上コンピューターを外部顧客にとって有用なものにできるかを試している。

現時点で両社は直接の競合相手ではない。将来的に独立プラットフォームがGoogle設計のプロセッサや他の専用プロセッサ上でワークロードを実行するようになれば、そのアーキテクチャは補完関係になる可能性さえある。

それでも、両社の優先順位は異なるコントロールの中心を示している。Googleは、自社が所有し理解しているハードウェアから始める。Satlytは、自ら制御しないハードウェア間での可搬性から始める。

軌道上コンピューティングが成長すれば、この違いは利益率、顧客の選択肢、開発者のアクセスを左右する。最終的な勝者は、最も多くの衛星を所有する企業ではなく、アプリケーションが衛星間をどう移動するかに影響力を持つ企業かもしれない。

オープンな軌道上クラウドは、なお現実を乗り越えなければならない

Satlytの最も強い主張は柔軟性だが、宇宙機間の差異が大きすぎたり、顧客がリソース共有を拒んだりすれば、柔軟性は負債になり得る。

同社は、小規模な言語モデルが制約のあるハードウェア上で診断データを処理できることを示した。しかし、それは衛星をまたぐ分散クラウドの運用とは別物だ。

Satlytの次の大きな技術目標は、異なる2機の宇宙機にまたがるコンピューティング能力を接続することだ。同社は来年、この実証を試みる見込みだとしている。

分散コンピューティングにはマシン間の協調が必要なため、試験が成功すれば重要な意味を持つ。ソフトウェアは作業を分割し、データを転送し、遅延に対応し、中断から復旧し、結果の正しさを確認しなければならない。

信頼性の高い電力と高速ネットワークを備える地上データセンターでは、こうした作業は日常的だ。しかし、両方のコンピューターが地球を周回し、特定の軌道条件下でしか通信できない場合、難易度は上がる。

問題はレイテンシーだけではない。衛星ごとに、プロセッサ、OS、セキュリティ要件、利用可能な電力、ミッションの優先順位が異なる可能性がある。

衛星間リンクにも大きな差がある。レーザー通信を備える宇宙機もあれば、無線リンクを使用する機体もあり、多くは近隣衛星との間で大規模なコンピューティングワークロードを交換するよう設計されていない。

Googleは、計画中のレーザー接続に必要な精度を、両方の地点が移動するなかで数マイル離れた場所から硬貨ほどの標的に当てることに相当すると説明している。

同社のテストは、ハードウェア面の課題も示している。Googleによれば、打ち上げコンポーネントには重力の50倍から100倍に達する力が加わる可能性があり、放射線は電子システム内に保存されたデータを変化させ得る。

熱制御も同様に重要だ。プロセッサは熱を発生させるが、宇宙は真空であるため、宇宙機は通常の気流で冷却できない。

Satlytのソフトウェアは、こうした物理的制約を取り除くことはできない。宇宙機が正確なテレメトリーを公開し、プラットフォームに十分な運用制御を与える場合にのみ、それらを考慮したスケジューリングが可能になる。

サイバーセキュリティも別の障壁となる。複数の衛星にまたがってワークロードを管理するソフトウェアは、侵害が複数の事業者に影響を及ぼしかねないため、価値の高い攻撃対象になり得る。

顧客は、アプリケーション間の分離、署名付きアップデート、アクセス制御、監査記録、緊急停止に関する明確な権限を求めるだろう。こうした保護機能は追加のコンピューティング資源を消費する。

AIの出力には別種のリスクもある。特に入力が学習時やテスト時の条件と異なる場合、モデルはエラーを誤って要約したり、画像を誤分類したりする可能性がある。

そのため、Satlytの現時点の診断用途は、自律的な指令より安全に見える。モデルは宇宙機の挙動を変更する権限を持たずに、地上運用者へ対応策を提案できる。

同社は、異常検知やマルチエージェントによる意思決定へ拡大する際にも、運用者が指令権限を保持するとしている。支援と制御の実務上の境界には、慎重な検証が必要になる。

ビジネス上のインセンティブも同様に不確実だ。衛星所有者には未使用のプロセッサ時間があるかもしれないが、それを外部ワークロードに貸し出せば、十分な収益を得られないまま責任リスクが生じる可能性がある。

所有者はまた、本来のミッションのために能力を確保しなければならない。地球観測衛星は、別のアプリケーションが電力を消費したりストレージを埋めたりしたために、顧客向け画像の取得を遅らせるわけにはいかない。

Satlytの「Android」戦略は、宇宙機メーカーが共通インターフェースを支持する場合にのみ機能する。意味のある標準化がなければ、統合のたびにカスタムエンジニアリングプロジェクトが必要になる。

それは独立プラットフォームの経済性を弱める。ソフトウェアの利益率は、衛星ごとに作り直すことではなく、多くの顧客に同じ製品を繰り返し展開することに依存する。

競争は、ハードウェアを所有する企業からも生じ得る。SpaceX、Google、Starcloud、その他の軌道上コンピューティング事業者は、基盤システムを独自仕様のまま維持しつつ、開発者向けインターフェースを提供できる。

管理されたクローズドプラットフォームは、オープンネットワークより購入しやすいことがある。1社のプロバイダーがより簡単な導入、強力なサポート、予測可能な性能を提供するなら、顧客はベンダー依存を受け入れることが多い。

したがってSatlytは、Androidモデルが優位に立つことをまだ示していない。同社が示したのは、オープンな道筋が資金を獲得し、実運用ミッションに到達するのに十分な信頼性を持つということだ。

次の段階では、再現性を実証しなければならない。1基の衛星で1つのモデルを動かすことは実現可能性を証明するが、異なる宇宙機間で可搬性のあるワークロードを実行できれば、より広範なプラットフォームの主張を裏付けられる。

Satlytが軌道上プラットフォームになれるかを示す3つのシグナル

次に必要な証拠は、また別の野心的な比較ではなく、衛星間コンピューティング、リピート顧客、測定可能な運用価値から得られなければならない。

第1のシグナルは、Satlytが計画する2衛星クラウド実証だ。これは同社の中心的な技術的主張を最も直接的に試すものとなる。

観察者は、宇宙機が異なるプラットフォームに由来することの確認を注視すべきだ。1つの運用者が保有する同一衛星2基であれば分散コンピューティングは検証できるが、幅広い相互運用性は検証できない。

また実証では、衛星間でどのような作業が移動するのかも明らかにすべきだ。小規模なメッセージ交換より、レイテンシー、リソース使用量、復旧挙動が記録された協調処理の方が意味を持つ。

実行に成功すれば、Satlytがハードウェアの違いを抽象化できるという主張は強まる。遅延やより限定的な実証にとどまれば、オープンプラットフォームはマーケティングが示すより初期段階にあることが分かるだろう。

第2のシグナルは、顧客による継続利用だ。NASA、Stellerian、TakeMe2Spaceは同社に有用な初期ワークロードをもたらしているが、パイロット案件だけでは持続的な需要を証明しない。

より強い兆候となるのは、顧客が1回の実験から複数の宇宙機へ拡大することだ。それは、ソフトウェアがミッションレビューと予算編成を乗り越えるだけの価値を生み出したことを示す。

もう一つの重要な指標は、Satlytを統合する独立系宇宙機メーカーの数だ。Androidとの類推には、1社のパートナーのハードウェア上に複数ミッションを展開するだけでなく、複数のメーカーが必要になる。

Satlytは、2026年に最大50機の宇宙機へ展開できるソフトウェアを準備しているとしている。準備済みの能力は有効化済みの展開と同じではないため、完了した導入の方が重要だ。

読者は、契約締結、システム打ち上げ、アクティブなワークロード、有償更新を区別すべきだ。各段階は、異なる水準の商業的証拠を伴う。

第3のシグナルは、運用パフォーマンスだ。ダウンリンク削減は初期の指標になるが、顧客は精度、エネルギー使用量、メモリー消費、応答時間も重視するだろう。

Gemmaのテストは有用な基準となる。Satlytは、2つのシナリオで診断ペイロードを約64%小型化し、毎秒22トークン超の生成速度を記録したと報告している。

同社のより広範なテストでは、推論中のプロセッサ消費電力がおよそ11ワット、温度上昇が摂氏3度から5度であることを調べている。これらは、制約のあるテスト条件で得られた同社提供の測定値だ。

今後の開示では、こうした技術結果をミッション成果と結び付ける必要がある。運用者は障害をより早く解決できたのか。より価値の高い画像をダウンリンクできたのか。地上側の作業負荷を削減できたのか。

顧客や研究パートナーによる独立した確認は、社内ベンチマークをもう一つ示すよりも重みを持つ。実際の宇宙飛行データは、管理されたテストの外でも利益が持続するかを明らかにするだろう。

SpaceXとGoogleが待つ可能性は低い。Googleはすでに、放射線や極端な温度下での性能を含め、軌道上TPUプロトタイプからデータを収集している。

同社が次に計画するマイルストーンは、2基の衛星間通信のテストだ。Googleが幅広い商用プラットフォームを提供しないとしても、そこでの進展は垂直統合型モデルを強化するだろう。

SpaceXには異なる優位性がある。それは展開規模だ。打ち上げと衛星製造を自ら管理しているため、無関係な宇宙機プロバイダーが共通インターフェースを採用するのを待たずに反復開発できる。

Satlytは、こうした資本力に対抗できない。その機会は、市場の残りの部分を共有コンピューティング基盤に近い形で機能させることにある。

このパターンは他業界でも機能してきた。顧客が選択肢を求め、どのハードウェアベンダーも市場全体を支配できないとき、独立ソフトウェアは価値を持つ。

ただし宇宙は、通常のソフトウェア市場ではない。信頼性基準、物理的制約、国家安全保障上の懸念、長い調達サイクルはいずれも、プラットフォーム採用を遅らせる。

開発者は、最初のミッションからどのようなインターフェースが現れるかを注視すべきだ。安定したアプリケーションモデルがあれば、一度開発して複数の宇宙機に展開しやすくなる。

衛星の購入者は、誰がアップデート、ワークロードのスケジューリング、テレメトリーへのアクセス、障害復旧を制御するのかを問うべきだ。こうした詳細によって、「オープン」が可搬性を意味するのか、あるいはカスタム作業を通じた互換性にすぎないのかが決まる。

証拠を評価するチームには、ミッション報告、試験結果、契約、エンジニアリング上の判断をまたぐ規律ある記録も必要だ。検索可能なナレッジベースは、こうした主張を裏付け文書と結び付けた状態で維持できる。

Satlytの軌道上AIソフトウェアは、重要な閾値に到達した。現在、同社には資本、飛行実績、顧客実験、そして明確なアーキテクチャ上の対抗軸がある。

同社はまだ、異なる衛星にまたがる軌道上クラウドを構築していない。また、独立プラットフォームが規模を拡大できるほど、メーカーが十分な制御を手放すことも示していない。

だからこそ、この動向は追う価値がある。退けられたアイデアはもはや仮説ではないが、その中核となる約束はまだ実証されていない。

今後数か月は、2基の衛星によるテスト、繰り返しの展開、そしてミッションレベルの性能データに注目したい。これらを総合すれば、Satlytが軌道上のAndroidを構築しているのか、それとも少数の宇宙機向けに特化したツールを作っているのかが明らかになるだろう。