Google Earth Engine

解決する課題

• 数十年分の衛星画像を分析したいが、ダウンロード・保管・前処理に膨大なストレージと手間がかかる
• 森林破壊・水域変化・農地モニタリングなどの変化検出を、広域かつ長期にわたって実行したい
• 大量のラスター（画像）データを処理するための計算クラスタを自前で構築・運用したくない
• 公開衛星（Landsat、Sentinel など）や気象・地形データを探して取り込む手間を省きたい
• 地理空間解析の結果を、社内の BigQuery や Cloud Storage の分析基盤へつなぎたい

主要概念と用語

• データカタログ (Data Catalog): Landsat・Sentinel・MODIS などの衛星画像や、気象・標高・土地被覆といった公開地理空間データを集めたペタバイト級の蓄積。利用者は取り込みや保管をせず、その場で参照できる
• Image / ImageCollection: 単一のラスター画像と、その時系列やシーンの集合。バンド（観測波長）ごとの値を持ち、時間軸で重ねて解析する基本単位
• Feature / FeatureCollection: 点・線・ポリゴンといったベクターデータと、その集合。行政界や観測地点など、画像と組み合わせて集計する際に使う
• Reducer（リデューサー）: 画素や時系列を集約する演算の抽象。平均・合計・中央値などを、空間方向や時間方向にまとめて算出する
• 遅延評価 / サーバーサイド実行: クライアントで書いたコードは即時に計算されず、演算グラフとして組み立てられ、結果を要求した時点で Google 側の基盤がまとめて実行する
• Code Editor: ブラウザ上で JavaScript により対話的に解析・可視化できる開発環境。地図表示と結果の即時確認に向く
• クライアントライブラリ: Python API（earthengine-api）などから同じ機能を呼び出せる。Colab やパイプラインへの組み込みに向く
• アセット (Asset): 利用者が持ち込む独自の画像・テーブルを Earth Engine 上に登録したもの。公開カタログと同じように解析へ組み込める

仕様・制限・クォータ

• サーバーレスで、ラスター処理用のクラスタを自前でプロビジョニングする必要はない。計算は Google 側のマネージド基盤で分散実行される
• 計算は遅延評価で組み立てられ、結果を取り出す（地図表示・集計・エクスポート）時点でまとめて実行される。対話的な処理には応答時間の上限があり、大規模処理はバッチのエクスポートとして実行する
• 同時に実行できるタスク数、1 リクエストあたりの処理量、エクスポートサイズなどに上限がある。具体的な数値は変動するため、設計時は公式のクォータを確認する
• 商用利用には Google Cloud プロジェクトへの紐付けと有償プランが前提。学術・研究や非営利用途には無償の枠組みが用意されている
• 主に扱うのは地理空間のラスター/ベクターであり、汎用の表形式分析は BigQuery、汎用バッチ処理は Dataflow など別サービスが担う

内部の仕組み

Earth Engine の中核は、ペタバイト級のデータカタログと、それを並列処理する分散計算基盤の組み合わせです。利用者はデータをダウンロード・保管せず、カタログ上の画像をその場で参照します。膨大な衛星画像は、効率よく取り出せるようタイル（小区画）状に分割・前処理されており、必要な範囲・期間・バンドだけを読み出して計算できます。

クライアント（Code Editor や Python API）で記述したコードは、その場で計算されるのではなく、演算グラフとして組み立てられます。地図表示・集計・エクスポートなど結果を要求した瞬間に、このグラフが Google 側へ送られ、対象タイル群へ並列に演算が適用されます。Reducer は「空間方向にまとめる」「時間方向にまとめる」といった集約を表し、広域・長期のデータでも一括で平均や変化量を求められます。この遅延評価により、利用者は分散処理の詳細を意識せずに惑星規模の解析を記述できます。

対話的な解析にはレスポンス時間の制約があるため、広い領域・長い期間の本格的な処理はバッチのエクスポートとして投入し、結果を Cloud Storage や Earth Engine アセット、あるいは BigQuery へ書き出します。これにより、対話的な試行錯誤と大規模な本番処理を使い分けられます。

設計パターン / ベストプラクティス

• まず Code Editor で小さな領域・短い期間で試作し、ロジックが固まってから広域・長期へ広げて手戻りを減らす
• 広い領域や長期間の処理はバッチのエクスポートに回し、対話的なクエリでは応答時間の上限に触れないようにする
• 集約は早い段階で Reducer にまとめ、不要なバンドや期間を絞ってから計算し、処理量を抑える
• 繰り返し使う中間結果は Earth Engine アセットとして保存し、再計算のコストを避ける
• パイプライン化やレポート連携には Python API（Colab など） を使い、対話的な探索は Code Editor と役割分担する
• 解析結果を社内の表形式分析に載せるなら、BigQuery へエクスポートして既存のダッシュボードや SQL 分析につなぐ

運用・監視

• バッチのエクスポートタスクは完了・失敗・キャンセルの状態を持つため、長時間ジョブの進捗と失敗を監視する
• 処理が応答時間の上限で打ち切られる場合は、対象範囲・期間・解像度を縮小するか、バッチ処理へ切り替える
• 同時実行タスク数などのクォータ超過を検知し、ジョブの投入ペースを調整する
• 自前で持ち込んだアセットの取り込み状況とエラーを確認し、座標系や形式の不整合を早期に見つける
• パイプライン実行は Google Cloud プロジェクトに紐付け、利用状況とアクセスを Cloud の監視・監査の枠組みで把握する

コスト

セキュリティ

• 利用は Google Cloud プロジェクトに紐付き、アクセスや課金は Cloud の IAM とプロジェクト管理の枠組みで統制する
• 自前で持ち込んだアセットには共有範囲を設定でき、限定共有か公開かを制御する。意図せぬ公開を避けるため既定は限定共有に保つ
• エクスポート先の Cloud Storage / BigQuery 側では、それぞれの暗号化・アクセス制御（IAM、CMEK 対応）が適用される
• 公開カタログは Google が保持する読み取り中心のデータであり、機密データは持ち込みアセット側の共有設定で管理する
• パイプラインから利用する場合は、サービスアカウントに最小権限を与えて認証し、個人資格情報の埋め込みを避ける

関連サービス・比較

Earth Engine は地理空間ラスターの解析エンジンで、結果を表形式で分析・蓄積する BigQuery としばしば組み合わせて使われます。両者は競合ではなく、解析（Earth Engine）と表形式分析・配信（BigQuery）で役割を分担します。

ハンズオン / CLI例

# 1) Python クライアントライブラリを導入（earthengine コマンドが付属）
pip install earthengine-api

# 2) Google Cloud プロジェクトに紐付けて認証
earthengine authenticate
earthengine set_project MY_PROJECT

# 3) 自前のラスター画像を Cloud Storage 経由でアセットとして取り込む
earthengine upload image \
  --asset_id=projects/MY_PROJECT/assets/my_raster \
  gs://MY_BUCKET/my_raster.tif

# 4) 取り込みタスクの進捗・完了を確認
earthengine task list

# 5) 登録したアセットのメタデータを確認
earthengine asset info projects/MY_PROJECT/assets/my_raster