2026.08.22 業務システム

Web GISとは？タイル配信とベクタタイル・ライブラリ選定を実装目線で解説【2026年8月時点】

Web GISとは、地理情報システムの機能をブラウザ上で提供する構成を指します。サーバ側で地図とデータを配信し、閲覧と簡易な編集はブラウザが担う。実装者が向き合うのは「地図を出す」ことではなく、どの単位でデータを切り出して送るか、誰が背景地図の更新を追うか、何件まで描いて止めるかという設計です。本記事では構成要素を四層に分け、配信方式の三択、ライブラリ選定、描画性能と同時接続の見積り、費用構造の順に整理します。版番号は2026年8月22日に実測しました。

まとめ｜Web GISの構成要素と配信方式・ライブラリ選定の結論

先に結論を置きます。Web GISの実装で決めるのは三つです。データをどの単位で切り出して配信するか、クライアントに何を描かせるか、背景地図とライセンスを誰が維持するか。ライブラリの機能比較から入ると、この三つが後回しになって作り直しが発生します。

配信方式は静的タイル・動的タイル・地物APIの三択です。更新が日次以下なら事前生成した静的タイルをオブジェクトストレージから配るのが最も軽く、随時更新で属性の絞り込みが要るならPostGISのベクタタイル生成を挟む。編集まで要るならOGC API – Featuresに寄せますが、書き込みを担うPart 4は2026年8月時点で草案のため、更新系は自前の設計になります。

クライアント側は、機能ではなく更新の速さで切るのが実務的でしょう。MapLibre GL JSは2026年7月22日のv6.0.0でESM専用配布へ移行し、8月21日のv6.5.0まで1〜2週間隔で更新が続く一方、Leafletは安定版1.9.4が2023年5月18日で止まったままです。製品の選定から整理したい場合は、判断ハブのGISとは？地理情報システムの仕組み・種類と業務システムへの組み込み判断を先に読んでください。

Web GISとは何か、四層構成で見る仕組みとデスクトップGISとの分かれ目

まず言葉の範囲を固定します。Web GISは仕組み全体を指す場合と地図配信サーバだけを指す場合があり、この取り違えが見積りの食い違いを生みます。

Web GISの構成要素をデータ層・配信層・API層・描画層に分ける

四つの層に分けると責任範囲がはっきりします。データ層は空間データを保持する層で、PostgreSQLにPostGIS拡張を入れた構成が定番でしょう。2026年8月時点の正式版は3.6.4（2026年6月8日）、3.7系はベータ2が8月10日に出た段階です。配信層はその中身をタイルや画像へ変換して配る層で、GeoServerのようなマップサーバ、PostGISから直接ベクタタイルを作るMartin、事前生成ファイルを置くオブジェクトストレージが該当します。

API層は地物を条件付きで取り出す層で、クリックした地物の属性を返す処理はここが担う。描画層はブラウザ側です。デスクトップの地図ソフトとの分かれ目もここにあり、解析はサーバ側に残し、ブラウザには描画と絞り込みだけを任せるのが安定した構成でしょう。

ラスタタイルとベクタタイルの違いが実装工数と運用の手間に及ぼす差

配信されるタイルには二種類あります。ラスタタイルは、サーバ側で描画まで済ませた画像です。ブラウザは並べるだけなので端末の負荷は軽い。代わりに色や線幅を変えるには画像を作り直す必要があり、属性も持たないため、クリック時の情報表示は別のリクエストで補います。

ベクタタイルは、図形と属性をバイナリで詰めて送る形式になります。描画はブラウザ側がWebGLで行うため、色分けや絞り込みをサーバに戻らず切り替えられる。見た目を利用者ごとに変える要件があるなら、この形式でないと成立しません。ただし生成時にズームレベルごとの間引き設計が要り、定番ツールのTippecanoeは2.79.0（2025年7月24日）が最後のリリースです。

比較項目	ラスタタイル	ベクタタイル
描画の場所	サーバ側	ブラウザ側
スタイル変更	画像の再生成	設定の切り替えのみ
属性の保持	持たない	タイル内に持つ
端末の要件	ほぼ不問	WebGL対応が前提
向く用途	背景地図・航空写真	主題データの絞り込み

両方を一つの地図に重ねる構成も成立します。背景は地理院タイル、自社データはベクタタイルという組み合わせが実務では多い形です。

タイル座標と座標系の指定、地理院タイルを背景に重ねる際の条件

タイルはズームレベルと縦横の番号で位置が決まります。基本は256ピクセルの正方形で、ズームレベル0が全世界を収めた1枚、レベルが1つ上がるごとに縦横のタイル数が2倍になる。1段深くなるたびに必要な枚数は4倍です。URLがこの三つの数字だけで決まるため、キャッシュとの相性が良い性質もここから来ます。

座標系は二本立てで考えます。保存側は日本測地系2011を基準にした地理座標系（EPSG:6668）、描画側はWebメルカトル（EPSG:3857）。取り込むデータが旧測地系のままだと数百メートル単位でずれるため、受け入れ時に測地系を記録する運用を初期設計へ入れておく。距離を測る処理は緯度経度のまま計算せず、平面直角座標系へ投影してから行うのが基本です。背景は国土地理院の地理院タイルを読み込む構成が現実的で、ベクタタイルとしては地理院地図Vectorが2020年3月19日に全国データの公開を開始しています。取り込むデータ側の形式ごとの制約とEPSGコードの体系はGISデータとは？形式・座標系・取り込み設計を実装目線で解説にまとめました。

地図データの配信方式は静的タイル・動的タイル・地物APIの三択で決まる

次に自社データの配り方を決めます。ここが構成の骨格で、後から変えると配信層とクライアントの両方に手が入ります。

PMTilesを含む事前生成の静的タイルが向く更新頻度と件数の範囲

最も運用が軽いのは、タイルを事前に作ってファイルとして置く方式です。オブジェクトストレージへ配置してCDNから配れば、サーバプロセスが不要なので監視も冗長化も要りません。

単一ファイルにまとめられるPMTiles形式なら、HTTPのRange取得で必要な部分だけを読めるため、1ファイル置くだけで配信が成立する。JavaScript実装のpmtilesは4.5.0（2026年8月10日）が最新です。向くのは更新が日次以下の場合で、反映が数分以内に求められる要件では、生成時間が反映の下限になるため成立しません。

PostGISで動的にベクタタイルを生成する構成と負荷の逃がし方

更新が随時発生し、属性による絞り込みも要件なら、リクエストのたびにタイルを作る構成を選びます。PostGISには地物をベクタタイル形式へ変換する関数があり、タイル範囲の切り出しと合わせてSQL一本で書けます。

SELECT ST_AsMVT(t, 'facilities') FROM (
  SELECT id, name,
         ST_AsMVTGeom(geom, ST_TileEnvelope(z, x, y)) AS geom
  FROM facilities
  WHERE geom && ST_TileEnvelope(z, x, y)
) AS t;

ここで効くのが空間インデックスです。ジオメトリ列にGiSTインデックスを張っていないと、タイル1枚ごとに全件走査が走って即座に詰まる。データベース選定の段階なら、PostGISが使える点はPostgreSQLを選ぶ実質的な理由になり、両者の違いはPostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け【2026年版】にまとめました。

タイルサーバを自前で書かずに済ませるなら、PostGISのテーブルを読んでベクタタイルを返すMartinのような実装があり、2026年8月18日にv1.14.0が出ています。動的生成はズームレベルが低いタイルに負荷が集中するため、浅い側だけ事前生成して混在させると負荷は目に見えて落ちます。

OGC API – FeaturesとWMS・WMTS・WFSの使い分けの判断軸

タイルではなく地物そのものを取り出す口も要ります。従来はOGCのWMS（画像を返す）、WMTS（タイル画像を返す）、WFS（地物を返す）の三系統でした。現在はこれらをRESTとJSONで置き換えるOGC API群が整備され、OGC API – Featuresは2026年8月時点でPart 1 Coreがv1.0.1、Part 2の座標参照系がv1.0.1、Part 3のフィルタリングがv1.0.0として承認されています。

実装判断に効くのは、承認されていない部分のほうでしょう。作成・置換・更新・削除を定義するPart 4とスキーマを扱うPart 5は草案の段階で、読み取りは標準に沿って組めても書き込みAPIは自前設計になる。編集機能を標準準拠で作り切ろうとすると、この一点で計画が崩れます。

サーバ実装としてはGeoServerが定番で、2026年8月14日付で3.0.1・2.28.5・2.27.6が同時に出ている。3.0系の登場は6月11日なので、新規構築なら3.0系、既存環境なら2.28系を追う選び分けが無難です。地図ソフトそのものの比較はGISソフトの比較｜無料・商用・クラウドの選定軸と受託開発への切替点に整理しました。

三つの配信方式の比較と、どの条件でどれを選ぶかの対応関係の一覧

比較項目	静的タイル	動的タイル	地物API
更新の反映	生成の周期に依存	ほぼ即時	即時
件数の上限	生成時間で決まる	索引と負荷で決まる	応答サイズで決まる
サーバ構成	ストレージのみ	DBとタイルサーバ	APIサーバ
初期実装量	小	中	中から大
向く要件	背景・固定の主題図	随時更新の業務データ	編集と詳細取得

実務では、この三つは排他ではありません。背景は静的、業務データは動的、クリック時の詳細は地物APIという組み合わせが最も多く、一つの方式で全部を賄おうとする設計があとで詰まります。

地図ライブラリの選定はMapLibreとLeafletの更新速度で切る

クライアント側の選定は、機能表の比較では差が出ません。どれも地図は出るためです。効くのは、そのライブラリが今どれだけ動いているかという性質でしょう。OGC標準への対応幅が広いOpenLayers（latestは10.10.0・2026年7月27日）は、WMTSやWFSを直接扱う構成でその幅が実装量の差になります。

MapLibre GL JS 6系のESM専用配布で発生する移行作業の中身

MapLibre GL JSは、ベクタタイルをWebGLで描くライブラリです。v6.0.0が2026年7月22日に公開され、配布形態が変わりました。ESM専用の配布物に切り替わり、従来のUMDバンドルは公開されていません。CSP専用のバンドルも廃止され、ワーカーを実URLとして読み込む構成に変わったため、blobのワーカー許可は不要になりました。

移行時に手が入るのは三か所です。scriptタグで直接読み込んでいた箇所はモジュール指定へ書き換える、既定インポートで受けていた箇所は名前空間インポートへ変える、CSPを緩めていた設定は外す。さらにMapがCameraを継承せず内包する構造へ変わり、内部プロパティを直接触っていたコードは公開APIへ寄せる作業が生じます。更新は7月30日のv6.1.0から8月21日のv6.5.0まで1〜2週間隔で続くため、長期保守なら採用する版を固定する方針を先に決めるべきでしょう。

Leafletの安定版が三年更新されていない事実をどう受け止めるか

Leafletは、ラスタタイルを軽量に扱えるライブラリとして広く使われてきました。ただし2026年8月時点で、npmのlatestは1.9.4のままです。公開は2023年5月18日で、三年以上正式リリースが出ていない。2.0系は2025年5月のアルファ、8月のアルファ1で止まり、直近コミットも依存パッケージの更新が中心でした。

更新が止まっている＝使えない、と読むのは誤りです。Leafletが担うのは地図の表示と操作という枯れた領域で、仕様が動かない部分になります。既存のプラグイン資産があり、扱うのがラスタタイルと数千件程度の点データなら、1.9.4を版固定して使う判断は成立する。逆にベクタタイルを主題データとして扱う、数万件を描くといった要件はWebGL前提の設計が要るため、MapLibreへ寄せたほうが総工数は下がります。

描画性能と同時接続の設計、件数の壁とタイルキャッシュの効かせ方

止まる原因はほぼ二つです。一度に描く地物が多すぎるか、タイルのリクエストがオリジンまで届きすぎているか。どちらも設計段階で数えれば防げます。

数万件の地物をブラウザへ送りたい要件を三つの手当てで折り返す

数万件の点データをそのままGeoJSONで送ると、応答は数十メガバイトに達し、描画以前に受信で止まります。手当ては三つ。タイル化して見える範囲だけを送る、ズームが浅い間は集約表現に切り替える、タイルの属性を絞って詳細は地物APIで取りに行く、の三点です。

三つ目は見落とされがちですが効きます。タイルに載せるのは識別子と表示に要る二、三項目だけにして、残りはクリック時に取得する。属性を全部詰めたタイルは容量が数倍になります。要件定義では、総件数・同時表示の最大件数・属性項目数・更新頻度の四つを先に確認してください。

タイルのキャッシュ制御とCDN配信で転送量と応答時間を抑える

タイルのURLはズームレベルと座標だけで決まるため、キャッシュとの相性が極めて良い。同じ地域を見る利用者が多い業務システムならCDNのヒット率は高くなり、オリジンへ届くリクエストは一部で済みます。CDN側の仕組みと制御の考え方はCDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説に整理しました。

設計で決めるのは保持期間と更新の方法です。作り直すたびに全タイルを消して回る運用は、件数が増えるほど破綻する。確実なのは、タイルのパスに世代を表す文字列を含め、生成のたびに新しい世代へ切り替える方法です。古い世代は保持期間の経過で落ちるため、消去を待たずに切り替えられます。

同時接続数から毎秒のタイルリクエスト数を見積もる計算の手順を示す

必要な処理能力は、画面を覆うタイル枚数から積み上げます。1920×1080の表示領域を256ピクセルのタイルで覆うと横8枚・縦5枚で40枚、境界にまたがる分を含めると9枚×6枚の54枚が上限。512ピクセルのタイルなら、この4分の1に収まります。

ここに操作の頻度と人数を掛けます。利用者100人が同時に操作し、1人が1分間に10回移動や拡大を行うなら、毎分の要求は40枚×10回×100人でおよそ4万件、秒あたりおよそ670件。CDNのヒット率が9割なら、オリジンに届くのは秒あたり67件で動的生成でも捌ける水準です。外しやすいのは絞り込み条件が利用者ごとに違う主題データで、URLに条件が乗ってキャッシュが分散するため、地物APIへ分けて設計します。

ライセンスとコスト設計、地理院タイルとSaaS地図APIの費用構造

最後に費用です。開発費よりも配信の継続費用と規約に沿った運用の手間で決まります。ここを詰めずに構成を選ぶと、稼働後に想定外の請求が発覚します。

地理院タイルの利用条件と出典の明示、申請が必要になる場面の線引き

背景地図の無償の選択肢として現実的なのが地理院タイルです。基本測量成果にあたるタイルをリアルタイムに読み込む場合、出典の明示のみで申請は不要とされています。出典は「国土地理院」または「地理院タイル」と記載し、一覧ページへのリンクを置く形が求められます。

注意すべきは、読み込み方が変わると扱いも変わる点でしょう。自社サーバへ保存して再配信する、加工して別の成果物にするといった利用は別の扱いになります。自前でキャッシュを持つ構成へ踏み込むなら事前に条件を確認する、という線引きを設計レビューの項目に入れてください。自治体案件での庁内共用と公開の役割分担は統合型GISとは？個別GIS・公開型GISとの違いと自治体の調達判断で扱いました。

SaaS地図APIの課金単位と自前運用の損益分岐はどこで見るか

商用の地図サービスは、課金の単位が製品ごとに違います。地図の読み込み回数、タイルのリクエスト数、月間の利用者数、ジオコーディングの件数。同じ利用量でも単位が違えば請求は桁で変わるため、比較の前に自社の使い方を「回数」「利用者数」「件数」のどれで表せるかを決めます。AWSで組む場合の機能と課金体系はAmazon Location Serviceとは？地図・検索・ルート・追跡の機能と料金に整理してあります。

自前運用側の費用は、サーバとストレージと転送量、そして運用工数です。損益分岐を左右するのは最後の項目でしょう。タイルサーバの監視、データベースの版上げ、生成バッチの失敗対応を誰が担うか。この人件費はSaaSの利用料を上回りがちで、表示回数が限られるうちはマネージドが安く、回数が伸びた時点で自前が有利に転じます。位置情報の入力側の費用は測位の話で、LBSとは？GPS・Wi-Fi測位の仕組みと位置情報サービスの事例で扱う領域です。

Web GISを内製するか地図APIで済ませるか、採用条件と見送る場面

ここまでを判断に落とします。以下は、実装の相談を受けたときに実際に切っている線です。

SaaSの地図サービスとマネージド構成だけで足りる三つの条件

次の三つが揃うなら、地図サービスを使い自前のタイル配信は持ちません。第一に、必要な処理が表示・検索・単純な距離判定に収まること。第二に、地図へ出すデータが数千件規模で更新が日次以下であること。第三に、背景地図の更新を追う体制を持たないこと。

三つ目が実は決定的です。背景地図は道路も建物も変わり続けるため、自前で持つと更新が止まった瞬間に古い地図で業務が回り始める。追う体制がないなら背景は外部に任せる一択で、ここを外すと二年目以降に地図が実態と合わなくなります。

PostGISとタイルサーバを自前で建てる判断が成立する条件

逆に、次のいずれかに該当するなら自前構成が成立します。地物が数万件を超え、属性による絞り込みが業務の中心にある場合。位置データを外部のサービスへ送れない制約がある場合。空間検索の結果を既存業務のトランザクションと同じデータベースで扱いたい場合。

三つ目は費用対効果が読みやすい条件でしょう。受注データや設備マスタと同じデータベースに空間列を持てば、地図の絞り込みと業務の集計を一つのSQLで書けます。外部へ複製する構成だと同期が要り、それが壊れた日に地図は事実と違うものを表示する。当社ではブラウザで動く業務システムの設計と実装を業務用・Webアプリ開発として受託しており、既存データベースへの空間機能の追加から地図画面の実装まで対応します。

Web GISとして作らず、一覧と住所リンクに留めるべき場面

作らない判断も明示します。地図に出したいデータが数百件規模で更新が月次以下なら、地図機能そのものを作らないほうが総費用は下がる。一覧表の住所に地図サービスへのリンクを置けば目的は達成できるためです。

もう一つ、地図が意思決定に使われない場合も見送ります。報告資料の見栄えのために地図を出したいという要望は、稼働後に使われなくなる典型でしょう。基準は「地図を見て人が何かを決めるか」。決めないなら、投資は回収できません。

よくある質問

実装検討で実際に挙がる質問を、判断に直結する順に並べました。

Web GISと地図アプリの埋め込みは何が違いますか？

違いは、自社データを条件で絞り込めるかどうかです。埋め込みは地点を示すところまでを担う。Web GISは自社の空間データを配信層から送り、属性による絞り込みや範囲検索を成立させます。「この範囲の未点検設備だけを出す」という要求が入った時点で、埋め込みでは届きません。

ラスタタイルとベクタタイルはどちらを選ぶべきですか？

背景として置くだけならラスタ、利用者が見た目や条件を変えるならベクタです。迷う場合は「属性で色を変える要件が将来出るか」で決めてください。出るならベクタで組んでおくほうが安く、後からラスタをベクタへ変える改修は配信層とクライアントの両方に及びます。

Leafletは今から採用しても問題ありませんか？

ラスタタイル中心で、扱う地物が数千件規模なら問題ありません。安定版1.9.4は2023年5月18日の公開で以降更新が出ていませんが、担う範囲が枯れているため実害は出にくい。ただし版を固定し、2.0系のアルファ向けプラグインを混ぜない運用は決めておく。ベクタタイルやWebGL描画が要件なら別を選びます。

地理院タイルは商用のシステムに組み込めますか？

基本測量成果にあたるタイルをリアルタイムに読み込む形であれば、出典の明示のみで申請は不要とされています。出典として「国土地理院」または「地理院タイル」を記載し、一覧ページへのリンクを置く。自社サーバへ保存して再配信する場合は扱いが変わるため、その構成を選ぶ前に条件を確認してください。

PostGISを使わずに位置検索を実装できますか？

緯度経度を数値列で持ち、矩形の範囲で絞り込むだけなら通常のインデックスでも動きます。数千件規模で検索が「この四角の中」に限られるならこれで足りる。ただし多角形の内外判定、距離順の並べ替え、重なり判定が入った時点で、空間インデックスなしでは実用的な速度が出ません。要件が見えているなら最初からPostGISを入れるほうが手戻りは小さくなります。