建築・土木で使うIFC形式とは？BIM連携の基本・実務活用と注意点まとめ
エバープレイ編集部IFCとは何か：概要と目的
IFC（Industry Foundation Classes）は、建築・土木のBIMデータの交換と共有を目的としたオープンなデータ仕様です。buildingSMART（旧：buildingSMART International）が標準化を進め、ISO規格（ISO 16739）にも採用されています。IFCは設計、施工、維持管理を横断するデータの共通言語として、異なるソフトウェア間でのジオメトリや属性情報の整合性を保ちながらモデルをやり取りするために用いられます。
IFCの基本構造：エンティティと空間構造
IFCはオブジェクト指向的なスキーマで構成され、主にエンティティ（例えば IfcWall、IfcSlab、IfcDoor）とそれらの属性・関係でモデルを表現します。空間構造は階層化され、一般に IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey → IfcSpace といった単位で整理されます。各要素はGUIDに相当するGlobalIdを持ち、IfRel系（IfcRelAggregates、IfcRelDefinesByPropertiesなど）で関係付けられます。
ジオメトリと表現方法
IFCは複数のジオメトリ表現方式をサポートします。代表的なものはスイープ形状（ SweptSolid ）、B-Rep（境界表現）、CSG（Constructive Solid Geometry）、メッシュ表現などです。1つの要素に対して複数の表現（例えば設計用のソリッドと解析用のメッシュ）を持たせることも可能で、IfcShapeRepresentationで管理されます。ただし、ソフト間でのパースやレンダリング方法の違いにより形状情報が劣化することがあり、運用設計が重要です。
属性情報とプロパティセット（Pset）
IFCは数量、材料、製造者情報、設置日など多様な属性を保持できます。属性はIfcPropertySet（Pset）としてまとめられ、プロジェクト固有のPsetを定義して利用できます。分類体系（例：Uniclass、OmniClass、国別の分類）と組み合わせることで要素検索や数量集計の精度を高められます。
バージョンとファイル形式
主要なIFCのバージョンにはIFC2x3とIFC4があり、IFC4はISO 16739で標準化されています。近年はIFC4系列で追加・改善が進み、IFC4.3などでインフラや土木分野の拡張も行われています。ファイル形式は従来のSTEPベースのテキスト（.ifc）、XMLベースの.ifcXML、圧縮コンテナ.ifczip、およびifcJSONといった新しいシリアライズ形式があります。運用上はソフトの対応状況を確認して採用します。
MVD（Model View Definition）と交換要件
IFCは非常に広範な仕様を持つため、すべてをやり取りするのは現実的ではありません。そこでMVD（Model View Definition）は、交換に必要なIFC要素とルールのサブセットを定義します。代表的なMVDには「Coordination View」「Reference View」「COBie（FM引継ぎ向けの情報）」などがあります。プロジェクトの受渡し要件（EIR）やBEP（BIM Execution Plan）でどのMVDを使うかを明確にすることがトラブル防止になります。
実務での活用ケース
- 設計調整・干渉チェック：複数モデルを統合してSolibriやNavisworks等で干渉チェックを実施。
- 数量算出とコスト見積り：IFCから材料数量や寸法を抽出して積算ツールと連携。
- 解析連携：構造解析や設備解析用にジオメトリや荷重情報をエクスポート。
- 施設管理（FM）：維持管理用の属性（設備の型式、保守履歴）をIFCに含めて引き渡す。
- デジタルツイン：現場のセンサーデータや点群をIFCモデルに紐付けて運用管理に活用。
IFC導入の実務ポイント（チェックリスト）
- 交換の目的を明確化する（Clash、数量、FMなど）。
- 使うIFCバージョンとMVDを明確に契約で定義する。
- 命名規則・分類・Psetのテンプレートを標準化する。
- 共有座標系と高さ基準（ゼロ基準）を統一する。
- ジオメトリの詳細度（LOD）と情報の詳細度（LOI）をプロジェクト段階ごとに決める。
- 出力後は複数のビューアで検証し、IFCバリデータで整合性をチェックする。
よくある課題とその回避策
導入にあたっては次のような課題が見られます。まずソフト間の実装差により、同じIFCでも情報欠落やジオメトリ崩れが起きます。回避策はMVDに沿った最小限の属性のみを確実に渡すこと、そして受け手でのテストを事前に行うことです。また、IFCは巨大化すると処理が重くなりやすいため、用途別にモデルを分割して扱う（リンク方式や分散モデル）ことが有効です。さらに、IFCにはパラメトリック情報が失われることがあるので、ソフト間連携時に必要なパラメータは独立した属性として明示的に出力しておくと良いでしょう。
ツールとオープンソース実装
主要なBIMソフト（Revit、ArchiCAD、Tekla、Allplan、Bentleyなど）はIFCの読み書きに対応していますが、エクスポート設定に差があります。オープンソースやライブラリとしては IfcOpenShell（ジオメトリ処理・変換）、xBIM（.NET向け）、IfcJSON関連ツールが有用です。これらを使って自動化スクリプトや量測ツールを作る事例が増えています。
将来動向：IFCの進化とインフラ対応
IFCは単に建築物の形状を交換するツールから、より広範なライフサイクルデータプラットフォームへと進化しています。インフラ分野（道路・橋梁・トンネルなど）向けの拡張や、ifcJSON等の軽量化フォーマットの普及、そしてクラウドベースの協調ワークフローとの連携が進んでいます。データ駆動型の運用管理（デジタルツイン）においてIFCは重要な役割を果たすと期待されています。
まとめ：実務でIFCを使いこなすために
IFCは異なるツールと組織をつなぐ強力な共通語ですが、仕様の広さと実装差に伴う運用上の注意が必要です。プロジェクト開始段階で交換要件（MVD）、属性テンプレート、座標系、LOD/LOIを定義し、出力後に多面的な検証を行うことが成功の鍵です。目的に応じたIFCの活用を設計し、継続的に運用ルールを改善することで、設計・施工・維持管理の効率化と品質向上が期待できます。
参考文献
- buildingSMART: IFC Standard
- ISO 16739: Industry Foundation Classes (IFC) — building information models
- IfcOpenShell — Open source IFC toolkit
- xBIM Toolkit（GitHub）
- buildingSMART: Model View Definitions (MVD)
投稿者プロフィール
