Satlytは衛星搭載コンピューター向けソフトウェアの開発に、800万ドルのシード資金を調達した。当面の価値は巨大な宇宙データセンターより限定的で、測りやすい。テレメトリー、ログ、画像を発生場所の近くで分析し、限られた地上向け通信で有用な情報を送ることだ。
より大きな目標は、異なるメーカーの宇宙機で計算を持ち運べるようにすることだ。飛行経験と顧客実験はあるが、異なる衛星をまたぐ分散クラウドはまだ実証していない。この段階を分けることが資金調達とリスクを理解する鍵になる。
社内で却下された案が独立した会社に
創業者Rama AfulloはGoogleのクラウド部門を経て、2024年にSpaceXのStarlink事業へ入った。TechCrunchに対し、両社で軌道計算を提案したが当時は却下されたと述べている。その後Satlytを共同創業し、カリフォルニア州サニーベールとケニアのナイロビを拠点にした。
シード調達を主導したのはヒューストンのNon Sibi Venturesで、元NASA宇宙飛行士Bernard Harrisもパートナーを務める。Satlytによるとソフトウェアは2回の実証飛行を経験し、最新の報告ではインドのTakeMe2Spaceの衛星計算ハードウェアに搭載される。
このミッションには三つの異なる処理がある。NASAは宇宙クラウド計算プロトコルの試験に費用を払い、軌道監視企業Stellerianは画像処理を評価する計画だ。TakeMe2Spaceは外部ソフトを搭載できることを示したい。目的の異なる顧客実験であり、成熟した共有軌道サービスの証明ではない。
Afulloは今の10年間の終わりまでに衛星の20％へ到達したいとする。Satlytは2026年に最大50機への導入用ソフトを準備したとも述べる。しかし目標や準備済み容量は、稼働中の導入数、有料更新、独立確認された市場シェアとは違う。
最も明確な初期成果は小さい診断メッセージ
SatlytはMomentus運用衛星に、量子化した10億パラメーターのGemma 3をllama.cppで導入した。量子化は数値精度を下げてメモリーと計算要求を抑える。Gemmaの事例は、テレメトリー、アプリログ、ソフトウェアエラーの機上分析を説明している。
二つの故障注入シナリオでは診断データが1,319から469バイト、1,318から464バイトに減り、削減率は64.4％と64.8％だった。モデルは短い診断と推奨操作を生成し、両シナリオの生成速度は毎秒22トークンを超えたと報告されている。
より広い社内試験では推論中のプロセッサー電力約11ワットと、3～5度の温度上昇も調べた。制約された条件での企業提供値であり、衛星群全体の運用特性を独立検証したものではない。データ量の削減も、すべての故障で診断が正しいことを示さない。
仕組みは、すべての生ログを送る代わりに通信可能時間までに故障を要約するというものだ。地上側は小さく有用な報告を受け取れる可能性がある。画像処理でも、雲に隠れた画像を除外したり、監視対象らしいものがある画像を先に送ったりできる。
これらはエッジ計算の用途であり、巨大な軌道AIクラスターを先に建設する必要はない。経済価値は帯域契約、人員、応答要件で変わる。削減バイト数だけでなく、異常解決の迅速化、価値の高い画像、地上作業削減との関係を、精度・エネルギー・メモリーとともに示すべきだ。
可搬性と垂直統合は異なる課題を解く
AfulloはSpaceXを軌道のiPhone、SatlytをAndroidにたとえる。多様な機器を支えるソフトウェア層と、密に協調した一式のシステムとの違いだ。両社が同じ規模だとか、Satlytが既に開かれた業界標準だという意味ではない。
SpaceXは打ち上げ、衛星製造、通信接続、運用環境の多くを管理する。統合によってインターフェースが簡潔になり、電力、リンク、プロセッサーを調整できる。導入やサポートが容易なら、顧客は一社のロードマップ、打ち上げ日程、価格への依存を受け入れるかもしれない。
Satlytは衛星を製造する計画はない。VMwareやSnowflakeになぞらえ、アプリが特定の物理マシンに依存しにくい抽象化層を目指す。互換メーカーが増えれば開発者を呼び、アプリが増えればメーカーを呼べる。しかし当面は双方が相手を待つ立ち上げ問題を解く必要がある。
GoogleのProject Suncatcherは、自社TPUと太陽光で動く相互接続衛星から始める。Planetと製作した試作機は打ち上げ、放射線、熱の影響を調べる。Googleは、2026年10月1日にSpaceXのTransporter-18で試作機が軌道へ到達し、通信を確立して試験を始めたと述べた。
同じ打ち上げ手段を使っても設計思想は同じではない。Googleは専用機器の宇宙動作を、Satlytは所有しない計算機をまたいで外部顧客がソフトを使えるかを試す。現時点で直接競合とは限らず、将来は補完関係にもなり得る。
宇宙機の安全性が共有層の限界を決める
地上サーバーには標準インターフェース、安定した通信、物理保守がある。衛星は放射線、熱サイクル、断続的通信、軌道運動、厳しい電力制約にさらされる。プロセッサー、OS、任務の優先順位は異なり、大規模な計算負荷交換用リンクを持たない機体も多い。
Googleは将来のレーザーリンクの照準を、数マイル離れた移動する硬貨大の標的に当てる難しさにたとえる。打ち上げ部品には重力の50～100倍の力が加わり得て、放射線は記録データを変え、真空では通常の空冷が使えない。正確なテレメトリーと十分な操作権限があって初めて、ソフトは物理制限に応じて処理を計画できる。
外部の処理が航法や主要搭載装置に必要なメモリー、電力、通信を使い切ってはならない。隔離、署名付き更新、アクセス制御、監査記録、緊急停止の権限は任意機能ではなく受け入れ条件だ。複数運用者を管理する仕組みは、サイバー攻撃の標的にもなりやすい。
AIは故障を誤診し、画像を誤分類することがある。地上担当者へ操作を勧めることと宇宙機を直接指揮することは違う。Satlytは異常検知と複数エージェントの判断へ進んでも運用者が指揮権を保つとするが、実際の統合でその境界を検証する必要がある。
事業上の動機も技術と同じほど難しい。空き計算時間があっても、外部負荷の責任や収益配分が見合うとは限らない。共通インターフェースがなければ毎回が個別開発となり、反復販売できるソフトウェアの経済性が弱まる。
次に必要なのは打ち上げ以上の証拠
Satlytは来年、異なる2機をまたぐ計算を試す予定だ。有意義な開示には機種、協調処理、遅延、資源使用、復旧動作が必要で、単なるメッセージ交換では不十分だ。同一機2台なら分散性は示せても広い相互運用性までは示せない。
顧客の再利用と独立した宇宙機メーカーの参加は事業の裏付けになる。契約、打ち上げ済み機器、稼働処理、有料更新は証拠の段階が違う。内部ベンチマークに加え、顧客や研究機関の運用データが望ましい。その間もGoogleは衛星間リンクを進め、SpaceXは展開規模の優位を持つ。
ミッション報告、試験定義、契約は検索可能な技術文書ナレッジベースで追跡できる。Satlytは提案段階を超えたが、混在衛星群で可搬性、安全性、反復可能な採算を示すという核心はこれからだ。それこそが機上ツールを軌道プラットフォームへ変えるのであり、Androidの比喩ではない。