OGC CityGMLの本質的定義とセマンティック・モデリングの重要性

現代のスマートシティ戦略において、3D都市モデルは「単なる景観の可視化」という初期の役割を脱し、都市の物理的・論理的構造を記述する高度な情報基盤へと昇華しています。

エビデンスに基づく都市経営を可能にするのは、点群やメッシュといった幾何形状ではなく、各オブジェクトが持つ「意味（セマンティクス）」の構造化に他なりません。この課題に対し、OGC（Open Geospatial Consortium）が策定したCityGMLは、都市を「意味論的に解釈可能なオブジェクトの集合」として定義する世界標準の仕様です。

オブジェクト指向による都市の体系化

CityGMLの本質は、都市を構成する要素を「AbstractCityObject」を基底クラスとした継承階層によって体系化することにあります。
建物、道路、植生、河川といった各クラスは、単なる幾何学的な広がりではなく、特定の意味論的な役割と属性（高さ、築年数、用途、浸水耐性等）を内包しています。このセマンティック構造により、システムは「そのポリゴンが壁であるか屋根であるか」を識別し、建物と地形、あるいは建物と道路といったオブジェクト間の相互作用を論理的に計算可能にします。

セマンティクスと幾何学の双方向連携

CityGMLは、意味論的な「定義」と、幾何学的な「形状・トポロジー」を密接に紐付ける双方向の参照構造を持っています。
これにより、特定の属性（例：南向きの屋根面）に基づいた空間抽出や、トポロジー情報を用いた容積率の自動計算、あるいは建物内の部屋同士の包含関係の抽出といった高度な空間解析が可能になります。
この「意味の記述」こそが、単なる3D可視化を超え、シミュレーションや管理実務に耐えうる都市デジタルツインを成立させるための絶対的な要諦なのです。

歴史的変遷：CityGML 1.0から2.0における到達点と限界

3D都市モデルの国際標準化は、2008年のCityGML 1.0.0採択、そして2012年の2.0への進化を経て、静的な空間データの管理手法を確立してきました。これにより、世界の主要都市で一貫性のあるデータ整備が進むこととなりました。

1.0から2.0への進歩

CityGMLはGML3（Geography Markup Language 3）をベースとしたISO TC211準拠の国際標準として策定されました。
2.0では、橋梁、トンネル、土地利用といったモジュールが追加され、さらにADE（Application Domain Extension）による各国の特定ドメインに応じた拡張機構が洗練されました。これにより、ベルリン、ウィーン、シンガポール、そして日本のPLATEAUといった大規模プロジェクトの共通言語としての地位を固めました。

初期アーキテクチャの課題

しかし、初期のCityGMLは「モノリシックなXMLファイルによる交換」という1990年代〜2000年代初頭のパラダイムに縛られていました。

XML/GMLの冗長性
テキストベースの冗長な記述によりファイルサイズが肥大化し、大規模な都市データのハンドリングにおいて極めて高い計算コストを強いていました。

動的データへの対応不足
基本的に静的な空間形状の管理に最適化されており、IoTセンサーからのリアルタイムな情報変動を扱うためのネイティブな機構が欠落していました。

静的な空間管理の限界
時間的な変遷（時系列）を扱う機能が限定的であり、刻々と変化する「生きている都市」のデジタルツインとしては、アーキテクチャ上の転換が必要不可欠となっていました。

CityGML 3.0の革新：デジタルツイン基盤への構造的転換

2021年に公開されたCityGML 3.0は、都市データの概念を「見た目のスナップショット」から「運用可能なデジタルツイン」へと再定義する、抜本的なパラダイムシフトをもたらしました。

LOD（詳細度）概念の再定義とAbstractSpace

3.0では、従来の固定的なLOD4（屋内モデル）を廃止し、屋外（Exterior）と屋内（Interior）を独立して管理する柔軟なモデルへと移行しました。
その中核を担うのが「AbstractSpace」と「AbstractSpaceBoundary」によるコアモデリングです。
これにより、屋外を簡易なLOD1（箱型）で保持しつつ、屋内のみを高精細な空間情報として構築するといった、用途に応じた最適な組み合わせが可能となりました。また、開口部や主題面（Wall, Roof等）に対する従来のLOD制限も撤廃され、設計の柔軟性が格段に向上しています。

Dynamizerモジュール：静動分離の分散アーキテクチャ

リアルタイムなIoT連携を支える「Dynamizer」は、アーキテクチャ上の核心部です。10万台規模のセンサーが毎秒送信するようなデータを、重厚な都市モデル本体に直接書き込むことはデータベースのパンク（Bloat）を招きます。
3.0では、「静的な形状データ」と「動的な属性データ」を論理的に分離し、空間ID（GMLID）をハッシュキーとして時系列データベース（InfluxDBやTimescaleDB等）と高速に紐付ける分散アーキテクチャを採用しています。

Atomic/CompositeTimeseries: 個別または複合的なセンサー記録の管理。
SensorConnection: MQTTやSOSを用いた外部ストリームとの統合。

実際、EPFL（スイス連邦工科大学）の実証では、354,000 kWh規模のエネルギー消費量データを動的にマッピングし、リアルタイムな電力負荷解析を可能にしています。

Space概念による「決定論的パスファインディング」

3.0が物理的な「構造物（壁・床）」ではなく「空間（Space）」そのものをオブジェクト化した意義は計り知れません。
これにより、建物内の部屋、道路上の空間、ロボットの移動可能範囲が論理的なネットワークとして記述されます。
これは、生の点群やボクセルデータを用いたAIの不確実な推論に頼ることなく、「決定論的な経路探索（Pathfinding）」を最小限の計算コストで実行できることを意味し、自動運転、ドローン配送、人流避難シミュレーションの信頼性を根底から支えます。

Versioning（二時相管理）とSpatial RAGへの応用

Git風の履歴管理（VersionTransition）が導入され、DB登録日の「creationDate」とは別に、実世界での有効期間を示す「validFrom/validTo」による二時相管理が実現しました。
さらに、これらの厳密なセマンティクスはLLM（大規模言語モデル）との相性が極めて良く、「Spatial RAG（空間検索拡張生成）」を通じて「南向きで50平米以上の屋根を持つ建物を抽出せよ」といった自然言語クエリによる都市解析を可能にします。

CityJSON：Web・API時代の軽量エンコーディング技術

XMLの冗長性を克服し、WebブラウザやAPIでの高速配信を実現するために開発されたのがCityJSONです。これはCityGML 3.0の主要なセマンティクス構造を継承しつつ、実務的なデータ転送効率を追求した規格です。

頂点インデックスとtransformプロパティの圧縮効果

CityJSONは、座標値を配列で一括管理し各オブジェクトからインデックスで参照する「頂点インデックスメカニズム」を採用しています。
さらに、座標値を浮動小数点ではなく「transform」プロパティによる整数化（量子化）で扱うことで、劇的なファイルサイズ削減を達成しています。
この平坦化（Flattening）されたハッシュマップ構造は、JavaScript等でのパース負荷を最小化し、Webベースのデジタルツインにおける「3D都市モデルのJPEG」としての役割を担います。

3D City Database (3DCityDB v5) による空間データ管理の高度化

大規模な都市モデルをファイルベースの交換から「解析可能なサービス」へと転換させるのが、3DCityDB v5です。v5はCityGML 3.0コンセプトモデルのPostgreSQL/PostGISへの完全マッピングを実現しました。

スキーマの最適化とNative PostGISサポート

v4までの課題であったポリゴンの細分化格納を廃止し、PostGISが提供する「Solids」「MultiSurfaces」「TINs」といった3D幾何タイプへ直接マッピングする方式へと刷新されました。
この最適化により、QGISやArcGISといった標準的なGISクライアントからカスタムミドルウェアを介さず直接空間オブジェクトを利用することが可能となり、クエリの実行速度と相互運用性が飛躍的に向上しています。

citydb-toolによる自動化パイプライン

新たに導入された「citydb-tool」は、GUIを排したCLI特化型のツールです。
これは設計者の意図として、手動操作ではなくCI/CDパイプラインやデータ更新ワークフローへの組み込みを前提とした、エンジニアリング重視の進化と言えます。

BIM-GIS統合：3DCityDB4BIMとレンダリング・パイプライン

建築詳細（IFC）と広域都市モデル（CityGML）の統合は、都市のライフサイクル管理において「SVG（ベクター）とJPEG（ラスタ）」の関係に例えられます。

IFC 5への進化とデータガバナンス

IFC 5（IFC-X）がモノリシックなファイル交換を脱却し、API経由のモジュール化されたデータアクセスへとシフトしている流れは、CityGML 3.0の方向性と完全に同期しています。
3DCityDB4BIMアーキテクチャでは、「プライバシーに関わる屋内詳細はBIMServerに保持し、可視化用モデルのみを配信する」というデータガバナンスを「bimCityTable」によるGMLIDとIFC-GUIDのマッピングによって実現しています。

LoGeoRef 30と描画最適化（glTF 2.0 / 3D Tiles）

Web上での高速描画には、3D界のJPEGとも言える「glTF 2.0」を内包した3D Tiles 1.1が用いられます。

LoGeoRef 30の精密配置
BIMモデルを正しく配置するため、IFCファイル内に保持された現実世界の回転・位置情報をLoGeoRef 30（明確に定義された参照点と回転角）相当の精度で処理し、AttributeProcessorとproj4.jsを用いて正確な地理座標へと変換します。

HLODと八分木
視点距離に応じたポリゴン軽量化（HLOD）により、数千万個のオブジェクトもブラウザ上で滑らかに描画されます。

PLATEAUの現状とCityGML 3.0へのロードマップ

日本のPLATEAUプロジェクトは、世界最大級のオープン3D都市モデルとして、独自の進化を遂げています。

2.0ベースの実績とADEの戦略的運用

現在はCityGML 2.0を基盤に、日本固有の法制度を反映した「都市計画ADE」や「防災ADE」を構築し、実務的なユースケースを量産しています。全国5,600万棟以上の建物データを国際標準で整備した実績は、世界的に見ても極めて特筆すべきものです。

3.0移行への技術的展望

将来的な3.0への移行においては、Dynamizerによるリアルタイム人流統合や、Space概念を用いた自動運転・ロボット向けの空間表現が検討されています。
既存の膨大なツール資産との互換性を維持しつつ、セマンティックの高度化を図ることが次なるステップの焦点となります。

まとめ：API主体の次世代4層都市データスタックへの進化

CityGML 3.0を核とした一連の技術革新は、3D都市データを「重く静的なファイル」という制約から解放し、ソフトウェアからプログラマブルに制御可能な「動的APIサービス」へと決定的に昇華させました。このアーキテクチャ転換により、未来の都市デジタルツインは以下の4層スタックとして統合されていきます。

層1：マスターデータ（セマンティック層） CityGML 3.0やIFC5を基盤とし、都市および建築物の意味論（セマンティクス）、トポロジー、空間構造を厳密かつ堅牢に管理する領域。
層2：データ統合・API層 3DCityDB v5、CityJSON、OGC API等を活用し、多様なドメインのデータを空間データベース上で柔軟に結合・抽出するミドルウェア領域。
層3：リアルタイムストリーミング層 3D Tiles 1.1、glTF 2.0、MQTT等を駆使し、静的な形状と動的なIoTデータを分離したままGPU描画・解析用に高速配信する基盤領域。
層4：AI・アプリケーション層 Spatial RAGによる自然言語解析、空間知能（Spatial Intelligence）、自律移動ロボットの経路探索、高度な物理シミュレーション等を提供する意思決定・実行領域。

このように、データモデルの静動分離、幾何と意味の高度な紐付け、そしてWeb標準技術との密接な融合が果たされたことで、都市モデルは単なる「可視化のための背景データ」から「都市OSの中核をなす実行可能基盤」へと変貌を遂げました。

この持続可能で拡張性の高いアーキテクチャへの転換こそが、刻々と変化する「生きている都市」を高度に制御し、人とAI、そしてロボティクスが共生する次世代スマートシティの基盤を確立するための確実な道筋となるのです。

特集：3DCityDB

CityGMLの技術的進化と次世代3D都市データエコシステムの全貌：1.0から3.0、そしてBIM-GIS統合への道