BIM・IFCブログに戻る
BIMコーディネーターなら誰もが経験しているはずです。IFCファイルをエクスポートして共通データ環境（CDE）に送ったところ、存在すら知らなかった構造的なエラーのせいで差し戻される。何千ものIFCファイルを検証してきた経験から言えば、不合格になる納品の大半は、同じ7つのエラーが原因です。
- 44 — チェックするルール
- 7 — 差し戻しの80%の原因
- 30秒 — どのモデルでも検証完了まで
- 100% — ブラウザー内で実行
1. GlobalId（GUID）の重複
GlobalIdは、IFC要素の恒久的なIDです。モデルの統合、バージョンの更新、ソフトウェアの移行を経ても保たれます。2つの要素が同じGUIDを共有すると、安定した参照に依存するあらゆるツール（BCFのワークフロー、Revitのリンク追跡、CDEのバージョン管理）が、気づかないうちに機能しなくなります。
2. 孤立要素
孤立要素（オーファン）とは、IFCの階層内に空間コンテナを持たない物理要素のことです。ファイルには存在するのに、Project → Site → Building → Storeyの中には現れません。ほとんどのビューアーは、孤立要素をまったく表示しません。原因は通常、平面図に関連付けられないままレベルに配置された要素か、エクスポート時にホストとなる階を失ったリンクファイルの要素です。
3. 誤ったコンテナ
要素にコンテナはあるものの、それが間違っているケースです。階の中ではなく、IfcSiteの直下に配置されています。敷地レベルへの配置が有効なのは、インフラの要素だけです。IfcSiteの中にある壁や柱は、NavisworksからSolibriまで、下流のあらゆるツールを混乱させます。
4. 集約関係の破綻
IfcRelAggregatesは、空間ツリーを組み立てるための関係です。集約関係が壊れているとは、こうした関係のどれかが存在しないエンティティを指しているということです。典型的には、関係が書き込まれた後にエンティティが削除された場合や、削除が正しく反映されないままモデルが統合された場合に起こります。
5. 空間階層の違反
IFCは厳密な順序を定めています。IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey → 物理要素です。この順序が崩れると（SiteがないままBuildingがProjectの直下にある、要素が階ではなくIfcBuildingに配置されている、など）、多くのツールがツリーを正しく構築できません。
6. IfcProjectの欠落
有効なIFCファイルには、IfcProjectがちょうど1つ含まれていなければなりません。モデル階層全体のルートノードだからです。サブモデルを生成するエクスポートのワークフローの中には、これを省いてしまうものがあります。その結果、エラーなくパースできるのに、空間のルートを持たないファイルができあがります。
7. 要素名が空
Name = "" やnullの要素はスキーマ違反ではありませんが、下流のほぼすべてのワークフローを妨げます。BCFのコメントでは要素をはっきり参照できず、数量拾いの表には空白の行が並び、干渉レポートは読めないものになります。
ライブで検証する
buildingSMARTのDuplexを開いて、問題のないIFC検証レポートがどのようなものかを確認してください。そのうえで自分のモデルを開き、この7つのエラーがないかチェックしてみましょう。
IFC2x3 · 2.4 MB
インタラクティブなIFCビューアーを開く
納品前チェックリスト
- CDEへのアップロードの前に、毎回検証を実行する。後からではなく。
- 調整用の納品では、Health Score（ヘルススコア）80以上を目標にする。
- GUIDの重複はゼロ。BCFのワークフローでは譲れない条件。
- すべての物理要素を階の中に配置する。SiteやBuildingの直下には置かない。
- ルートにはIfcProjectを1つ。例外なし。
- すべての要素に名前を付ける。汎用的な名前でも構わない（「Wall-001」でも空の文字列よりはまし）。
- 空間階層は「Project → Site → Building → Storey → 要素」の順に揃える。
IFC検証で最も多い7つのエラーとその修正方法
