なぜ衛星推論は一般的なMLと異なるのか
通常のMLモデルは数MBのデータを入力し、1秒以内に結果を返します。LLMが段落を処理したり、スマートフォンの写真を解析したりするイメージです。しかし地球観測（Earth Observation）の推論はスケールが根本的に異なります。1回のファインチューニングジョブがテラバイト級のデータを移動しながら数時間稼働することもあります。
入力データも複雑です。複数のスペクトルバンド、センサータイプ、タイムステップが混在し、プロバイダごとに投影法（projection）や解像度が異なります。雲で遮蔽された観測値も多く含まれます。さらに出力が地図であるため、すべての予測値が周辺地域と同一の座標系に精密に整列している必要があります。
最大のボトルネックはデータ取得段階です。実際、予測ジョブはモデル実行時間よりも画像のダウンロードと前処理に多くの時間を費やすことが多く、データパイプラインが全体の性能を左右します。
本記事はAI2（Allen Institute for AI）が公開したOlmoEarthプラットフォームの構築事例を基に、大規模地球観測システム設計の要点を再構成したものです。根拠資料はOlmoEarthインフラブログで確認できます。
核心設計：ハードウェアをタスクに合わせて分割する
最も重要な原則は**「高価なGPUに雑務をさせない」**ことです。データ取得と前処理がランタイムを支配するなら、その処理をGPUに任せた瞬間、最も高価なリソースがCPUでも十分な作業を行うことになります。そこでOlmoEarthは各ジョブを3段階に分け、それぞれに適したハードウェアプロファイルを割り当てます。
| 段階 | ハードウェア | 役割 |
|---|---|---|
| データ取得・前処理 | CPU、高I/O | 画像取得、再投影、整列、正規化後、高速ロード用フォーマットで保存 |
| 推論 | GPU | モデルのforward pass実行、最小限の加工出力のみストレージへ記録 |
| 後処理 | CPU | ウィンドウ単位の出力を結合、マスク/リスケール、Zarr/GeoTIFF/GeoJSONでエクスポート |
この構造の要点は、マルチプロセスデータローダーがGPUに継続的にデータを供給する一方、完了した出力は即座にblobストレージへストリーミングされることです。GPUのアイドル時間を最小化します。
パーティショニング：1リクエスト、数千ワーカー
OlmoEarth Run実行レイヤーは、対象地域をワーカー（compute instance）サイズに合わせてパーティションに分割し、さらにモデルが処理するウィンドウへ細分化します。各ウィンドウは独立したforward passで処理されるため、地図の一方が他方を待つ必要がありません。
# パーティショニングの概念を単純化した擬似コード
def run_inference(region, model, workers):
partitions = split_by_worker_size(region) # 州規模 → 数百個
tasks = []
for p in partitions:
for w in subdivide_into_windows(p): # ウィンドウ単位に分割
tasks.append({"window": w, "overlap": True}) # 隣接パーティションは少し重複
# パーティションは独立なので数千インスタンスへ同時fan-out
results = parallel_map(tasks, model.forward, max_workers=workers)
return reconcile_seams(results) # 重複部分を結合し継ぎ目を除去
実際に北米全体の山火事リスクマップを生成した際、ピーク時に約19,600 CPUと994 GPUを並列稼働させ、ネットワークスループットは168 GB/sを超えました。直列計算なら4,737時間かかる作業を約30.5時間に短縮し、155倍の高速化を達成しています。
ただしfan-outは無限ではありません。ワーカーを増やすとクラウドクォータに衝突するため、並列度はジョブごとに調整するノブです。解像度はデータ量/演算量とディテールを、モデルサイズはGPU時間と精度を、元画像キャッシュはストレージと反復実行速度をトレードオフします。
注意事項：華やかな数字の裏にある落とし穴
1. 外部STAC APIを直接叩いてはいけない
大規模な推論ジョブ1つが数千のメタデータクエリを同時に生成します。ESAやMicrosoft Planetary ComputerのSTAC APIは、そのような同時性を想定して設計されていません。そこでOlmoEarthは独自のメタデータインデックスを維持します。AWS Open DataのようにSNS通知を提供する場所は変更ストリームを受信し、提供しない場所は数分間隔でポーリングします。結果として外部サービスへのリクエストは、ジョブの爆発ではなく新規画像の公開ペースに合わせて緩やかに流れます。
2. 失敗は正常である
このスケールでは失敗は例外ではなくデフォルトです。プロバイダが遅延したり一時停止したり、メタデータはあるが実際のバンドが欠けていたり、雲で使用可能な観測が不足したり、タスクがそのままクラッシュしたりします。そこで全タスクを**再入可能（reentrant）かつ冪等（idempotent）**に設計し、再実行すれば安全に復旧できるようにしています。再試行可能エラーと致命的エラーを区別し、代替プロバイダへフォールバックし、停止したランナーを検知して再起動する監視プロセスも別途用意します。
3. データプロバイダに望むこと
OlmoEarthチームがまとめた「地球観測データ公開のベストプラクティス」は実務に直結します。
- 新規画像公開時のキュー基盤通知の提供
- 主要クラウドへ特殊なrate limitなしで保存
- range readをサポートするクラウド最適化フォーマット（COG、Zarr）での提供
この3点を守るだけで、下流パイプラインの複雑さが大幅に軽減されます。
日本環境への適用について：JAXAの衛星データ（だいち、しきさい等）を扱う場合もこの原則は有効です。国内データポータルの多くはキュー通知やrange readをサポートしていないケースがあり、インデックスレイヤーを自前で構築する必要が生じがちです。その際、COG変換パイプラインを初期段階で整備しておくと後々の負債を減らせます。
結論：このアーキテクチャから持ち帰るべき3点
- ハードウェアプロファイルの分離は選択ではなく必須。 CPU/GPU境界を明確に引かないと、コストが静かに漏れ出します。
- インデックスは外部サービスへのクッション。 元のカタログを直接叩かず、公開ペースに合わせて流れる独自インデックスを置きましょう。
- 冪等性は大規模システムの生存条件。 再試行が安全でなければ、障害復旧は恐怖になります。
OlmoEarthチームのロードマップには自動スケジューリング、変化検知/アラート、埋め込みの事前計算、マルチクラウド対応などが含まれています。特に埋め込みを地球規模で事前計算し、元画像のforward passを代替する方向は、コスト効率化を狙うすべての地球観測チームが注目すべき点です。
あわせて読みたい記事
- AIエージェント開発でなぜオープンデータが重要なのか（Nemotron事例分析） — オープンデータがAIエージェント性能をどう変えるかを事例中心に整理しています。
- レガシーERPの限界を超えたリアルタイム分析アーキテクチャ構築記（Infor + Aurora + QuickSight） — 大規模データをリアルタイム分析へ接続するアーキテクチャ設計の観点で参考になります。
次のステップ学習の方向性
- STAC仕様とCOG/Zarrフォーマットを実際に触ってみてください。データレイヤーの理解が設計全体の半分を占めます。
- 冪等タスク設計パターン（例：Airflow/Temporalの再試行モデル）を学ぶと、障害復旧設計が容易になります。
- 関心があればOlmoEarthモデル自体をファインチューニングし、プラットフォームが隠蔽してくれる複雑さを体感するのも良いでしょう。