見出し画像

第2回：IFCモデルの基礎と法規リファレンスの重要性

Kenya Sagara｜サグブレインCEO

こんにちは、相楽（さがら）です。前回は、BIMと建築確認の課題や展望についてざっくりとお話ししました。
第2回となる今回は、IFC（Industry Foundation Classes）がどのような構造を持ち、なぜ建築基準法や各種の法規と関連づけるうえで重要なのかを解説していきます。BIMを使った建築確認の自動化・効率化に興味をお持ちの方にとって、IFCの仕組みや法規リファレンスの概念を理解することは不可欠です。ぜひ一緒に考えていきたいです。

1. IFCとは何か？

建築業界の「共通言語」

IFC（Industry Foundation Classes）は、建築・土木・設備分野で標準化されたデータ交換フォーマットです。さまざまなCADソフトやBIMツール間で、建築モデルの情報をやり取りするために策定されました。IFCファイルには、以下のような情報が含まれます。

  • ジオメトリ情報（壁・床・天井などの形状や位置）

  • プロパティ情報（部材の材料・寸法・仕上げ、建物の用途・階数など）

  • 関係性情報（「この壁はこの部屋を仕切る」などの要素間リレーション）

ここで大事なのは、IFCが特定メーカーのソフトや特定国の仕様だけに依存しないオープンな標準であることです。そのため、異なるBIMソフトウェアを使うチーム同士でも、IFCフォーマットを介してモデル情報を交換できる可能性が高まります。

国際的な開発とバージョンの進化

IFCは、buildingsmart International（旧IAI: International Alliance for Interoperability）が中心となって策定を進めています。IFC2x3やIFC4など、バージョン更新が続けられ、より豊富な要素や新しいカテゴリが追加されてきました。近年では、土木インフラ分野も含めたIFC4.3なども注目されています。
建築確認に関わる場合にはIFC4以降が推奨されるケースが多く、IFC4.3であればより細かい部材属性やインフラ関連要素を扱うことも視野に入ります。

2. IFCモデルの基本構造

エンティティとプロパティセット

IFCモデルは、大まかにエンティティ（Entity）という単位で要素が定義されます。たとえば「壁」はIfcWall、「ドア」はIfcDoor、「空間」はIfcSpaceというように、各エンティティには固有の属性（高さ、厚み、材料など）が紐づいています。
加えて、プロパティセット（Pset）という仕組みによって、エンティティの標準属性に加えてさらにカスタマイズされた情報を持たせることができます。たとえば消防法関連情報や自治体条例向けのパラメータなどもPsetとして登録可能です。

リレーションシップと階層構造

IFCには「この壁がどのフロアに属するか」「この部屋がどの建物に属するか」といった階層構造や、「この梁がこの柱に取り付いている」というリレーションシップがモデル化されています。
建築確認においては、階層情報や部屋の用途、外壁との関係などが重要なチェックポイントになるため、IFCモデルを正しく作ることで自動チェックの精度を高めやすくなります。

3. 法規リファレンスとの関連

なぜIFCと法規を連動させるのか

建築確認では、建築基準法や自治体条例といった法規を満たす必要があります。BIMモデルから自動的に高さ制限や容積率、採光・換気要件などをチェックするためには、法規要件をデータ上で参照できる形にしておくことが重要です。
そこで、IFCモデルの属性（高さや用途など）が、建築基準法や自治体条例で要求される値と自動照合できる仕組みを作ると、時間と手間のかかる図面チェック作業を大幅に軽減できます。

具体例：用途地域や防火地域の指定

たとえば、用途地域や防火地域がそれぞれの自治体で異なります。

  • IFCモデルには敷地の位置情報や建物用途情報を入れておき、

  • GISデータなどで用途地域を検索し、

  • その結果と建築基準法の制限（用途地域別の容積率や建ぺい率、防火構造など）をチェックする
    という流れが考えられます。IFCモデルが位置・用途・構造といった必須項目を正しく保持していれば、自動チェックがかなりスムーズになります。

法令リファレンス（Rule Set）

法改正や自治体ごとの条例変更があっても、ルールエンジンやmvdXMLなどを使ってIFCモデルと法規との照合ルールを別途管理しておけば、法令が更新された際にはルールだけ更新すれば良い、という状態に近づけます。
こうした「IFCモデル × 法規リファレンス」の仕組みが充実すると、設計者が自分のモデルをセルフチェックしやすくなるだけでなく、審査官の負荷も減るため、建築確認全体のDX化が進む可能性が大きいのです。

4. IFCに含めるべき情報とは？

必須属性の例

  • Building（建物）

    • 建物の名称、階数、用途、延べ床面積など

  • Floor（又はStory）

    • 階ごとの用途、床面積、高さ

  • Space（部屋）

    • 部屋の用途、面積、仕上げ材など

  • Wall / Door / Window / Beam / Column

    • 寸法、材料、耐火性能、取り付け位置情報など

すべてを網羅していなくても、少なくとも法規チェックに必要な属性（建物用途、階数・高さ、構造種別、防火区画情報など）をIFCモデル上で定義しておくと、後の自動チェックが機能しやすくなります。

ローカルルールへの対応

自治体ごとに異なる独自の条例がある場合、PsetやPropertySingleValueを使って、その地域特有の情報を拡張しておくやり方が考えられます。例えば、防火区画や特定用途制限などを「Pset_LocalRegulations」といった形で付与することで、モデルと条例を紐づける設計ができます。

5. IFCをどう活用するか：実装イメージ

  1. モデル作成（設計段階）
    設計者がRevitやArchiCAD等でBIMモデルを作成し、IFC形式で書き出す。

  2. IFCモデルの取り込み
    連載の次回以降でも扱うBIMserverやifcOpenShellなどを用いて、IFCファイルを読み込む。

  3. 基本情報のチェック

    • Buildingの有無、Floor数、Spaceの定義などが成立しているか

    • 建物用途や防火区画などの必須属性が入力されているか

  4. 法規との照合
    ルールエンジンやmvdXMLで「用途地域別の容積率」「建物高さ制限」などを自動判定し、エラーや警告を表示する。

  5. 不整合への対処
    Psetの書き忘れや命名ミスがある場合、設計者にフィードバックが返る。修正後、再度IFCを出力し、再チェックする。

6. まとめと次回予告

IFCモデルの基礎構造は、BIMを使った建築確認の自動化や効率化を実現する土台となるものです。そして、建築基準法や自治体条例と連動させるためには、IFCモデル上に正しい属性やリレーションシップを設定し、法規の内容をデジタルなルールとして別途管理する必要があります。

次回以降は、システム全体をどのように設計し、BIMserverやBIMvie.wsなどのツールを用いて管理・可視化していくのかを具体的に見ていきます。IFCの基本を念頭に入れておくと、後々の自動チェックや幾何解析、条例対応などの話がよりわかりやすくなるはずです。

もし疑問や気になる点があれば、コメント等でぜひ教えてください。皆さんと一緒に、建築確認のDX化を探求していければ幸いです。では、また次回！

株式会社サグブレイン　CEO　相楽賢哉

いいなと思ったら応援しよう！