3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@rino_yume(rino yume)

GeoAIとは何か？ GIS × AIが変える地理空間解析の現在地と、防災・WebGISへの展開を考える

3
Posted at

GeoAIとは何か？ GIS × AIが変える地理空間解析の現在地と、防災・WebGISへの展開を考える

はじめに

最近、GISやリモートセンシングの分野で GeoAI という言葉を目にする機会が増えてきました。

GeoAIは、単に「GISにAIを追加する」という話ではありません。

これまでGISが扱ってきた、

  • 位置
  • 距離
  • 地形
  • 河川
  • 道路
  • 建物
  • 衛星画像
  • 気象
  • 災害履歴

といった地理空間データそのものをAIが理解し、分類・予測・推論・自動処理する考え方です。

さらに最近では、

  • Geo Foundation Model
  • マルチモーダルGeoAI
  • Physics-informed AI
  • Agentic GeoAI
  • AI-ready Geospatial Data

といった考え方も登場しており、GeoAIの範囲はかなり広がっています。

この記事では、GeoAIについて調べた内容をもとに、

  1. GeoAIとは何か
  2. 従来のAIとの違い
  3. 何ができるのか
  4. Foundation Modelとは何か
  5. NASAのPrithvi
  6. Google DeepMindのAlphaEarth Foundations
  7. 防災への応用
  8. WebGISとの統合
  9. 数値シミュレーションとの統合
  10. GeoAI Agent
  11. AI-readyな地理空間データ
  12. 実際にシステム化する場合の構成

まで整理してみます。

GeoAIとは何か

GeoAIは、

Geospatial Artificial Intelligence

の略です。

ざっくり表すと、次のような技術の組み合わせだと考えています。

20260915_a01.png

従来のGISでは、

どこに何があるか

を調べることが中心でした。

GeoAIでは、そこから一歩進んで、

  • どこで何が起きているのか
  • なぜそこで起きているのか
  • 次にどこで起きそうなのか
  • 画像から地物を自動抽出できないか
  • GIS操作そのものをAIに実行させられないか

といったことまで扱います。

普通のAIとGeoAIは何が違うのか

一般的なAIでは、単純化すると次のようになります。

Data
  ↓
AI Model
  ↓
Prediction

一方、地理空間データには通常の表形式データとは異なる特徴があります。

例えば雨量100mmというデータがあったとします。

Rainfall = 100 mm

これだけでは、地理空間解析には十分ではありません。

実際には、

Latitude
Longitude
Elevation
River basin
Timestamp
Rainfall
CRS
Spatial resolution

などが重要です。

例えば、

Latitude : 35.x
Longitude: 139.x
Elevation: 320 m
Basin    : River-A
Time     : 2026-09-15 08:00
Rainfall : 100 mm

のように、場所と時間の意味を持ったデータとして扱う必要があります。

GeoAIでは特に、

  • 空間自己相関
  • 距離
  • 隣接関係
  • ネットワーク構造
  • 地形
  • 時系列
  • 空間スケール
  • 座標参照系

といった要素を考慮します。

GeoAIで何ができるのか

GeoAIの利用方法は大きく分けると次のようになります。

分野 内容 例
地物抽出 画像から地物を抽出 建物、道路、河川
分類 場所や画像を分類 土地利用、植生
予測 将来状態を予測 洪水、土砂災害
時空間解析 時間＋空間を解析 降雨、交通、人口
異常検知 通常状態との差を検知 災害、森林変化
空間推論 AIがGIS処理を組み立てる Buffer、Spatial Join
自動化 AIがAPIやGISツールを操作 GeoAI Agent

従来は、

20260917_a01.png

のような処理が中心でした。

しかし現在は、

20260915_a14.png

という方向に発展しています。

GeoAIで扱うデータ

ベクトルデータ

代表的なのは、

Point
LineString
Polygon

です。

例えば、

  • 避難所
  • 道路
  • 河川
  • 建物
  • 行政界
  • 災害警戒区域

などがあります。

利用されるモデルとしては、

  • Random Forest
  • XGBoost
  • Graph Neural Network
  • Transformer
  • Spatial Machine Learning

などがあります。

特に、

道路ネットワーク
河川ネットワーク
上下水道ネットワーク

のようなデータでは、グラフ構造を扱える Graph Neural Network（GNN） と相性がよいです。

ラスターデータ

GeoAIで非常によく扱われるのがラスターデータです。

例えば、

Satellite
Aerial Photo
DEM
DSM
Rainfall
Temperature
Land Cover
Flood Depth

などです。

AIモデルとしては、

CNN
U-Net
Vision Transformer
Segmentation Model
Foundation Model

などが使われます。

例えば、

20260917_a02.png

のように、画像から地物を自動抽出できます。

Geo Foundation Model

最近のGeoAIで非常に重要なのが、

Geospatial Foundation Model

です。

従来は用途ごとにモデルを学習することが多くありました。

Flood AI
Forest AI
Agriculture AI
Building AI

これに対してFoundation Modelでは、大量の地球観測データを事前学習します。

20260915_a02.png

大量のデータから基本的な特徴を学習しておき、その後、目的ごとにFine-tuningします。

ChatGPTなどのLLMで使われているFoundation Modelの考え方が、地球観測データにも広がってきたと考えると分かりやすいです。

NASA + IBM の Prithvi

Geo Foundation Modelの代表例の一つが、

Prithvi Geospatial Foundation Model

です。

NASA、IBM、Forschungszentrum Jülichなどによって開発されています。

PrithviはNASAの、

Harmonized Landsat and Sentinel-2（HLS）

データで事前学習されています。

NASAによると、Prithviは、

  • 洪水域マッピング
  • 山火事跡抽出
  • 土地利用分類
  • 作物分類
  • 地滑り検出
  • バイオマス推定

などに利用されています。

概念的には次のようになります。

20260915_a03.png

さらに2026年には、Prithviの圧縮版が人工衛星と国際宇宙ステーション上の計算環境に展開されました。

NASAはこれを、軌道上に展開された最初のGeospatial Foundation Model としています。

これはかなり面白い方向性です。

20260915_a04.png

という処理も増えていく可能性があります。

いわゆる Edge GeoAI です。

参考:

Google DeepMindのAlphaEarth Foundations

もう一つ注目されているのが、

AlphaEarth Foundations

です。

Google DeepMindが2025年に発表しました。

Google DeepMindはAlphaEarth Foundationsを、

virtual satellite

のように機能するモデルと説明しています。

複数のEarth Observationデータを統合し、地球表面をEmbeddingとして表現します。

20260915_a05.png

AlphaEarth FoundationsのEmbeddingは64次元で構成されています。

また、Google Earth Engineには年次のSatellite Embedding Datasetも公開されています。

これにより、

  • 土地利用分類
  • 生態系分類
  • 農地解析
  • 都市変化
  • 森林変化
  • 水資源解析

などに利用できます。

参考:

Multimodal GeoAI

今後さらに重要になるのが、

Multimodal GeoAI

です。

衛星画像だけではなく、

20260917_a03.png

といった異なる種類の情報を同時に扱います。

例えば土砂災害であれば、

20260915_a06.png

となります。

防災では、一種類のデータだけで判断できないことが多いため、Multimodal GeoAIとの相性はかなり良いと考えています。

GeoAIと防災

GeoAIが特に有効だと考えられる分野の一つが防災です。

洪水

例えば、

20260917_a04.png

といった解析が可能です。

特にSARは雲の影響を受けにくいため、大雨・台風時の災害監視で有効です。

土砂災害

例えば、地すべり災害に対しては、

20260917_a05.png

という構成が考えられます。

従来の統計解析と、

Random Forest
XGBoost
Deep Learning

などを組み合わせることで、危険度マップを作成できます。

GeoAIと数値シミュレーション

ここは個人的にかなり重要だと思っています。

GeoAIは、

数値シミュレーションを全部AIに置き換える

という話ではないと思っています。

むしろ、

Physics Simulation
        +
      GeoAI

の組み合わせが有効です。

例えば、

20260915_a07.png

という構成です。

AI側では、

  • 入力データ生成
  • パラメータ推定
  • 計算ケース選定
  • サロゲートモデル
  • 計算結果の分類
  • 異常箇所抽出

などを担当できます。

物理モデル側では、

  • 洪水
  • 河川不定流
  • 土石流
  • 泥流
  • 火砕流
  • 溶岩流
  • 火山降灰

などを計算します。

この構成なら、物理的な意味を維持したままAIを活用できます。

例えば河川シミュレーションなら

従来は、

20260917_a10.png

となります。

GeoAIを追加すると、

20260917_a06.png

という流れが考えられます。

つまり、

GeoAI → Simulation → GeoAI

です。

この構成は防災システムでかなり使いやすいと思います。

GeoAIとWebGIS

GeoAIはWebGISとも相性があります。

例えばユーザーが、

この範囲で浸水深1m以上、かつ避難所から500m以上離れている建物を抽出して

と自然言語で入力したとします。

LLMが直接答えを作るのではなく、

20260917_a07.png

と処理します。

この方式なら計算そのものはGISエンジンが行うため、LLMだけに計算を任せるより信頼性を上げやすくなります。

Agentic GeoAI

この考え方は今後かなり重要になると思っています。

20260915_a18.png

になります。

例えば、

この豪雨で危険になりそうな流域を調べて

と指示すると、

20260915_a17.png

までつなげます。

AIが「答えを生成する」のではなく、

GISやSimulation APIをオーケストレーションする

という設計です。

この考え方は、LLMを防災システムに入れる場合には特に重要だと思います。

AI-ready Geospatial Data

2026年のGeoAIを調べていて特に興味深かったのが、

AI-ready Geospatial Data

という考え方です。

OGCは2026年の技術文書で、AI-readinessを単なるデータ形式の問題ではなく、

Data Architectureの問題

として整理しています。

重要なのは、

AI
 ↓
Guess CRS
 ↓
Guess Unit
 ↓
Guess Meaning

という状態にしないことです。

例えばデータに、

dataset:
  title: rainfall
  crs: EPSG:6677
  unit: mm/h
  datetime: 2026-09-15T08:00
  source: JMA
  resolution: 250m

のような情報が明示されている必要があります。

つまりAIが、

  • この値は何なのか
  • 単位は何か
  • CRSは何か
  • いつのデータか
  • 誰が作ったか
  • 品質はどうか
  • 他のデータと組み合わせてよいか

を推測しなくてもよい構造にします。

これは、AI AgentがGISを操作する時代にはかなり重要になると思います。

参考:

STACも重要になる

GeoAIでは大量の衛星・ラスターデータを扱います。

そこで重要になるのが、

STAC（SpatioTemporal Asset Catalog）

です。

STACは、

どこに、いつの、どのような地理空間データが存在するか

を検索するための仕様です。

当初は衛星画像を中心にしていましたが、現在は、

  • SAR
  • LiDAR
  • DEM
  • Vector
  • Machine Learning Label
  • NDVI
  • Mosaic

なども扱えるようになっています。

GeoAI Agentから、

20260917_a09.png

のように利用できます。

参考:

GeoAIシステムの構成

OSSを中心にGeoAI基盤を作る場合、例えば次のような構成が考えられます。

20260915_a08.png

かなりOSSだけで構築できます。

想定する技術スタック

例えば次の構成です。

Layer Technology
WebGIS OpenLayers
API FastAPI
Async Job Celery
Queue Redis
Database PostgreSQL / PostGIS
Vector GeoParquet / FlatGeobuf
Raster COG / GeoZarr
Catalog STAC
GIS GeoPandas / GDAL / Rasterio
AI PyTorch
GeoAI TorchGeoなど
LLM Local LLM / API
Container Docker Compose

なぜAPI経由にした方がよいのか

GeoAI Agentを実装するとき、

AI
 ↓
Database

と直接接続するより、

AI
 ↓
API
 ↓
GIS Service
 ↓
Database

にした方が管理しやすくなります。

例えば、

GET /datasets
GET /layers
GET /features
POST /jobs
GET /jobs/{id}
GET /results/{id}

といったAPIを用意します。

さらに地理空間APIについては、

OGC API - Features

などに合わせる方法もあります。

例えば、

GET /collections
GET /collections/{collectionId}/items

です。

OGC API - FeaturesはREST / OpenAPIをベースにしたWeb向けの地理空間API標準です。

参考:

GeoAIで注意すべきこと

GeoAIは便利ですが、普通のAIとは違う注意点があります。

Spatial Leakage

これはかなり重要です。

例えば隣接するメッシュをランダムに、

Train
Test

へ分けるとします。

空間的に近い場所は特徴が似ているため、TestデータにTrainデータの情報が実質的に漏れてしまう場合があります。

結果として、

精度が異常に高い

という状態になります。

そのためGeoAIでは、

Spatial Cross Validation

を検討する必要があります。

Spatial Generalization

例えば、

神奈川県で学習
       ↓
北海道で予測

して、同じ精度になるとは限りません。

理由は、

  • 地質
  • 気候
  • 植生
  • 地形
  • 都市構造
  • 降雨特性

などが違うためです。

AIモデルの精度だけでなく、

どの地域まで適用できるのか

を評価する必要があります。

CRS

GISでは当然ですが、GeoAIでもCRSは重要です。

例えば、

EPSG:4326
EPSG:3857
日本の平面直角座標系

などがあります。

距離・面積を計算する場合、適切な座標系を使わないと結果に誤差が出ます。

AIの前処理だからといって無視できません。

解像度

例えば、

Sentinel-2   : 10m
DEM          : 5m
Aerial Photo : 1m
Rainfall     : 250m

のデータを使うとします。

これらを単純に重ねるだけではなく、

  • Resampling
  • Aggregation
  • Grid Alignment
  • Temporal Alignment

を考える必要があります。

Explainability

特に防災では、

Risk = 0.87

だけでは不十分です。

例えば、

Slope      +0.31
Rainfall   +0.27
Geology    +0.16
Past Event +0.09
Land Use   +0.04

のように、

なぜ危険と判定されたのか

を説明できることが重要です。

防災・インフラ分野では、

  • Explainability（説明可能性）
  • Provenance（データ・処理の来歴）
  • Reproducibility（再現性）
  • Auditability（監査可能性）

まで含めて設計する必要があります。

GeoAIは「地図を作るAI」から「GISを操作するAI」へ

GeoAIの発展を大きく分けると、次のように考えられます。

20260915_a16.png

第1世代

Satellite 
 ↓
CNN
 ↓
Land Cover

画像認識中心です。

第2世代

Satellite
+
DEM
+
GIS
 ↓
Geo Foundation Model
 ↓
Various Geospatial Tasks

Foundation Model中心です。

第3世代

User
「この地域の災害リスクを調べて」
        ↓
GeoAI Agent
        ↓
STAC Search
        ↓
Data Acquisition
        ↓
GIS Analysis
        ↓
Simulation
        ↓
GeoAI Analysis
        ↓
WebGIS
        ↓
Report

AI Agent中心です。

個人的には、今後ここがかなり面白くなると思っています。

WebGIS + Simulation + GeoAI

防災分野でシステムを作るなら、最終的には次の3本柱がかなり相性が良さそうです。

WebGIS + Simulation + GeoAI

例えば、

20260915_a09.png

このような構成です。

例えば、

この豪雨条件で危険な流域を抽出して

と入力すると、

20260915_a19.png

まで一連で処理できます。

実際にGeoAIを始めるなら

いきなりFoundation Modelを自作する必要はないと思います。

段階的に進める方が現実的です。
イメージはこんな感じです。

20260915_a10.png

Step 1 : GeoAI基盤

まずは、

Python
GeoPandas
Rasterio
PostGIS
FastAPI

を組み合わせます。

Step 2 : Machine Learning

次に、

Random Forest
XGBoost

などを使って、

  • 災害危険度
  • 土地利用
  • 地形分類

などを試します。

Step 3 : Deep Learning

Satellite
Aerial Photo
DEM

から、

  • 建物
  • 河川
  • 道路
  • 浸水域
  • 土砂災害域

などを抽出します。

Step 4 : Geo Foundation Model

Prithviなど既存のFoundation Modelを使います。

Existing Foundation Model
        ↓
Fine-tuning
        ↓
Own Application

とします。

最初から巨大モデルを学習する必要はありません。

Step 5 : GeoAI Agent

次に、

Natural Language
 ↓
LLM
 ↓
GIS Tools
 ↓
PostGIS / GeoPandas

へ進みます。

Step 6 : Simulation統合

最後に、

GeoAI
 ↓
Simulation
 ↓
GeoAI
 ↓
WebGIS

を構築します。

ここまで来ると、単なるGeoAIではなく、

GeoAI-based Disaster Intelligence Platform

のようなシステムになってきます。

最初に作るPoC案

個人的には、最初のPoCとして、

OpenLayers + FastAPI + PostGIS + GeoAIによる防災WebGIS

が面白いと思っています。

入力は、

20260915_a11.png

です。

これを、

20260915_a12.png

のように処理します。

最初はRandom ForestやXGBoostでも十分です。

そこから、

20260917_a08.png

へ拡張できます。

まとめ

GeoAIについて調べてみると、単純な、

GIS + Machine Learning

という言葉では収まらなくなってきています。

現在は、

20260915_a15.png

へ発展しています。

特に重要だと感じたのは、

AIが地図を作る

ことより、

AIが地理空間データを探し、意味を理解し、GISやSimulationを操作する

方向に進んでいることです。

そのため、これからGeoAIシステムを作る場合にはAIモデルだけを見るのではなく、

  • API
  • PostGIS
  • STAC
  • OGC API
  • Metadata
  • Provenance
  • CRS
  • Data Quality
  • Simulation

まで含めて設計することが重要になります。

最終的には、

20260917_a11.png

という構成が、防災・社会インフラ分野ではかなり面白いのではないかと思っています。

次からは実際に、

OpenLayers + FastAPI + PostGIS + GeoAI

で動く小さなPoCを作ってみたいと思います。

参考

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?