BIM・IFCブログに戻る
デジタルツイン · 2026-10-10 · 8分
BIMとデジタルツインの違い：同じモデルで見る3つのステップ
BIMとデジタルツインは、同じものであるかのように語られがちです。しかし両者は別物で、その違いは1組のモデルで見るといちばんよくわかります。BIMファイルのままの状態、都市の中に配置した状態、そしてライブデータにつないだ状態です。各ステップで何が加わるのか、ツインがBIMに求めるもの、そもそもツインが不要なのはどんな場合かを解説します。
IFC Viewer Onlineで表示した、カタルーニャ広場の同じIFCモデルの3つの状態。BIMとして単体で表示したもの、バルセロナの3Dマップ上に配置したもの、デジタルツインとしてオープンデータのライブ値で色分けしたもの
BIMは、設計・施工されたものをそのデータとともに表すモデルです。デジタルツインは、モデル化の対象そのものとつながったモデルであり、対象が今どんな状態にあるかも把握しています。建物やアセットのツインには、その下にBIMのようなものが必ず必要です。一方、ほとんどのBIMモデルはツインになることはなく、その必要もありません。
違いは、1組のモデルで見るといちばんよくわかります。以下では、バルセロナのカタルーニャ広場の同じ8つのIFCファイルを、3つのステップで見ていきます。BIMファイルのまま、都市の中に配置した状態、ライブデータにつないだ状態です。
この記事のポイント
- BIMは「これは何か、どのように設計されたか」に答えます。ツインはさらに「今どうなっているか」にも答えます。
- 両者の間には、見落とされがちなステップがあります。モデルを実際の位置に、実際の地形の上に、周囲の環境とともに配置することです。
- ツインがBIMに求めるのは、各アセットを見つけるための情報です。変わらない識別子（GlobalId）、タイプ、分類、位置です。詳細な形状は、その中でいちばん重要度が低いものです。
- ライブの状態をもとに誰も行動しないのであれば、ツインは不要です。良いBIMモデルと適切な引き渡しで十分です。
同じモデルに各ステップが加えるもの。今起きていることを把握しているのは、最後のステップだけです。
ステップ1：BIMモデル
8つのIFCファイル単体の状態。データは豊富ですが、周りに何があるのか、何が起きているのかは何もわかりません。
IFCモデルは多くの情報を持っています。各要素の形状、タイプ、プロパティと数量、要素がどのようにシステムやアセンブリにまとめられているか、そして施設の所有者が使う分類コードです。このBicingステーションは、自分が21本のドック支柱を持つこと、それらが何であり、どのアセンブリに属するかを把握しています。
一方で、誰かがファイルにジオリファレンスを入れていない限り、世界のどこにあるのかはわかりませんし、どの部分がどんな状態にあるのかもわかりません。設計や調整にはそれで問題ありません。モデルはそのためのものだからです。モデルの構成はIFCの空間構造で解説しています。
ステップ2：都市の中のモデル
ジオリファレンスによって実際の地形の上に配置し、周りに街並みを表示した状態。まだスナップショットです。
モデルをジオリファレンス（実際の座標系へのIfcMapConversion）で配置すると、周りに街路や建物がある実際の地形の上に置かれます。これで、モデル単体では見えなかったことがわかります。噴水が縁石に対してどう収まっているか、自転車ステーションが地下鉄の出入口に対してどこにあるか、といったことです。手法はIFCを3D地図上に表示する方法で、よくある問題はIFCの座標とジオリファレンスで解説しています。
それでも、これはまだスナップショットです。誰かがファイルを編集しない限り、画面上の何も変わりません。
ステップ3：ツイン
試してみる：つながった同じモデル
バルセロナのライブフィードとつないだ8つのモデルです。BicingのドックとEV充電の駐車区画がデータに応じて色を変え、その上にライブの値が浮かびます。
インタラクティブなIFCビューアーを開く
最後のステップで、モデルを場所とつなぎます。デバイスソースがフィードをポーリングし、バインディングが、デバイスがどの要素をどのように動かすかを指定します。Bicingステーション65は21本のドック支柱を動かします。自転車がなければ赤、フィードが途絶えればグレーです。これでモデルは、何が建てられたかだけでなく、何が起きているかを示すようになります。
違いはこれに尽きます。Digital Twin Consortiumの定義の要点もここにあり、「指定された頻度と忠実度で」同期され続ける表現であることです[dtc]。このツインの構築方法はカタルーニャ広場のライブ・デジタルツインで解説しています。
ツインがBIMに求めるもの
| ツインに必要なもの | IFCでの格納場所 | ないと起きる問題 |
|---|
| アセットごとの変わらない識別子 | GlobalId | 次のエクスポート後、バインディングが存在しない要素を指してしまう |
| それが何の種類か | IFCクラスとタイプオブジェクト（IfcTypeObject） | 「すべてのドック支柱」や「すべてのポンプ」を対象にしたルールが書けない |
| 所有者が使うコード | IfcClassificationReference（Uniclass、OmniClassなど） | ツインが維持管理システムと連携できない |
| どこにあるか | IfcSiteとIfcMapConversion | モデルが通りからもデータからもずれていく |
| 維持管理データ | プロパティセット、または引き渡し時のCOBie | 誰も特定できないアセットでアラームが出る |
実務で最も問題になりやすいのは1行目です。ツールによってはエクスポートのたびにGlobalIdを再生成するため、IDでバインドしたツインは次の更新でアセットを見失います。詳しくはIFCのGUIDがエクスポートのたびに変わる理由をご覧ください。引き渡しの側面は、IFCからCOBieへとIFCモデルと一緒に引き渡すべきもので取り上げています。
ツインがBIMに加えるもの
- 現在の状態：アセットごとの値を、決まった間隔で更新します。
- 鮮度：各計測値がどれだけ古いか。古いデータが「問題なし」として扱われるのを防ぎます。
- ルールとアラート：値がしきい値を一定時間超えたときの色分けと警告。
- 履歴：過去の計測値。何が起きたかを再生できます。
ツインが不要な場合
ツインはモデルよりもコストがかかります。誰かがフィードを動かし続け、改訂のたびにバインディングをモデルに合わせ直し、アラートに対応しなければなりません。ツインが元を取れるのは、運用、維持管理、モビリティなど、ライブの状態をもとに人が行動する場合です。設計調整、干渉チェック、1回限りの引き渡しであれば、よく構造化されたBIMモデルが適切なツールであり、ツインは飾りにすぎません。
ツインが失敗する原因
- 3Dビューアーをツインと呼ぶこと。ライブの状態がなければ、同期すべきものは何もありません。
- ジオリファレンスがないこと。モデルが間違った位置に置かれ、データと何も揃いません。
- エクスポートのたびに変わる識別子。バインディングをすべてやり直すことになります。
- 古いデータを現在のものとして表示すること。鮮度のルールがない計測値は、2秒前のものも2日前のものも同じに見えます。
BIMとデジタルツインの違い：同じモデルで見る3つのステップ