3D Tilesとは何か？基本概念から最新トレンド、活用事例まで徹底解説

近年、都市の「デジタルツイン（現実空間のデジタル模倣）」やメタバース、スマートシティの構築において、3D空間データの活用が急速に進んでいます。しかし、超高精度な3D都市モデルや、レーザースキャンによる点群データは非常に容量が大きく、Webブラウザやモバイル端末でスムーズに表示・操作するのは困難でした。

この課題を解決するために開発されたのが、オープンな標準規格である 3D Tiles です。

この記事では、3D Tilesの定義、仕組み、従来の2Dタイルとの違い、進化を続けるバージョンごとの特徴、そして実際の活用事例まで分かりやすく解説します。

3D Tilesの基本概要

3D Tiles とは、テラバイトやペタバイト規模に及ぶ膨大な3D地理空間データを、Webやデスクトップ、モバイルアプリケーション上で高速にストリーミング配信・描画するために設計されたデータ規格です。

CesiumGS社 が主導して開発し、地理空間情報の国際標準化団体である OGC (Open Geospatial Consortium) の「コミュニティ標準規格」として2018年に正式に採用されました。
その目的は、BIMなどの3Dモデルや、地形、フォトグラメトリ、点群などの多様な3Dデータを、ネットワークの帯域やPCのスペックに依存せず、効率よくユーザーに届けることです。

なぜ3D Tilesが必要なのか？

従来のWeb地図でおなじみの「2Dタイル（XYZタイル）」と「3D Tiles」を比較すると、3D Tilesがなぜ革新的なのかがよく理解できます。

従来の2Dタイルのアプローチ

2D地図では、地球を緯度・経度の格子状（4分木）に分割し、ズームレベルに合わせて「画像（PNG/JPEG）」や「ベクトルデータ（MVT）」のタイルを配信します。 しかし、3D空間には「高さ（Z軸）」があり、視点の角度（カメラの傾き）や距離によって表示すべきデータが動的に変化します。

3D Tilesのアプローチ

3D Tilesは、平面的に分割するだけでなく、「空間全体を立体的な境界で階層的に分割」します。

そして、視点に近い場所やズームインした場所では超高解像度な3Dモデル（詳細なテクスチャ、複雑なポリゴン）を読み込み、視点から遠い場所、または広域を見渡すズームアウト時には大まかな形状の簡易的な3Dモデル、または低解像度なデータを読み込みます。

これにより、画面に映らない余計なデータを読み込まず、必要な部分だけをスマートに取得して描画することが可能になります。

3D Tilesの核となる仕組み

3D Tilesは、主に以下の技術的な仕組みによって超高速な描画を実現しています。

① HLOD（Hierarchical Level of Detail：階層的詳細度）

3D Tilesの最も重要なコアコンセプトです。カメラ（ユーザーの視点）からの距離や「幾何エラー（Geometric Error：簡略化による見た目のズレ）」を基準に、最適な詳細度のデータを動的に判定・ロードします。 木の根から葉（ツリー構造）のように、親タイル（広域・低精細）から、必要に応じて子タイル（狭域・高精細）へと切り替えていきます。

② 自由度の高い空間分割（Bounding Volumes）

空間を切り分ける際、単純なグリッド分割だけでなく、データの密度や地形に合わせて柔軟にバウンディングボリューム（境界領域）を定義できます。

• Box（直方体）: 建物群や、特定のブロックに適した分割。
• Sphere（球体）: 地球規模、または特定の中心点からの距離に基づく分割。
• Region（地域/経緯度・高度）: 地理座標系に沿った正確なエリアの分割。

③ インデックスとしての「tileset.json」

3D Tilesのデータセット全体を管理するのが tileset.json というファイルです。このファイルには、空間全体のツリー構造、境界領域の位置、各タイルが持つ幾何エラーの閾値、そして各タイルが参照する実データ（3Dモデルなど）へのリンクが記述されています。

バージョンによる違い（3D Tiles 1.0 と 1.1）

3D Tilesは進化を続けており、2022年に 3D Tiles 1.1 がOGCの標準規格として承認されました。1.0と1.1ではデータの持ち方が大きく近代化されています。

主な活用事例

3D Tilesは、すでに多くの商用・公共プロジェクトやサービスでベースインフラとして活用されています。

① 国土交通省の「Project PLATEAU（プラトー）」

日本全国の都市デジタルツイン化を目指す「Project PLATEAU」では、実世界を再現したオープンな3D都市モデルが整備されています。このPLATEAUがWeb上でデータを軽快に配信するために採用している主要なフォーマットの一つが 3D Tiles です。都市の建物情報（築年数、用途、災害リスクなど）の属性情報を、3Dモデルに付与した状態でWeb上から即座に確認できます。

② Google Photorealistic 3D Tiles

Googleが提供する「Google Maps Tile API」では、Googleアースで使われている膨大かつ写実的な（フォトリアリスティックな）3D地図データを 3D Tiles（1.0形式） として開発者に提供しています。これにより、使い慣れたCesiumJSや、Unreal Engine、Unityなどのお好みの3Dレンダラーに、Googleの超高品質な3D地球儀データをストリーミング表示させることが可能になりました。

③ インフラ・建設分野のデジタルツイン

道路、トンネル、ダムなどの大規模インフラをドローンで空撮（フォトグラメトリ）したデータや、レーザースキャンによる数億点規模の「点群（Point Cloud）」データを、現場の進捗管理や保全計画のためにブラウザ上で共有するシステム等で活用されています。

対応している主な描画エンジン

3D Tilesは特定のプラットフォームに縛られないオープン規格のため、多様な開発フレームワークでサポートされています。

CesiumJS
本家本元であるCesiumが開発しています。3D TilesをWebブラウザ上で最も高度にレンダリングできるオープンソースライブラリです。

Cesium for Unreal / Unity / Omniverse
ゲームエンジン内で高精度な地理空間データをストリーミングするためのプラグイン群。リアルなゲーム開発やシミュレーターに3D Tilesを取り込めます。

Deck.gl / loaders.gl
Uberが開発する可視化フレームワークです。大容量データビジュアライゼーションにおいて、3D Tilesのロードに対応しています。

ArcGIS (Esri)
GIS業界のデファクトスタンダードツールです。ArcGIS ProやArcGIS Onlineでも3D Tilesのインポート・可視化を広くサポートしています。

glTFへの対応

3D Tilesは、単に「3D空間を細かく分けて軽くする」だけの仕組みではありません。1.1へのアップデートによって、3Dデータ形式の世界標準である glTF/glb をそのまま利用できるようになり、高機能な「構造化メタデータ（セマンティックデータ）」も持てるようになりました。

これにより、3Dモデルに「材質」「温度」「センサーデータ」「人口統計」「不動産価値」といった無数の現実情報を重ね合わせ、Web上で動的にフィルタリングや分析を行うといった、真の「デジタルツインプラットフォーム」としての進化を遂げています。

地理空間情報を扱うアプリ開発や、スマートシティに関連するプロジェクトに携わる上で、3D Tilesはもはや避けては通れない、そして非常に強力な武器となる標準規格です。

PLATEAUも「タイルベース」

PLATEAUは2020年のプロジェクト発足当初（実証フェーズ）から、3D Tilesへの対応を完全に念頭に置いて設計されていました。
「CesiumJS、3D Tiles 1.1、glTF」という技術スタックは、まさにPLATEAUが最初期から今日に至るまで採用し続けている、システムの核心部分です。

そのため、PLATEAUも大元のデータ（CityGML）から配信用のデータ（3D Tiles）にいたるまで、すべて「タイルベース（区画分け）」で管理されています。

国土地理院が定めた「地域メッシュ（標準地域メッシュ）」という規格があり、PLATEAUの生データ（CityGML）は主に「3次メッシュ（約1km四方）」というタイル単位でファイルが分割されて配布されています。

そして、Web配信用の「3D Tiles」になると、さらにカメラの距離に応じて細かく（数十メートル〜数百メートル単位の立体的な箱＝バウンディングボックスに）階層的にタイル分割されます。

タイルの境界線上にある建物の扱い

東京駅のように横に非常に長い建物や、タイルの境界線上をまたいで建っている建物がある場合、「壁の途中でスパッと切られて別々のタイルに分かれる」ということはありません。

3D Tilesでは、建物は「1つの独立したオブジェクト（塊）」として扱われます。もし境界線で建物を物理的に分割してしまうと、ユーザーが「東京駅」をクリックしたときに半分しか選択できなくなったり、結合部のテクスチャがずれたり、データベースとしての整合性が崩れてしまうからです。

境界線をまたぐ建物がどちらのタイルに所属するかは、主に以下の2つの方法（アルゴリズム）で厳密に決定されています。

① 「重心（アンカーポイント）」がある方のタイルに所属させる
最も一般的なルールです。 建物の3D形状から「重心（または代表点）」を計算し、その重心が属している方のタイルに、建物丸ごと（100%）を所属させます。

このため、タイルBのエリア（東側）だけをロードした段階では、東京駅は画面に現れません。カメラが移動してタイルA（西側）がロードされた瞬間に、東側にはみ出している部分も含めて東京駅全体がバッと描画されます。

②タイル（バウンディングボックス）自体を重ね合わせる（AABB/OBB）
3D Tilesの仕様では、タイル（データを区切る見えない箱）は、隣のタイルと「空間的に重なり合ってもよい（Overlapping）」というルールになっています。

そのため、またがっている建物がある場合、その建物がすっぽり収まるように「タイルのサイズ（境界線）」を少し外側に広げて、はみ出た部分を包み込むように制御します。

だからこそ、東京駅や都庁は「単体」で取り出せる

PLATEAUの中には、東京駅や都庁のデータが「東京駅.obj」のような名前で単体で入っているわけではありません。

しかし、3D Tiles規格を読み込むビューア（Cesiumなど）の上で、画面に表示された東京駅をマウスでクリックすると、「東京駅（ID: 13101-bldg-XXXXX）」という1つのオブジェクトとして丸ごと認識され、その建物だけの属性データ（構造や築年数）を正しく取得・ハイライトすることができます。

ぶった斬らずに「オブジェクトの塊」を保ったまま、賢くタイリングする。これが3D Tilesが「単なる3Dの寄せ集め」ではなく、スマートシティの基盤として使える最大の理由なのです。

柔軟なタイル分割方式

ところで、世界中には様々な3D Tilesデータがありますが、それらはWebメルカトル図法などの固定された2Dのタイル分割ルール（XYZ方式やQuadtreeなど）には縛られていません。

それぞれデータの種類や密度に応じて「独自の3次元的な区切り方」で分割されています。

なぜ2D地図でお馴染みの「Webメルカトル」を使わないのか、そして3D Tilesがどのように世界を分割しているのか、その理由を紐解くと、この規格の本当の凄さが見えてきます。

なぜ「Webメルカトル図法」で分割しないのか？

2DのWeb地図（Google MapsやMapboxなど）では、地球を真上から見た平面の正方形として扱い、それを4等分（クアッドツリー）、さらに4等分……と均等に割っていく「Webメルカトル図法」に基づく分割ルールが一般的です。

しかし、3Dデータをこのルールで分割しようとすると、主に3つの致命的な問題が発生します。

① 「高さ（3次元）」に対応できない

Webメルカトルは平面（2D）のルールです。そのため、例えば「地下鉄の駅」「地上の高層ビル」「上空を飛ぶ飛行機のルート」が同じ緯度経度（同じタイル座標）に存在する場合、すべて1つのタイルに詰め込まれてしまい、データが激重になります。3D Tilesには、高さ方向にも空間を分割する仕組み（八分木＝オクツリーなど）が必要です。

② 極限状態での歪みが激しい

Webメルカトルは北極や南極に近づくほど、面積が無限大に引き伸ばされるという特性があります。地球全体を3Dの球体（地球儀）として正確に表現しようとする3D Tilesにとって、この歪みは3Dモデルの位置ズレを招くため相性が最悪です。

③ データの密度が場所によって違いすぎる

「何もない太平洋のど真ん中」と「超高層ビルが林立する新宿」を同じサイズで均等に分割するのは非効率的です。
均等に分割してしまうと、東京駅の周辺だけ異常にデータが重いタイルになり、海の上は「空っぽのタイル」だらけになってしまいます。

3D Tilesは「データの形」に合わせて箱を設計する

3D Tilesは、Webメルカトルのような固定された枠線にデータを当てはめるのではなく、「データが存在する場所に、最適なサイズの見えない箱（Bounding Volume / 境界ボリューム）をその都度作る」というアプローチを取ります。

この「箱」の定義方法は非常に柔軟で、データの性質に合わせて以下のような分割方法を使い分けています。

ボックス
傾いた立方体。個々の建物や、傾いた道路などに合わせて最も隙間なくフィットする箱を作ります。

球体
中心点と半径で定義される球。広域のデータや、カメラがぐるぐる回る視点での判定が高速に行えます。

領域
緯度・経度・高度の最小値・最大値で定義される扇型の箱。地球の丸みに沿った広大な都市エリアを囲むのに適しています。

データがない場所にはそもそも「箱」を作らず、建物や点群が密集している場所だけ、そのデータの形に合わせてぴったりな箱（タイル）を細かく、階層的に生成します。

国やサービスによる具体的な分割例

このように「ルールが自由」だからこそ、配信されるデータによって全く異なる分割がなされています。

PLATEAU（3D都市モデル）
大元は「約1km四方の地域メッシュ」という日本の標準規格で区切られていますが、3D Tilesに変換される際は、建物が集まっている場所（中心市街地など）の箱だけが自動的にさらに細かく分割された階層構造（木構造）になります。 Cesium

Google Maps（Photorealistic 3D Tiles）
地球全体をシームレスにカバーするため、「S2セル」（Googleが開発した、地球を歪みの少ない6つの面で囲んで正方形の階層で割る3Dグリッド規格）などの特殊な幾何学アルゴリズムをベースに、独自の3D Tilesツリーを構築して配信しています。

ドローンで空撮した建設現場の点群
緯度経度ベースのメッシュは無視し、その「工事現場の敷地（例えば数百メートル四方）」だけを原点とした、独自の小さな立方体の箱を基準に3D Tiles化されます。 MapTiler documentation

だからこそ「どんな3Dデータも」同じ画面に重なる

もし、3D Tilesが「Webメルカトル」という単一のルールに縛られていたら、ドローンの点群データや室内のBIMデータをきれいに取り込むことは困難だったでしょう。

3D Tilesが持つ「データの形状に合わせて、境界の箱（タイル）のサイズも傾きも自由に変えていい。それらをメタデータ（tileset.json）に記録して、ビューア側が解釈すればいい」という極めて寛容な設計思想こそが、現在の3Dデジタルツインのデファクトスタンダード（事実上の業界標準）たり得ている最大の技術的強みなのです。

異なる分割方式のタイルの重ね合わせ

CesiumJSなどのライブラリは、複数の異なる3D Tilesを重ねて配置した際、それぞれの3D Tilesが完全に独立して、個別にLOD（詳細度）の計算と切り替えを行えるように設計されています。

この「独立した自律分散的なLOD評価」ができる仕組みと、それが可能にする高度な重ね合わせ（マッシュアップ）の裏側を解説します。

独立したLOD切り替えを実現するSSE（画面スペース誤差）

CesiumJSがLODの切り替え判定（これ以上近づいたら、より詳細なタイルをロードする、という判断）に使う指標を、SSE（Screen Space Error：画面スペース誤差）と呼びます。

このSSEの評価プロセスは、以下のようにタイルセットごとに完全に独立して並列処理されます。

 ユーザーのカメラ視点 (位置・角度・ズームレベル)
   │
   ├─► [3D Tiles A: PLATEAUビル群] ──► A独自のツリー構造から、現在の視点に応じたLODを選択・ロード
   │
   └─► [3D Tiles B: 自社ドローン点群] ──► B独自のツリー構造から、現在の視点に応じたLODを選択・ロード

• カメラ情報は共通： すべての3D Tilesは、ビューア上の「現在のカメラの位置・角度・視野角」という共通情報を受け取ります。
• 判断は個別： そのカメラ情報をもとに、「現在の自分の画角において、これ以上の詳細度が必要か？」の計算（SSE計算）を、各タイルセットが自分自身の tileset.json に書かれたルールに従って個別に行います。

したがって、PLATEAUのビル群がまだ引き気味の粗いLODを表示している最中であっても、ズーム先の中心にある高精細な自社点群データだけをピンポイントに最高解像度のLODに切り替える、といった挙動が極めて自然に行われます。

独自の区切り（データ構造）が競合しない理由

前述の通り、世界中の3D Tilesは、あるものは「約1km四方の地域メッシュ」を基準にし、あるものは「ドローンで撮った敷地境界」を基準に、独自の「見えない箱（Bounding Volume）」でバラバラに区切られています。

それでもCesiumJS上で競合したり、描画が壊れたりしないのは、CesiumJSが「タイルの枠線」を基準にして描画しているのではなく、単に「個別の3Dオブジェクトのレンダリング命令（glTFのロードと描画）」を並列で実行しているだけだからです。

【CesiumJSの描画（レンダリング）ループ】
1. カメラの視点を取得する
2. シーンに登録されている「すべての3D Tiles」をループ処理する
3. 各3D Tilesに対し、「お前のtileset.jsonをベースに、今ロードすべき最適なタイル（glbファイル）はどれか？」を個別に問い合わせる
4. 返ってきた必要なglbファイルを非同期でダウンロードし、GPUに描画命令を投げる

ライブラリ側にとっては、画面に映っているのが「PLATEAUのビル」だろうが「ドローンの点群」だろうが関係ありません。「そこに描画すべき3Dモデル（glb）の指示書（tileset.json）」が複数あるため、それをただ忠実に並列処理しているに過ぎません。

実務開発者が調整できる「独立したコントロール」

この設計思想のおかげで、開発者はプログラムからタイルセットごとに個別の制御をかけることができます。

タイルセット個別の表示・非表示（showプロパティ）
「PLATEAUのビルを非表示にして、自社の点群データだけを見せる」といった制御が1行で可能です。

タイルセットごとの描画クオリティ調整（maximumScreenSpaceError）
「背景のPLATEAUビル（3D Tiles A）は少し粗いままでいいから動作を軽くしたい（SSE値を上げる）」「主役である自社の建設BIM（3D Tiles B）は、少し遠くからでも超高精細に表示させたい（SSE値を下げる）」といった、データごとの重み付け（パフォーマンスの最適化）が可能です。

まとめ：3D Tilesが切り拓く、デジタルツインの未来

かつて2Dのデジタル地図において、背景の「航空写真」の上に自社の「営業エリア（ポリゴン）」を重ね合わせて新しい価値を生み出したように、3D Tilesの登場によって、私たちは「完全に独立した3D空間のレイヤー」をWeb上で自由自在にマッシュアップ（重ね合わせ）できる時代を迎えました。

3D Tilesの真の革新性は、単に大容量データを軽量化したことだけではありません。

• 「Webメルカトル」という従来の2Dの呪縛から脱却し、データの形状に合わせた最適な3D空間分割を可能にした寛容な設計
• 各データソースがお互いの構造を知らなくても、共通のカメラ視点（SSE）を介して美しく調和する自律分散的なLODシステム

これらの優れた設計思想があるからこそ、国家規模のオープンデータである「Project PLATEAU」、Googleが誇る圧倒的な地球儀データ、そして現場のドローン点群やBIMモデルにいたるまで、出自もスケールも異なる異種多様な3Dデータを、ひとつの画面上でシームレスに融合させることができるのです。

空間コンピューティングやスマートシティの社会実装が加速する今、3D Tilesは単なる一規格にとどまらず、「現実世界をデジタル空間に完全に複製し、分析・シミュレーションする」ための世界共通の基盤（インフラ）へと進化を遂げています。

これから地理空間情報を扱うアプリケーション開発や都市DXプロジェクトに携わるすべての人にとって、3D Tilesの特性を理解し、そのポテンシャルを引き出すことは、次世代のビジネスやサービスを構築する上での強力な武器、ひいては最大のアドバンテージとなるでしょう。