BIM・IFCブログに戻る
デジタルツイン · 2026-10-10 · 8分
都市デジタルツインとは？今すぐ開ける3つのライブ事例
都市のデジタルツインとは、ある場所の3Dモデルが、そこで今起きていることとつながり続けているものです。それが実際に何を意味するのかを、ツインを構成する5つのレイヤー、各レイヤーのデータの出どころ、そしてオープンデータを使ってブラウザー上で動くバルセロナ、ヘルシンキ、東京の3つのライブ事例で解説します。
IFC Viewer Onlineで並べた3つのライブ都市デジタルツイン。バルセロナのカタルーニャ広場、ヘルシンキのエリエル広場のバスターミナル、東京の駅出入口が、それぞれの都市のオープンデータで色分けされている
都市デジタルツインとは、都市の一部を表す3Dモデルが、そこで起きていることとつながり続けているものです。モデルは、何がどこにあるかを示します。地面、建物、街路、そしてそこにあるアセットです。つながりは、それらが今どんな状態にあるかを示します。自転車のドックが空になった、バスが乗り場に着いた、列車が遅れている、といったことです。
Digital Twin Consortiumは、デジタルツインを「指定された頻度と忠実度で同期される、現実世界のエンティティとプロセスの仮想表現」と定義しています[dtc]。多くの3D都市モデルに欠けているのが、この「頻度」の部分です。このガイドでは、その先がどのようなものかを、今すぐ開ける3つのツインで示します。いずれもそれぞれの都市のオープンデータで構築され、ブラウザー上で動作します。
この記事のポイント
- デジタルツインとは、モデルに、モデル化した場所とのライブなつながりを加えたものです。そのつながりがない3D都市モデルは、優れた地図ではあってもツインではありません。
- 都市のツインは5つのレイヤーを積み重ねたものです。地表、周辺の街並み、アセットの詳細モデル、バインディング、ライブの状態です。レイヤーごとにデータの出どころが異なり、更新のペースもそれぞれです。
- 提供元がブラウザーからのリクエストを許可していれば、すべてのレイヤーをオープンデータだけで閲覧者のブラウザー内で動かせます。プラットフォームも、私たちのサーバーも使いません。
- 以下のバルセロナ、ヘルシンキ、東京の事例はライブで動作します。自転車のドック、バスの乗り場、駅の出入口が、それぞれの都市のフィードで色分けされます。
モデルをツインにするもの
条件は3つあり、見落とされがちなのは3つ目です。
- 実在する場所のモデル。そこにあるものの形状、識別情報、データを持ち、実際の位置に配置されていること。
- その場所の現在の状態とのつながり。決まった間隔で更新されること。バスなら1秒ごと、自転車のドックなら1分ごと、大気質なら1時間ごとです。
- その状態の活用。モデル上に表示し、ルールでチェックしてアラートを出し、再生できる履歴として残すこと。
2つ目がなければ、それは3D都市モデルです。それでも十分に役立ちます。日本はPLATEAU[plateau]を通じて各都市のオープンなモデルを公開しており、ヘルシンキも独自のモデルを公開しています[helsinki3d]。その多くはオープン標準のCityGML[citygml]で提供されています。こうしたモデルとツインの違いは、BIMとデジタルツインの違いで順を追って解説しています。
都市ツインを構成する5つのレイヤー
バルセロナのツインの5つのレイヤー。地形からライブの計測値までを示しています。数値はすべてシーンファイルからとったものです。
- 地表 他のすべてのレイヤーの土台となる標高モデルです。バルセロナではICGCの5mメッシュ地形モデルを使っているため、モデルは宙に浮いたり地面に沈み込んだりせず、通りの上にきちんと載ります。
- 周辺の街並み アセットの周囲の建物と街路です。ここではOpenStreetMapから取得し、モデルと同じ投影法で描画しているため、地図の縁石がIFC内の縁石とぴたりと揃います。
- アセットモデル 状態を知りたい対象を詳細にモデル化したものです。ここでは8つのIFC 4.3ファイル（噴水、ドック支柱を備えたBicingステーション、地下鉄の出入口、EV充電器）で、それぞれが自身のジオリファレンスによって配置されています。
- バインディング フィードと要素を結び付けるものです。どのソースの、どのデバイスを、どのIFC要素に対応させ、どの値でどの色にするかを決めます。バインディングがなければ、ライブデータはモデルの横に並んだ数字の羅列にすぎません。
- ライブの状態 計測値そのものです。それぞれのペースで更新され、Bicingは60秒ごと、EV充電器は5分ごと、大気質は15分ごとです。ソースが許容するより古い計測値はグレーになり、最新のデータとして扱われることはありません。
作業の大半も、失敗の大半も、レイヤーとレイヤーの間で起こります。通りから数メートルずれたモデル、ドックがアセンブリの構成部材であるために要素を1つも見つけられないバインディング、タイムスタンプが見かけどおりの意味ではないフィードなどです。以下の事例では、それぞれがそのうちの1つを取り上げています。
3つのライブ事例
いずれも1つのシーンファイルと、その都市のオープンデータで動作します。開いたら、アセットをクリックしてデータを表示し、「探索」でライブ地点の間を移動してみてください。
バルセロナ：自転車のドックとEV充電器
カタルーニャ広場をライブで
バルセロナの3Dマップ上に8つのIFCモデルを表示します。BicingのドックとEndollaの充電用駐車区画が、市のフィードに応じて色を変えます。
インタラクティブなIFCビューアーを開く
広場周辺にある、ジオリファレンス済みの8つのIFCモデルです。Bicingステーション65と路上の充電器がそれぞれのライブフィードにバインドされ、交通と大気質は地図レイヤーとして表示されます。フィードから色付きのドック支柱までの構築の全体は、カタルーニャ広場のライブ・デジタルツインで解説しています。
ヘルシンキ：乗り場に着くバス
ヘルシンキ中央駅に隣接するエリエル広場。バスが到着し、停車し、ドアを開けるのに合わせて、各乗り場の色が変わります。
駅、大聖堂、ターミナルの3つのIFCモデルと、HSLのリアルタイム車両位置にバインドした9つの乗り場です。位置情報はMQTTで、バス1台につき約1秒に1回届きます。GTFS-RealtimeではなくMQTTを使う理由や、停留所IDを乗り場に対応させる方法は、MQTTで作るライブのバスターミナル・ツインで解説しています。
東京：駅の出入口と路面電車の停留場
都庁前駅 A4出口。都営マークは大江戸線の運行状況を、駅名標はホームにいる列車を、バス停の標柱は直近に通過したバスを示します。
ODPTのオープンデータにバインドした2つの駅です。列車の位置、路線の運行状況、そしてページ内でデコードする都営バスのGTFS-Realtimeフィードを使っています。詳細と、ODPTからわかること・わからないことは、ODPTのオープンデータで作る東京の駅のツインをご覧ください。
データがモデルに届くまで
通信方式は3つ、ルールは1つ。ブラウザーがフィードを読み込めるのは、提供元がCORSヘッダーを返す場合だけです。
リクエストはすべて、閲覧者のブラウザーから提供元へ直接送られます。これが可能なのは、提供元がCORSヘッダーを付けて応答する場合だけです。このヘッダーがあると、別サイトのページがその応答を読み込めます。バルセロナのシェアサイクルと充電のフィード、HSLのMQTTストリーム、ODPTの公開エンドポイントはいずれも対応していますが、HSLのGTFS-Realtimeフィードは対応していません。そのためヘルシンキのツインでは、代わりにMQTTストリームを使っています。
ブラウザーだけのツインにできないこと
- 非公開データやキーが必要なデータ。ブラウザーとソースの間にサーバーが必要です。
- 重いシミュレーション。地区全体を対象にした浸水、エネルギー、人流のモデルには、Webページが担うべき以上の計算量が必要です。
- 制御。機器を操作するツインに必要なのは、公開リンクではなく、認証、監査証跡、信頼性の高い接続です。
- スマートフォン。シーン全体はデスクトップのブラウザーでテストしていますが、スマートフォンではまだ計測していません。
自分のモデルでツインを作る
- IFCを地図に配置する 3Dマップで開き、正しい位置に配置されるかを確認します。手順はIFCを3D地図上に表示する方法をご覧ください。
- ずれていればジオリファレンスを修正する 位置がずれるモデルの多くは、IfcMapConversionが欠けているか誤っています。詳しくはIFCの座標とジオリファレンスで解説しています。
- フィードとバインディングを追加する CORSヘッダーを返すフィードをデバイスソースに指定し、IFCクラスと名前、またはGlobalIdで要素にバインドします。
- 共有する シーンファイルとして保存するかリンクにまとめ、関係者が普段使っている場所に埋め込みます。方法はIFCビューアーを埋め込む方法をご覧ください。
都市デジタルツインとは？今すぐ開ける3つのライブ事例