GeoAIはLLMに置き換わったのか？―地理空間モデル・言語理解・GISエージェント・MCPを整理する

はじめに

GeoAIという言葉から、何を思い浮かべるでしょうか。

航空写真からの建物検出、衛星画像のセグメンテーション、土地被覆分類、交通量予測。こうした「地理空間データから何かを認識・予測するモデル」を思い浮かべる方は多いと思います。

一方、LLMの登場後は、自然言語で地理空間データを検索する、GISのコードを生成する、外部ツールを呼び出して分析するといった話題も目立つようになりました。MCPを介してGISを操作する仕組みも、この文脈で語られます。

これらをすべてGeoAIと呼ぶと、地理空間情報を学習するモデルの話と、そのモデルやGISを使う仕組みの話が混ざります。

TL;DR

• GeoAIを「認識・予測」「言語との対応付け」「計画・操作」「接続」の四つの役割から整理します。
• LLMによるGIS操作と、地理空間モデルによる認識・予測は、異なる役割として組み合わされます。
• 「GeoAIを使った」の先に、誰が計算し、何を根拠に品質を確かめたかを示すことが重要です。

この分類は、既存研究を理解するための本記事独自の整理です。標準化された分類や固定的な階層ではなく、一つのモデルやシステムが複数の役割を持つこともあります。資料の確認日は2026年11月3日です。

1. GeoAIは、もともと画像認識だけを指す言葉ではない

最初に、歴史の見方を少し補正しておきます。

JanowiczらのGeoAIに関する論考では、画像分類や地物検出だけでなく、自然言語による検索・質問応答、知識の統合なども対象に含まれています。また、空間をモデルの表現や定式化に取り入れる「spatially explicit」なモデルが論点になっています。Janowicz et al., 2020

したがって、「昔のGeoAIは画像認識だけで、LLMによって初めて言語を扱うようになった」という区切り方は正確ではありません。地名の曖昧性解消や地理的な質問応答は、LLM以前からの研究対象です。

本記事ではGeoAIを、地理空間情報の表現・認識・予測・推論や、それらを用いた知識獲得・処理をAIで支える広い領域として扱います。

そのうえで、近年の変化を「対象の完全な交代」と見るよりも、汎用的な言語モデルを入口にして、データ・モデル・処理系を組み合わせる構成が加わったと捉えます。

ただし、「モデル研究の議論が薄くなった」という印象と、実際の研究活動の減少は別です。本記事は論文数や投稿内容の時系列分析を行っていないため、分野全体の研究比重がどう変化したかまでは断定しません。

2. 四つの役割を分けて見る

観点	中心となる問い	入力と出力の例	主な実装要素
認識・予測	そこに何があるか、何が起きるか	衛星画像 → 浸水域マスク	分類器、CNN、Transformer、GNN、地理空間基盤モデル
言語との対応付け	言葉がどの場所・対象・条件を指すか	「港湾の画像」→ 候補画像、画像 → 説明	地名解決、画像・テキスト埋め込み、VLM、LLM
計画・操作	目的の結果を得るには何を実行するか	要求 → 検索・推論・空間演算の手順	LLMエージェント、コード生成、ツール選択
接続	どの機能を、どの形式で呼べるか	ツール呼び出し → データ・処理結果	MCP、API、SDK、各種アダプター

ここでいうVLMはVision-Language Model、画像と言語を扱うモデルです。画像と文章を同じ空間に埋め込むモデルも、文章を生成するモデルもあり、すべてが対話型LLMというわけではありません。

また、GISのバッファ、空間結合、座標変換などは、それ自体に学習モデルを必要としません。AIがそれらを呼び出すことと、空間演算そのものがAIになることは区別できます。

図1：LLMを入口とする構成例。矢印は主な処理・情報の流れを表す。 接続部分には複数の選択肢があり、MCPが必須という意味ではありません。また、認識モデルを直接実行する従来の構成も引き続き成立します。

この図で大切なのは、LLMの下に「学習モデル」「空間演算」「データ」が並んでいることです。それぞれが異なる根拠で結果を作ります。

3. 認識・予測：地理空間モデルが学ぶもの

3.1 地物検出や分類の基本形

地理空間モデルの推論を、概念的に次のように表します。

\hat{Y}=f_\theta(X,C)

• X：画像、点群、道路ネットワーク、観測時系列などの入力。
• C：位置、時刻、近傍関係、センサー情報など、モデルが利用する文脈。
• θ：学習されたパラメーター。
• Ŷ：分類結果、検出対象、予測値など。

セグメンテーションなら出力は画素単位のクラス、地物検出なら矩形やポリゴン、交通予測なら道路リンクごとの将来値です。すべてのモデルが明示的な座標や時刻を入力に取るわけではなく、上式はそれらを利用する場合も含めた一般形です。

教師あり学習の基本形は、正解との差を小さくするパラメーターを探すことです。

\theta^*
=\operatorname*{arg\,min}_{\theta}
\frac{1}{N}\sum_{i=1}^{N}
\mathcal{L}\left(f_\theta(X_i,C_i),Y_i\right)

ここで、Nは学習例の数、Yは正解、Lは損失関数です。

この領域で問われるのは、どんな特徴を学習するか、別の地域でも通用するか、季節やセンサーが変わっても使えるか、といった問題です。利用者が自然言語で指示するようになっても、これらの問いは残ります。

3.2 「地図に表示できる」ことと「空間をモデル化する」こと

例えば、市区町村ごとの属性を通常の表形式モデルに与える方法と、隣接関係をGNNに与える方法では、空間の取り込み方が異なります。

地理空間モデルを評価するときには、少なくとも次を確認したいところです。

• 位置や近傍は、モデルのどこに入っているか。
• 空間解像度や対象範囲を変えると、予測はどう変わるか。
• 時系列や道路の接続関係などを、どう表現しているか。
• 学習地域から離れた場所で、性能を維持できるか。

「GeoAIを使った」という説明だけでは、これらは分かりません。地理空間データに汎用モデルを適用したのか、空間構造を取り入れたモデルなのかを記述すると、技術的な中身が伝わります。

3.3 基盤モデルの進展も、この論点の延長にある

地理空間モデルの研究がLLMだけになったわけではありません。

例えば、Prithvi-EO-2.0は、地球観測の時系列データから事前学習し、複数の下流タスクへの適用を扱う地理空間基盤モデルです。TerraMindは、複数の地理空間モダリティを扱う生成的な基盤モデルを提案しています。Prithvi-EO-2.0、TerraMind

これらは「GISの操作方法を文章で考える」という役割とは異なり、観測データの表現や、タスク間・モダリティ間の転用を扱っています。

なお、基盤モデルはLLMの同義語ではありません。 大規模な事前学習と下流タスクへの適用という観点から、画像や地球観測データを対象とする基盤モデルもあります。

4. 言語との対応付け：「言葉を扱う」をさらに分解する

「言語と地理空間情報の相互変換」という表現には、異なる問題が含まれます。

問題	例	必要になる根拠
地名・場所の対応付け	「府中市」がどの自治体か決める	地名辞書、行政区域、会話の文脈
画像と言葉の対応付け	「港湾」に近い衛星画像を探す	画像と文章の表現、検索対象の画像
対象領域への対応付け	「中央の大きな建物」がどれか示す	画像中の位置・領域との対応
自然言語から処理条件への変換	「駅から500m以内」を条件化する	距離の定義、座標系、対象レイヤー
分析結果の言語化	集計表から地域差を説明する	実際の計算結果、単位、出典

これらは可逆な変換とは限りません。説明文から元の画像や正確な形状を復元できるとは限らず、「近く」という言葉から距離のしきい値が一意に決まるわけでもありません。

4.1 画像・テキストの共通表現と、文章生成の違い

画像と言語を対応付ける一つの方法は、両者をベクトルに変換して類似度を比較することです。

z_I=e_I(I),\qquad z_T=e_T(T),\qquad
s(I,T)=\frac{z_I^\top z_T}{\lVert z_I\rVert\lVert z_T\rVert}

Iは画像、Tはテキスト、eはそれぞれのエンコーダー、zは埋め込みベクトルです。類似度sを使えば、文章をクエリーとする画像検索や、候補ラベルとの比較ができます。

リモートセンシング画像と言語を対応付ける例にRemoteCLIPがあります。一方、GeoChatは、リモートセンシング画像を対象とする対話や、画像中の領域と言葉の対応を扱う大規模視覚言語モデルです。RemoteCLIP、GeoChat

同じ「画像と言語を扱うモデル」でも、検索のための表現学習と、回答文や対象位置の生成では、出力と評価方法が異なります。

4.2 「説明できる」「認識できる」「測定できる」を分ける

画像を見て「住宅地が広がっています」と説明できても、すべての建物を正確に抽出できるとは限りません。また、建物を抽出できても、実世界の面積を正しく求めるには地理参照や座標系の処理が必要です。

特に、画像中の画素座標と地球上の座標は区別する必要があります。画像内の矩形を出力しただけでは、緯度経度や地図上のポリゴンを得たことにはなりません。

言語の流暢さ、画像認識の精度、幾何計算の正確さは、それぞれ確認するべき能力です。

5. 計画・操作：GISを使うLLMは何を担うのか

次の要求を考えます。

対象市の駅から500m以内にある建物を抽出し、建物面積の合計を地図と表で示してください。

LLMを用いるシステムは、これを「データの特定」「距離条件の設定」「空間演算」「面積集計」「出力」といった手順に分けられます。

LLMの行動選択を、概念的に次のように書けます。

a_t \sim \pi_\phi\left(\,\cdot\mid q,h_t,\mathcal{T}\right),
\qquad o_{t+1}=\operatorname{Execute}(a_t,D)

• q：利用者の要求。
• h_t：時点tまでの実行履歴や観測結果。
• T：利用可能なツール群。
• πφ：LLMなどによる行動選択の方策。
• a_t：ツール名と引数、または生成するコードなど。
• D：対象データ。
• o：実行結果やエラーなどの観測。

前節のモデルが「データから対象を推定する」のに対し、ここでは「次にどの処理を実行するか」を選びます。実際の距離計算や空間結合は、外部のGISエンジンが担当できます。

この分担には理由があります。LLMが座標列や処理コードを生成しただけでは、多角形の自己交差がないことや、要求どおりの幾何計算が行われたことは保証されません。 そこで、交差判定や面積計算は専用のGISエンジンで実行し、形状の妥当性も検証します。例えばPostGISのST_IsValidは、個々の形状がOGCの規則に従って有効かを検査できます。PostGIS：ST_IsValid

ただし、GISエンジンにも数値精度の限界があります。GEOSも有限精度の浮動小数点演算を用いるため、専用エンジンの使用と、結果の検証はセットで考える必要があります。GEOS公式FAQ

自然言語からQGISを操作する研究例としてGIS Copilotがあります。これはLLMによるツール選択やコード生成などを用いて空間分析を支援するもので、複雑なタスクの完全自律化には課題があることも報告されています。GIS Copilot

重要なのは、LLMの応答だけから、処理が実行されたとは判断できないことです。生成コード、呼び出し履歴、実行ログ、成果物まで確認して初めて、システムの処理を評価できます。

また、先ほどの要求にも未確定の条件があります。

• 500mは直線距離か、道路に沿った徒歩距離か。
• 建物は中心点が範囲内なら採用するのか、一部が交差すれば採用するのか。
• 面積は採用した建物全体か、500m圏内に入る部分だけか。
• 複数の駅の圏域が重なるとき、同じ建物を重複集計するのか。

これらを明示することも計画の一部です。APIが正常終了していても、条件の解釈が違えば、要求に合う結果にはなりません。

6. 接続：MCPはGeoAIモデルの一種なのか

MCPはModel Context Protocolの略で、AIアプリケーションと外部の機能・情報を接続するプロトコルです。基本構成にはホスト、クライアント、サーバーがあり、サーバーはツールやリソース、プロンプトなどを提供します。MCP公式アーキテクチャ

GISで使う場合は、次のような構成が考えられます。

図2：MCPを用いた呼び出し例。 ツール探索は接続時などに行われ、すべての呼び出しの前に繰り返す必要はありません。

MCPサーバーの内部では、既存API、QGISの処理機能、データベース、ローカルの推論コードなどを呼び出せます。必ずしも「MCPの先にWeb APIがある」とは限りません。

したがって、各要素の関係は次のようになります。

要素	担当すること	それだけでは保証しないこと
地理空間モデル	画像などからの認識・予測	GISワークフロー全体の成立
LLMエージェント	要求の解釈、処理計画、呼び出しの選択	正しいデータ・条件・計算結果
GISエンジン	指定条件による空間演算	利用者の意図と条件の一致
MCP	機能の発見や呼び出し、情報交換	地理的意味や分析結果の妥当性

MCPを導入しても、モデルの認識精度やGISの計算精度が直接向上するわけではありません。 また、MCPを使わず、APIやSDKを直接呼び出して同様の処理を組むこともできます。

「MCPによるGeoAI」という紹介では、MCP経由で何を使えるようにしたのかまで説明すると、技術的位置づけが明確になります。

7. 具体例：浸水建物の把握では、すべての役割が必要になる

次のようなシステムを仮定します。ここからの処理例は、本記事の説明用の設計であり、特定製品の機能や実証結果ではありません。

指定日の衛星画像から浸水候補域を抽出し、その範囲にかかる建物を自治体別に集計して、根拠付きで説明する。

図3：認識モデルとGISとLLMを組み合わせる例。 図は主要な順序を示しており、実装では各工程で検証し、必要に応じて前の工程に戻ります。

建物をb_i、推定した浸水候補域をF̂、建物iに割り当てた自治体をm_iとします。候補域と交差する建物を自治体ごとに数えるなら、次の式になります。

\hat{N}_k=\sum_i
\mathbf{1}\left[m_i=k\right]
\mathbf{1}\left[b_i\cap\hat{F}\ne\varnothing\right]

1[条件]は、条件が成り立つとき1、それ以外は0になる指示関数です。自治体をまたぐ建物は、事前に定めた代表点などのルールで、一つの自治体に割り当てるとします。

この処理では、役割を次のように追跡できます。

処理	主な担当	結果の根拠
「指定日」「対象地域」の解釈	言語処理・LLM	要求と確定した条件
データの検索・取得	カタログ・データ取得系	出典、時点、範囲、解像度
浸水候補域の推定	地理空間モデル	入力画像、モデル、しきい値
建物との交差・自治体別集計	GISエンジン	形状、座標系、演算と集計条件
処理順序の選択・再実行	LLMエージェントなど	呼び出し履歴、エラーと修正
結果の説明	LLMなど	実際の成果物と検証結果

ここで、交差判定の正しさと、入力される境界の確かさは別の問題です。モデルが画素ごとの浸水確率を出力する場合、二値化のしきい値によって候補域の境界が変わります。一方、建物のフットプリント（平面形状）には、位置や輪郭の誤差があります。境界付近の建物では、しきい値の変更やわずかな位置ずれだけでも、交差の有無が切り替わり、集計件数が変わり得ます。

つまり、この集計は、浸水域の推定に由来する不確実性と、建物形状の精度に由来する不確実性の双方に影響されます。 交差演算自体が、それらを解消するわけではありません。例えば、しきい値を変えたときに件数がどれほど変わるかを調べれば、集計結果の感度を確認できます。

そのため、説明では**「推定浸水候補域と交差する建物数」**と、実際に計算した対象を示します。建物データの更新時点も含め、結果の品質は、認識モデル・入力データ・空間演算・説明を通じて確かめる必要があります。

8. 評価も、役割ごとに分ける

8.1 モデルの精度と、システムの成功率は別の指標

評価対象	指標・確認項目の例
認識・予測	IoU、F1、検出のAP、予測値のMAE、地域・時期別の性能
言語との対応付け	地名解決の正答率、検索のRecall@K、領域対応の精度
計画・操作	ツールと引数の妥当性、要求充足率、タスク完了率、実行時間・費用
接続	スキーマへの適合、呼び出し成功率、エラーの扱い
成果物全体	データ時点・座標系・単位の整合、再現性、説明と成果物の一致

浸水域のセグメンテーションなら、予測領域F̂と正解領域Fの重なりをIoUで測れます。

\operatorname{IoU}(\hat{F},F)
=\frac{\mu(\hat{F}\cap F)}{\mu(\hat{F}\cup F)}

μは面積、または同一グリッド上の画素数を表します。これは領域推定の評価であり、「対象日のデータを選べたか」「自治体別に正しく集計したか」までは測りません。

8.2 空間的な汎化を評価する

近接する地点や隣り合う画像タイルは、互いに似ていることがあります。そのため、無作為に学習用・評価用へ分割した結果だけでは、未知地域への適用能力を適切に評価できない場合があります。構造を持つデータに対する交差検証の問題は、LLM以前から議論されています。Roberts et al., 2017

ただし、常に空間ブロック分割が唯一の正解という意味ではありません。近隣の未観測地点を補間したいのか、遠方の地域や将来時点に転用したいのかによって、評価の設計は変わります。

LLMに自然言語の入口を付けても、この検証が不要になるわけではありません。

8.3 各工程の成功率を足し合わせない

説明のため、成功に必要な工程を次の四つにまとめます。

• A：適切なデータを選択した。
• B：所定の基準を満たす認識結果を得た。
• C：要求に合う空間演算・集計を実行した。
• D：成果物に忠実な説明を返した。

すべてが必要なら、システム全体の成功確率は連鎖律により次のように表せます。

P(S)=P(A)P(B\mid A)P(C\mid A,B)P(D\mid A,B,C)

これは独立性を仮定した式ではありません。仮に各条件付き確率がすべて0.95なら、全体は約0.81になります。あくまで説明用の数値であり、実システムの性能を表すものではありません。

この式が示すのは、モデル単体の高精度やツールの正常終了だけでは、全体の成功を保証できないということです。失敗したときに、データ・認識・操作・説明のどこで問題が起きたか分かる評価が必要です。

9. 「GeoAIを使った」を、もう一段階具体的に説明する

記事やシステム紹介では、GeoAIという大きな言葉に、実際の役割を添えると議論しやすくなります。

やや抽象的な説明	役割が伝わる説明
GeoAIで建物を抽出した	航空写真に建物セグメンテーションモデルを適用した
GeoAIで衛星画像を検索した	衛星画像と文章の埋め込みを比較し、自然言語で画像検索した
GeoAIが面積を計算した	LLMが処理条件を作り、GISエンジンで面積を計算した
MCPで地理空間推論した	MCP経由で、空間結合ツールと認識モデルを呼び出した

また、システムを理解するときには、次の問いが役立ちます。

1. 学習しているのは何か。 観測データの特徴、言葉との対応、処理手順のどれか。
2. 空間計算を実行するのは誰か。 モデル自身か、外部GISか。
3. 結果の根拠は何か。 モデル出力、観測データ、データベースの照会結果、実行済みの計算結果か。
4. 何を成功として測ったか。 認識精度、呼び出しの成功、要求を満たす成果物の完成のどれか。

この四点を明示すれば、地理空間モデルの研究と、LLMを使ったシステム構築の貢献を、それぞれ評価できます。

おわりに

GeoAIには、地理空間情報を認識・予測するモデルと、言語を介した情報の対応付け、処理計画、外部システムとの接続が共存しています。

LLMを中心とする構成が増えると、利用者から見える入口は自然言語になります。その背後にある認識モデルや空間演算は、画面上では見えにくくなります。これが、モデルそのものの議論が薄くなったと感じる一因ではないか、というのが本記事の見方です。

しかし、入口が変わっても、別の地域で通用する認識モデル、正しい空間演算、適切なデータ選択の必要性は変わりません。

GeoAIを議論するときには、「何を認識するモデルか」「何を言語と結びつけるか」「誰が計画し、誰が計算するか」「何を介して接続するか」を分けて書く。 その整理が、地理空間モデルの技術的な議論を続けながら、LLMによる新しい利用方法も評価するための出発点になります。

参考文献

本文では研究の位置づけに必要な範囲を紹介しています。個々のモデルの優劣を比較するサーベイではありません。年は下記のように掲載年または初回公開年を示しており、arXivのリンク先には改訂版が含まれます。

1. Janowicz, K. et al.（2020年掲載、2019年オンライン公開）. GeoAI: spatially explicit artificial intelligence techniques for geographic knowledge discovery and beyond. International Journal of Geographical Information Science. 著者所属機関で公開された本文.
2. Szwarcman, D. et al.（2024年初回公開）. Prithvi-EO-2.0: A Versatile Multi-Temporal Foundation Model for Earth Observation Applications.
3. Jakubik, J. et al.（2025年初回公開）. TerraMind: Large-Scale Generative Multimodality for Earth Observation.
4. Liu, F. et al.（2023年初回公開）. RemoteCLIP: A Vision Language Foundation Model for Remote Sensing.
5. Kuckreja, K. et al.（2023年初回公開）. GeoChat: Grounded Large Vision-Language Model for Remote Sensing.
6. Akinboyewa, T. et al.（2024年初回公開）. GIS Copilot: Towards an Autonomous GIS Agent for Spatial Analysis.
7. Model Context Protocol. Architecture overview（2026-07-28版）.
8. Roberts, D. R. et al.（2017）. Cross-validation strategies for data with temporal, spatial, hierarchical, or phylogenetic structure. Ecography. 共著者の文献ページ.
9. PostGIS. ST_IsValid：形状の妥当性検査.
10. GEOS. FAQ：空間モデルと数値計算の頑健性.