【第1回】防災DX・建設コンサル向け：Ollama × MCP × GISで「クローズドなネットワーク対応AI-GIS基盤」を作ってみる

Last updated at 2026-06-10Posted at 2026-06-10

【第1回】防災DX・建設コンサル向け：Ollama × MCP × GISで「クローズドなネットワーク対応AI-GIS基盤」を作ってみる

ローカルLLMでGIS処理を自動化する、実務向けAIエージェント構成

本記事は、Ollama、MCP、Python GISライブラリを使って、インターネットに接続しない環境でも動作する「ローカルAI-GIS解析基盤」を構築する連載の第1回です。

技術記事でありつつ、自治体、防災、建設コンサル、インフラ管理業務への提案資料としても使えるように構成しています。

第1回：OllamaでローカルLLMを動かす ← 本記事

第2回：GIS処理を行うMCP Serverを作る

第3回：Open WebUIからGIS MCP Serverへ接続する

第4回：土砂災害解析AIアシスタントへ拡張する

この記事で伝えたいこと

生成AIは文章作成やコード生成だけでなく、GIS業務にも大きな影響を与える可能性があります。

ただし、GIS分野では次のような制約があります。

業務データをクラウドAIへ送れない
クローズドなネットワークで運用している
地形データ、点群、GeoTIFFなどが大容量
QGISやArcGISの操作が属人化している
防災、砂防、河川、インフラ分野、災害対応で専門人材が不足している

このような現場では、単にChatGPTなどの生成AIを使うだけでは不十分です。

必要なのは、

外部にデータを出さずに
ローカル環境でLLMを動かし
GIS処理だけを安全にツール化し
自然言語から解析を実行できる仕組み

です。

そこで本連載では、

Ollama
+
MCP
+
Python GIS
+
Open WebUI

を組み合わせて、ローカルで動作するAI-GISエージェント基盤を作ります。

想定読者

この記事は、次のような方を想定しています。

想定読者

GIS業務にAIを導入したい方
防災DX、自治体DX、インフラDXに関わっている方
建設コンサル、測量、砂防、河川、道路分野の技術者
QGISやPython GISを業務で使っている方
クローズドなネットワークで生成AIを使いたい方
MCP Serverを実務用途で作ってみたい方
ローカルLLMの活用先を探している方

連載全体のゴール

最終的には、利用者が次のように自然言語で指示できる環境を目指します。

このGeoJSONの土砂災害警戒区域から500m以内にある避難所を抽出してください。

DEMから傾斜量を計算して、30度以上の斜面を抽出してください。

この流域ポリゴン内の平均標高と最大傾斜を集計してください。

土砂災害警戒区域、避難所、人口メッシュを重ねて、優先的に点検すべき地区を抽出してください。

このとき、LLMが直接GIS計算をするわけではありません。

LLMは指示を理解し、必要なGISツールを選び、MCP Server経由でPython GIS処理を実行します。

全体アーキテクチャ

本連載で作る構成は次の通りです。

全体構成イメージ図

ポイントは、AIとGIS処理を分離することです。

レイヤー	役割
Open WebUI	利用者がブラウザから操作する画面
Ollama	ローカルでLLMを実行する基盤
MCP Server	LLMから呼び出せるGISツール群
GeoPandas / Rasterio / GDAL	実際のGIS解析処理
PostGIS / ファイル	業務データの保存先

なぜ「GIS × AI」は仕事につながるのか

技術記事として面白いだけでは、仕事にはつながりません。

仕事につながる技術には、次の3つが必要です。

1. 現場に強い課題がある
2. 既存の解決策に限界がある
3. 提案できる具体的な実装がある

GIS × AIは、この3つを満たしやすい分野です。

1. 現場の問題点と課題がある

GIS業務では、以下のような課題がよくあります。

ベテラン技術者に処理ノウハウが集中している
定型処理が多いのに手作業が残っている
データ形式や座標系の違いで作業が止まる
新人がQGISやArcGISの操作を覚えるまで時間がかかる
Python GISを使える人材が限られる
報告書作成まで含めると作業負荷が高い

特に防災分野では、災害時に緊急で迅速な判断が必要です。

しかし、災害時ほど人手が足りません。

ここに、AIによる作業支援の価値があります。
そして、あくまでも支援としてのAIの利用です。

2. 既存の解決策に限界がある

既存のGISシステムは高機能ですが、操作には専門知識が必要です。

また、クラウドAIをそのまま使う場合、以下の課題があります。

機密データをアップロードできない
自治体やインフラ企業ではクラウド利用制限がある
大容量GeoTIFFや点群を毎回送信するのは現実的でない
外部API依存だと災害時やクローズドな環境で使いづらい
利用料が継続的に発生する

つまり、GIS業務では「高性能なクラウドAI」だけでは解決しにくい領域があります。

3. 提案できる具体的な実装がある

ここが重要です。

単に「AIでGISを便利にします」では弱いです。

仕事につなげるには、次のように言える必要があります。

1.クローズドなネットワーク内に
2.OllamaでローカルLLMを立て
3.MCP ServerでGIS処理をツール化し
4.Open WebUIから自然言語で操作できます。

これは、かなり具体的な提案になります。

従来のGIS業務フロー

従来のGIS業務は、次のような流れが多いです。

業務フローイメージ図

この中で、AIが支援できる部分は多くあります。

作業内容の整理
必要データの確認
処理手順の提案
Python処理の実行
結果の要約
報告書文案の作成

AI-GISエージェント導入後の業務フロー

AI-GISエージェントを導入すると、次のような流れになります。

AI-GIS業務フローのステップ

AIに完全自動で任せるのではなく、技術者が確認する前提にします。

この設計が、実務では非常に重要です。

「AIがGISをする」のではなく「AIがGISツールを使う」

ここは誤解されやすいポイントです。

LLMそのものに、面積計算や空間結合をさせるべきではありません。

なぜなら、LLMは確率的に文章を生成するモデルであり、厳密なGIS計算エンジンではないからです。

正しい考え方は次の通りです。

AIとGISツールの役割分担

AIは頭脳です。

GISライブラリは手足です。

この役割分担を守ることで、実務に耐える構成となります。

なぜMCPなのか

MCPは、AIアプリケーションと外部ツールやデータを接続するための標準仕様です。

従来は、AIに外部ツールを使わせるために、アプリケーションごとに独自の連携処理を書く必要がありました。

MCPを使うと、次のように整理できます。

GIS MCPサーバーのアーキテクチャ

MCP Server側でGIS機能を一度定義すれば、複数のMCP対応クライアントから呼び出せる可能性があります。

MCP ServerにするGIS処理の例

GIS処理は、MCP Toolとして定義しやすいものが多いです。

MCP Tool名	内容
`read_vector_info`	GeoJSONやShapefileの属性・CRS・件数確認
`reproject_vector`	座標系変換
`buffer_geometry`	バッファ作成
`clip_vector`	ポリゴンで切り抜き
`spatial_join`	空間結合
`calculate_area`	面積計算
`read_raster_info`	GeoTIFFの解像度・CRS確認
`clip_raster`	ラスタ切り抜き
`zonal_statistics`	ポリゴン単位でラスタ統計
`slope_from_dem`	DEMから傾斜量を計算
`landslide_risk_screening`	土砂災害リスクの簡易抽出

このように、GIS処理は明確な入力・出力を持つため、MCP Toolと相性が良いです。

防災DXでの利用イメージ

例えば、自治体の防災担当者が次のように依頼します。

この市内の土砂災害警戒区域と避難所データを重ねて、
警戒区域から500m以内の避難所を抽出してください。

AI-GISエージェントは、内部的には次のような処理を組み立てます。

土砂災害警戒区域と避難所の重ね合わせ解析フロー

利用者はGIS操作を知らなくても、結果を得られます。

ただし、最終確認はGIS技術者が行います。

建設コンサルでの利用イメージ

建設コンサルでは、次のような業務に応用できます。

砂防基礎調査
道路防災点検
河川流域解析
斜面抽出
災害履歴と地形条件の重ね合わせ
点検優先度の一次スクリーニング

例えば、

DEMから傾斜量を計算し、30度以上かつ集水面積が大きい斜面を抽出してください。

という依頼を、MCP Toolの組み合わせに変換します。

DEM解析フローと危険斜面抽出

このような処理は、完全な判定ではなく「一次スクリーニング」として使うのが現実的です。

インフラ管理での利用イメージ

道路、鉄道、電力、通信などのインフラ分野でも応用できます。

設備位置と土砂災害警戒区域を重ねて、影響を受ける可能性がある設備を一覧化してください。

設備点検フロー図解

こうした処理は、防災計画、保守点検、BCP検討に活用できます。

なぜローカルLLMなのか

クラウドAIは非常に便利です。

しかし、GIS業務ではローカルLLMが有利な場面があります。

観点	クラウドAI	ローカルLLM
初期導入	簡単	やや難しい
モデル性能	高い	モデル次第
データ外部送信	発生しやすい	抑制しやすい
クローズドなネットワーク	不向き	向いている
大容量GISデータ	転送が課題	ローカル参照しやすい
ランニングコスト	API課金	ハードウェア中心
カスタマイズ	制限あり	自由度が高い

特に、次のようなデータを扱う場合はローカル構成が有力です。

施設台帳
避難所情報
災害対応計画
設備位置情報
測量成果
航空レーザー測量データ
GeoTIFF
DEM
点群
非公開の地形・地質データ
個人情報

クローズドなネットワーク構成

自治体やインフラ企業では、次のようなクローズドな構成が想定されます。

クローズドなネットワークのAI-GIS構成図

重要なのは、LLMとGISデータの両方を内部に置くことです。

これにより、外部送信を前提としないAI活用が可能になります。

Ollamaを採用する理由

ローカルLLM実行環境には複数の選択肢があります。

Ollama
llama.cpp
LM Studio
vLLM
Text Generation Inference

本連載では、まずOllamaを使います。

理由はシンプルです。

インストールが簡単
モデル管理が簡単
REST APIが使える
Dockerイメージもある
ローカル検証から始めやすい
Open WebUIとの組み合わせが一般的

Ollamaは公式にREST APIを持っており、ローカルの localhost:11434 でモデルを操作できます。

Open WebUIを採用する理由

Open WebUIは、ブラウザからローカルLLMを扱うためのUIとして使いやすい選択肢です。

さらに、Open WebUIはMCP連携にも対応してきています。

本連載では、最終的に次の構成を想定します。

ブラウザから使うローカルAI-GIS構成

これにより、GISを知らない利用者でも、チャット画面から処理を依頼できるようになります。

Dockerを採用する理由

GIS処理環境をPythonだけで作ると、環境構築でつまずきやすいです。

特に次のライブラリは依存関係が複雑です。

GDAL
PROJ
GEOS
Fiona
Rasterio
GeoPandas
Shapely
pyproj

ローカルPCに直接入れると、OSやPythonバージョンによってエラーが出ることがあります。

そのため、GIS MCP ServerはDockerで切り出すのが現実的です。

DockerベースのGIS MCPサーバー構成

Docker化することで、次のメリットがあります。

開発環境を再現しやすい
他のPCへ配布しやすい
ライブラリ依存を固定しやすい
本番環境へ移行しやすい
クローズドなネットワークでもコンテナ配布しやすい

GPUは必要か

最初の検証において、GPUは必須ではありません。

ただし、実務利用ではGPUがあると快適です。

環境	目安
CPUのみ	小さめのモデルで検証可能
RAM 16GB	7B〜8Bモデルの検証向け
RAM 32GB	複数サービスを同時起動しやすい
NVIDIA RTX 4060以上	ローカルLLMがかなり扱いやすい
NVIDIA RTX 4070以上	8B〜14Bクラスを試しやすい
AMD Radeon	ROCm等の対応状況に注意

GIS処理そのものはCPUで十分な場合も多いです。

重くなりやすいのは、LLMの推論、点群処理、大規模ラスタ処理です。

推奨する段階的導入

いきなり本番導入を目指すのではなく、段階的に進めるのがおすすめです。

ローカルAI-GIS導入ロードマップ

本記事はPhase 1です。

Chapter1：OllamaでローカルLLMを動かす

ここから実装に入ります。

今回のゴールは次の4つです。

Ollamaをインストールする
ローカルLLMモデルを取得する
チャットで動作確認する
API経由で呼び出せることを確認する

1. Ollamaをインストールする

Windowsの場合

PowerShellで以下を実行します。

winget install Ollama.Ollama

インストール後、確認します。

ollama --version

Linux / Ubuntuの場合

curl -fsSL https://ollama.com/install.sh | sh

確認します。

ollama --version

サービス状態を確認します。

systemctl status ollama

macOSの場合

公式サイトからインストーラを取得するか、以下を実行します。

curl -fsSL https://ollama.com/install.sh | sh

2. モデルを取得する

まずは扱いやすい8Bクラスから始めます。

ollama pull llama3.1:8b

日本語応答を重視する場合は、Qwen系も候補になります。

ollama pull qwen2.5:7b

軽量検証なら、より小さいモデルも選択肢です。

ollama pull phi3:mini

取得済みモデルを確認します。

ollama list

3. モデルを起動する

ollama run llama3.1:8b

次のように聞いてみます。

GISとは何ですか？防災分野での使い方も含めて説明してください。

応答が返れば成功です。

終了する場合は以下です。

/bye

4. APIとして動作確認する

OllamaはAPI経由でも呼び出せます。

curl http://localhost:11434/api/tags

モデル一覧のJSONが返ればOKです。

次に、チャットAPIを試します。

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1:8b",
  "messages": [
    {
      "role": "user",
      "content": "GISと防災DXの関係を短く説明してください。"
    }
  ],
  "stream": false
}'

5. PythonからOllamaを呼び出す

後でMCP Serverや周辺ツールと連携しやすくするため、Pythonからも確認します。

作業ディレクトリを作ります。

mkdir local-ai-gis
cd local-ai-gis
python -m venv .venv

Windowsの場合。

.venv\Scripts\activate

Linux / macOSの場合。

source .venv/bin/activate

必要パッケージを入れます。

pip install requests

テストコードを作成します。

# test_ollama.py
import requests

url = "http://localhost:11434/api/chat"

payload = {
    "model": "llama3.1:8b",
    "messages": [
        {
            "role": "user",
            "content": "土砂災害解析でGISを使う理由を、技術者向けに説明してください。"
        }
    ],
    "stream": False
}

response = requests.post(url, json=payload, timeout=120)
response.raise_for_status()

data = response.json()
print(data["message"]["content"])

実行します。

python test_ollama.py

応答が返れば、PythonからOllamaを呼び出せています。

Chapter1の到達点

ここまでで、以下ができました。

PythonからローカルLLMへのリクエスト

まだGIS MCP Serverは作っていません。

しかし、ローカルLLMの土台は完成しました。

次回作るGIS MCP Serverのイメージ

次回は、次のようなPython MCP Serverを作ります。

GIS MCPサーバーとツール構成

MCP Toolの最小例は次のようなイメージです。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("GIS MCP Server")

@mcp.tool()
def read_vector_info(path: str) -> dict:
    \"\"\"ベクタファイルの基本情報を返す\"\"\"
    import geopandas as gpd

    gdf = gpd.read_file(path)

    return {
        "path": path,
        "crs": str(gdf.crs),
        "feature_count": len(gdf),
        "columns": list(gdf.columns),
        "geometry_type": gdf.geom_type.unique().tolist()
    }

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

これを発展させて、GeoPandasやRasterioを呼び出せるようにします。

セキュリティ設計の考え方

MCP Serverは非常に便利ですが、何でも実行できるようにすると危険です。

特にGIS MCP Serverでは、次のような対策が必要です。

1. 読み書き可能なディレクトリを制限する

/data/input
/data/output

のように、MCP Serverが触れる場所を限定します。

2. 任意コード実行をさせない

ユーザーが入力したPythonコードをそのまま実行する設計は避けます。

悪い例。

ユーザー入力 → eval() → 実行

良い例。

ユーザー入力 → 定義済みMCP Tool → 引数検証 → 実行

3. 処理ログを残す

誰が、いつ、どのデータに、どの処理をしたかを記録します。

timestamp
user
tool_name
input_path
output_path
parameters

4. 出力結果を人間が確認する

必ず技術者が確認
AIが出した結果をそのまま正式成果にしないことが重要です。

AI-GISは補助ツールです。

技術者の確認を前提にします。

今回のまとめ

本記事では、実装に入る前に、ローカルAI-GIS基盤の意味を整理しました。

ポイントは以下です。

Cahpter1 まとめ

GIS業務はAIエージェント化と相性が良い
ただしLLMにGIS計算をさせるのではない
LLMは指示理解、処理計画、結果説明を担当する
GIS処理はGeoPandas、Rasterio、GDALなどGISツールに任せる
MCPによりAIからGISツールを標準的に呼び出せる
OllamaによりローカルLLMを簡単に動かせる
Open WebUIによりブラウザUIを提供できる
DockerによりGIS処理環境を再現しやすくできる
クローズドなネットワーク対応は自治体・防災・インフラ分野で価値が高い

次回予告

次回は、いよいよGIS MCP Serverを作ります。

内容は以下を予定しています。

GIS MCP Server

DockerでPython GIS環境を作る
GeoPandas / Rasterio / GDALを導入する
MCP Python SDKでGIS MCP Serverを作る
read_vector_info Toolを実装する
buffer_geometry Toolを実装する
MCP Inspectorで動作確認する
Open WebUI接続に向けた準備をする

参考リンク

Ollama公式サイト
https://ollama.com/
Ollama GitHub
https://github.com/ollama/ollama
MCP Python SDK
https://github.com/modelcontextprotocol/python-sdk
OpenAI Apps SDK: MCP Server
https://developers.openai.com/apps-sdk/concepts/mcp-server
Open WebUI MCP Documentation
https://docs.openwebui.com/features/extensibility/mcp/

最後に

生成AIの本当の価値は、単に文章を生成することではなく、現場の業務ツールと接続して作業を支援することにあります。

GIS分野では、まだAIエージェント活用の事例が多いとは言えません。

だからこそ、今から取り組む価値があります。

特に、防災DX、自治体DX、建設コンサル、インフラ維持管理の領域では、

クローズドなネットワークで動く
業務データを外に出さない
GIS処理を自然言語で扱える
AI-GIS基盤

は、今後重要な選択肢になると考えています。

次回は、この考え方を実装に落とし込みます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up