IFCからIFCXへ：BIMデータ標準の世代交代ガイド

BIM関係者を30年間悩ませてきた問題

      BIMコンサルティングに携わる人なら、誰もが経験したことがあるだろう。プロジェクトの終盤、発注者からIFCファイルの提出を求められる。RevitやTeklaからエクスポートすれば、ファイルは開け、モデルも表示できる。しかし相手が別のプラットフォームにインポートすると、部材タイプはすべて「汎用建築要素」になり、プロパティセットは半分失われ、プレキャスト部材の鉄筋情報に至っては跡形もない。

      ファイルは技術的には「有効」だが、意味論的には空っぽだ。これは個別の現象ではなく、業界全体が30年間抱えてきた共通の課題である。IFC——1997年に誕生したこの国際標準は、建設業界のデータ相互運用への期待のすべてを背負い、同時にますます重くなる技術的負債も背負ってきた。

      2026年8月、buildingSMART Internationalはロンドンでプレスリリースを発表し、IFCX（業界で「IFC5.0」と呼ばれるもの）のコアおよびモジュール化最終プロジェクト計画が承認されたことを明らかにした。これは、BIMデータ標準30年来最大の世代交代が、正式に実施カウントダウンに入ったことを意味する。

      BIMコンサルティングとプレハブ詳細設計を主業務とする筑緯建築科技のような企業にとって、この出来事の影響はファイルの拡張子が変わるだけにとどまらない。

IFCXは何を変えたのか

      まず命名を整理しよう。中国語圏では「IFC5.0」と呼ぶのが一般的だが、公式プレスリリースでは「IFCX」が使われている。また「BIMWS」と呼ばれるものは実は別のレイヤーのもの（openCDE API）である。名称が混乱していること自体、この件がまだ固まりきっていないことを示している。しかし技術的方向性はすでに明確で、核心的な変化は5つある：

      第一に、アーキテクチャがモノリシックからモジュール式へ。IFC4xは巨大な単一の定義ファイルだが、IFCXは「コア＋ドメイン拡張モジュール」に分割され、ソフトウェアは必要な部分だけを実装すればよい。プレハブBIMにとって、これはPC部材のデータ定義が独立して進化でき、標準全体の更新を待つ必要がないことを意味する。

      第二に、定義言語がEXPRESSからTypeSpecへ。EXPRESSは1980年代に生まれ、学習曲線が急でツールチェーンも老朽化している。TypeSpecは現代的なインターフェース定義言語で、開発者エコシステムが活発であり、習得コストが低い。

      第三に、シリアライズ形式がSTEPからJSONへ。ファイル拡張子は.ifcから.ifcxになる。JSONはWeb時代の共通言語であり、API転送やプログラム解析に自然に適し、AI・機械学習パイプラインでの消費にも適している。

      第四に、コンポーネントレベルの更新をサポート。従来は1つの属性を変更するたびにファイル全体を再エクスポートする必要があったが、IFCXでは特定のコンポーネントのみを変更し、他はそのままにできる。この点は多者協調プロジェクトにとって極めて重要である——構造コンサルタントが梁の配筋を変更しても、建築モデル全体を再エクスポートする必要はない。

      第五に、マルチオーサー分散協調。IFC4xは本質的に「1人が書き終えてファイルを送る」ものだが、IFCXは複数人が同一データ上で各自のモジュールを編集でき、サーバーが唯一の真実の源となるよう設計されている。

簡単にまとめると、過去30年のIFCの合格ラインは「開けるかどうか」だった。次の10年、合格ラインは「読み取れ、呼び出せるかどうか」に変わる。

サービス層はすでに動いている：openCDE API

      IFCXが扱うのはデータ自体の形であり、openCDEが扱うのはそのデータへのアクセス方法である。これはbuildingSMARTが同時に推進しているもう一つのラインであり、IFCXよりも速く進んでいる。

      openCDEは4つのAPIコンポーネントで構成される：Foundation APIはバージョン管理と認証を担当し、Documents APIはドキュメントの公開と取得を担当し、2023年12月に最終標準ステータスを取得した。BCF APIはソフトウェア間の課題チケットの連携を担当し、bSDD APIはデータ辞書の照会を担当し、2025年5月時点で300以上の辞書をホストしている。

      これら4つのインターフェースはすべて公開・無料である。複数のクラウドプラットフォームがすでにDocuments APIに準拠して接続しており、BCFは100以上のBIMソフトウェアに導入されている。言い換えれば、サービス層は机上の空論ではなく、すでに実装済みのインフラである。

      BIMコンサルティング企業にとって、これは将来のプロジェクト納品が「数百MBのIFCファイルを送る」ことではなく、「発注者にAPIインターフェースを提供し、必要に応じて部材データを照会する」ことになる可能性を意味する。データは静的ファイルから生きたサービスへと変わり、コンサルタントの役割も「ファイルを納める人」から「データを管理する人」へと変わる。

推進力はどこから：政策と技術的負債の二重の驱动

      標準の世代交代は技術だけで推進されるものではなく、真の加速器はしばしば政府の案件である。

      シンガポールのCORENET Xプラットフォームは2025年10月からIFC形式での提出を要求し、目標はアルゴリズムによる自動審査と消防審査である。ドバイ市は2024年1月からBIM提出にIFCの使用を義務付けている。フィンランドの新建築法はIFC 4.3.2以降のバージョン要件を明記している。英国、北欧、ドイツの公共調達は、ISO 16739に準拠したopenBIM方式での納品をますます明確に要求している。

      国内の状況には特殊性がある。住宅都市農村建設部（MOHURD）が2012年から発布しているBIM国家標準は、IFCをデータ保存形式として明確に位置づけている。2025年4月に発布されたGB/T 45393.3-2025「情報技術 建築情報モデル（BIM）ソフトウェア 第3部：モデルビュー定義」は、MVDの中国における実施経路をさらに規範化した。安徽省の2025年版BIMデータ交換ガイドライン、深圳市の房屋建築BIMプラットフォームなどの地方実践も加速している。

      技術的負債について、buildingSMART自身の総括は外部の批判よりも厳しい：IFC 4.3には1300以上のエンティティがあり、300以上の記録された例外を抱えている。MVDに基づく認証プロセスを完了するには約5年かかる。2024年になってようやくIFC4標準に完全準拠したサンプルファイルの第一陣が発行された。標準の管理者自身が適合サンプルを持っていないという事実は、旧来の経路がすでに限界に達していることを示している。

プレハブBIM：IFCXの先行受益者か、それとも傍観者か？

      筑緯の主業務の一つはPC詳細設計である。プレハブ分野では、IFCの問題は特に顕著である：

      プレキャスト部材のデータ密度は現場打ちコンクリート構造よりもはるかに高い。1枚の合成スラブには、幾何形状、プレストレスト筋の配置、吊り点位置、生産ロット、輸送識別、設置順序など数十の属性次元が含まれる。これらの情報はIFC4xの枠組みでは、MVD定義の不完全さにより交換時にしばしば失われる。

      IFCXのモジュール設計はまさにこの症状に合致している。ドメイン拡張モジュールはプレキャスト部材向けにデータ構造を個別に定義でき、コア標準があらゆるシナリオをカバーするのを待つ必要がない。コンポーネントレベルの更新も意味する：工場がある板の生産パラメータを変更した場合、そのコンポーネントだけを更新すればよく、モデル全体を再転送する必要はない。

      しかし現実には、国内のプレハブプロジェクトのデータ交換は依然としてDWG＋Excelの組み合わせに大きく依存している。TeklaからRevitへの相互運用、BIMモデルから工場MESシステムへの接続は、現在のところ多くが独自インターフェースや中間データベースを経由しており、IFC標準チャネルではない。IFCXがプレハブ業界に真に恩恵をもたらすには、ソフトウェアベンダーと工場側の同時的な追随が必要である。

      我々の判断はこうだ：プレハブBIMはIFCXが最も早く実際の価値を生み出し得るセグメントの一つだが、標準の公開から工事への実装までには、1〜3年のツール追随期間がある。この期間に企業ができるのは、データガバナンスをしっかり行うことだ——自社のモデルの意味が完全で属性が規範化されていることを確保すれば、形式がどう変わってもデータ移行のコストは最小になる。

BIMコンサルティング企業が今できること

      IFCXは現在もalpha段階にあり、公式には「生産使用を想定しない」と明記されている。しかしだからといって完全に無視してよいわけではない。以下のことは今日から着手できる：

      一、プロジェクト契約でIFCバージョン番号を明記する。「IFC対応」という4文字は曖昧すぎる。IFC2x3、IFC4、IFC4.3の間は自由に互換できるものではなく、エクスポート側とインポート側が同一バージョンに揃える必要がある。BIM実行計画（BEP）に明記することを推奨する。

      二、IDSで情報要求を定義する。IDS（Information Delivery Specification）1.0は2024年6月にbuildingSMART公式標準となった。プロジェクトの情報納品要求を自然言語の文書から機械検証可能な条項に変えるものである。モデル納品前に、IDSに照らしてフィールド、単位、値域を項目ごとにチェックする。この手法は新標準の実装を待つ必要がない。

      三、openCDE APIの実装進捗に注目する。Documents APIはすでに最終標準であり、BCF APIは100以上のソフトウェアをカバーしている。プロジェクトでクラウドプラットフォームを協調に使用しているなら、プラットフォームがopenCDEに接続済みかどうかを注視し始めるとよい。接続が完了すれば、クロスプラットフォームの課題追跡とドキュメント管理ははるかに円滑になる。

      四、「意味の完全性」を内部品質検査に組み込む。どのバージョンのIFCを使うにせよ、最も一般的な納品問題は意味が空であること——部材がエクスポート後に汎用要素になってしまうことだ。内部品質検査プロセスに一项追加する：IFCエクスポート後に主要部材のタイプと属性が完全に保持されているかを抜き取り検査する。

      五、ツールチェーンの切り替えを急がない。IFC4.3は依然として現在生産に使用可能な最新バージョンであり、多くのプロジェクトはこの口径にとどまることを要求している。IFCXの生産可用性にはまだタイムテーブルがない。今は「追随観察＋データガバナンスの徹底」の段階であり、「全面切り替え」の段階ではない。

結語：遅い変数の中の速い機会

      標準の世代交代は典型的な遅い変数である。2020年の技術ロードマップ公開から2026年のプロジェクト計画承認まで、6年4か月かかった。プロジェクト計画承認から標準の正式公開、ソフトウェアの追随、工事への実装までには、さらに3〜5年かかるかもしれない。

      しかし遅い変数の中には速い機会が隠れている。誰が先に新標準に適合するデータガバナンス能力を構築するかが、次のラウンドの政府プロジェクトや海外プロジェクトの入札で先手を取れるかどうかを決める。buildingSMARTのプレスリリースではすでにスポンサーを公募している——資金を出して標準策定に参加する企業は、最終稿の前に意見を述べられる。ルールを書く者が利益を得る。

      筑緯としては、IFCXとopenCDEの技術進展を継続的に追跡し、実際のプロジェクトで新標準の能力の限界を徐々に試験していく。BIMコンサルティングの価値は決してモデリングだけではなく、データを正しい時間に、正しい形式で、正しい人へ流すことにある。標準の世代交代こそ、この価値を再定義する窓口なのである。

延伸閱讀

      本文の執筆にあたり、「劉小会MEd」公众号の深掘り分析を参考にした。同記事は標準の進化、命名の辨析、国内外のソフトウェア認証など多角的に詳細な整理を行っており、一読を推奨する：《IFC5.0とBIMWS：OpenBIMの次の10年》

      buildingSMART公式IFC5開発リポジトリ：https://github.com/buildingSMART/IFC5-development/

END

本文の見解は著者個人の見解を表すものです  著作権は筑緯建築科技に帰属します

無断転載はお断りします

転載時は出典を明記してください：筑緯建築科技

      筑緯建築科技は、建築設計最適化、BIM設計コンサルティング、プレハブ建築設計コンサルティングを主業務とする新興技術サービス企業である。チームは設計事務所の技術幹部、元会社のベテラン管理職、BIMエンジニア、プレハブ詳細設計者で構成され、施工図を含む設計最適化、BIMコンサルティング、電気詳細設計、プレハブ設計コンサルティングおよび詳細設計などの全過程コンサルティングサービスを提供している。

      建築設計最適化業務：不動産開発業者の設計管理の延長と補完として位置づけ、「専門が価値を創造する」「品質第一」の理念のもと、設計の重要段階で経済性、合理性、安全性を管理し、「コスト削減」「図面最適化」「付加価値」の目的を達成する。

      BIM設計コンサルティング業務：各大手国有企業、中央企業、民間企業と協力し、BIMコンサルティング、設計、施工、運用保守の全段階をカバーする。高品質住宅設計、精密基盤設計、デジタル施工によりエラーを減らし品質を向上させ、施工会社のコスト削減と品質保証を実現する。主要ソフトウェアベンダーと協力して施工段階の管理を行い、BIMモデルを物流と現場管理に適用する（L0D500深度）。

      プレハブ設計コンサルティング業務：Teklaソフトウェアを使用した全過程PC詳細設計を行い、BIMモデル内で空間パラメータと接続方式を調整でき、施工時の衝突を回避し、インダストリー4.0基準に沿ったデジタル納品を実現する。PC部材データ（寸法、鉄筋間隔など）を提供し、IoTを活用して生産、倉庫、輸送、設置を支援する。従来のPC詳細設計会社と比較して、特に物流倉庫や高層建築分野でシステムレベルのソリューションを提供する。

      公司の専門家チームは大手設計院出身で、技術的基盤が厚く、双軌設計と最適化において豊富な経験を持ち、技術力と管理水準は業界をリードしている。

END

本文の見解は著者個人のものです  著作権は筑緯建築科技（Zhuwei Architectural Technology）に帰属します

無断転載を禁じます

転載の際は出典を明記してください：筑緯建築科技

      Zhuwei建築テクノロジーは、総合設計最適化・BIMコンサルティング・プレハブ建築設計コンサルティングを専門とする新しいタイプの技術サービス企業です。大手設計院の技術中核、不動産企業の元上級管理職、BIMエンジニア、プレハブ建築エンジニアが集結し、建築工程の総合設計最適化と精密図面審査、BIMコンサルティングおよびMEP詳細設計、プレハブ設計コンサルティング・詳細化サービスを提供しています。

      設計最適化コンサルティング：不動産開発企業の設計管理の延長・補完として、民用建築の総合設計コンサルティングと最適化に注力しています。「専門性が価値を創造し、サービスが品質を築く」の理念のもと、全プロセスまたはお客様指定の重要段階で設計の経済性・合理性・安全性を管理し、無駄なコストを削減しながら図面品質を大幅に向上させ、「コスト削減・効率向上」を実現します。

      BIMコンサルティング：デジタル建設技術により、設計段階では設計者のミス削減と品質向上を支援し、施工段階では施工者のコスト削減と高品質なMEP設備施工計画を支援します。また、BIMモデルを運用段階の施設管理に活用し、主要ソフトウェアベンダーと協業して建築の運用管理を支援します。

      プレキャスト設計コンサルティング：BIMプラットフォームによる全プロセス設計を採用し、RevitとTeklaでPC詳細設計を実施します。部材の空間パラメータと配筋はBIMモデル内で連動して修正・調整でき、見たままの成果が得られます。インダストリー4.0水準の出図、全鉄筋の切断寸法データの提供、IoT技術によるPC部材の生産・保管・輸送・設置支援サービスを提供します。

      当社の専門家チームは大手設計院出身で、確かな技術力と二系統設計・最適化の豊富な経験を持ち、技術能力と管理能力は業界トップレベルです。

—— 本記事はWeChat公式アカウント「筑緯建築科技」から自動同期されています。原文を読む ——