脱Shapefile時代へ - GISにおけるGeoJSON / GeoPackage / FlatGeobufの使い分け

GIS（地理情報システム）やWebマップ開発の世界において、2次元のベクターデータ（位置情報と属性情報のセット）を扱うフォーマットは大きな変革期を迎えています。

長年業界の標準として使われてきた「Shapefile（シェープファイル）」は、容量制限や文字化け問題といった時代の波に押され、すでに第一線からの退場（脱Shapefile）が推奨されています。

では、現代のGIS実務やWeb開発において、私たちはどのファイルフォーマットを選べばよいのでしょうか？

その答えとなるのが、現在主流かつ注目の3大フォーマット「GeoJSON」「GeoPackage」「FlatGeobuf」です。

「どれも地図データなのは分かるけれど、具体的に何が違うのかサッパリ分からない」 「Webマップを作ったら動作が激重になってしまった…」 「QGISで作業するとき、どの形式で保存するのが正解？」

今回は、そんな疑問や悩みを抱える方に向けて、これら3つの主要フォーマットの特徴、技術的な違い、そして実務における明確な使い分けの基準を約5,000字で徹底解説します！

なぜ「Shapefile」からの移行が必要なのか？

3つの最新フォーマットの解説に入る前に、まず「なぜ昔からあるShapefileではダメなのか」という時代背景を押さえておきましょう。

Shapefile（.shp）は、1990年代にEsri社によって開発された歴史あるフォーマットです。しかし、現代の巨大なオープンデータや複雑なシステムにおいては、以下のような深刻なデメリットが存在します。

「2GB」の容量壁（最大の問題）
単一ファイルのデータサイズが2GBを超えるとデータが破損・消失します。高精度な国土数値情報や全国レベルのデータを保存できません。

属性名の文字数制限（最大10文字）
データベースの列名（属性名）が英数字10文字までに制限されるため、「building_height」が「build_heig」のように強制的に切られてしまいます。

日本語の「文字化け」リスク
文字コード（UTF-8等）の指定仕様が曖昧なため、異なるソフトやOS間でデータを渡すと頻繁に日本語の属性情報が文字化けを起こします。

複数ファイルのバラバラ管理
.shp .dbf .shx など最低3〜5個のファイルがセットになっていないと機能しないため、メール添付やWeb配信用として扱う際にファイル欠損の事故が多発します。

これらの限界を克服し、現代のデータ環境に合わせて設計されたのが、今回紹介する3つのフォーマットです。

三大フォーマットの基本概要

それでは、現代のGISを支える「GeoJSON」「GeoPackage」「FlatGeobuf」の概要を順番に紐解いていきましょう。

① GeoJSON（ジオジェイソン）── Web開発の標準テキスト形式

• 拡張子： .geojson または .json
• 形式： テキスト形式（JSON）
• 主な用途： Webマップ開発、軽量データの受渡・デバッグ

GeoJSONは、Web技術で広く使われているJSON（JavaScript Object Notation）の文法に基づいて作られた空間データフォーマットです。テキストファイルですので、メモ帳やVS Codeなどのテキストエディタで直接開いて人間が中身（緯度経度や属性値）を解読・編集できます。

JSON

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [139.6917, 35.6895]
  },
  "properties": {
    "name": "東京都庁",
    "category": "役所"
  }
}

JavaScriptとの親和性が抜群に高いため、Webブラウザ上で地図を描画するライブラリ（Leaflet、MapLibre GL JS、OpenLayersなど）へそのまま読み込ませることができます。

② GeoPackage（ジオパッケージ）── デスクトップGISの現代版スタンダード

• 拡張子： .gpkg
• 形式： バイナリ形式（SQLiteデータベース）
• 主な用途： デスクトップGIS（QGIS/ArcGIS）での編集・解析・保存、データの一括統合管理

GeoPackageは、国際標準化団体であるOGC（Open Geospatial Consortium）によって策定されたオープンな標準規格です。

その実体は、世界中で使われている超軽量データベース「SQLite」のコンテナファイルです。1つの .gpkg ファイルの中に、膨大なベクターデータ（ポイント・ライン・ポリゴン）だけでなく、ラスタデータ（航空写真や標高タイル）、さらには関連する属性テーブルなどをまとめてパッキングできます。 Shapefileの「2GBの壁」を打ち破り、実質無制限の容量を扱えるため、現在QGISやArcGIS Proで新規データを保存する際の第一推奨形式となっています。

③ FlatGeobuf（フラットジオバフ）── 次世代Web配信の爆速フォーマット

• 拡張子： .fgb
• 形式： バイナリ形式（FlatBuffers ＋ 空間インデックス）
• 主な用途： Webマップにおける大容量ベクターデータの高速描画・部分ロード

FlatGeobufは、近年の「クラウドネイティブGIS（Cloud Native Geospatial）」の思想に基づいて開発された、Web配信特化型の比較的新しいオープン規格です。

Googleが開発した高速なバイナリシリアライゼーション構造「FlatBuffers」をベースにしており、最大の強みは「ファイル内部にRツリー空間インデックスが組み込まれていること」です。

後述しますが、この構造により「数百万件のデータから、今ブラウザに映っている画面範囲のデータだけをピンポイントで取得・高速描画する」という従来不可能だった動作をWeb上で実現します。

徹底比較：性能・仕様・得意分野の違い

3つのフォーマットの技術的な違いを比較表にまとめました。

この性能差を生み出している背景には、それぞれの「データ構造の思想」が関係しています。

なぜ「速度」と「扱いやすさ」にこれほどの差が出るのか？

実務でフォーマットを選ぶ際、表面上のスペックだけでなく「なぜその差が生まれるのか」という技術的理由を知っておくと選択ミスを防げます。

GeoJSONが「重くて遅い」理由

GeoJSONは人間が読めるテキスト形式です。一見便利ですが、コンピューターにとっては非効率の極みです。

文字数による容量増加
例えば「35.68951234567」という単なる数値1つを格納するのに、テキストだと15バイト以上の容量を消費します。バイナリ形式であれば半分のバイト数で表現できるため、GeoJSONは本質的にファイルサイズが大きく（重く）なります。

JavaScriptのパース（解釈）負荷
ブラウザがGeoJSONを描画するためには、巨大なテキストをパースしてJavaScriptのメモリ空間に全オブジェクトを展開しなければなりません。データ件数が1万〜10万件を超えると、パース処理だけでブラウザの挙動が重くなり、最悪の場合はクラッシュ（フリーズ）します。

GeoPackageが「安定して高速」な理由

GeoPackageは内部がRDBMS（リレーショナルデータベース）であるSQLiteそのものです。

インデックス機能による高速抽出
空間インデックス（RTree）や属性インデックスが有効に働くため、100万件あるデータの中から「特定の属性を持つ図形」や「特定の地域内のデータ」を一瞬で抽出できます。

データ統合性
ベクターレイヤーを何十個も1つの .gpkg ファイル内にテーブルとして保持できるため、プロジェクトの管理が劇的にラクになります。ただし、SQLiteのファイル構造上、Web経由で部分取得ストリーミング配信を行う用途には向いていません（ローカルでの編集・解析作業に特化しています）。

FlatGeobufが「Webで爆速」な技術的理由

FlatGeobufが「Webマップの救世主」と呼ばれている秘密は、以下の2つの技術的アプローチにあります。

パース処理がゼロ（FlatBuffersの恩恵）
通常、バイナリやJSONを受信したブラウザはデータを解釈（デコード）する処理が必要です。しかし、FlatGeobufは受信したバイナリデータをメモリ上に配置したまま、そのまま即座にレンダリングエンジンへ渡せます。デコードのオーバーヘッドがほぼゼロであるため、巨大なデータでも瞬時に画面に反映されます。

HTTP Range Request と 空間インデックス
FlatGeobufファイルは、先頭領域に「どのデータがどこに配置されているか」を示す空間インデックス（Packed R-Tree）を持っています。

ブラウザ側は、最初にファイルの先頭（インデックス部分）だけを軽量にダウンロードし、「今見ている画面の緯度経度エリアのデータが、ファイルの何バイト目から何バイト目に書き込まれているか」を把握します。

そして、HTTPの Range Request 機能を使って、サーバ上の巨大な .fgb ファイルから必要なバイト領域だけをピンポイントでダウンロードします。

この仕組みのおかげで、仮に1GBを超える全国の全道路データ（.fgb）がサーバに置いてあっても、ユーザーは数メガバイトのデータ通信だけで自分の表示している街の道路を数ミリ秒でWeb画面上に描画させることができるのです。

実務での使い分け・完全選定フロー

これらの特性を踏まえ、実際の仕事やプロジェクトでどのフォーマットを選ぶべきか、分かりやすい判断ツリーを提示します。

【Q1】 主な作業環境はデスクトップGIS（QGIS / ArcGIS）ですか？
  ├── YES ──► 【 GeoPackage (.gpkg) 】 を選択！
  │            (編集、空間解析、ローカル保存、データのまとめ役に最適)
  │
  └── NO (Webマップでの配信やデータ共有がメイン)
        │
        ▼
【Q2】 扱うデータ件数はどれくらいですか？
  ├── 小規模（概ね 1万件未満 / 数メガバイト程度）
  │     └──► 【 GeoJSON (.geojson) 】 を選択！
  │           (シンプルで開発が容易。メモ帳で確認できデバッグもしやすい)
  │
  └── 大規模（数万〜数百万件 / 数十MB〜数GB以上）
        └──► 【 FlatGeobuf (.fgb) 】 を選択！
              (大容量でもWeb上で爆速ストリーミング描画が可能)

具体的なユースケースの例

ユースケース A：「QGISで行政の都市計画データを分析・加工したい」

• 最適解：GeoPackage
• 理由： 属性の書き換えや図形の移動・結合などを繰り返す作業では、GeoPackageのデータベース機能が最も安定・高速です。文字化けのリスクもなく、複数レイヤーを1ファイルで管理できます。

ユースケース B：「店舗の場所（約100件）をWebサイト上のLeafletマップにピン表示したい」

• 最適解：GeoJSON
• 理由： データ件数が非常に少なく軽量なため、テキストで直感的に書けるGeoJSONが最も手軽です。サーバー設定も不要で、JavaScriptとのデータ受け渡しがシンプルに行えます。

ユースケース C：「全国の避難所（数万件）や全色別標高図ベクターデータをWebマップでサクサク見せたい」

• 最適解：FlatGeobuf
• 理由： 全データをGeoJSONでWebに読み込ませるとブラウザが確実にフリーズします。FlatGeobufを採用すれば、ユーザーが開いた画面（例: 東京都渋谷区周辺）のデータだけがストリーミングで読み込まれ、ストレスのない爆速Webマップを提供できます。

補足：関連する重要フォーマット（PMTiles / COGとの関係）

Web空間データの配信においては、FlatGeobufの他にも覚えておくと役立つ関連技術があります。

PMTiles（ベクタータイル）との使い分け

Webマップの背景地図などを配信する際、ベクタータイル（MVT / PMTiles） という技術もよく使われます。

PMTiles / MVT
データをズームレベルごとの「画像のようなタイル」に区切って配信します。拡大率に応じて表示を間引くため、「見た目の描画（背景地図）」に特化しています。

FlatGeobuf
図形の正確な幾何形状（座標）と属性データを間引かずに保持します。Web上で「特定オブジェクトのクリック検索・属性確認・クライアント側での空間解析」を行いたい場合に強力です。

「背景地図として見せるならPMTiles」「データをそのままWeb上で検索・分析させるならFlatGeobuf」という使い分けが一般的です。

COG（Cloud Optimized GeoTIFF）

FlatGeobufが「ベクターデータ」のクラウドストリーミング配信の雄なら、衛星写真や標高データなどの「ラスタデータ」の配信で同様の役割を果たすのが COG です。どちらも「必要な部分だけをRange Requestで読み込む」というクラウドネイティブGISの思想を共有しています。

まとめ

かつてGISの世界を統治していたShapefileの時代は終わりを告げ、現代は用途に応じた「適材適所」のフォーマット選定を行う時代へと移行しました。

最後に、今回紹介した3大フォーマットの役割を短い言葉で復習しましょう。

GeoJSON
手軽さ重視── 小規模データの受渡しやシンプルなWeb表示に。

GeoPackage
編集・解析・万能性── QGISやArcGISで作業・保存する際の絶対的標準。

FlatGeobuf
Webでの爆速描画── 大容量ベクターデータをWebでサクサク動かす決定打。

それぞれの強みと弱みを正しく理解して使い分けることで、GISデータの管理コストは格段に下がり、Webアプリケーションのパフォーマンスも劇的に向上します。

ぜひ、次回のGIS作業やWebマップ開発から、プロジェクトに最適なフォーマットを選び抜いて活用してみてください！