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	GeoPackage	FlatGeobuf
データ保持形式	テキスト (JSON)	データベース (SQLite)	バイナリ (FlatBuffers)
ファイル容量	非常に重い (約2〜3倍)	コンパクト	非常にコンパクト
読み込み速度	遅い (パース処理が必要)	速い	爆速 (パース不要)
部分取得 (HTTP Range)	不可 (全データロード必須)	不可 (ローカル利用前提)	可能 (画面内のみ取得)
ラスタデータの格納	不可	可能 (画像・標高等)	不可 (ベクターのみ)
主データ編集	不向き	非常に強い	閲覧・配信向け
主な得意環境	Webブラウザ (小規模)	GISデスクトップソフト	Webブラウザ (大規模)

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

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

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

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マップ開発から、プロジェクトに最適なフォーマットを選び抜いて活用してみてください！

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