BIM・IFCブログに戻る
ツールと比較 · 2026-10-02 · 11分
IFC ファイルの中身は？フォーマットを図解で解説
.ifc ファイルはコードエディタで開けるプレーンテキストです。読み方が分かれば、IFC の謎の半分は消えます。ヘッダー、番号付きインスタンス、GlobalId、プロパティを運ぶ関係。フォーマットを図にして解説します。
IFC ファイルの中身は？フォーマットを図解で解説 — IFC Viewer Online article cover
多くの人は IFC ファイルをビューア越しにしか見たことがありません。もったいないことです。.ifc ファイルはプレーンテキストで、10 分読むだけで、ふだん謎のままのことが説明できます。なぜ GUID が重要なのか、見えているのになぜプロパティが「ない」ことになるのか、なぜファイルが大きくなるのか、なぜエクスポートの設定 1 つで下流すべてが壊れるのか。
このガイドではファイルを開き、中身を図にします。
STEP 形式（ISO 10303-21）の IFC ファイル。スキーマを示すヘッダーの後、1 行に 1 つの番号付きインスタンスが続きます。
この記事のポイント
- IFC ファイルは番号付きインスタンスのリストです。番号はファイル内でのみ有効で、エクスポートのたびに変わります。
- 各インスタンス内の 22 文字の文字列 GlobalId こそが、長く保たれることを想定した識別子です。
- プロパティや空間的な包含を含め、重要な情報のほとんどは要素に直接ではなく、関係エンティティを介して関連付けられています。
ヘッダー：どのスキーマ、どのビューか
ファイルは ISO-10303-21; と短い HEADER セクションで始まります。重要なのは 3 行です。
- FILE_DESCRIPTION はモデルビュー定義（Coordination View、Reference View、Design Transfer View）を示し、エクスポーターが使うつもりだった IFC のサブセットを定めます。
- FILE_NAME はファイル名、タイムスタンプ、作成者、オーサリングアプリケーションを記録します。
- FILE_SCHEMA はスキーマ（IFC2X3、IFC4、IFC4X3）を示します。以下のすべての行はこのスキーマに従って読まれ、同じエンティティでもバージョンによって属性が異なることがあります。
スキーマのバージョン選びは別のテーマです：IFC2x3 と IFC4 の違い。
データ部：1 行に 1 インスタンス
DATA; の後は、すべての行が同じ形をしています。番号、エンティティ名、そしてスキーマが定める順序の属性リストです。
#245= IFCWALL('1kTvXnbbzCWw8lcMd1dR4o',#2,'Basic Wall:Ext 300',$,$,#210,#240,$,.STANDARD.);
| 要素 | 意味 |
|---|
| #245 | インスタンス番号（express ID）。このファイル内でのみ有効 |
| '1kTvXnbbz…' | GlobalId。22 文字の圧縮 GUID |
| #2 | 別のインスタンスへの参照（ここではオーナー履歴） |
| $ | 属性が未設定 |
| .STANDARD. | 列挙値（定義済みタイプ） |
| #210, #240 | 配置と形状表現。別の行で定義される |
GlobalId 自体がエクスポートのたびに変わると、下流の処理がすべて同時に壊れます。原因と各オーサリングツールでの対処はIFC の GUID がエクスポートのたびに変わる理由にあります。
エンティティは互いに継承する
IFC はオブジェクトモデルです。IfcWall は IfcBuiltElement であり、それは IfcElement、IfcProduct、IfcObject、そして最終的には IfcRoot です。そしてそのすべての属性を持ちます。すべての壁、ドア、スペースに GlobalId と Name があるのはそのためで、どちらも IfcRoot に由来します。
各エンティティは上位型の属性を継承します。IfcElement 向けのチェックは、その下のすべての壁、ドア、柱に適用されます。
名前はバージョン間で変わります。IFC4.3 で IfcBuiltElement と呼ばれるものは、IFC2x3 と IFC4 では IfcBuildingElement でした。名前をハードコードしたツールはもう一方を見逃します。同じモデルが、あるツールではチェックに通り、別のツールでは落ちる理由の 1 つです。
関係もエンティティである
最初は IFC を読みにくくしている設計判断が、同時に IFC の強みでもあります。関係はそれ自体が独立したオブジェクトなのです。壁は自分のプロパティ一覧を持っていません。その代わりに、IfcRelDefinesByProperties のインスタンスが壁とプロパティセットの両方を指します。空間的な包含、材料、タイプ、開口、グループも同じ仕組みです。
プロパティはプロパティセットにあり、要素かそのタイプに関連付けられます。タイプのプロパティセットはすべてのオカレンスに適用されます。
これが IFC 品質チェックで最も多い誤検出の根本原因です。タイプに定義されたプロパティは、オカレンスしか読まないツールには欠落して見えます。本当の原因はエクスポート後に IFC のプロパティが消えるで、コードでこれらの関係をたどる方法はPython でプロパティセットを読むで解説しています。
IFC ファイルが大きくなる理由
- 形状が大半を占めます。三角形分割されたファサードや詳細な設備部材は数千行になることもありますが、押し出し形状やマップ（インスタンス）形状はずっと小さく済みます。
- 繰り返しのデータは繰り返し書かれます。プロパティセットや形状表現を共有しないエクスポーターは、要素ごとに同じ行を書き出します。
- 素の STEP には圧縮がありません。ifcZIP にすると通常は数分の 1 になり、受け手のツールが対応していれば納品形式として妥当です。
安全にファイルを小さくする方法はIFC ファイルサイズを小さくする方法に、ブラウザが落ちるほど大きいファイルについては大きな IFC ファイルとブラウザのクラッシュにまとめています。
自分でファイルを読む
- テキストエディタで開く 大きなファイルに耐えられるエディタなら何でも構いません。まずヘッダーを見ましょう。スキーマとモデルビューで何が入っているか見当がつきます。
- 気になるエンティティを検索する IFCWALL(、IFCSPACE(、IFCBUILDINGSTOREY(。件数を見るだけでも手早い確認になります。
- 1 つの要素の参照をたどる 壁の # 番号を検索して、それを指している関係（包含、プロパティ、タイプ）を見つけます。
- そのあとビューアに切り替える 同じ情報を、空間ツリー、プロパティパネル、そしてこれらの関係を自動でチェックする検証機能で、操作しながら確認できます。
要素が階やスペースにどう整理されるかは、IFC の空間構造を図解で解説しています。
IFC ファイルの中身は？フォーマットを図解で解説