IFC
一言でいうと
IFCは、BIMモデルを別ソフトや別会社でも再利用しやすくするための中立データ標準です。
IFCはIndustry Foundation Classesの略で、buildingSMARTが策定するオープンなBIMデータ標準です。形状だけでなく、部材、空間、属性、階層関係などを一定ルールで表現できるため、RevitやArchicadのような異なるBIMソフト間で情報を受け渡す土台になります。重要なのは「書き出せるか」ではなく、「相手の用途に合う形で出せるか」です。
IFCで受け渡すもの
IFCは単なる3D形状ファイルではありません。部材の種類、空間、階層、属性、分類などを一定のルールで持たせて受け渡すための形式です。
- 壁、床、柱、梁、開口などの要素情報
- 部屋やゾーン、階層構成などの空間情報
- 部材に付随する属性やプロパティセット
- 分類や識別情報など、他システム連携の手がかり
IFCが必要になる場面
IFCが必要になるのは、ソフトが違う相手にモデルを渡す場面だけではありません。受け取り側の利用目的が自社と違うときにこそ重要になります。
- 設計モデルを施工会社や協力会社へ渡すとき
- 発注者要件に基づいて中立データ納品が必要なとき
- FMやチェックツール、別系統のプラットフォームとつなぐとき
Revit / Archicad / openBIMとの関係
ArchicadはopenBIMを重く受け止めた思想が強みとして語られやすく、IFCを前提にした議論とも親和性があります。Revitは外れ値を許しにくいシステマチックな構造が強みですが、その強みをIFC受け渡しに生かすには、属性設計や出力条件を明示的に整える必要があります。つまり、どちらのソフトでもIFCは使えますが、思想と運用設計の置き方が少し違います。
IFCがうまくいかない典型
- 相手の利用目的を決めずに、とりあえず書き出してしまう
- 必要属性や分類が揃っていないまま受け渡す
- 受け取り側のビューアや検証方法を事前に決めていない
- モデルの粒度や責任範囲が曖昧で、何を信用してよいか分からなくなる
実務で先に確認すべきこと
- 誰が受け取り、何に使うのか
- 最低限必要な属性、分類、LODの前提は何か
- 受け渡し前にどのような検証を行うか
- 再入力や手修正が発生した場合、どこまで許容するか
日本で普及が遅れやすい理由
日本では、まず社内のBIM導入や作図効率化を優先し、他社連携や中立データ納品まで設計していないケースが少なくありません。また、案件ごとに属性や分類の運用がばらつきやすく、IFCを出しても再利用しにくい状況になりやすいのが実情です。
重要なのは書き出しより受け渡し設計
RevitもArchicadもIFC入出力には対応していますが、自動的にopenBIM運用が成立するわけではありません。重要なのは、どの属性をどの粒度で出すか、受け取り側がどう確認し、どう再利用するかまで含めて設計することです。