やってみた 2026年7月28日

ブラウザだけで動く自己ホスト型GIS「GeoLibre」を使い捨てコンテナで動かし、『データはローカル』の実際を運用目線で確かめた

XECIN TypeScriptGISMapLibreセルフホスト

GitHubのトレンドを眺めていたら、opengeos/GeoLibre が上のほうに来ていました。「軽量・クラウドネイティブなGISプラットフォーム。ブラウザでもデスクトップでもモバイルでもJupyterでも動く。しかもデータはローカルに保持する」。GIS基盤の選定に何度か関わってきた立場としては、この「データはローカル」という一文が気になったんですよね。

私が普段見ているのは、地理空間データを扱いたいがクラウドのGISサービスにデータを預けるのは避けたい、という要望です。自己ホスト型を謳うツールは多いのですが、「どこまでが本当にローカルで、どこからが外部通信なのか」は運用を考えると最初に線引きしておきたいところです。ちょうど良い題材だったので、使い捨てコンテナで実際に動かして確かめました。

試した環境

いつも通り、ホスト（Windows）を汚さないよう、使い捨ての node:22-bookworm コンテナの中だけで動かしています。キャプチャだけはホスト側のブラウザから撮っています。

  • 対象: opengeos/GeoLibre v2.3.0（commit 417e52911ef3、TypeScript、MITライセンス）
  • ランタイム: Node.js v22.23.1 / npm 10.9.8
  • ビルド: Vite 8.1.5
  • 構成（READMEより）: Tauri v2 + React + TypeScript + MapLibre GL JS + DuckDB-WASM Spatial + deck.gl

Tauri製なのでデスクトップ・モバイルのネイティブアプリにもなりますが、今回は運用で真っ先に検討するであろう「ブラウザ版（Vite開発サーバ）」だけを非Dockerの起動パスで動かしています。ネイティブシェル（Tauri/Rust）は使っていません。

セットアップは拍子抜けするほど速い

クローンして依存を入れるところまでは、正直なところ身構えていたより速かったです。

git clone --depth 1 --branch v2.3.0 https://github.com/opengeos/GeoLibre.git repo
cd repo
npm install
# added 1404 packages, and audited 1414 packages in 16s
# node_modules は 2.1G

1404パッケージで node_modules が2.1GBというのは、フロントエンドのモノレポとしては標準的な重さです。install自体は16秒で終わりました。

開発サーバの起動はもっと速くて、Viteらしい立ち上がりでした。

npm run dev -w geolibre-desktop -- --host 0.0.0.0 --port 5173 --strictPort
#   VITE v8.1.5  ready in 321 ms
#   ➜  Local:   http://localhost:5173/

ready in 321msです。ここは素直に速いと感じました。

ただ、起動直前の predev フックで一つ想定外がありました。

[build-jupyterlite] `jupyter lite` is not available — skipping the JupyterLite build.
The web Notebook panel will show a 'not built' message.

READMEでは「Jupyterでも動く」ことを推していますが、Python側（JupyterLite）のビルド依存が入っていないと、その場では黙ってスキップされ、Notebookパネルは「未ビルド」表示になる作りでした。エラーで止まるわけではないので実害はないのですが、「Jupyter連携込みで評価したい」なら別途 pip install -r ... が要る、という前提は運用資料に書いておくべきポイントだと考えています。JavaScript側だけなら完全にスルーできるのは、むしろ設計として好感が持てました。

ブラウザを開くと、いきなり地球儀が回っている

http://127.0.0.1:5173/ を開くと、初回リクエストから数秒で日本語ロケールのフルGISワークスペースが立ち上がりました。MapLibreの3Dグローブ、地形ベースマップ、星空の背景。上部にプロジェクト・編集・表示・データ追加・プロセシング・コントロール・プラグイン・設定・ヘルプというメニューが並びます。

GeoLibreの初期画面。日本語UIで、中央にMapLibreの3Dグローブ（北米・南米が見える地形ベースマップと星空の背景）、左にレイヤーパネル、右にスタイルパネル、上部にプロジェクト/編集/表示/データ追加などのメニューバーが並んでいる

「軽量」と言っている割にいきなり globe が滑らかに回るので、ここは体感の掴みが良いですね。WebGLはホスト側の実ブラウザで描画しているので、この見た目はそのまま出ました。

感心したのは「データ追加」メニューの守備範囲です。数えてみたら30種類の地理データ形式が並んでいました。運用でよく聞かれる形式がひととおり揃っています。

分類対応形式（抜粋）
ベクター / ラスターベクターレイヤー、ラスターレイヤー、区切りテキスト、CAD(DXF/DWG)、ファイルGDB、GPX
タイル / OGCXYZ、MBTiles、PMTiles、WMS、WFS、WMTS、OGCベクタータイル、ArcGIS
クラウドネイティブ / 大容量GeoParquet、FlatGeobuf、Zarr、NetCDF/HDF、STAC、OSM PBF
3D / 点群 / DBLiDAR、3D Tiles、glTF、ガウシアンスプラッティング、Deck.gl、DuckDB、PostgreSQL

GeoParquetやFlatGeobuf、DuckDBレイヤーがブラウザ側から直接読めるという設計は、DuckDB-WASMを積んでいる強みがよく出ています。ここは正直、想像していたより本格的でした。

実データを一枚載せてみる

「動く」だけでは評価にならないので、外部の公開タイルを一枚載せてみます。データ追加 → XYZレイヤーで、URLテンプレートに次を入れました。

https://tile.openstreetmap.org/{z}/{x}/{y}.png

追加した瞬間、地形ベースマップの上にOpenStreetMapのラスタータイルが重なりました。レイヤーパネルに「XYZレイヤー」が積まれ、右のスタイルパネルには不透明度・明るさ・彩度・コントラスト・色相回転のスライダーが出て、「変更はMapLibreのラスターペイントプロパティにリアルタイムで反映されます」と注記されています。ラスターの見た目調整をMapLibreの raster ペイントプロパティにそのまま渡している、素直な作りです。

globeの上にOpenStreetMapのXYZラスタータイルが重なった状態。左のレイヤーパネルには「XYZレイヤー」と「背景」の2レイヤーが並び、右のスタイルパネルに不透明度・明るさ・彩度・コントラスト・色相回転のスライダーが表示されている

ついでに左下の「場所を検索」に Tokyo と打ってみたら、候補に「東京都, 日本」が出てきました。選ぶと、カメラがズーム12まで滑らかに飛んで、OSMのストリートレベルのタイルと赤いピンが表示されます。座標表示は 139.83565, 35.73868 になりました。

「Tokyo」で検索して東京へ移動した画面。ズーム12でOpenStreetMapのストリートレベルのタイルが表示され、新宿区・千代田区・渋谷区・港区などの区名と東京湾が見える。中央に赤いピン、左下の検索欄には「東京都, 日本」と入っている

この間、アプリ右下の「Diagnostics」カウンタは0のまま、ブラウザのコンソールにもエラーは出ませんでした。触っていて安定していたのは印象が良かったです。

で、「データはローカル」の実際はどうだったか

ここが今回いちばん確かめたかったところです。ブラウザの通信を実際に見てみました。

# 既定ベースマップ（背景）
GET https://tiles.openfreemap.org/styles/liberty      [200]
GET https://tiles.openfreemap.org/planet/.../2/1/1.pbf [200]
GET https://tiles.openfreemap.org/natural_earth/...    [200]

# 場所検索の候補（ソース上の既定プロバイダ）
https://nominatim.openstreetmap.org/search

つまり、こういう線引きでした。自分が追加したデータ（GeoParquetやローカルファイル）はブラウザ内で完結してサーバに送られない——ここは謳い文句どおりです。一方で、既定の基盤地図タイルは tiles.openfreemap.org、住所検索は nominatim.openstreetmap.org という外部の無料公開サービスに出ていきます。ソースを見るとジオコーダはNominatimのほか geocode.earth・ArcGIS・Mapbox・Google にも対応していましたが、キー無しで動く既定はNominatimでした。だから Tokyo がそのまま引けたわけです。

これは別に不誠実という話ではなくて、普通のWeb地図と同じ挙動です。ただ「データはローカル」というコピーを額面どおり受け取ると、運用側が誤解する余地はあります。私の整理はこうです。

対象外部通信運用上の含意
追加した自分のデータなし（ブラウザ内で完結）機微データの可視化にそのまま使える
基盤地図タイルopenfreemap.org へ出る閉域運用なら自前タイルサーバに差し替えが要る
住所・地名検索nominatim.openstreetmap.org へ出る（検索文字列が外に出る）検索語が機微なら無効化 or 別プロバイダ検討

運用を考えると、「機微データそのものは外に出ないが、基盤地図と検索は外部の無料サービスに依存する」という理解でツールを配ればよさそうです。閉域やオフラインで完全に閉じたいなら、基盤タイルをMBTiles/PMTilesで自前配信に差し替え、ジオコーディングは無効化する、という追加設計が要ります。GeoLibreはXYZもPMTilesもMBTilesも読めるので、その差し替え自体は仕組みとしては用意されている、という点は評価できます。

ここは好みが分かれるところですが、無料の公開タイルサーバ（openfreemap）にデフォルトで乗っているのは、個人が「とりあえず開いて使える」体験としては正解だと思います。組織で使うなら、そのデフォルトを運用ポリシーに合わせて締める、という前提で見ればいい、というのが私の受け止めです。

試してみての所感

30分弱触ってみて、GeoLibreは「ブラウザで開くだけで本格的なGISが立ち上がり、GeoParquetやDuckDBまでローカルで扱える」という一点で、選定候補に入れる価値は十分あると考えています。セットアップの軽さ（npm一発、Vite 321ms）と安定性（Diagnostics 0）も、社内でちょっと配って試してもらうハードルを下げてくれます。

一方で「データはローカル」という言葉は、追加データに関しては本当ですが、基盤地図とジオコーディングには当てはまらない——ここは運用資料で明確に線引きしておくべきポイントでした。今思えば、この手のツールを評価するときに毎回最初に見るべきなのは、機能一覧より「どこと通信しているか」なのかもしれません。

私自身は、まず機微でない社内データの可視化用途で様子を見つつ、閉域要件が出てきたら基盤タイルの自前配信とセットで再評価する、という進め方にしたいと思っています。もっと良い評価の観点があれば教えてください。