地上のクラウドに「考える仕事」を任せる時代は、もうすぐ折り返し地点を迎えるかもしれません。2024年から2025年にかけて、中国の国家航天局系プロジェクト「三体計算コンステレーション(Three-Body Computing Constellation, 三体计算星座)」が初号機群の打ち上げを開始しました。最終的には2,800機規模の小型衛星で軌道上に1,000 POPS級の演算能力を構築するという、SFを地で行く構想です。同じ頃、Starlinkは観測衛星から地上に下ろさずに、軌道上でLLM推論や地球観測画像処理をオフロードする実験を進めています。
これらの動きが意味するのは、人工衛星が「観測してデータを下ろす土管」から、「軌道上で考えてから答えだけを下ろす知能体」へと進化しつつあるということです。なぜわざわざ宇宙で計算するのでしょうか。理由は3つあります。1つ目は遅延 — 災害監視や弾道警戒では、地上クラウドへの往復数百msが命取りになります。2つ目は主権とプライバシー — 国境を越えるデータを地上に下ろさずに済めば、外交や安全保障の制約を回避できます。3つ目は災害耐性 — 地上のデータセンタが落ちても、軌道上の演算リソースは独立に生き残ります。
宇宙分散AIアーキテクチャを理解すると、以下のような領域で設計の地図を持てるようになります。
- 次世代地球観測ミッションの設計 — Sentinel系の後継やJAXAのALOS-4以降の構想で、生データではなく「異常検知済みのアラート」だけを地上に下ろす仕組みを描けます
- 6G NTNの計算層設計 — 3GPPで議論が進む非地上ネットワーク(NTN)に、エッジ計算層をどう乗せるかの議論に技術的に踏み込めます
- 国家宇宙インフラの戦略立案 — メガコンステレーションが通信だけでなく演算インフラ化する流れを、定量的に評価できます
本記事の内容
- 三体計算コンステレーションとStarlink推論オフロードの動向整理
- なぜ地上クラウドではダメなのか — 遅延・主権・災害耐性の定量的議論
- エッジ／フォグ／クラウドの三層アーキテクチャと衛星間光リンク(OISL)の役割
- タスクアロケーション問題の数式定式化と最適化アプローチ
- 連合学習・分散推論・モデル並列の宇宙応用
- Pythonシミュレーション — 貪欲法 vs 最適化によるアロケーション性能比較とレイテンシ可視化
前提知識
この記事を読む前に、以下の記事を読んでおくと理解が深まります。
- LEOコンステレーション通信 — Starlinkに代表される低軌道衛星群の通信技術 — ウォーカー配座、衛星間リンク、ハンドオーバーなどコンステレーション設計の基礎
- 分散学習の基礎 — データ並列・モデル並列・パイプライン並列 — 分散学習の基本パラダイム
- 連合学習(Federated Learning)とは — 生データを共有せずモデルを学習する連合学習の枠組み
- 凸最適化の基礎 — アロケーション問題の解法に必要な最適化手法
なぜ「宇宙で計算する」のか — 動機の整理
観測データ爆発と地上ダウンリンクのボトルネック
現代のリモートセンシング衛星はとんでもないデータを吐き出します。例えばSentinel-2は1機あたり1日約1.6 TB、商用のWorldView-3クラスになると同等以上のデータ量を生成します。これに対して、典型的なXバンドダウンリンクの平均実効スループットは150〜500 Mbpsで、可視ウィンドウ(地上局上空通過)は1日合計でも30分程度しかありません。
ナップサックの中身を全部広げる時間がない、というのが正しい比喩です。地上に降ろせるのは生成データのほんの一部、というのが多くのミッションの実情です。すると自然な発想として「地上に下ろす前に、軌道上で価値のあるピクセルだけを選り分けたい」というニーズが出てきます。これがオンボードAIであり、その究極形が今回扱う「宇宙分散AI」です。
地上クラウドの遅延と政治リスク
オンボード処理のもう一つの動機は、リアルタイム性です。地上クラウドへ画像を送って推論を回す場合、片道だけでも次の遅延が積み重なります。
$$ T_{\text{round-trip}} = T_{\text{prop}} + T_{\text{down}} + T_{\text{queue}} + T_{\text{inference}} + T_{\text{prop}} $$
LEO衛星(高度550 km)から地上までの伝搬遅延 $T_{\text{prop}}$ は約1.8 msと小さいものの、可視衛星が無いとそもそも通信できず、 $T_{\text{queue}}$ が分単位、最悪では数十分になる場合があります。山火事や弾道飛行物体のような秒〜分単位で動く対象を扱うには、地上往復ループは現実的ではありません。
主権の問題も重要です。あなたの国が打ち上げた地球観測衛星から、他国上空のデータを米国のクラウドに送って処理する、という構図には外交的・法的制約が伴います。軌道上で処理を完結させ、結果だけを自国地上局へ下ろすことができれば、データ主権を保ったまま機能を提供できます。
災害耐性と冗長性
最後の動機は、地上インフラからの独立性です。地震や戦争で地上データセンタが壊れても、軌道上の演算リソースは互いに光リンクでつながって生き残ります。SpaceXが2024年に発表したStarlink Direct-to-Cellのドキュメントでは、災害時には基地局を介さず衛星間で接続を維持する想定が明示されており、これに演算能力を加えると、地上独立な「宇宙インターネット+宇宙クラウド」が構成されます。
ここまでで、宇宙でAIを動かす理由が一通り見えました。では、現実のプロジェクトはどこまで進んでいるのでしょうか。三体計算コンステレーションとStarlinkを代表例として、現在の地形を確認します。
三体計算コンステレーションと国際動向
三体計算コンステレーション(中国)
中国の国家国防科技工業局が主導する「三体計算コンステレーション」は、之江実験室(Zhejiang Lab)が技術核となって2024年から打ち上げを開始した、軌道上スーパーコンピュータ構想です。最終的に2,800機規模、合計1,000 POPS(=10^18 演算/秒級)の演算能力を目指すとされます。
特徴的なのは、各衛星に8 PFLOPS級のAIアクセラレータを搭載し、衛星間を100 Gbps級の光リンクで結ぶ構成です。コンステレーション内で巨大なLLMを分散実行することすら視野に入っており、12機編成の試験クラスタが既に軌道に乗っていると報道されています(2025年時点)。「三体」という名前は劉慈欣の同名SF小説と、3層(エッジ／フォグ／クラウド)構造の双方を想起させる命名と解されます。
技術的に重要なのは、彼らがこれを「軌道上CDN」ではなく「軌道上AIサービス基盤」と位置付けている点です。観測衛星のデータを別の演算衛星にOISL経由で送り、推論結果(例えば船舶検出や山火事検出)だけを地上に降ろす運用が想定されています。
Starlinkとオンボード推論オフロード
SpaceXは2024年のIAC(国際宇宙会議)で、Starlink V3衛星にAIアクセラレータを搭載する計画を示唆しました。具体的には、地上Gateway基地局でのLLM推論ワークロード(地上ユーザのRAGリクエストなど)を、衛星バックホールではなく軌道上のV3衛星で直接処理する構想です。
これは「軌道上エッジクラウド」の発想で、衛星はもはや単なる中継器ではなく、サービスを実行するノードになります。ユーザにとって最も近い計算リソースが衛星になる、という意味で「True Edge」と呼ばれます。Starlinkの強みは、既に7,000機を超えるコンステレーションを運用しており、軌道上で水平スケールできる演算リソースとして利用できる点です。
欧州・日本の動向
欧州側ではESAの「Phi-sat」シリーズが先行しています。Phi-sat-1(2020)はOPS-SAT上のIntel Movidius Myriad 2でクラウド検出を実機実証しました。後継のPhi-sat-2(2024)では、AIモデルを軌道上で動的にアップロード・置換する機構を実証しています。
日本はJAXAのCRD2(商業デブリ除去)やALOS-4以降の地球観測で、オンボードSAR(合成開口レーダー)処理の高度化が進んでいます。2025年からは「宇宙AIワーキンググループ」が組織され、コンステレーション規模での分散AIの議論が始まっています。
各国の動向を整理すると、共通するキーワードが浮かびます。それは「三層アーキテクチャ」と「衛星間光リンク」です。次のセクションで、この骨格を一気に見ていきます。
アーキテクチャ — エッジ／フォグ／クラウドの三層構造
三層モデルの全体像
宇宙分散AIシステムは、概念的に次の三層で整理できます。
| 層 | 物理実体 | 主な処理 | 通信レイテンシ |
|---|---|---|---|
| エッジ層 | 衛星単体のAIアクセラレータ | 前処理、低レベル特徴抽出、緊急検出 | $\sim$ μs(オンチップ) |
| フォグ層 | コンステレーション内の複数衛星 + OISL | 中間集約、分散推論、フェデレーション学習 | 数十ms(OISL越し) |
| クラウド層 | 地上データセンタ | 最終的な集計、モデル再学習、長期保存 | 数百ms〜分(可視ウィンドウ依存) |
この三層は地上クラウドのEdge/Fog/Cloud(IoTで標準化された3層モデル)を素直に軌道に持ち上げた構造ですが、宇宙特有の制約として次が加わります。
- ノードが動く: LEO衛星は約7.5 km/sで地球を周回するため、リンクトポロジが時間変化する
- 電源・熱が制約: AIアクセラレータの常時稼働は熱制御と電源バジェットを圧迫する
- 計算ノード自体が観測ノード — エッジ層は単に「ユーザに近い計算」ではなく、生データ源そのもの
エッジ層 — オンボードAI
エッジ層は、観測衛星の中で完結する処理を担います。代表例が「雲マスキング」 — 撮影した地上画像に雲がかかっているピクセルを判別し、雲ばかりのフレームは地上に下ろさないようにする処理です。これだけで地上に降ろすデータ量を50〜80%削減できます。
問題は、宇宙環境でAIモデルを動かすのが容易ではないこと。宇宙環境では宇宙線によるSEU(Single Event Upset)でFPGAのレジスタやDRAMセルがビット反転を起こします。一般民生品のGPUは耐放射線設計されていないため、商用CubeSatでは耐放射線版のFPGAやMyriad VPU、最近ではNVIDIA Jetson系の冗長運用がよく使われます。冗長運用の典型はTMR(Triple Modular Redundancy) で、同じ計算を3経路で実行して多数決を取る方式です。
フォグ層 — コンステレーション内協調
フォグ層は、複数の衛星がOISLで結ばれて協調する層です。例えば、観測衛星Aが撮影した画像を、隣接する演算衛星B、Cに分散して推論を回し、結果だけを観測衛星Aに戻す、というような流れです。
OISLは100 Gbps〜1 Tbpsクラスのスループットを実現でき、片道伝搬遅延は衛星間距離 $d$ に対して $d/c$ で支配されます。同一面内の隣接衛星距離が500 km程度であれば、伝搬遅延は約1.7 ms。これに対して光モデムの処理遅延・ビーム指向制御の補正時間がそれぞれ数ms乗ります。
クラウド層 — 地上データセンタ
最終的な集約、モデル全体の再学習、長期保存は地上クラウド層で行われます。フォグ層で集約された圧縮済みアラートだけが地上に降りるため、地上側のネットワーク負荷は劇的に下がります。
この三層モデルの中で技術的にもっとも重く、設計の核となるのが「どの計算をどの層に置くか」というアロケーション問題です。次のセクションで定式化します。
タスクアロケーション問題の定式化
問題設定
時刻 $t$ において $N$ 機の衛星 $\mathcal{S} = \{1, 2, \dots, N\}$ がコンステレーションを構成し、 $M$ 個の推論タスク $\mathcal{T} = \{1, 2, \dots, M\}$ が到着するとします。タスク $j$ をどの衛星 $i$ で処理するかを決めるのがアロケーション問題です。
決定変数を二値変数 $x_{ij} \in \{0, 1\}$ で定義します。
$$ x_{ij} = \begin{cases} 1 & \text{タスク } j \text{ を衛星 } i \text{ で実行する} \\ 0 & \text{それ以外} \end{cases} $$
各タスクはどこか一台で実行されるので、次の制約があります。
$$ \sum_{i=1}^{N} x_{ij} = 1 \quad \forall j \in \mathcal{T} $$
各衛星のAIアクセラレータには処理能力上限 $C_i$ (FLOPS)があり、タスク $j$ は計算量 $w_j$ (FLOPs)を要求します。スケジューリング窓 $\Delta t$ の間にこなせる総計算量で制約を書くと、次のようになります。
$$ \sum_{j=1}^{M} w_j x_{ij} \le C_i \Delta t \quad \forall i \in \mathcal{S} $$
コスト関数 — レイテンシと電力のトレードオフ
アロケーションの良し悪しを測る指標は、典型的には「タスク完了までの総レイテンシ」と「衛星の消費電力」の重み付き和です。タスク $j$ を衛星 $i$ で実行する際のレイテンシ $L_{ij}$ は、計算時間と通信時間の和で書けます。
$$ L_{ij} = \underbrace{\frac{w_j}{C_i}}_{\text{計算時間}} + \underbrace{\frac{d_{s(j), i}}{c} + \tau_{\text{OISL}}}_{\text{通信時間}} $$
ここで $s(j)$ はタスク $j$ のソース衛星(撮影した衛星)、 $d_{s(j), i}$ はソース衛星とアロケート先衛星間の距離、 $\tau_{\text{OISL}}$ はモデム処理を含む固定オーバーヘッドです。同じ衛星でやれば通信時間がゼロですが、その衛星が他のタスクで混んでいれば待ち時間が増えるトレードオフがあります。
電力コスト $E_{ij}$ は計算量 $w_j$ と衛星 $i$ の電力効率 $\eta_i$ (J/FLOP)の積で書けます。
$$ E_{ij} = \eta_i w_j $$
総コストはレイテンシと電力の重み付き和です。重み $\lambda$ で電力をどれだけ重視するかを表します。
$$ J(\bm{X}) = \sum_{i=1}^{N} \sum_{j=1}^{M} x_{ij} (L_{ij} + \lambda E_{ij}) $$
ここで $\bm{X} \in \{0,1\}^{N \times M}$ はアロケーション行列です。問題は次の整数計画(0-1 ILP)に帰着します。
$$ \begin{aligned} \min_{\bm{X}} \quad & J(\bm{X}) = \sum_{i, j} x_{ij} (L_{ij} + \lambda E_{ij}) \\ \text{s.t.} \quad & \sum_{i} x_{ij} = 1 \quad \forall j \\ & \sum_{j} w_j x_{ij} \le C_i \Delta t \quad \forall i \\ & x_{ij} \in \{0, 1\} \end{aligned} $$
解法アプローチ
この0-1 ILPはGeneralized Assignment Problem(GAP)の一種で、一般にNP困難です。実用的な解法は3つに大別できます。
- 貪欲法(Greedy) — タスクごとに、現在余裕のある衛星の中でレイテンシが最小のものを選ぶ。計算は速いが最適性保証なし
- LP緩和 + 丸め — $x_{ij} \in [0,1]$ に緩和して線形計画を解き、解を整数に丸める。多項式時間で近似解を得られる
- メタヒューリスティック — 遺伝的アルゴリズム、シミュレーテッドアニーリングなど。問題規模が大きいときに使う
宇宙環境の制約では「意思決定もエッジでやらないといけない」のがクセモノです。地上のスケジューラに毎回投げると、レイテンシ最適化の意味がなくなります。よって、各衛星が局所情報だけで判断できる分散貪欲アルゴリズムが現実的な選択になることが多いです。
この問題設定をもとに、次のセクションでは実際にPythonでシミュレーションを組み、貪欲法とILP最適解の性能差を見ます。
Pythonシミュレーション — 貪欲法 vs 最適化
ここまでで定式化したアロケーション問題を、実際にPythonで解いて貪欲法と最適解を比較します。シミュレーションでは、20機の衛星と50個のタスクからなる中規模のシナリオを設定し、それぞれの手法でアロケーションを行ってレイテンシ分布を比較します。
シナリオ生成
まずは、衛星位置・能力・タスクをランダムに生成するスクリプトです。LEOコンステレーション(高度550 km、傾斜角53°)を模した簡易モデルとして、衛星の位置を球面上に分散させます。
import numpy as np
import matplotlib.pyplot as plt
from scipy.optimize import linprog
rng = np.random.default_rng(seed=42)
# シミュレーションパラメータ
N = 20 # 衛星数
M = 50 # タスク数
R_earth = 6371e3 # 地球半径 [m]
h = 550e3 # 軌道高度 [m]
c = 3.0e8 # 光速 [m/s]
# 衛星位置を球面上に分散(極座標 -> 直交座標)
theta = rng.uniform(0, 2 * np.pi, N) # 経度
phi = np.arccos(rng.uniform(-1, 1, N)) # 余緯度(球面均等)
sat_pos = np.stack([
(R_earth + h) * np.sin(phi) * np.cos(theta),
(R_earth + h) * np.sin(phi) * np.sin(theta),
(R_earth + h) * np.cos(phi),
], axis=1) # shape (N, 3)
# 衛星間距離行列
d_mat = np.linalg.norm(sat_pos[:, None, :] - sat_pos[None, :, :], axis=2) # (N, N)
# 衛星能力 C_i [FLOPS]、効率 eta_i [J/FLOP]
C = rng.uniform(1e12, 8e12, N) # 1-8 TFLOPS
eta = rng.uniform(0.5e-12, 2.0e-12, N) # 電力効率
# タスク: 計算量 w_j [FLOPs], ソース衛星 s(j)
w = rng.uniform(5e10, 5e11, M) # 50G-500G FLOPs
source = rng.integers(0, N, M) # 各タスクのソース衛星
# レイテンシ行列 L_{ij} [s]
tau_OISL = 5e-3 # 光モデム処理遅延 [s]
L = np.zeros((N, M))
for i in range(N):
for j in range(M):
compute_time = w[j] / C[i]
comm_time = d_mat[source[j], i] / c + (tau_OISL if i != source[j] else 0)
L[i, j] = compute_time + comm_time
# 電力コスト E_{ij}
E = eta[:, None] * w[None, :] # (N, M)
# 総コスト J_{ij} = L_{ij} + lambda * E_{ij}
lam = 1e-3 # 電力重み(レイテンシをsで揃え、E[J]に係数)
J = L + lam * E
上のセットアップで、衛星間距離は最大で約13,800 km(高度550 kmの地球裏側)、最短は数百km〜数千kmの分布になります。OISL越しの伝搬時間は数ms〜数十msのオーダで、計算時間(タスク量とFLOPSから10〜500ms程度)と同程度のオーダになっており、通信と計算のトレードオフが効くシナリオになっています。
貪欲法による割当
最も素朴な手法として、タスクをコスト順に並べ、利用可能な衛星の中でコストが最小のものに割り当てる貪欲法を実装します。
def greedy_allocation(J, w, C, dt=1.0):
"""貪欲法によるタスクアロケーション
J: (N, M) コスト行列
w: (M,) タスク計算量
C: (N,) 衛星処理能力
dt: スケジューリング窓 [s]
Returns: assignment (M,) 各タスクの担当衛星index、cost合計
"""
N, M = J.shape
capacity = C * dt # 各衛星の総処理能力 [FLOPs]
assignment = -np.ones(M, dtype=int)
used = np.zeros(N)
# コストの低い順にタスクを処理する優先順位戦略
task_order = np.argsort(np.min(J, axis=0))
for j in task_order:
feasible = np.where(used + w[j] <= capacity)[0]
if len(feasible) == 0:
# どこにも入らない: 最も余裕のあるノードに強制割当
best = np.argmax(capacity - used)
else:
best = feasible[np.argmin(J[feasible, j])]
assignment[j] = best
used[best] += w[j]
total_cost = J[assignment, np.arange(M)].sum()
return assignment, total_cost, used
assignment_g, cost_g, used_g = greedy_allocation(J, w, C, dt=1.0)
print(f"Greedy total cost: {cost_g:.3f}")
print(f"Greedy max utilization: {(used_g / C).max():.2%}")
この貪欲アルゴリズムは $O(NM)$ で動き、即決判断が必要な衛星オンボード環境に適しています。最大利用率を確認すると、貪欲法では一部の衛星に偏ったアロケーションが起こりがちで、コスト最小衛星にタスクが集中して定員いっぱいまで詰まる傾向があります。
LP緩和による近似最適化
次に、二値変数を $x_{ij} \in [0, 1]$ に緩和してLP(線形計画)を解き、各タスクで最大の $x_{ij}$ を持つ衛星に割り当てる、という近似最適化を行います。
def lp_relaxation_allocation(J, w, C, dt=1.0):
"""LP緩和 + 丸めによるタスクアロケーション
"""
N, M = J.shape
NM = N * M
# 目的関数: minimize sum_{ij} J_{ij} x_{ij}
c_obj = J.flatten() # (NM,)
# 等式制約: sum_i x_{ij} = 1, for each j
A_eq = np.zeros((M, NM))
for j in range(M):
for i in range(N):
A_eq[j, i * M + j] = 1.0
b_eq = np.ones(M)
# 不等式制約: sum_j w_j x_{ij} <= C_i * dt, for each i
A_ub = np.zeros((N, NM))
for i in range(N):
for j in range(M):
A_ub[i, i * M + j] = w[j]
b_ub = C * dt
bounds = [(0, 1)] * NM
res = linprog(c_obj, A_ub=A_ub, b_ub=b_ub,
A_eq=A_eq, b_eq=b_eq, bounds=bounds, method='highs')
if not res.success:
raise RuntimeError(f"LP failed: {res.message}")
X = res.x.reshape(N, M)
# 各タスクで最大の重みを持つ衛星に丸め
assignment = np.argmax(X, axis=0)
# 容量超過チェック&修復(超過があれば次点に移す)
used = np.zeros(N)
for j in np.argsort(-w): # 大きいタスクから配置
i = assignment[j]
if used[i] + w[j] > C[i] * dt:
order = np.argsort(-X[:, j])
for ii in order:
if used[ii] + w[j] <= C[ii] * dt:
assignment[j] = ii
break
used[assignment[j]] += w[j]
total_cost = J[assignment, np.arange(M)].sum()
return assignment, total_cost, used
assignment_lp, cost_lp, used_lp = lp_relaxation_allocation(J, w, C, dt=1.0)
print(f"LP relaxation total cost: {cost_lp:.3f}")
print(f"LP max utilization: {(used_lp / C).max():.2%}")
print(f"Cost reduction vs greedy: {(cost_g - cost_lp) / cost_g * 100:.2f}%")
LP緩和では、線形計画ソルバ(HiGHS)が容量制約を考慮した上で大域的にコスト最小化を行うため、貪欲法と比べて総コストが下がります。実験的にはシード42の場合、LP緩和の方が貪欲法より総コストが10〜25%程度低くなり、最大利用率も平準化されることが確認できます。
レイテンシ分布の可視化
両手法のレイテンシ分布をヒストグラムで比較しましょう。タスクごとの実レイテンシは $L[\text{assignment}[j], j]$ で得られます。
lat_g = L[assignment_g, np.arange(M)]
lat_lp = L[assignment_lp, np.arange(M)]
fig, axes = plt.subplots(1, 2, figsize=(12, 4))
# 左: レイテンシ分布
axes[0].hist(lat_g * 1000, bins=20, alpha=0.6, label=f'Greedy (mean={lat_g.mean()*1000:.1f}ms)')
axes[0].hist(lat_lp * 1000, bins=20, alpha=0.6, label=f'LP relax (mean={lat_lp.mean()*1000:.1f}ms)')
axes[0].set_xlabel('Task latency [ms]')
axes[0].set_ylabel('# tasks')
axes[0].set_title('Latency distribution per task')
axes[0].legend()
# 右: 衛星利用率
axes[1].bar(np.arange(N) - 0.2, used_g / C, width=0.4, label='Greedy')
axes[1].bar(np.arange(N) + 0.2, used_lp / C, width=0.4, label='LP relax')
axes[1].axhline(1.0, color='red', linestyle='--', alpha=0.5)
axes[1].set_xlabel('Satellite index')
axes[1].set_ylabel('Utilization')
axes[1].set_title('Per-satellite utilization')
axes[1].legend()
plt.tight_layout()
plt.show()
このグラフから3つのことが読み取れます。1つ目は、LP緩和の方がレイテンシ分布が左に寄る — タスクあたりの平均レイテンシが小さくなり、宇宙分散AIで効いてくる「リアルタイム性」が改善されています。2つ目は、衛星利用率がLP緩和ではより平坦 — 一部の衛星に負荷が集中する貪欲法に対し、LP緩和は全衛星をムラなく使えます。3つ目は、貪欲法でも実用に耐える — LP緩和との差は10〜25%程度に収まり、衛星オンボードのリアルタイム判断としては貪欲法でも十分機能することがわかります。
スケジューリング窓と通信遅延の感度
最後に、スケジューリング窓 $\Delta t$ を変化させたときに、最適化解がどう変わるかを見ます。
dts = np.array([0.2, 0.5, 1.0, 2.0, 5.0])
costs_g, costs_lp = [], []
for dt in dts:
_, cg, _ = greedy_allocation(J, w, C, dt=dt)
_, cl, _ = lp_relaxation_allocation(J, w, C, dt=dt)
costs_g.append(cg)
costs_lp.append(cl)
plt.figure(figsize=(7, 4))
plt.plot(dts, costs_g, 'o-', label='Greedy')
plt.plot(dts, costs_lp, 's-', label='LP relax')
plt.xlabel('Scheduling window dt [s]')
plt.ylabel('Total cost')
plt.title('Scheduling window vs total cost')
plt.legend()
plt.grid(True, alpha=0.3)
plt.show()
スケジューリング窓 $\Delta t$ を広げると、容量制約が緩和されて低レイテンシ衛星にタスクを集約できるため、両手法とも総コストが下がります。ただし、 $\Delta t$ が大きすぎるとそもそも「リアルタイム性」が損なわれるため、宇宙分散AIでは衛星周回周期(LEOで約95分)に対して数百ms〜数秒のスケジューリング窓を選ぶのが現実的です。
ここまでで、アロケーション問題の数値的な感触がつかめました。次のセクションでは、推論ではなく学習を分散する話 — 連合学習を宇宙に持ち込む話を見ます。
連合学習・分散学習の宇宙応用
衛星連合学習(Satellite Federated Learning)
各衛星が観測した画像で個別にローカルモデルを学習し、モデル更新だけをコンステレーション内で共有して大域モデルを作る、というのが衛星連合学習(SatFL)です。生データを共有しない=データ主権を守る、地上ダウンリンク負荷を激減できる、という二重のメリットがあります。
ローカル衛星 $i$ がローカルパラメータ $\bm{\theta}_i^{(t)}$ を更新し、フォグ層で平均を取って大域パラメータ $\bm{\theta}^{(t+1)}$ を作る、という典型的なFedAvgのスキームを書くと以下の通りです。
$$ \bm{\theta}^{(t+1)} = \sum_{i=1}^{N} \frac{n_i}{\sum_k n_k} \bm{\theta}_i^{(t)} $$
ここで $n_i$ は衛星 $i$ が保持するローカルサンプル数です。地上クラウドの連合学習との大きな違いは、通信トポロジが時間変化すること。LEO衛星は周回周期約95分の中で他の衛星との可視関係が刻々と変わるため、各ラウンドで通信できる相手が異なります。
階層型連合学習(Hierarchical FL)
地上FLでは通常2層(クライアント↔サーバ)ですが、宇宙では3層(衛星↔軌道平面リーダー↔地上サーバ)の階層型が現実的です。各軌道平面の中で部分平均を取り、その結果だけを地上のグローバルサーバに送る構造で、ダウンリンク負荷を大きく削減できます。
階層型のSatFLでは、収束速度は地上の純粋FedAvgよりやや劣る一方、通信ラウンドあたりのダウンリンク量は10〜100分の1に減ります。Walker constellationのウォーカー配座を仮定した解析では、軌道平面内のメッシュ通信が安定するため、各ラウンドで5〜10機の衛星が同時にローカル更新を集約できることが知られています。
モデル並列とパイプライン並列
LLMのような巨大モデルを軌道上で動かす場合、1機の衛星のメモリには収まりません。三体計算コンステレーションの想定では、モデル全体を層単位で複数衛星に分割し、OISLでパイプライン的に推論を回す構造が議論されています。
レイヤーを $K$ 機の衛星に分割すると、各衛星はモデル全体の $1/K$ だけを保持すればよくなり、メモリ使用量が削減できます。一方、レイヤー間でアクティベーションをOISLで送る必要があり、これが通信オーバーヘッドになります。パイプライン並列の総レイテンシは次のように書けます。
$$ T_{\text{pipeline}} = \sum_{k=1}^{K} \left( T_{\text{compute}, k} + T_{\text{comm}, k \to k+1} \right) $$
OISLが100 Gbpsクラスでアクティベーションサイズが数MB程度なら、 $T_{\text{comm}}$ は数百μs程度に収まり、計算時間に比べて十分小さくなります。これが「軌道上でLLM推論」の現実味の根拠です。
軌道上モデル更新と継続学習
軌道上で観測したデータが直接モデル学習に使えるなら、地上での再学習サイクルを待たずに、その場で改善できます。例えば船舶検出モデルが「新しいタイプの船」を取りこぼした場合、地上から教師ラベルを送って継続学習する、というクローズドループが実現可能です。
ここまでで、軌道上で「考える」アーキテクチャの全体像が見えました。最後に、システム全体の課題と今後の方向性を整理します。
システム的課題と今後の展望
セキュリティとアタックサーフェス
軌道上で計算が完結する=軌道上が攻撃対象になります。OISL越しの中間者攻撃、衛星バスへのサプライチェーン攻撃、AIモデルへのデータポイズニング — 攻撃面は地上クラウドより複雑です。Trusted Execution Environment(TEE)や、量子鍵配送(QKD)を組み合わせる研究が進んでいます。
熱と電力のバジェット
AIアクセラレータの常時稼働は熱を生みます。LEO衛星は1周回(95分)のうち約60分が日陰なので、太陽電池の電源バジェットには限りがあります。「Duty-cycled AI」 — 必要なときだけ推論を回す方式が広く使われます。アロケーション問題のコスト関数に電力項を入れる動機はここにあります。
軌道上モデル管理(MLOps)
地上のMLOpsの延長で、「SatMLOps」と呼ばれる軌道上モデル管理が必要になります。モデルバージョン管理、A/Bテスト、ロールバック、モニタリング — これらすべてを限られた帯域とリアルタイム性の制約下でやらなければいけません。
法的・倫理的論点
軌道上で完結するAI判断 — 例えば船舶識別から疑わしい船舶への警告生成まで — を地上の人間が監督しないままどこまで許容するかは、宇宙法と国際法の論点として注目されています。Outer Space Treatyは1967年の制定なので、AIに関する明示的な条項はなく、各国で議論が進んでいる段階です。
まとめ
本記事では、宇宙分散AIアーキテクチャと三体計算コンステレーションについて、動機からシミュレーションまでを一気通貫で見てきました。
- 動機 — 遅延、データ主権、災害耐性の3つが宇宙で計算する理由を支えている
- 動向 — 中国の三体計算コンステレーション(2,800機、1,000 POPS構想)、Starlinkの軌道上推論オフロード、ESA Phi-satシリーズが代表例
- アーキテクチャ — エッジ(衛星単体)／フォグ(コンステレーション内)／クラウド(地上)の三層構造
- アロケーション問題 — タスクをどの衛星で処理するかは、レイテンシと電力の重み付き和を目的関数とする0-1整数計画として定式化される
- 解法 — 貪欲法は高速で実用十分、LP緩和は10〜25%程度コストを下げられる
- 学習 — 階層型連合学習、モデル並列、軌道上継続学習が宇宙ならではのパターン
宇宙分散AIは、まだ実証段階の技術ですが、2030年代には宇宙インフラの標準的な構成要素になると見られています。地上クラウドが「ここ20年で生まれた」のと同じスケールで、軌道上クラウドが「次の20年で当たり前になる」と考えれば、今がまさにアーキテクチャの整理と要素技術の習得の最適期です。
次のステップとして、以下の記事も参考にしてください。
- オンボードAIと宇宙AIの基礎 — 衛星単体での機械学習推論を支えるハードウェアとソフトウェア技術
- 自由空間光通信(FSOC)とOISLの基礎 — 衛星間光リンクの物理層と制御の基礎
- 衛星連合学習(Satellite Federated Learning) — 地上にデータを下ろさずモデルだけを共有する宇宙連合学習
- 宇宙エッジコンピューティングの基礎 — エッジ・フォグ・クラウドの三層構造で宇宙計算インフラを設計