ベクタータイルvsラスタータイル：Webアプリが使うべきはどちらか？

Webアプリにマップを組み込むとき、その後のすべてを左右するアーキテクチャ上の判断が1つあります。ラスタータイルにするか、ベクタータイルにするかです。正しく選べば、マップは速く、見た目がよく、柔軟に変更できます。選択を誤ると、ピクセルの粗い動作の重い背景画像を出荷することになり、デザインシステムとことあるごとに衝突します。

このガイドでは、2つの形式の技術的な違いを説明し、フロントエンド開発者にとって実際に重要なトレードオフを順に見ていき、明確な判断の枠組みを示します。読み終える頃には、自分のプロジェクトにどちらの形式を選ぶべきか、そしてMapAtlasでベクタータイルを使い始める方法がはっきりわかります。

タイル形式の問題は、ほぼすべての地図プロジェクトの初期に持ち上がります。インターネット上には「ベクタータイルのほうが新しい」で止まる表面的な回答があふれています。このガイドはさらに踏み込み、レンダリングのパイプライン、ペイロードのサイズ、ブラウザの互換性、スタイルの制御、そしてラスタータイルが今も正しい選択である具体的な場面を扱います。

すでに開発を進めていてコードだけが必要な場合は、クイックスタートのセクションに進んでください。

ラスタータイルとは

ラスタータイルは、事前にレンダリングされたPNGまたはJPEGの画像で、通常は256×256または512×512ピクセルです。特定のズームレベルにおける世界の固定された一区画を表します。ユーザーがパンやズームをすると、ブラウザは隣接するタイルや高解像度のタイルを要求します。これらのタイルは、サーバーがすでにレンダリングしてキャッシュしたものです。

レンダリングはすべてサーバー側で行われます。ブラウザに届くタイル画像は完成した絵であり、ピクセルの配置も色もすでに焼き込まれています。ブラウザの役割は、それを表示することだけです。

ラスタータイルサーバーの仕組み

ラスタータイルの構成は、一般に次のようになります。

1. 生の地理データ（OpenStreetMap、地籍データ、標高モデル）を処理してデータベースに格納します。
2. レンダリングエンジン（定番はMapnik）が、すべてのズームレベルのタイルを事前にレンダリングしてタイルキャッシュに保存します。
3. タイルサーバー（ラスターモードのTileServer GL、またはマネージドCDN）が、/{zoom}/{x}/{y}.pngのURL規則でキャッシュ済みの画像を配信します。

結果として、シンプルで高速、かつステートレスな仕組みになります。ブラウザ、モバイルアプリ、地図画像を生成するサーバー側のプロセス、GISのデスクトップアプリケーションなど、どのHTTPクライアントでもタイルを要求できます。

ラスタータイルの強み

• クライアント側のレンダリング負荷がゼロ。 ブラウザは画像を表示するだけです。WebGLもシェーダーのコンパイルもフォントのレンダリングも必要ありません。
• どこでも動く互換性。 Internet Explorerやヘッドレスのレンダリング環境を含め、どのブラウザのどのバージョンでも動作します。
• 見た目が予測できる。 マップはタイルサーバーがレンダリングしたとおりに表示されます。クライアント側による違いは生じません。
• サーバー側での画像生成が簡単。 メール、PDFレポート、SNS共有用カードの静的な地図画像の生成に最適です。

ラスタータイルの弱み

• ファイルサイズが大きい。 256×256のPNGタイルは、開けた郊外では数KB、密集した都市中心部では40-45 KB程度になります。Retina用（512×512）のタイルはピクセル数が4倍です。
• 高DPIの画面でピクセルが粗くなる。 1x表示用にレンダリングしたタイルは、2xのRetina画面ではぼやけて見えます。@2xのタイルを配信すれば解決しますが、帯域幅は2倍になります。
• 回転や傾きに対応しない。 ラスターのマップを回転させると、テキストのラベルも一緒に回転して読めなくなります。ラスターのマップがほぼ常に北を上にして表示されるのはこのためです。
• クライアント側でスタイルを変更できない。 道路の色を変えたい、POIのアイコンを非表示にしたい、ダークモードに切り替えたい、といった場合は、サーバー側で事前にレンダリングした新しいタイルセットが必要です。
• ズームの補間。 整数のズームレベルの間では、ブラウザが既存の画像を拡大縮小するため、画像がぼやけます。ベクタータイルで得られる「滑らかなズーム」の感覚は、ラスターにはありません。

ベクタータイルとは

ベクタータイルには、地図のある領域の生の地理データが含まれています。道路のジオメトリ、建物のポリゴン、水域、土地利用の区域、ラベルの配置データなどが、コンパクトなバイナリ（通常はMapbox Vector Tile形式、.mvt）としてエンコードされています。タイルにはピクセルが含まれていません。その領域に何が存在するかを記述しており、どう見えるべきかは記述していません。

レンダリングはすべてクライアント側でWebGLを使って行われます。Mapbox GL JS互換のマップ（MapAtlasなど）を読み込むと、SDKがベクタータイルを要求してジオメトリのデータを受け取り、スタイルの定義に従って道路、建物、ラベルのすべてを<canvas>要素にリアルタイムで、十分な性能のハードウェアなら最大で毎秒60フレームで描画します。

ベクタータイルのレンダリングの仕組み

Vector tile (.mvt) + Style JSON → WebGL shader → Canvas pixels

スタイルJSON（あなたが管理する構造化ファイル）は、レンダラーに次のような指示を与えます。道路はこの色で描く、建物の立ち上げはこの高さで描く、ラベルにはこのフォントを使う、ズーム12未満ではこれらのレイヤーの種類を非表示にする、といった内容です。スタイルは新しいタイルを取得せずに、実行時に変更できます。

ベクタータイルの強み

• ズーム時のダウンロードが少ない。 ベクタータイルはソースの最大ズーム（多くは14）まで取得され、それより近いズームレベルではすべて再利用されます。一方、ラスターのマップはズームを1段階進めるたびに4枚の新しいタイルを取得します。密集した都市中心部では1枚のベクタータイルが同等のラスタータイルより大きくなることもあるため、削減効果はファイルの小ささではなく再利用から生まれます。
• どの解像度でも鮮明。 ベクターのジオメトリは数学的に拡大縮小されます。Retinaディスプレイにも標準のディスプレイと同じタイルが届き、レンダラーがより多くのピクセルを出力するだけです。@2xのタイルの派生版は必要ありません。
• 滑らかなズームと回転。 レンダラーは生のジオメトリを扱うため、ズームを（整数のレベルだけでなく）連続的に補間でき、ラベルを常に正立させたままマップを傾けたり回転させたりできます。
• クライアント側でスタイルを完全に制御できる。 道路の色、ラベルのフォント、レイヤーの表示、不透明度など、あらゆる見た目のプロパティをスタイルオブジェクトの更新だけで変更できます。新しいタイルのリクエストは発生しません。ダークモードは新しいタイルセットではなく、スタイルJSONの差し替えで実現できます。
• 3Dの建物の立ち上げ。 ベクタータイルには建物の高さのメタデータが含まれています。レンダラーはWebGLを使ってポリゴンを3Dで立ち上げられます。ラスタータイルには高さの概念がありません。
• データ駆動のスタイル。 制限速度で道路を色分けする、カテゴリで土地利用を塗り分ける、人口でマーカーの大きさを変えるといったことを、サーバーに手を加えずにタイル内のデータのプロパティだけで実現できます。

ベクタータイルの弱み

• WebGLが必要。 WebGLに対応していなければ、ベクタータイルはレンダリングできません。非常に古いブラウザ（IE11）や一部のヘッドレス環境は対象外になります。
• クライアント側のCPUとGPUの負荷。 レンダリングはユーザーの端末で行われます。ローエンドのAndroidスマートフォンや負荷の高いデスクトップでは、多くのレイヤーを持つ複雑なマップスタイルでフレーム落ちが起きることがあります。
• 初期設定がより複雑。 <img>タグだけでは済まず、レンダリングライブラリ（Mapbox GL JS、MapLibre GL、またはMapAtlas SDK）とスタイルJSONが必要です。
• フォントとグリフの読み込み。 ラベルのレンダリングには、別途配信されるグリフファイルが必要です。そのため、初回読み込み時にネットワークリクエストがいくつか増えます。

パフォーマンスの比較: 実測値

トレードオフを具体的に示すため、ズームレベル14のアムステルダム中心部を公開のOpenStreetMapタイルサーバーで比較した結果を紹介します（2026年9月に計測）。

規模が大きくなると、差はバイト数よりもリクエスト数に表れます。査読付きの負荷試験では、ズームやパンの操作で取得されたタイルはベクタータイルが1、2枚、ラスタータイルが40枚で、ただしベクタータイルのほうが多くのデータを含んでいたことが示されています。月に1,000万回のタイルリクエストが発生する中規模のトラフィックのアプリでは、リクエストが少ないことに意味があります。地図APIの課金単位はタイルリクエストだからです。地図APIの料金ページでは、ジオコーディングやルーティングと並んで、タイルのリクエスト数ごとの料金区分を確認できます。

ラスタータイルを使うべき場面

ラスタータイルは時代遅れではありません。今も正しい選択である場面がはっきり存在します。

レガシーシステムとの統合。 .NET WebFormsのアプリ、サーバーでレンダリングするRailsのビュー、HTMLと基本的なJavaScriptしか扱えない環境にマップを埋め込む場合は、WebGLのレンダラーを導入するより、LeafletやOpenLayersでラスタータイルのレイヤーを使うほうがシンプルで確実です。

サーバー側での地図画像の生成。 メールのテンプレート、PDFのエクスポート、Open Graphの画像のためにNode.jsサーバーで地図のスナップショットをレンダリングする必要がある場合は、ヘッドレスのラスターレンダリングを選んでください。node-canvasとラスタータイルのソースを組み合わせたツールは、WebGLが使えない環境でも動作します。

衛星画像と航空写真。 航空写真は本質的にラスターデータです。ベクターのマップでも、衛星画像のレイヤーは常にラスタータイルとして配信されます。ハイブリッドのマップは両方の形式を組み合わせ、道路とラベルにはベクター、写真のベースにはラスターを使います。

ごくシンプルなユースケース。 お問い合わせページに静的な所在地の地図を埋め込むだけなら、LeafletとOpenStreetMapのラスターによるシンプルな構成が20分で完成し、JavaScriptの複雑さもありません。操作しない所在地のピンのためにベクタータイルへ移行する理由はありません。

ベクタータイルを使うべき場面

次の点を重視する現代的なWebアプリケーションでは、ベクタータイルを選んでください。

• ブランドに合わせたカスタムスタイル。 デザインシステムに決まった色があるなら、マップもその色に合わせるべきです。ベクタータイルなら、これはJSONの変更で済みます。
• ダークモードへの対応。 ダークスタイルのJSONは1つの設定ファイルです。ライトとダークの切り替えはmap.setStyle()の呼び出し1回で済みます。
• 高DPIやRetinaでの鮮明さ。 モバイルファーストのアプリや、鮮明な描画をデザインの優先事項とするUIでは特に重要です。
• 滑らかなユーザー体験。 ベクターのマップの連続的なズーム補間と滑らかなレンダリングは、ユーザーがすぐに気づく違いです。インタラクティブな場面では、比べるとラスターのマップはもたついて感じられます。
• データ可視化のレイヤー。 ベクターのマップにヒートマップ、コロプレス、クラスターのレイヤーを追加するには、クライアント側の設定だけで済みます。ラスターのマップでは、新しいレイヤーのタイルを一括生成するか、canvasを重ねる力技が必要になります。
• 3Dや傾けた視点。 ベクタータイルとWebGLでしか実現できません。

クイックスタート: MapAtlasでベクタータイルを使う

MapAtlasは、Mapbox GL JS互換のAPIでベクタータイルを配信しています。Mapbox GL JSを使ったことがあれば、移行はスタイルURLの変更とAPIキーの差し替えだけです。新しく始める場合の完全な設定手順は次のとおりです。

SDKをインストールする

npm install @mapmetrics/mapmetrics-gl

通常のHTMLプロジェクトなら、CDNから読み込みます。

<link rel="stylesheet" href="https://unpkg.com/@mapmetrics/mapmetrics-gl/dist/mapmetrics-gl.css" />
<script src="https://unpkg.com/@mapmetrics/mapmetrics-gl/dist/mapmetrics-gl.js"></script>

ベクターマップをレンダリングする

import mapmetricsgl from '@mapmetrics/mapmetrics-gl';
import '@mapmetrics/mapmetrics-gl/dist/mapmetrics-gl.css';

const map = new mapmetricsgl.Map({
  container: 'map',         // <div> の ID
  style: 'https://gateway.mapmetrics-atlas.net/styles/?fileName=YOUR_STYLE_ID/style.json&token=YOUR_API_KEY',
  center: [4.9041, 52.3676], // [経度, 緯度]、アムステルダム
  zoom: 12,
  pitch: 0,     // 0 = 真上から、60 = 3Dで傾ける
  bearing: 0,   // 0 = 北が上、それ以外の値 = 回転
});

styleのURLは、MapAtlasのサーバーでホストされているJSONファイルを指しており、すべてのレイヤー、フォント、ソースを定義しています。カスタムのスタイルJSONを自分でホストして、マップの見た目のあらゆる要素を制御することもできます。詳しくはMap Visualization & Stylingのガイドをご覧ください。

実行時にダークモードへ切り替える

const LIGHT_STYLE = 'https://gateway.mapmetrics-atlas.net/styles/?fileName=YOUR_STYLE_ID/style.json&token=YOUR_API_KEY';
const DARK_STYLE  = 'https://gateway.mapmetrics-atlas.net/styles/?fileName=YOUR_DARK_STYLE_ID/style.json&token=YOUR_API_KEY';
let isDark = false;

document.getElementById('toggle-dark').addEventListener('click', () => {
  isDark = !isDark;
  map.setStyle(isDark ? DARK_STYLE : LIGHT_STYLE);
});

すでにキャッシュされているデータについては、新しいタイルのリクエストは発生しません。変わるのはスタイルだけで、タイルは同じバイナリのジオメトリのまま、新しい色で再レンダリングされます。

GeoJSONのデータレイヤーを追加する

ベクタータイルの特に便利な機能の1つが、独自のデータをスタイル付きのレイヤーとして重ねられることです。

map.on('load', () => {
  // 独自のデータソースを追加
  map.addSource('delivery-zones', {
    type: 'geojson',
    data: {
      type: 'FeatureCollection',
      features: [
        {
          type: 'Feature',
          geometry: {
            type: 'Polygon',
            coordinates: [[[4.85, 52.34], [4.95, 52.34], [4.95, 52.40], [4.85, 52.40], [4.85, 52.34]]],
          },
          properties: { zone: 'Zone A', capacity: 150 },
        },
      ],
    },
  });

  // 色付きの塗りつぶしレイヤーとしてスタイルを設定
  map.addLayer({
    id: 'delivery-zones-fill',
    type: 'fill',
    source: 'delivery-zones',
    paint: {
      'fill-color': '#97C70A',
      'fill-opacity': 0.2,
    },
  });

  map.addLayer({
    id: 'delivery-zones-outline',
    type: 'line',
    source: 'delivery-zones',
    paint: {
      'line-color': '#97C70A',
      'line-width': 2,
    },
  });
});

ソースを追加し、レイヤーを追加し、スタイル式で描画するというこのパターンは、ヒートマップ、ルートの線、等時線のポリゴン、コロプレスマップでも同じです。これが成り立つのは、ベクタータイルが完成したピクセルではなく、生のジオメトリをレンダラーに渡すからです。

ラスターからベクターへの移行

Leafletとラスタータイルによる既存の構成をアップグレードしたい場合、最小限の移行手順は次のとおりです。

1. Leafletを置き換える: MapAtlas SDK（完全なオープンソースのレンダラーを使いたい場合はMapLibre GL JS）に切り替えます。
2. タイルのURLを置き換える: MapAtlasのスタイルJSONのURLに変更します。
3. オーバーレイを移す: LeafletのレイヤーをGL JSのソースとレイヤーに移行します。
4. WebGLがない環境でテストする: WebGLを使えない一部のユーザー向けに、フォールバックまたは機能を段階的に縮小したメッセージを追加します。

機能面では、より鮮明に見え、より速く読み込まれ、サーバーに手を加えずにスタイルを変更できるマップが得られます。

ベクタータイルをベースに、マーカー、ポップアップ、住所検索、Reactとの統合を追加する手順の全体は、ウェブサイトにインタラクティブなマップを追加する方法をご覧ください。

ダークモード、ブランドカラー、カスタムフォント、透かしの削除など、スタイルをさらに作り込むには、ブランドに合わせたカスタムマップのスタイル設定方法をご覧ください。

コストと機能の観点からMapAtlasとGoogle Mapsを比較検討している場合は、MapAtlas vs. Google Maps: 開発者が乗り換える理由で主な違いを解説しています。

まとめ: 判断の枠組み

2026年にインタラクティブなものを作るなら、ベクタータイルが標準の選択です。ラスタータイルは、特定の互換性やレンダリングの制約がある場合に意図して選ぶ例外です。

ベクタータイルで開発を始める準備はできましたか？MapAtlasの無料APIキーに登録してください。クレジットカードは不要です。キーは初日から、タイル、ジオコーディング、ルーティング、等時線のAPIで使えます。