ブラウザ完結GIS「GeoLibre」の仕組みと1000+の処理ツール

地理空間データを扱うプロジェクトで技術選定を任されたとき、候補の GIS ソフトウェアは QGIS や kepler.gl をはじめ数多く存在します。しかし「ブラウザだけで動く」「分析処理まで完結する」「マルチプラットフォームで同じプロジェクトを開ける」という条件を同時に満たせる選択肢は限られており、公開情報だけで一次判断を下すのは意外と難しい領域です。

QGIS は成熟したデスクトップ GIS ですが、利用にはインストールと環境構築が必要です。kepler.gl はブラウザで動く強力な可視化ツールですが、buffer や spatial join といった空間分析ツールの網羅性は限定的です。「ブラウザ完結」と「分析処理」を両立させたい要件に、どのプロダクトが応えられるのかは、公式ドキュメントを横断して読み解かないと見えてきません。

このニッチに位置するのが、opengeos/GeoLibre が公開する OSS の GIS プラットフォーム「GeoLibre」です。1.0 リリース時点で 5,000 スターを超え、Whitebox 由来の 1,000 以上の空間処理ツールを WebAssembly でクライアント実行できる設計を持ちます。

本記事では、公式リポジトリ・公式サイト・公式ドキュメントの記載に基づき、GeoLibre の仕組み、特徴的な機能、採用技術、類似 OSS との違い、導入経路、そして採用判断で見落とされがちな制約までを整理します。動作検証は行わず、ドキュメントベースで「自プロジェクトに合うか」を判断するための材料を提示することを目的としています。

GeoLibreとは何か

GeoLibre は、opengeos/GeoLibre（GitHub リポジトリ）で公開されている、軽量・クラウドネイティブの OSS GIS プラットフォームです。公式サイト（https://geolibre.app/）の説明によれば、Web ブラウザ・デスクトップ・モバイル・Jupyter Notebook のいずれでも同一のワークスペースで地理空間データを扱えることが最大の特徴とされています。

開発は Qiusheng Wu 氏（GitHub アカウント giswqs）が主導しており、leafmap や geemap などの既存 OSS でも知られる著者による新しいプロジェクトです。1.0 リリースは 2026 年に公開され、リリース単位で Zenodo に DOI（10.5281/zenodo.20785400）が付与されているため、学術用途での引用にも対応できる体裁を持ちます。

リポジトリメタデータを 2026 年 8 月 14 日時点で確認すると、以下の指標が確認できます（値はいずれも gh api /repos/opengeos/GeoLibre の応答による）。

最終更新日時が記事作成日と同一である点、フォーク数がスター数の約 10 % に達している点から、活発にメンテナンスされている状況が読み取れます。加えて、リポジトリはアーカイブされておらず、他リポジトリからのフォーク版でもないため、本家のメインラインで開発が続いている前提で採用判断ができます。

なお、本記事では実行・インストール・環境構築などの動作検証は行いません。あくまで公式ドキュメントとリポジトリ情報に基づき、初見のエンジニアが採用可否の一次判断を下すための材料を整理する構成としています。

特徴的な機能

GeoLibre の特徴は、公式サイトの Features ページ と README で整理されています。ここでは 4 つのカテゴリに分けて要点を整理します。

ブラウザ完結型 GIS（データはローカルに留まる）

Features ページの説明によれば、GeoLibre は Web ブラウザ・デスクトップ・モバイル・Jupyter Notebook・R のいずれからでも「同じワークスペース」を開ける設計になっています。Web 版はインストール不要でアクセスでき、読み込んだデータはクライアント側の処理でローカルに保持される仕組みです。サーバへデータを送信しない設計は、機密性の高い地理空間データを扱う組織にとって採用判断のしやすさに直結します。

Web 版は PWA としてオフライン動作もサポートすると Features ページに記載があり、ネットワーク環境に依存しないフィールドワーク用途にも配慮されています。ワークスペースは .geolibre.json（GeoJSON ベース）の単一プロジェクトファイルで永続化されるため、Web で作ったプロジェクトをデスクトップで開き直す、といった環境横断の使い方が想定されています。

WebAssemblyで動く1,000+の処理ツール

GeoLibre で最も差別化要因になるのが、README で紹介されている「1,000 を超える地理処理ツール群」です。これは Whitebox Next Gen 由来のツールと GeoLibre 独自の WASM ツールが Processing → Whitebox のツールボックスに集約されているもので、README ではカテゴリ別のツール数が示されています。

（出典: opengeos/GeoLibre README、および公式サイトの Processing Tools ガイド）

これらのツールは Python サイドカーもサーバ呼び出しも介さず、WebAssembly のみでクライアント側で動作する仕組みだと README に明記されています。さらに ?tool=<name> というディープリンクでツールを直接呼び出し、フォームの事前入力までできる URL パラメータ設計が備わっており、外部システムから特定処理を叩く連携用途にも対応しやすい構造です。

クラウドネイティブなデータ形式サポート

現代の地理空間データワークフローで前提となる形式群がひととおりサポートされている点も、Features ページから確認できます。ベクタ形式は GeoJSON / GeoParquet / GeoPackage / Shapefile / FlatGeobuf / KML / KMZ / GML / CSV / GPX / OSM PBF、ラスタ・3D は COG / Zarr / 3D Tiles / LiDAR / Gaussian splats / glTF / EXIF 付き写真、サービス系は WMS / WFS / vector tiles / ArcGIS feature services が挙げられています。

URL ディープリンクによる直接オープンにも対応しており、GeoJSON / GeoParquet / PMTiles / REST エンドポイントを URL パラメータ経由でロードできます。さらに QGIS プロジェクト（.qgs / .qgz）や ArcGIS Pro プロジェクト（.aprx / .mapx）のインポート機能も備わり、既存資産の持ち込みハードルを下げる設計です。

SQL・AI・Python/R 連携

分析基盤としての側面も広く用意されています。SQL Workspace では DuckDB Spatial のクエリをロード済みレイヤやリモート URL に対して実行でき、インブラウザの PostGIS 実装である PGlite PostGIS、Apache Sedona の spatial SQL エンジンにも対応します。

AI・Python・R 連携としては、自然言語 GIS アシスタント（provider-pluggable、独自 API キー対応）、インアプリの Python コンソール（自動化 API）、Jupyter Notebook パネルの地図横ドッキング、Python パッケージ geolibre（Jupyter に anywidget として埋め込み）、MCP サーバ geolibre-mcp（ヘッドレスプロジェクト作成）、R パッケージ geolibre（RStudio / Quarto / R Markdown / Shiny）、そして SamGeo / Meta SAM 3 を用いた AI Segmentation やブラウザ内 ONNX / YOLO 物体検出まで、README ではカバー範囲の広さが記載されています。

採用技術とアーキテクチャ

GeoLibre のコアスタックは README で以下の技術に整理されています。

• Tauri v2: デスクトップ・モバイルシェル。単一コードベースからマルチプラットフォームのネイティブアプリを配布するために採用されています
• React + TypeScript: UI レイヤ
• MapLibre GL JS: マップレンダリング
• DuckDB-WASM Spatial: インブラウザの空間 SQL 実行
• deck.gl: GPU レイヤ描画

このスタック構成は、ブラウザ／デスクトップ／モバイルを単一コードベースで統合するというプロダクトのゴールに沿った選定と読み取れます。UI 層に React、地図レンダリングに MapLibre GL JS を採用しており、Web フロントエンドの経験があるエンジニアであればアーキテクチャの見通しをつけやすい構成です。データ層は DuckDB-WASM Spatial により、ブラウザ内で空間 SQL を発行できる構成になっています。

分析処理の実行モデルは Python サイドカーやサーバ呼び出しを介さず、Whitebox Next Gen 由来の WebAssembly バイナリをクライアント側で直接実行する形になっています。この設計により、Web 版でもデスクトップ版でも同じロジックで処理が完結する仕組みが実現されています。

環境横断を支える中核が、先ほど触れた .geolibre.json（GeoJSON ベース）プロジェクトファイルです。同一ファイルを Web／デスクトップ／モバイル／Jupyter／R のいずれのクライアントでも開けるため、環境切り替え時に設定を再構築する必要がありません。QGIS が長年築いてきたエコシステムがデスクトップに閉じているのに対し、GeoLibre は「プロジェクトファイルをキャリアとして環境をまたぐ」設計思想を採っている点が特徴的です。

類似OSSとの違い

「ブラウザで動く GIS」「クラウドネイティブ GIS」という枠には複数の OSS が存在するため、初見のエンジニアが GeoLibre を採用するかどうかを判断するには、代表的な類似 OSS との差分を押さえておく必要があります。ここでは QGIS と kepler.gl の 2 プロダクトを軸に、公式 Comparison ページ の記述と各プロダクトの公開情報に基づき差分を整理します。

QGIS との違い

QGIS（qgis/QGIS）は 2002 年以来長期にわたって開発されてきた老舗のデスクトップ GIS で、C++ と Python のプラグインエコシステムを備える成熟したプロダクトです。機能の網羅性と拡張性は現時点でも業界標準に位置します。

GeoLibre の公式 Comparison ページは、両者の関係を「QGIS はプロ用の一眼レフカメラ、GeoLibre はスマートフォンのカメラ」というアナロジーで説明しています。QGIS はプロフェッショナルの深い要件に応える成熟した選択肢、GeoLibre はアクセシビリティとデプロイ容易性を優先した選択肢という位置づけです。したがって「QGIS の代替」ではなく、QGIS の利用が難しいシーン（インストール制約のある業務端末、ブラウザ完結が求められる Web 埋め込み、モバイルからの参照など）を補完する層と捉えるのが実態に近い理解となります。

kepler.gl との違い

kepler.gl（keplergl/kepler.gl）は Uber が公開したブラウザ向けの地理データ可視化ライブラリで、deck.gl を基盤とした GPU レンダリングで大規模データの可視化に強みを持ちます。ブラウザで動くという点では GeoLibre と重なりますが、プロダクトのフォーカスは可視化領域に置かれており、buffer や spatial join、hydrology 系の空間分析ツール群は限定的です。

GeoLibre は先ほど紹介した Whitebox 由来 1,000+ の処理ツールを WebAssembly でクライアント実行できるため、「可視化」だけでなく「分析まで完結」できる範囲が広い点が差分です。可視化と分析の両方を単一のブラウザ環境で完結させたい要件では、GeoLibre 側に検討価値があります。

どのようなユースケースで GeoLibre を選ぶか

以上の差分を踏まえると、GeoLibre の適合するシーンは以下のように整理できます。

• インストール制約のある環境で GIS を提供したい: 業務端末にソフトウェアを追加できない、あるいは外部ユーザーに配布したいケース。Web 版・埋め込み URL パラメータで対応しやすい
• 機密性の高い地理空間データを扱う: データがクライアント側でローカルに保持される設計のため、サーバ送信を伴うアーキテクチャよりリスク管理がシンプル
• 可視化だけでなく空間分析まで一気通貫で行いたい: buffer / spatial join / hydrology / terrain 等の処理を可視化と同じ画面で完結できる
• マルチプラットフォームで同一プロジェクトを扱いたい: Web で作ったワークスペースをデスクトップやモバイル、Jupyter、R でそのまま開き直したい要件

一方、大規模なローカル GIS データに対する集中バッチ処理や、既存の QGIS プラグイン資産に強く依存したワークフローでは、QGIS のほうが優位に立つ場面が残ります。この判断は次の章で改めて整理します。

導入方法とライセンス

GeoLibre はマルチプラットフォームでの配布経路が用意されています。公式サイトの Getting Started ページ に導入経路と初期設定手順が整理されており、以下のチャネルが提示されています。

• Web 版: https://web.geolibre.app/ にアクセスするだけで利用可能。インストール不要
• デスクトップ版: Windows（MSIX / Winget / portable zip）、macOS（署名済み・Homebrew Cask・Mac App Store）、Linux（AppImage + zsync）
• モバイル版: Android（Google Play）／iOS（App Store）
• Python パッケージ: pip install geolibre。Jupyter Notebook に anywidget として埋め込み可能
• R パッケージ: geolibre。RStudio / Quarto / R Markdown / Shiny から利用可能
• Docker / セルフホスト: 共有・アカウント・ライブコラボの自前運用に対応。HTTP Basic Auth オプションあり

配布経路が Microsoft Store / Mac App Store / Homebrew / AUR / Flatpak 等のパッケージマネージャに広く展開されている点は、単一メンテナ主導のプロダクトとしては配布インフラが厚めに整えられている印象を与えます。

ライセンスは MIT で、商用利用・改変・再配布のいずれも許可されています。社内システムへの組み込みや、SaaS への埋め込み利用にも法的な制約が少なく、採用可否の一次判断において障害になりにくい条件です。

本記事は動作検証を行っていないため、実際の挙動・依存パッケージのバージョンの正確な追跡・想定外の挙動については、公式ドキュメントおよび各配布経路のインストールガイドで最新情報を確認してください。

採用時に踏まえたい制約と留意点

採用判断は「向くケース」だけでは決められません。公式 Comparison ページの記載と、リポジトリの公開情報から読み取れる制約・留意点を整理します。

第一に、1.0 リリースの時期が 2026 年で、QGIS（2002 年から開発）や ArcGIS（1999 年以来の商用プロダクト）に比べて歴史が浅い点は公式サイトも明言しています。プラグインの豊富さ、エッジケースへの対処実績、GIS 業界での標準化度合いといった観点では、老舗プロダクトに一日の長があります。

第二に、公式 Comparison ページは「非常に大きなローカルデータセットの処理」「特殊ツールボックス（例: ArcGIS の Spatial Analyst）に依存する処理」「エンタープライズ Geodatabase 管理」の 3 領域で QGIS / ArcGIS が優位である旨を明記しています。これらの要件が中核にあるプロジェクトでは、GeoLibre は補完的な位置づけになる可能性が高い点を踏まえてください。

第三に、リアルタイム多人数コラボレーション機能は README で「MVP」と表記されています。共同編集を業務クリティカルな要件として組み込む場合は、機能成熟度と運用実績の観点で慎重に評価する必要があります。

第四に、開発リーダーは基本的に単一メンテナ体制（Qiusheng Wu 氏）である点も採用判断材料に含めるべきです。コミュニティコントリビュータやベータテスターの記載は README にありますが、企業システムに組み込む場合はメンテナンスリスクの評価が必要です。リリース単位で Zenodo に DOI 付きアーカイブが残る仕組みは、バージョン固定・監査対応の観点で救いになります。

最後に、日本語ドキュメント・国内事例は 2026 年 8 月時点ではほぼ確認できません。Features ページには 18 言語のインターナリゼーションが記載されていますが、日本語コミュニティで質問先を確保できるかは別問題です。導入時は英語ドキュメントベースでの運用を前提に、社内での知識共有体制も含めて計画してください。

まとめ

GeoLibre は、Whitebox 由来の 1,000+ 処理ツールを WebAssembly でクライアント実行できる点と、Web／デスクトップ／モバイル／Jupyter／R を単一プロジェクトファイルで横断できる設計を強みとする、クラウドネイティブ志向の OSS GIS プラットフォームです。「ブラウザで動く GIS」の中でも、可視化にとどまらず分析まで完結できる領域を狙う点で、kepler.gl のような可視化特化プロダクトとも QGIS のようなデスクトップ完結プロダクトとも異なるポジションを確立しつつあります。

初見のエンジニアが採用可否を判断する際には、以下の観点を出発点にすると整理しやすいはずです。

• 向くケース: インストール制約下での GIS 提供、ブラウザ完結の分析ワークフロー、機密データをクライアント内に留めたい要件、マルチプラットフォーム横断のプロジェクト
• 向かないケース: エンタープライズ Geodatabase の中央管理、Spatial Analyst 等の特殊ツール依存、大規模ローカルデータの集中バッチ処理、既存 QGIS プラグイン資産への強い依存

次のアクションとしては、公式サイト（https://geolibre.app/）で Features ページと Comparison ページ を参照した上で、Web 版で自プロジェクトの代表データを開いてみるのが最短経路になります。並行して GitHub リポジトリ（https://github.com/opengeos/GeoLibre）で Issues と Releases の動きを確認し、メンテナンス活動が継続していることを自身の目で追認しておくと、採用判断の確度がさらに上がります。

関連情報

自社サービスや業務システムに地理空間データの活用を組み込みたい方、あるいは OSS の GIS を用いた新規プロダクト開発をご検討中の方は、お問い合わせフォーム からご相談いただけます。要件整理の段階からお話をうかがえます。