MVDを制するものが、IFCを制する
こんにちは、ANDPAD ZEROの山田です。
今回は、BIMのデータ連携において重要なカギを握る「IFC（共通フォーマット）」と、それを最適化するフィルター役である「MVD」についてお話ししたいと思います。
データ連携という難題
建築情報をデータ化する上で欠かせないのが「フォーマット」の話題です。
従来は紙や2D図面でデータをやり取りしていたため、フォーマットについて深く悩む必要はありませんでした。しかし現在は、意匠、構造、設備など、分野ごとに特化した様々なBIMソフトが普及し、それぞれ異なる形式でBIMモデルが作成・納品されます。
では、各専門チームから納品された異なる形式の「BIMモデル（3Dモデル）」を、どのように統合すればよいのでしょうか。
ここで活躍するのが「IFC」というフォーマットです。
現在、ほとんどのBIMソフトがこの「.ifc」形式のデータ出力に対応しています。 異なるソフト間でのモデル受け渡しを可能にし、BIM確認申請の指定フォーマットとしてもメジャーな存在となってきました。
これでデータ連携の問題は一件落着……かと思いきや、実は「ただ書き出せばいい」というわけではありません。 ここには、「受け手を意識せずに書き出すと、不要な情報まで詰め込まれ、データが重すぎて使い物にならなくなる」という意外な落とし穴が存在するのです。
この落とし穴を回避し、IFCを真に使いこなすための”ルール決め”こそが、タイトルにもある「MVD」です。
今回は、そんな当たり前のようで意外と知られていない「IFC」の基本構造と、ぜひ理解して活用したい「MVD」の役割について解説していきます。
IFCのおさらい
IFC（Industry Foundation Classes）とは、直訳すると「建築業界基礎クラス」という少し難解な言葉になってしまいます。分かりやすく言うと、「建築・建設・土木業界におけるBIMデータの共通ファイルフォーマット（標準規格）」です。
IFCは国際規格であるため、世界中でIFCデータのやり取りが可能です。 もちろん、ANDPAD BIM Viewerで取り扱えるデータ形式もこのIFCです。
IFCは、国際的な非営利団体であるbuildingSMART International（ビルディングスマート・インターナショナル）が策定・管理しています。日本支部の「buildingSMART Japan」も存在し、国交省と連携した取り組みや、企業向けのイベント・セミナーなどを開催しています（山田もお世話になっております！）。
前提となるルールの違い
BIMモデルは、各ソフト固有のフォーマット（ネイティブ形式）で出力されます。
つまり、「Aのソフト」から出力されたデータをそのまま「Bのソフト」に渡して読み込ませようとしても、前提となるルールが違うためうまくいきません。
これを例えるなら、「洋菓子店（Aソフト）」が作った”外国語でかかれたショートケーキのレシピ”を、突然「和菓子専門店（Bソフト）」に持ち込んで「これをもとに同じものを作って！」とお願いするようなものです。
お店の分類や保存方法の定義が全く違うため、和菓子専門店側は「なにそれ？どう扱えばいいの？」と困惑し、フリーズ（データ破損）してもおかしくありません。
そうならないために、どのお店（ソフト）でも正しく取り扱える共通のルールとして「定義を構造化」したものが、IFCなのです。
IFCのバージョン（スキーマ）を振り返る
どのソフトでも読める共通規格であるIFCですが、実はいくつかバージョン（種類）が存在します。MVDの話に入る前に、おさらいとしてここで一度振り返っておきましょう。
このバージョンのことを、BIMの世界では「スキーマ」と呼んでいます。
なぜこのようにバージョンが分かれているかというと、「共通規格として表現できる『言葉（定義）』の数」が、時代の変化や技術の進歩に合わせてアップデートされてきたからです。
先ほどのお菓子作りに例えるなら、古い基本のレシピ本（IFC2x3）には「スポンジケーキやクッキー（柱や壁）」といった王道のメニューしか載っていませんでしたが、新しいレシピ本（IFC4）になると「複雑な曲線のデコレーション（曲線美）」や「最新のオーブンレンジの電子制御（複雑な設備システム）」のルールが追加されました。
さらに最新のレシピ本（IFC4.3）では、お店の敷地を飛び出して「デリバリーのルートマップ（道路や線路といった土木インフラ）」の書き方までカバーできるようになった、というイメージです。
このように、時代の変化に合わせて「共通言語として表現できる範囲」が拡張されてきたため、複数のスキーマが存在し、それぞれのターゲット（守備範囲）が異なっているのです。
IFCは定義が広すぎる
このように、IFCはバージョンアップを重ねることで、あらゆる建築情報を詰め込める非常に便利で万能なフォーマットになりました。
しかし、あまりにも万能すぎるがゆえに、事前に何の取り決めも交わさないまま、各々が必要だと思う情報をすべて書き出してしまえば、情報過多に陥ってしまいます。作り手が仕様を理解し、ストレスのないデータ納品方法を考慮しなければ、結果的に膨大なデータ容量の負担をお互いに背負うことになります。
そこで意識していただきたいのが、本日の主役である「MVD」の存在です。
MVDとは？
MVD（Model View Definition）は、通称「モデルビュー定義」と呼ばれます。モデルのビューに必要な情報を定義しておくことで、データの受け渡しを最適化するものです。
これも、先ほどのお菓子作りの例え話になぞらえて考えてみましょう。
洋菓子店（Aソフト）のレシピデータを和菓子店（Bソフト）へ渡す際、相手が「基本のスポンジケーキの焼き方だけを参考にしたい」のであれば、「王道レシピ」だけを渡せば十分です。そこに「複雑な曲線のデコレーション（曲線美）」や「最新のオーブンレンジの電子制御設定（複雑な設備システム）」まで丸ごと詰め込んで渡してしまうと、和菓子店側は情報が多すぎて困惑してしまいます。つまり、相手の状況に応じて「今回の受け渡しには王道レシピだけでいいのか」「デコレーションまで必要なのか」を意識して、必要な情報だけをコントロールして吐き出すこと。これこそが、MVDの役割なのです。
これを実際のBIMの現場に置き換えてみましょう。
例えば、意匠設計ソフトで作られた「建物のすべての情報（壁紙の色、ドアの取っ手の材質、柱の寸法や強度など）」が詰まった重いIFCデータを、そのまま構造設計ソフトに渡したとします。構造計算を行いたい担当者にとって、「壁紙の色」などの情報は不要なだけでなく、データを重くしてソフトをフリーズさせる原因になってしまいます。
そこで、構造設計に特化した「MVD」というフィルターをかけてIFCデータを出力します。すると、「柱や梁の寸法・材質」といった、相手が本当に欲しがっている情報だけがスッキリと抽出され、スムーズなデータ連携が可能になるのです。
つまりBIMにおいても、「どんな立場の人が、どんな目的で利用するのか」を考えながらMVDを選択することが極めて重要です。
各IFCのスキーマで提供されているMVDには、以下のような種類があり、それぞれ得意とする目的が異なります。
結局、どれが一番いいの？
ここまで理解が進むと、「結局、どれを選べば一番いいの？」という疑問がわいてくると思います。
実は、IFCやMVDという考え方は、BIMソフトの利用者だけでなく、提供者（ベンダー）にとっても無視できない重要なテーマです。
「MVDによってIFCを使いやすい状態にする」ためには、利用者のデータ作りの工夫だけでなく、「ソフト側がどうやってMVDに準拠して出力するか」というベンダー側の開発努力も必要になります。
せっかくBIMモデルをIFCで書き出そうとしたのに、ソフトの仕様上「対応しているMVDに限りがある」「MVDを指定しても情報が正しく流し込まれない」といった壁にぶつかると、最悪の場合「別の手法で一から作り直す」という悲惨な結末が待っています。
そんな結末を避けるために、まずは「今使っているBIMソフトが、どのIFC形式・MVDでの出力に対応しているのか」「出力した際、どんな情報が欠落するのか」という視点を持って運用を始めることを強くお勧めします。
使うソフトがどのMVDを得意としているかを知ることは、BIMを横断的に運用する上で強力な武器になります。 「とりあえずIFCで」と全データを丸投げするのではなく、「誰に、どのレシピ（情報）を届けるか」を意識してMVDを選ぶ。 それが、複雑なBIM連携をシンプルにするための、最も確実な第一歩なのです。
まとめ
いかがでしたか。
データ連携は、自社内で工夫できることもあれば、他社との協力やソフトの仕様理解が必要な部分もあり、非常に奥深く可能性の広がるテーマだと思います。
IFCの何が便利なのか。重要なのは、「誰にとって」という視点です。
記事の中で触れた通り、MVDを正しく選択・理解することは、単にデータを軽くするだけでなく、異なるソフト間でのコミュニケーションエラーを減らすことに直結します。 まずはご自身のソフトが「何を得意としているか」を確認するところから始めてみてください。
本日の記事が、データ連携やソフト間の不慣れな変換に行き詰まっている方にとって、一つの気づきとなれば幸いです。
ANDPAD ZEROのBIMグループでは、運用や仕組み化についてBIMサービスとして支援する体制を整えております。 ぜひお気軽にご相談ください！
最後までお読みいただきありがとうございました。
