【連載】オープンなファイルフォーマット「IFC」の可能性に再注目｜芝浦工業大学 志手教授
「建築×情報」の第一人者である、芝浦工業大学 建築学部 建築学科・志手教授による連載です。
2025年度のBIM確認申請試行開始が迫る中、BIMやDX化への注目度が高まっています。今回は建築確認における「IFC」の可能性や、関連する研究の内容についてです。
第二回の「BIM積算の現状と、概算精度向上の重要性」の記事はこちらからもお読みいただけます。
「IFC」とは｜オープンファイルとして機能
みなさんは「IFC（Industry Foundation Classes）」と聞いてどのような利用方法を思い浮かべるでしょうか。異なるBIMソフトウエア間でのデータ交換に利用する「中間ファイル」という見かたもあるかと思います。
CADで言えばDXFに近い印象でしょうか。それはある意味で正しい気もしますが、IFCの使い方の一部にすぎません。ファイル交換に過大な期待をしたあまり「IFCファイルをインポートしても思った通りにデータが来ない」とがっかりした経験もあるのではないでしょうか。
buildingSMARTは、建物を構成する全てのオブジェクトのシステム的な表現方法の仕様をIFCと呼んでいます。IFCは「建物や土木インフラを含む構築環境の標準化されたデジタル記述方法」であり、中立的でオープンな国際規格 （ISO 16739-1:2018） です。一方「BIMソフトウエアのネイティブファイル」は、利便性を追求しなくてはならないためシステム的な表現方法の仕様がBIMソフトウエアごとに異なっています。したがって、高機能な記述を標準的な記述に変換することはできても「標準的な記述を高機能な記述に戻せない」という不可逆性を避けられません。
そのため、IFCはファイル交換のための「中間ファイル」ではなく、情報を共有するための「オープンファイル」と考えるのが正しいと思います。
IFCフォーマットによるデータ共有について
それでは、オープンファイルで情報を共有するとはどのようなことでしょうか。具体的には「IFCファイルのままBIMデータを統合的に扱うこと」かと思います。
主要なBIMソフトウエアのほとんどは、「Reference View」などbuildingSMART Internationalなどが定義した主なモデルビュー定義（Model View Definition：MVD）をサポートしていると思います。
同じMVDで変換されたIFCは、変換元のBIMソフトウエアが異なっていても統一形式の情報を含んでいると認識して差し支えないでしょう。複数のIFCファイルを重ね合わせて表示できるIFCビューアは、フリー、有償、ローカル、クラウドなどいくつもあります。それらを利用することで「IFCフォーマットのまま」干渉チェックや空間確認などのコーディネーション、属性情報の共有などができます。
IFCでBIMデータの共有をおこなう際の要点は「属性情報」だと考えます。buildingSMART Internationalは、IFCでクラス分けした要素（Element）ごとに、属性情報の標準セット（Property sets）を定義しています。
そのひとつであるProperty Setsは、例えば壁の場合、遮音等級、耐火等級、可燃性区分、外部区分、熱貫流率、耐力部材、防火区画のように、壁に求められる性能が列挙されています。これらの項目に「建築基準法や空間の使い方から求められる要求性能の値」を入力すれば、それらは設計与条件となります。それらの値を満たす設計の結果に置き換えれば設計図書で要求された品質となり、その品質を満足させる材料・機材の品質・性能に置き換えることでその壁の属性となります。
このようにBIMによるデータ連携の要点は「基本設計、実施設計１、実施設計２の各段階で個々の属性値がどの状態であるのかを管理すること」です。そしてISO19650シリーズでいうデータ共有環境（Common Data Environment：CDE）の本質だと思います。
要求性能、設計図書の要求品質、材料・機材の属性をエビデンスとして保管しておくことは、リニューアル工事やデューデリジェンスなどの資産マネジメントの有用な情報になるでしょう。
「IFCデータを利用した建築基準法の適合判定の研究」を紹介
ここでは、筆者の研究室に所属する大学院生が取り組んでいる「IFCデータを利用した建築基準法の適合判定の研究」についてご紹介したいと思います。
法律文は基本的に「基準部分、条件部分、例外部分」の3要素に分解できます。分解した要素をもとに対象法律文の適合判定を行う手順をすると、先ず例外処理を行い、次に条件処理を行い、最後に基準部分で判定処理を行うフローとなります。例外部分は建物周囲の状況によるためGISや3D都市モデルとの連携が必要となりますが、条件部分はIFCのProperty Setsを用いて次のように記述して条件を判定できると仮定します。
例えば、「地階を除く階数が四以上である建築物」は「max {IfcBuildingStorey / Pset_BuildingStoreyCommon / AboveGround == TRUE} >= 4」、「高さが十六メートルを超える建築物」は「IfcBuilding / Qto_BuildingBaseQuantities / Height > 16000㎜」と表現できます。基準部分については、壁を例とすれば、防火区画で2時間耐火が求められる壁を「(IfcWall / Pset_WallCommon / Compartmentation == TRUE) ∧ (IfcWall / Pset_WallCommon / FireRating == 2h)」と表記できます。
建築確認とは、設計図書が建築基準法に適合しているかどうかを確認する行為です。しかしここで考えたいのは、「BIMで建築確認審査を行うこと」から「建築基準法に適合した設計を効率よく行うこと」へのコンセプトの切り替えです。
後者の考え方では、プログラムコードで記述した条項から導き出される結果をBIMオブジェクトのProperty Setsの値に入力し、要求性能の参考値とする可能性が見えてきます。それを実現するためには、条項プログラムのライブラリを拡充していく必要があるでしょう。
このような建築基準法という公共財の情報を利用した設計支援プログラムは、誰でも参加できるオープンソースコミュニティで取り組むべきだと我々は考えています。
IFCを利用する環境｜BIMの広がりに期待
近年、IFCを利用する環境はかなり整備されてきました。IFCビューアを提供しているベンダーの多くは、数量集計や保全マネジメントシステム用のデータ（Construction Operations Building Information Exchange：COBie）出力など、多様なプラグインやIFCサーバーを提供しています。オープンソースの3次元CGソフトのBlenderはプラグインを組み込むことでIFCデータを構築することができます。IFCファイルを用いたBIMアプリケーションやWebアプリケーションの開発環境の提供がオープンソースで進められています。
IFCはオープンフォーマットですので、ユーザー主導の便利なBIMアプリ開発というイノベーションの民主化が広がっていくかもしれません。そうしたツールが充実していけば、IFCデータを直接、構築・編集・更新・共有・集約・抽出・再利用するようなBIMの広がりが期待できます。
参考文献
buildingSMART International “IFC4_ADD2_TC1 – 4.0.2.1”（https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/）
渡邉圭太郎，志手一哉，大越潤，萱嶋誠，「IFCの属性情報を用いた建築確認自動化の可能性に関する研究 建築部材の防耐火適合判定を対象として」，日本建築学会，第37回建築生産シンポジウム論文集，pp.263-270，2022.8
