IFCモデルに関するよくある疑問と実務上の留意点
発注者・設計者・施工者それぞれの現場から
第1回では、IFCを「建設分野の情報を共通ルールで表現するための標準」として整理しました。
実務では、設計者から施工者への引き渡し、発注者への納品、別のソフトウェアでの確認、維持管理情報の抽出などのために、BIMソフトウェアで作成したモデルをIFCファイルとして書き出し、受け渡すことがあります。その際、「別のソフトウェアで開くと形状や属性が違って見える」「必要な属性が入っていない」「施工や維持管理にそのまま使えるのか分からない」といった問題や疑問が生じています。
こうした問題や疑問には、BIMソフトウェアで作成・保存されたモデルと、そこからIFCファイルとして書き出されたモデルとの違いが関係しています。本稿では、前者を「オリジナルモデル」、後者を「IFCモデル」と呼び、両者を区別します。ここでいう「モデル」とは、建築物や土木構造物、その構成要素を、形状、属性および相互の関係によって表現したものです。
IFCモデルは、オリジナルモデルの完全な複製ではありません。IFCモデルに含まれる情報やその表現は、オリジナルモデルの内容、利用目的に応じた書き出し設定、ソフトウェアがIFCのオブジェクト、形状、属性などの書き出し、読み込み、表示などに対応できる範囲（以下、IFC対応範囲）によって変わります。一方で、利用目的、必要な情報、書き出し設定および確認方法を関係者間で定めることで、異なるソフトウェア間でも、目的に必要な情報を共通の意味で受け渡しやすくなります。
第2回では、このようなIFCモデルの性質を踏まえ、IFCモデルの見え方、業務における活用との関係、オリジナルモデルの作り方と書き出し設定、施工での利用可能性に関する疑問を整理したうえで、形状・位置・データ容量の問題と、属性の不足や不整合を起こさないための留意点を取り上げます。
まず、IFCモデルがソフトウェアによってどのように見えるか、受け取ったIFCモデルを業務に活用できるか、オリジナルモデルの情報がIFCモデルに適切に反映されるか、設計段階のIFCモデルを施工にそのまま利用できるかについて、実務で生じやすい疑問を取り上げます。
IFCモデルを扱う際に、まず生じるのが、どのソフトウェアでも同じように表示されるのかという疑問です。
IFCモデルは、共通ルールに基づいて構成されているため、異なるソフトウェア間で情報を共有・確認しやすくなります。ただし、すべてのソフトウェアで同じ表示を保証するものではありません。書き出し側・読み込み側で使用するソフトウェアやビューア、確認ツールでは、それぞれのIFC対応範囲や情報の解釈方法が異なるためです。
そのため、同じIFCモデルであっても、形状や属性の表示、分類の扱い、階層構造の見え方が異なる場合があります。例えば、設計ソフトウェアから書き出したIFCモデルをビューアでは問題なく確認できても、別のソフトウェアに読み込むと、部材の階層構造が異なって表示される、属性が別の項目として読み込まれる、曲面が分割されて表示されるといったことがあります。こうした違いは、必ずしもIFCモデルの不完全さによるものではなく、ソフトウェアごとの情報の解釈や表示方法の違いによって生じることがあります。
このように、IFCモデルの表示結果は、使用するソフトウェアによって異なる場合があります。そのため、表示結果の完全な一致を前提とするのではなく、利用目的、確認対象、使用するソフトウェアおよび確認方法を事前に定めます。これにより、異なるソフトウェア間でも、必要な情報の有無や内容を判断しやすくなります。IFCモデルを確認するときは、表示が同じかどうかだけでなく、利用目的に必要な情報が意図したとおりに読み取られているかを確認することが重要です。
発注者の立場では、IFCモデルに含まれる情報をソフトウェア上で確認し、業務上の判断や管理に利用できることを期待します。そこで生じるのが、IFCモデルを受け取れば業務に活用できるのかという疑問です。
IFCモデルを成果として受け取ることで、特定のBIMソフトウェア固有の形式に限定せずに情報を保管し、IFCに対応するソフトウェアで確認・利用できます。ただし、IFCモデルを受け取るだけで、業務に活用できるとは限りません。業務で活用するには、利用目的に必要な情報がIFCモデルに含まれていることが前提となります。
必要な情報は、IFCモデルの利用目的によって異なります。例えば、設計照査、住民説明、施工段階への情報の引き継ぎ、維持管理台帳との連携では、それぞれ必要となる情報が異なります。閲覧が目的であれば、形状と基本的な名称で目的を満たす場合があります。一方、維持管理では、管理対象となる部材、管理番号、材料、点検単位、設置位置などの情報を扱います。
そのため、発注者は「IFCモデルを提出すること」と定めるだけでなく、利用目的、対象範囲、対象とするオブジェクトとその分類、必要な属性、位置、形状の詳細度、確認方法などの要件を具体的に示すとともに、受入基準を定めます。ここでいう受入基準とは、提出されたIFCモデルを受入れ可能と判断するための基準です。発注者は、提出されたIFCモデルがこれらの要件を満たし、受入基準に適合していることを確認します。これにより、IFCモデルを照査、数量算出、情報の引き継ぎ、維持管理などに活用できます。
表 発注者が指定すべきIFCモデルの要件例
| 指定項目 | 内容 | 指定しない場合のリスク |
|---|---|---|
| 利用目的 | 閲覧、照査、数量、維持管理など | 利用目的に必要な情報が含まれない |
| IFCバージョン | IFC2x3、IFC4、IFC4.3のいずれか | 受け取り側が対応していない場合、開けない、または情報が欠落する |
| 対象範囲 | 建築、構造、設備、土木、地形など | 必要な対象が含まれない |
| 属性項目 | 材料、管理番号、分類、数量、維持管理要件など | 後工程で必要な情報を利用できない |
| 確認方法 | ビューア、確認ツール、検査項目 | 受領時に利用の可否を判断できない |
| 受入基準 | 形状、位置、属性、データ容量などについて受入れ可能と判断する基準 | 提出されたIFCモデルの適否を判断できない |
設計者は、オリジナルモデルに入力した分類や属性などの情報が、IFCモデルにも意図したとおりに反映され、異なるソフトウェア間で利用できることを期待します。そこで生じるのが、オリジナルモデルの情報がIFCモデルに適切に反映されるのかという疑問です。
BIMソフトウェア上で「梁」として作成・分類されている部材であっても、IFCモデルでは汎用的な要素として表現される場合があります。この場合、受け取り側のソフトウェアで「梁」として認識されないため、「梁」だけを抽出して数量を集計したり、「梁」に必要な属性を確認したりできない可能性があります。
このような違いが生じる要因の一つに、オリジナルモデルからIFCファイルを書き出す際の設定があります。なかでも、IFCバージョンやMVDは書き出し結果に影響します。IFCバージョンは、IFCの仕様の改訂段階を示すもので、IFC2x3、IFC4、IFC4.3などがあり、バージョンごとに表現できるオブジェクトの種類や情報構造などが異なります。MVDはModel View Definitionの略称です。特定の用途に必要な情報を交換するために、使用するIFCバージョンの仕様から、交換対象となるオブジェクト、属性、関係、形状表現などを絞り込み、それらの使用方法を定めた仕様です。IFCファイルを書き出す際、BIMソフトウェアは、選択されたIFCバージョンとMVDに基づいて、オリジナルモデルの部材をIFCのオブジェクトに対応付けます。このため、選択するIFCバージョンやMVDによって、部材の対応付けやIFCモデルに含まれる情報が変わります。
書き出したIFCモデルを確認する際は、形状だけでなく、情報の意味にも着目します。画面上では同じ直方体に見えても、梁、柱、基礎、設備架台のいずれとして分類されているかによって、後工程での扱いは異なります。
そのため、設計者は、書き出し前に、IFCモデルの利用目的と使用するソフトウェアのIFC対応範囲を確認し、適切なIFCバージョンやMVDなどの書き出し設定を選択します。書き出し後は、形状だけでなく、オリジナルモデルにおけるオブジェクトの分類や属性が、IFCモデルに意図したとおりに反映されているかを確認します。これにより、IFCモデルが利用目的に必要な情報を備えていることを確かめたうえで、後工程へ引き継ぐことができます。
施工者は、設計段階のIFCモデルに含まれる情報を、施工計画、数量確認、仮設検討などに活用できることを期待します。そこで生じるのが、設計段階のIFCモデルを施工にそのまま使えるのかという疑問です。
設計段階と施工段階では、モデルの利用目的、必要な情報の詳細さ、部材の管理単位が異なるため、受け取ったIFCモデルをそのまま施工検討などに使えるとは限りません。設計段階では、設計意図の伝達、設計内容の整合性確認、関係者との協議などに用いる情報が中心となります。一方、施工段階では、施工計画、仮設計画、工程計画、出来形管理などに用いる、工事の分割単位などの情報を扱います。
例えば、設計段階では一体のコンクリート部材として表現されていても、施工段階では打設リフト、施工ブロックなどに分けて管理する場合があります。設計段階のIFCモデルにおける部材分割が施工管理単位と一致していなければ、施工者は、施工目的に合わせてモデルを補正または再構成しなければなりません。
属性についても、設計段階のIFCモデルに、施工区分、品質管理項目、出来形計測対象などが含まれているとは限りません。設計段階で必要とされる属性と、施工者が施工段階で必要とする属性が異なる場合があるためです。
このように、設計段階のIFCモデルが、施工段階で必要となる部材の管理単位や属性を備えているとは限らず、そのまま施工検討に利用できない場合があります。その場合、施工者は、施工目的に合わせてIFCモデルを補正・再構成するか、施工用モデルを別途作成します。また、IFCモデルだけでは必要な情報の追加や編集が難しい場合もあるため、施工用モデルの作成にあたっては、オリジナルモデルの利用についても検討します。そのため、設計段階から施工段階へ引き継ぐモデルの形式と情報、施工段階で追加・再構成する内容、その作業を行う者を、関係者間で事前に整理することが重要です。
これまでの疑問から分かるように、IFCモデルの表示や利用の結果は、オリジナルモデルの内容、書き出し設定、使用するソフトウェアのIFC対応範囲、利用目的などによって変わります。実際の受け渡しでは、これらの条件の違いにより、形状、位置、データ容量、属性などが想定と異なる場合があります。
以下では、形状・位置・データ容量および業務に必要な属性とその利用方法について、受け渡し時に確認すべき事項を整理します。
IFCモデルを受け渡す際は、形状の欠落、位置ずれ、データ容量の増大に留意します。これらには、オリジナルモデルにおける形状の作成方法、許容誤差、部材同士の接続状態のほか、書き出し設定、読み込み設定、形状の変換方法、座標情報の扱い、使用するソフトウェアの機能など、複数の要因が関係します。
曲面や特殊な部材形状などは、IFCで形状を記述する形式（以下、形状表現）へ変換する過程で、一部が欠けたり、元の形状と異なって表示されたりする場合があります。オリジナルモデルのモデリング方法や精度が影響する場合もあれば、書き出し側または読み込み側のソフトウェアが、使用された形状表現に十分対応していない場合もあります。
位置ずれについては、オリジナルモデルの座標系と読み込み側の座標設定だけでなく、書き出し時の座標変換や、ソフトウェアによる座標情報の解釈も関係します。書き出し側と読み込み側で同じ座標系を設定していても、座標情報の変換方法や解釈が異なれば、位置ずれが生じる場合があります。
IFCモデルのデータ容量は、オリジナルモデルの詳細さだけでなく、書き出し時の形状表現にも左右されます。例えば、曲面を多数の面に分けて表現すると、記録する頂点や面の数が増えるため、データ容量が大きくなります。また、書き出す属性や数量情報が多い場合も、その分だけデータ容量が増えます。このため、同じような形状であっても、書き出し設定や使用するソフトウェアによって、IFCモデルのデータ容量が異なる場合があります。
こうした問題が生じる可能性や影響を小さくするため、実務の開始段階で、IFCモデルの利用目的、使用するソフトウェア、IFCバージョンやMVDなどの書き出し設定、座標系、必要な形状の詳細さ、確認方法、受入基準を整理します。書き出し前には、オリジナルモデルの形状、不要な要素、座標系、書き出し設定を確認します。書き出し後には、IFC対応ビューアと受け取り側のソフトウェアを用いて、形状、位置、データ容量、表示状態が受入基準を満たしているかを確認します。
受入基準を満たしていない場合は、オリジナルモデル、書き出し設定、読み込み設定、使用したソフトウェアなどの観点から原因を調査します。ただし、原因を特定できても、利用者によるモデルや設定の変更だけでは解決できない場合があります。ソフトウェアの機能や変換処理が関係している場合は、原因と対応可能な範囲を関係者間で共有し、利用方法の見直しやソフトウェア提供元への確認を含めて対応を検討します。
IFCモデルを業務に活用する際は、必要な属性が含まれているか、属性名や値が想定した内容になっているか、受け取り側のソフトウェアで属性を確認・利用できるかに留意します。形状、位置、データ容量に問題がなくても、属性が不足している、値が空欄になっている、分類が統一されていない場合は、目的とする業務に利用できないことがあります。
IFCモデルには、オリジナルモデルに入力された情報やソフトウェアが自動的に生成した情報が、書き出し設定とソフトウェアのIFC対応範囲に応じて反映されます。オリジナルモデルに入力されていない属性が、IFCモデルへの書き出し時に自動的に補われることはありません。一方、書き出し設定によっては、要素の管理や計算に用いられる識別子、分類、内部パラメータなども属性として書き出されます。その結果、利用目的に必要な属性が不足する一方で、業務で使用しない属性が含まれる場合があります。
属性の表示方法も、ソフトウェアによって異なります。同じIFCモデルを読み込んでも、属性が表示される項目やグループ、属性の検索・抽出方法などが異なる場合があります。そのため、IFCモデルに属性が含まれていることだけでなく、受け取り側のソフトウェアで、その属性を目的どおりに確認・利用できることを確かめます。
必要な属性は、利用目的と利用者によって異なります。例えば、発注者が維持管理番号、施工者が施工区分を必要としていても、設計者が設計図書の作成に必要な名称と属性だけを入力していれば、関係者が必要とする属性はそろいません。
実務の開始段階では、利用目的に基づいて必要な属性を定義し、オリジナルモデルへの入力方法とIFCモデルへの書き出し方法を定めます。あわせて、属性を使用する業務、作成者と利用者、作成・確定する段階、確認に使用するソフトウェア、書き出し対象とする属性を整理します。新たな属性を定める場合は、既存の属性名称や定義との重複や不一致についても確認します。
表 属性で確認すべき主な項目例
| 確認項目 | 定める内容 | 定めない場合のリスク |
|---|---|---|
| 利用目的 | 何の業務で使う属性か | 不要な属性が増える、または必要な属性が不足する |
| 作成・利用段階 | いつ作成し、いつ使うか | 入力漏れ、入力遅延、未確定情報の利用が生じる |
| 作成者・利用者 | 誰が入力し、誰が使うか | 責任範囲が不明確になる |
| 使用ソフトウェア | 作成・確認・利用に使うツール、バージョンなど | 表示・書き出し・検索方法が食い違う |
| 既存属性との整合 | 既存の属性名称や定義との対応関係 | 属性の重複、名称や表記の不統一が生じる |
属性の設定は、単なるデータ入力ではなく、情報の作成、確認、管理および利用のルールを定める作業です。誰が、どの属性を、いつ入力・確定し、どのように利用するかを決め、その内容がIFCモデルに正しく反映されていることを受け渡し前後に確認します。
IFCモデルを実務で活用するうえでは、書き出し後の確認だけでなく、受け渡し前の準備が重要です。特に、以下の点をあらかじめ整理しておくと、目的に合ったIFCモデルを作成・利用しやすくなります。
IFCモデルは、受け取るだけで自動的に業務へ活用できるものではありません。しかし、利用目的、必要な情報、使用するソフトウェア、書き出し設定、確認方法、受入基準を関係者間で共有すれば、設計照査、数量算出、施工検討、情報の引き継ぎ、維持管理などに活用できます。
次回は、今回整理したIFCモデルの性質や留意点を踏まえ、IFCを実務で活用するデータとして捉える視点から、活用目的に応じた情報要件、openBIMやCDEとの関係などを取り上げます。
