【第3回】防災DX・建設コンサル向け：Ollama × MCP × GISで「GIS MCP Server」を作ってみる

Posted at 2026-06-20

【第3回】防災DX・建設コンサル向け：Ollama × MCP × GISで「GIS MCP Server」を作ってみる

ブラウザから自然言語でGIS処理を呼び出す、クローズドなネットワーク対応AI-GIS基盤

本記事は「ローカルLLM × MCP × GIS」によるAI-GIS基盤構築シリーズの第3回です。

第1回：OllamaでローカルLLMを動かす

第2回：DockerでGIS MCP Serverを作る

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

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

今回は、利用者がブラウザから自然言語でGIS処理を依頼できる状態を作ります。

この記事で作るもの

第1回ではOllamaを使ってローカルLLMを動かしました。

第2回ではGeoPandas、Rasterio、GDALを利用するGIS MCP ServerをDocker上に作りました。

第3回では、その2つをOpen WebUIから使えるようにします。

完成形は以下です。

ローカルAI-GISシステム構成図

利用者はブラウザでOpen WebUIを開き、次のように依頼します。

土砂災害警戒区域から500m以内にある避難所を抽出してください。
結果はCSVとGeoJSONで出力してください。

Open WebUIはOllamaに会話・推論を任せます。

GIS処理が必要になったら、Open WebUIからGIS MCP Serverを呼び出します。

GIS MCP ServerはGeoPandasやRasterioで処理し、結果ファイルと説明を返します。

なぜOpen WebUIを使うのか

ローカルLLMを業務利用する場合、コマンドラインだけでは利用者に広がりません。

現場で使うには、次のような要件があります。

ブラウザから使える
利用者が自然言語で依頼できる
管理者がモデルや接続先を管理できる
複数ユーザーで使える
ローカルLLMと接続できる
外部ツールを呼び出せる
ネットワークでも運用しやすい

Open WebUIは、これらを満たしやすいUIです。

公式ドキュメントでも、Open WebUIはOllamaやOpenAI互換APIに対応し、完全オフラインで動作できるセルフホスト型AIプラットフォームとして説明されています。

参考：

Chapter3の位置づけ

第1回・第2回・第3回の関係は以下です。

ローカルAI-GIS連載ロードマップ

第1回と第2回は、部品を作る回でした。

第3回は、それらをつないで利用者が使える形にする回です。

ブラウザから自然言語でGIS解析を依頼できます。
データはローカルまたはクローズドなネットワーク内で処理されます。

この説明ができるようになることが、Chapter3の価値です。

今回のゴール

今回のゴールは以下です。

【第3回】のゴール

Open WebUIをDockerで起動する
Open WebUIからOllamaへ接続する
Open WebUIからGIS MCP Serverへ接続する
チャット画面からGIS Toolを有効化する
自然言語でGIS処理を呼び出す
業務PoCとして見せられる構成にする
クローズドなネットワーク導入時の注意点を整理する

想定する構成

今回は、以下の3コンポーネントを同じDockerネットワーク上で動かす構成を基本にします。

ローカルAI-GISシステム構成図

業務利用では、最初から大規模構成にしない方がよいです。

まずは1台の検証PCまたは小さなオンプレサーバーでPoCを作ります。

Open WebUIのMCP対応について

Open WebUIは、v0.6.31以降でMCPをネイティブにサポートしています。

公式ドキュメントでは、MCP Serverは管理者が Admin Settings → External Tools から追加し、Typeに MCP (Streamable HTTP) を指定する流れになっています。

また、MCP Serverの追加は管理者のみ可能とされています。

これは実務上とても重要です。

なぜなら、MCP Serverは外部ツール実行能力を持つため、誰でも自由に追加できるとセキュリティリスクになるからです。

参考：

https://docs.openwebui.com/features/extensibility/mcp/

全体の利用フロー

利用者から見ると、処理の流れはシンプルです。

ブラウザベースAI-GIS処理フロー

ここで重要なのは、AIが最終成果を勝手に確定しないことです。

AIは作業を支援します。

技術者が品質を担保します。

防災・インフラ・行政業務では、この考え方が必須です。

今回のディレクトリ構成

第2回で作成した gis-mcp-server を利用します。

今回は親ディレクトリを作り、その中にOpen WebUI、Ollama、GIS MCP Serverの構成をまとめます。

local-ai-gis-platform/
├── docker-compose.yml
├── .env
└── gis-mcp-server/
    ├── app/
    │   └── server.py
    ├── data/
    │   ├── input/
    │   └── output/
    ├── Dockerfile
    └── requirements.txt

第2回の gis-mcp-server をそのままコピーして使う想定です。

1. .envを作成する

Open WebUIでは、永続的な秘密鍵として WEBUI_SECRET_KEY を設定しておくことが推奨されます。

MCPやOAuth連携を扱う場合、コンテナ再作成後のトークン復号エラーを避ける意味でも重要です。

.env を作成します。

WEBUI_SECRET_KEY=replace-this-with-a-long-random-secret
OLLAMA_MODEL=llama3.1:8b

本番では、以下のようなコマンドで強い値を生成してください。

openssl rand -hex 32

出力例です。

4d7a7f7e8f4e7f2b2c1d3e4f5a6b7c8d9e0f11223344556677889900aabbccdd

これを WEBUI_SECRET_KEY に設定します。

2. docker-compose.ymlを作成する

今回は3つのサービスを定義します。

ollama
open-webui
gis-mcp-server

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped

  gis-mcp-server:
    build:
      context: ./gis-mcp-server
    container_name: gis-mcp-server
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - ./gis-mcp-server/data:/data
    environment:
      - MCP_HOST=0.0.0.0
      - MCP_PORT=8000
      - GIS_DATA_ROOT=/data
    restart: unless-stopped

volumes:
  ollama:
  open-webui:

この構成では、ホストPCからは以下のURLでアクセスできます。

サービス	URL
Open WebUI	`http://localhost:3000`
Ollama API	`http://localhost:11434`
GIS MCP Server	`http://localhost:8000/mcp`

コンテナ間では以下の名前で通信できます。

接続元	接続先	URL
Open WebUI	Ollama	`http://ollama:11434`
Open WebUI	GIS MCP Server	`http://gis-mcp-server:8000/mcp`

ここが重要です。

Open WebUIコンテナから見ると、localhost はOpen WebUI自身を指します。

そのため、同じDocker Compose内のGIS MCP Serverへ接続する場合は、http://gis-mcp-server:8000/mcp のようにサービス名を使います。

3. 起動する

docker compose up -d --build

起動状態を確認します。

docker compose ps

ログを確認します。

docker compose logs -f open-webui

docker compose logs -f gis-mcp-server

4. Ollamaモデルを取得する

Ollamaコンテナ内でモデルを取得します。

docker exec -it ollama ollama pull llama3.1:8b

日本語を重視する場合は、Qwen系も候補です。

docker exec -it ollama ollama pull qwen2.5:7b

モデル一覧を確認します。

docker exec -it ollama ollama list

5. Open WebUIへアクセスする

ブラウザで以下を開きます。

http://localhost:3000

初回アクセス時に管理者アカウントを作成します。

業務PoCでは、最初に作成したアカウントを管理者として扱い、MCP Serverの追加や接続設定を行います。

6. Open WebUIからOllama接続を確認する

Open WebUIはOllamaとの接続に対応しています。

同一Docker Compose構成では、以下の環境変数を設定しています。

OLLAMA_BASE_URL=http://ollama:11434

Open WebUIの管理画面で確認する場合は、以下です。

Admin Settings
  → Connections
  → Ollama
  → Manage

公式ドキュメントでは、Dockerユーザーがホスト側のOllamaに接続する場合は http://host.docker.internal:11434 を使う案内があります。

今回のように同一Compose内でOllamaを起動する場合は、Dockerのサービス名 ollama を使うのが分かりやすいです。

7. GIS MCP Serverの疎通確認

まずホストPCからMCP Serverへアクセスできるか確認します。

curl http://localhost:8000/mcp

MCPは通常のREST APIとは異なるため、単純なGETで分かりやすい結果が返らない場合があります。

動作確認にはMCP Inspectorを使うのが確実です。

npx -y @modelcontextprotocol/inspector

接続先に以下を指定します。

http://localhost:8000/mcp

health_check が実行できれば、MCP Server側は正常です。

8. Open WebUIにGIS MCP Serverを追加する

Open WebUIの管理画面からMCP Serverを追加します。

公式ドキュメント上の流れは以下です。

Admin Settings
  → External Tools
  → + Add Server
  → Type: MCP (Streamable HTTP)
  → Server URLを入力
  → Save

今回のDocker Compose構成では、Open WebUIコンテナからGIS MCP Serverへ接続するため、Server URLは以下にします。

http://gis-mcp-server:8000/mcp

認証方式は、ローカルPoCではまず None にします。

Auth: None

本番では、Bearerトークン、リバースプロキシ、アクセス制御、ネットワーク制限を組み合わせます。

9. チャット画面でToolを有効化する

MCP Serverを追加しただけでは、チャットですぐ使えない場合があります。

Open WebUIでは、チャット画面側でToolを有効化します。

公式ドキュメントでは、チャット画面で以下の操作が案内されています。

Chat
  → +
  → Integrations
  → Tools
  → 追加したMCP Toolを有効化

有効化後、利用者は自然言語でGIS処理を依頼できます。

10. 動作確認プロンプト

まずは安全な health_check から試します。

GIS MCP Serverの状態を確認してください。
利用可能なGISライブラリのバージョンも教えてください。

次に、ベクタ情報確認を試します。

/data/input/landslide_area.geojson の件数、座標系、属性項目を確認してください。

期待される内部処理は以下です。

Open WebUI
  → Ollama
  → Tool利用判断
  → GIS MCP Server: read_vector_info
  → 結果を日本語で要約

11. 実務デモ：土砂災害警戒区域と避難所の重ね合わせ

第2回で実装したToolを使って、次のデモを行います。

入力データ

/data/input/landslide_area.geojson
/data/input/shelters.geojson

利用者の依頼

土砂災害警戒区域から500m以内にある避難所を抽出してください。
結果はGeoJSONとCSVで出力し、最後に日本語で要約してください。

AI-GIS側の処理イメージ

AIによる避難所抽出フロー

ここまで動くと、デモとしてかなり見せやすくなります。

「自然言語で依頼したら、GIS処理が実行され、成果ファイルが出力される」

という体験を見せられるからです。

12. プロンプト設計

MCP Toolを使わせるには、プロンプト設計も重要です。

Open WebUIのシステムプロンプトや、モデルへの指示として、以下のようなルールを入れると安定します。

あなたはGIS業務を支援するAIアシスタントです。
GIS計算を自分で推測して答えず、必要な場合は利用可能なGIS MCP Toolを呼び出してください。

ルール:
- 面積、距離、空間結合、ラスタ統計はMCP Toolを使う
- CRSが不明な場合は先にデータ情報確認Toolを使う
- 距離や面積を扱う場合は投影座標系の確認を促す
- 結果は断定しすぎず、技術者確認が必要であることを明記する
- 入力データがない場合は、必要なファイル名と場所を確認する

これは実務では非常に重要です。

LLMが勝手に推測して答えるのを防ぐためです。

13. GIS業務向けシステムプロンプト例

以下は、GIS業務向けシステムプロンプト例です。

あなたは防災・建設コンサル向けのGIS解析支援アシスタントです。
利用者の自然言語による依頼を理解し、必要に応じてGIS MCP ServerのToolを呼び出してください。

重要方針:
1. GIS計算を推測で答えない
2. 実データに対する確認・変換・解析はToolで実行する
3. 座標系、単位、出力形式を確認する
4. 処理結果は日本語でわかりやすく説明する
5. 防災・インフラ判断に使う場合は技術者確認が必要と明記する

出力形式:
- 実行した処理
- 入力データ
- 出力ファイル
- 結果概要
- 注意点
- 次に確認すべきこと

このプロンプトを使って確認をします。

Open WebUI連携でつまずきやすい点

1. localhostの意味が違う

Dockerで最も多いミスです。

ホストPCから見た localhost と、Open WebUIコンテナから見た localhost は違います。

場所	`localhost` が指すもの
ホストPC	ホストPC自身
Open WebUIコンテナ内	Open WebUIコンテナ自身
GIS MCP Serverコンテナ内	GIS MCP Serverコンテナ自身

同じDocker Compose内のサービスへ接続する場合は、サービス名を使います。

http://gis-mcp-server:8000/mcp

ホスト側で動いているOllamaへOpen WebUIコンテナから接続する場合は、Open WebUI公式ドキュメントでも案内されているように、Docker環境では host.docker.internal を使う構成があります。

http://host.docker.internal:11434

2. MCPのTypeをOpenAPIにしない

Open WebUIでMCP Serverを追加する際、Typeは MCP (Streamable HTTP) にします。

OpenAPIとして登録すると、MCP Serverの形式と合わず動きません。

3. MCP Serverは管理者が登録する

Open WebUIのMCP Server追加は管理者向けの操作です。

これは制限ではなく、安全設計です。

MCP Serverは強力な外部ツール連携なので、業務環境では管理者が確認したサーバーだけを登録すべきです。

4. Toolを増やしすぎない

最初から大量のGIS Toolを登録すると、LLMが選択を間違えることがあります。

PoCでは以下程度に絞るのがおすすめです。

health_check
read_vector_info
buffer_geometry
spatial_join
calculate_area
read_raster_info
zonal_statistics

まずは5〜7個程度で始めます。

5. 権限とデータ範囲を制限する

MCP Serverが触れるデータ範囲は限定します。

第2回では、/data 以下のみを許可しました。

/data/input
/data/output

これは本番でも重要です。

任意のパスを読める設計にしてはいけません。

PoC評価項目

PoCでは、技術的に動いたかだけでなく、業務価値を評価します。

評価項目	見るポイント
操作性	非GIS担当者でも依頼できるか
精度	Tool実行結果が正しいか
再現性	同じ入力で同じ結果が出るか
速度	業務上許容できる処理時間か
説明性	結果説明が分かりやすいか
安全性	データ範囲・権限が制限されているか
展開性	他業務へ横展開できるか

業務導入時の運用設計

1. 利用者権限

利用者を以下のように分けます。

権限	役割
一般利用者	チャットから処理依頼
GIS技術者	結果確認・修正
管理者	MCP Server追加・設定変更
システム管理者	サーバー・ネットワーク管理

MCP Serverの登録は管理者に限定します。

2. データアクセス制限

部署ごとに利用できるデータを分けます。

/data/department_a/input
/data/department_a/output
/data/department_b/input
/data/department_b/output

より厳密にする場合は、MCP Serverを部署ごとに分けます。

gis-mcp-sabo
gis-mcp-river
gis-mcp-road
gis-mcp-asset

3. ログ管理

本番では、少なくとも以下を記録します。

日時
利用者
入力プロンプト
呼び出したTool
入力ファイル
出力ファイル
処理パラメータ
成功・失敗
エラー内容

防災・行政・インフラ業務では、あとから説明できることが重要です。

ここまでの完成形

Chapter3まで完了すると、以下の状態になります。

AI-GISシステム構成の概要

これで、AI-GIS基盤の最小構成が完成です。

次回予告

次回は、より業務に近い形に拡張します。

テーマは以下です。

土砂災害解析AIアシスタントを作る

予定内容:

土砂災害警戒区域データの読み込み
避難所ポイントとの重ね合わせ
DEM情報の確認
傾斜量計算Toolの追加
危険斜面候補の一次抽出
出力CSVとGeoJSONの整理
AIによる報告書たたき台生成

ここまで進むと、単なる技術検証ではなく、実務PoCとして提案しやすくなります。

まとめ

本記事では、Open WebUI、Ollama、GIS MCP Serverを接続し、ブラウザから自然言語でGIS処理を呼び出す構成を作りました。

重要なポイントは以下です。

重要なポイント

Open WebUIは利用者の入口になる
OllamaはローカルLLMとして会話と判断を担当する
GIS MCP ServerはAIとGIS処理をつなぐ実行入口になる
GeoPandasやRasterioが実際のGIS解析を担当する
MCP Serverは管理者が登録し、利用権限を制御する
localhost とDockerサービス名の違いに注意する
業務PoCではToolを絞り、toolを増やさない
本番ではログ、権限、データ範囲、監査設計が重要になる

第1回で頭脳としてのOllamaを作り、第2回で手足としてのGIS MCP Serverを作りました。

第3回では、それらをOpen WebUIでつなぎ、利用者が使えるAI-GIS基盤にしました。

参考リンク

Open WebUI 公式ドキュメント
https://docs.openwebui.com/
Open WebUI: Ollama連携
https://docs.openwebui.com/getting-started/quick-start/connect-a-provider/starting-with-ollama/
Open WebUI: MCP
https://docs.openwebui.com/features/extensibility/mcp/
Ollama API
https://docs.ollama.com/api/introduction
MCP Python SDK
https://github.com/modelcontextprotocol/python-sdk

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