はじめに
２０２６年４月２１日から、「日本の地番図をみんなで整備する」をミッションとして、オープン地番ZooというWeb地図サービスを運用しています。
オープン地番Zooは、公図ポリゴンを編集し、蓄積・公開していくサービスで、サービス開始から１ヶ月になりますが、２２０万筆の登録データがあります。
本記事では、大量の動的ポリゴンデータを登録・配信するための手法として考案した GZTiles方式（造語）を解説します。
- 登録：fetch→Queue（
.zip）→ SQLite（.db）→ .gz再生成（.gz） - 配信：タイルインデックスの
.json、タイル単位で事前生成された.gz - 表示：JSが直接タイルデータ（
.gz）をfetch
というシンプルなアーキテクチャです。
※SQLite、PHPが使える環境であれば可能です。
実測値（2026年5月時点）
| 項目 | 値 |
|---|---|
| 公図ポリゴン総数 | 約220万筆 |
| SQLite DBサイズ | 2.78 GB |
| tiles/.gzファイル数 | 1,675ファイル |
| tiles/.gz合計サイズ | 228 MB |
| tiles_dissolve/.gzファイル数 | 119ファイル |
| tiles_dissolve/.gz合計サイズ | 2 MB |
OCZのデータ特性
① 増大し続けるデータ
現在の登録数は約220万筆ですが、最終的には数千万筆規模になることを想定しています。配信アーキテクチャは最初からそのスケールに耐えられる設計が必要です。
※１日平均５万筆ほど増加しています。
② 常に差分更新が発生する
OCZはクラウドソーシング型のプロジェクトです。参加者が随時ポリゴンを編集・保存するため、データは常に変化し続けます。更新のたびに全データを再処理するような方式は、データ量が増えるほどサーバー負荷がかかります。また、ローカルで処理しサーバーにUPする方法もデータ量とともに負担が増えると同時にタイムラグが生じます。
③ 形状・属性を劣化させられない
公図ポリゴンは表示するだけでなく、編集にも使用します。一般的なベクトルタイルのようにズームレベルに応じて間引き・簡略化してしまうと、正確な形状が失われ、表示専用のデータにしかなれません。
④ 即座に地図反映が必要
参加者が編集・保存した内容は、すぐに地図上に反映される必要があります。バッチ処理で数時間後に反映されるような設計はユーザー体験を損ないます。
⑤ 普通のレンタルサーバーで動かす
GISサーバーや専用インフラは使用しません。さくらインターネットのスタンダードプランという、ごく一般的なレンタルサーバー上で完結させる必要があります。
既存手法では対応できない理由
これら5つの条件を同時に満たす既存手法は存在しませんでした。
| 手法 | 問題点 |
|---|---|
| PMTiles・MVT | レンタルサーバー上でTippecanoeを動かしてタイル生成するのは現実的でない。全体再生成が基本設計のため差分更新に不向きで、データ量が増えるほど生成コストが累積的に増大する |
| FlatGeobuf | HTTPの範囲リクエストで高速な部分取得が可能だが、動的に更新されるデータをリアルタイムでサーバー上で再構築するのは困難 |
| 動的GeoJSON API | DBアクセスのたびに負荷が発生し、数千万筆規模では同時アクセスに耐えられない |
これらの課題をすべて回避するために考案したのがGZTiles方式です。
GZTiles方式とは
静的な.gzファイルをタイル単位で事前生成し、JSが直接fetchするアーキテクチャです。
※タイルを管理するindex.jsonあり
- DBアクセスなし：静的ファイルをfetchするだけ
- GISサーバー不要：通常のWebサーバー（Apache/nginx）のみで動作
- ポリゴン形状を完全保持：間引き・簡略化なし
-
差分更新：管理用
index.json、影響タイルの.gzを上書き - スケーラブル：データ量が増えても1回の更新処理コストは変わらない
アーキテクチャ設計
ファイル構成
/maps/
tile_index.json ← タイルキー インデックス（約34.4 KB）
dissolve_index.json ← Dissolveタイルキー インデックス（約2.1 KB）
tiles/
14-14520-6447.gz ← GeoJSONをgzip圧縮（1,675ファイル / 合計228 MB）
...
tiles_dissolve/
10-881-411.gz ← Dissolve済みGeoJSON.gz（119ファイル / 合計2 MB）
...
タイルキーは {z}-{x}-{y} 形式。tile_index.json はどのタイルデータがあるかのリストで、リストのみを先にDLします（不要なリクエスト防止）。
ズームレベルの選定
GZTiles方式では、表示ズームレベルに応じて2種類のタイル層を使い分けています。
| 層 | データズームレベル | 表示ズームレベル | 内容 | ファイル数 | サイズ |
|---|---|---|---|---|---|
| Dissolve層 | ZL10 | ZL10〜16 | クラスターID単位で融合・軽量化（広域表示用） | 119 | 約2 MB |
| Detail層 | ZL14 | ZL16〜24 | 完全な形状を保持（詳細・編集用） | 1,675 | 228 MB |
Detail層のズームレベルは、表示精度・リクエスト回数・ファイル数の3点を考慮してZL14を採用しました。ZL15にするとタイル数が4倍に膨らむため、日本全国規模のデータを扱う場合にはZL14が最適と判断しました。
〜ZL13:１ファイルが大きくなる（DL時間、メモリ負荷）
ZL14:ちょうど良い（サイズ・ファイル数）
ZL15〜:ファイル数が多くなる。（ファイル数制限）
さくらインターネット スタンダードプランのファイル設置可能数は300万ファイル（公式仕様）です。ZL15以上にするとファイル数が爆発的に増加するため、この上限も選定の根拠の一つとなっています。
.gzファイルの内容
各ファイルは通常のGeoJSON FeatureCollectionをgzip圧縮したものです。タイルをまたぐクラスターは両方のタイルに重複収録し、クライアントのJS側で _fid（フィーチャーID）で重複排除します。
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"geometry": { "type": "Polygon", "coordinates": ["..."] },
"properties": {
"kuiki_cd": "13101_001_001_0000_00",
"chiban": "100",
"_fid": "abc123"
}
}
]
}
JavaScript実装
読み込みフロー
ページロード
→ tile_index.json fetch
→ 画面内タイルの.gz fetch
→ MapLibre GeoJSONソースにUpdate
キャッシュ戦略
.gzファイルはブラウザのHTTPキャッシュに乗せつつ、展開済みのフィーチャーをJS変数（Mapオブジェクト）にもインメモリキャッシュとして保持します。表示範囲外になったタイルはメモリから削除（evict）しますが、再度その範囲に移動した際はHTTPキャッシュから.gzを再取得・展開するだけで済み、サーバーへのリクエストが発生しません。このキャッシュにより、パン操作のたびに同じファイルをサーバーから取得し直すコストを排除しています。
PMTilesとの比較・使い分け
| 観点 | GZTiles方式 | PMTiles |
|---|---|---|
| ファイル形式 | タイルごとの.gzファイル群 | 単一の.pmtilesファイル |
| 更新 | 影響タイルのみ上書き可能 | 全体再生成が基本 |
| 用途 | 頻繁に更新される編集データ | 静的な大規模ベースマップ |
| クライアント | ネイティブfetch API | maplibre-pmtilesライブラリ |
OCZではベースマップ（公共座標公図・農地ナビ）はPMTiles、ユーザー編集データはGZTilesと使い分けています。更新頻度と更新粒度がキーになります。
運用上の注意点
タイルまたぎクラスターの重複収録
1つのフィーチャーが複数タイルにまたがる場合、全タイルに同じフィーチャーを重複収録します。JS側で _fid をキーにしたSetで重複排除してから地図ソースに追加します。
体感速度
GZTiles方式は、PMTilesなどのベクトルタイルと同様、軽量な静的ファイルのfetchのため、高速な地図表示が可能です。
【OCZ Viewer】
https://office-shirado.github.io/view_ocz/
ぜひ、こちらから体験ください。
※青色：GZTiles（地番図）、赤色：PMTiles（公共座標公図）
まとめ
| 観点 | GZTiles方式 |
|---|---|
| インフラ | 通常のWebサーバーのみ・GISサーバー不要 |
| データ品質 | 形状・属性を完全保持 |
| 更新 | 影響タイルのみ差分再生成 |
| スケーラビリティ | データ量が増えても更新コスト一定 |
| 同時アクセス | 静的ファイル配信のため高耐性 |
GZTiles方式は特別なインフラを必要とせず、PHPとWebサーバーだけで数百万筆規模のポリゴン配信を実現できます。同じような課題を抱えているWebGISプロジェクトの参考になれば幸いです。