IFC（Industry Foundation Classes）とは、異なるBIMソフトウェア間で情報をやり取りするための中立的なファイル形式（データ仕様）です。
建設業界における情報交換の標準フォーマットとして、buildingSMART Internationalが策定・管理しており、ISO 16739として国際規格にもなっています。

各ソフトウェアはそれぞれ独自の形式（RevitならRVT、ArchiCADならPLNなど）を持っていますが、ソフトが違えばそのままでは開けない・使えないという問題が発生します。
その橋渡しをするのがIFCであり、「BIMモデルの共通言語」とも言える存在です。

２．IFCの特徴とメリット・デメリット

IFC（Industry Foundation Classes）の最大の特徴は、「中立性のあるオープンなデータフォーマット」であることです。
これは特定のBIMソフトウェアに依存せず、異なる製品間でも建築情報モデルを共有できるように設計されています。
このような中立性を活かすことで、業務全体の効率が向上するというメリットがあります。
たとえば、意匠・構造・設備といった異分野の設計チームが、共通の形式でモデルをやり取りすることで、変換ミスや再入力の手間を大幅に削減できます。
また、IFCは図面情報だけでなく、壁や窓など各部材に含まれる属性（材質、寸法、メーカー名など）も保持するため、施工や維持管理の段階においても情報の再活用が可能です。

一方で、万能ではないという点には注意が必要です。
IFC形式に変換した際、ソフトウェア独自のパラメータや細かな表現（例えばRevitで設定されたファミリのパラメトリック制御など）は保持されないことがあります。
あくまで「情報を共有するための中間フォーマット」として位置づけるべきであり、IFCを使ってそのままモデリング作業を継続するような用途には適していません。
このように、IFCは建設業界におけるBIM活用の基盤となる重要なフォーマットですが、その役割と限界を正しく理解した上で活用することが、トラブルを防ぎ、円滑なデータ連携につながるポイントとなります。

３．ソフトウェア間連携におけるIFCの役割

BIMを導入している多くの建設プロジェクトでは、1つのソフトウェアだけで業務が完結することは稀で、複数の専門ソフトウェアが用途や業種ごとに併用されるのが一般的です。
意匠設計にRevitやARCHICAD、構造設計にTekla Structures、設備設計にRebro、施工管理にNavisworksやSynchroなど、目的に応じたBIMツールがそれぞれ使われています。

しかし、各ソフトウェアは独自のファイル形式やデータ構造を持っており、そのままでは他ソフトで開くことができない、あるいは情報の欠損が発生するという課題が生じます。
この課題を解決するための“共通言語”として、IFCがソフトウェア間の橋渡しを担います。

IFCは、各BIMソフトで作成された情報を中立的な形式に変換（エクスポート）し、受け取り側のソフトで再利用可能な形に変換（インポート）する役割を果たします。
例えば、Revitで作成した意匠モデルをIFC形式に書き出し、Tekla Structuresで読み込んで構造設計に反映する、といったプロセスが可能になります。
これにより、「ソフトが違うからデータを渡せない」といった部門間・企業間の“情報の断絶”を防ぎ、BIMの本来の価値である“情報の一元管理と共有”を実現する土台となるのです。

４．IFCの活用シーン（設計～施工～維持管理）

IFCは単なる設計間のやり取りだけでなく、建設ライフサイクル全体で活用されます。

■設計段階
　他分野間でのモデル共有
　干渉チェックやモデル統合

■施工段階
　施工図作成や工程シミュレーション
　部材数量の拾い出し

■維持管理段階
　建物の属性情報（材料、仕様、設置年など）をIFCで保存し、FM（施設管理）に引き継ぐ
　導入ソフトが変わっても、基本情報を保ったまま活用可能

また、公共工事や海外プロジェクトではIFC形式での納品が求められるケースも増えており、BIM確認申請でもIFCデータの提出が必要になることから、今後ますます重要性が高まります。

５．IFCの注意点

IFCはBIMモデルの中立フォーマットとして、異なるソフトウェア間でのデータ連携を可能にする強力なツールです。しかしながら、「完全な互換性があるわけではない」という点には十分注意が必要です。

■ よくある変換エラー・問題例
① 座標や位置がずれる（モデルが意図しない位置に表示される）
原因例：各ソフトで設定されている「基準点」や「プロジェクト原点」の扱いが異なる。
具体例：Revitで作成したIFCをARCHICADで開いた際に、建物全体が原点から数百メートルずれて配置されることがある。
対処法：事前に座標系・基準点設定を統一し、読み込み後に位置確認を徹底する。

② 属性・パラメータが正しく引き継がれない
原因例：ソフト固有のパラメータやプロパティがIFC定義にマッピングされていない。
具体例：Teklaで設定した鋼材等の部材情報（断面記号や製品コード）が、IFC経由でRevitに読み込んだ際に消失する。
対処法：必須情報はIFCの「Property Set」にマッピングしておく。また、独自パラメータがある場合はCSV等で別管理も検討。

③ ファミリ（部品）や複雑形状の欠落・変形
原因例：複雑なジオメトリやブーリアン処理された形状が、IFCでは単純化される・失われる場合がある。
具体例：Revitのカスタムファミリが、IFC経由でArchicadに変換された際に、ただの立方体オブジェクトになってしまった。
対処法：重要な部材形状は事前にIFC出力で可視化確認を行い、必要に応じて再モデリングも検討する。


IFCは非常に有用なフォーマットですが、「一度出力して終わり」ではなく、変換後のデータ確認が必須です。
特に、以下のようなタイミングでは注意が必要です。

・プロジェクト間でBIMモデルを受け渡すとき
・設計から施工フェーズへデータを移行するとき
・維持管理用にBIMモデルを引き継ぐとき

６．まとめ

IFCは、「BIMのデータを共通の言語でやり取りするための基盤」となる存在です。
しかし、魔法のツールではなく、「できること」「できないこと」を理解し、適切に使うことが求められます。

今後のBIM活用や建設DXを進める上で、ソフト間連携や長期的な情報活用の視点からもIFCへの理解は不可欠です。
自社の業務フローに合わせて、「どのタイミングで」「どの粒度で」IFCを活用するか、今から検討を始めてみてはいかがでしょうか。

それでは次回のブログでお会いしましょう。