はじめに

２０２６年４月２１日から、「日本の地番図をみんなで整備する」をミッションとして、オープン地番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プロジェクトの参考になれば幸いです。