目次
意匠・構造・設備の分野間連携は、同じソフトで作業することが目的ではありません。座標・基準点・階・通り芯の統一、モデル分割とファイル構成、ネイティブ連携とIFC連携の使い分け、IFCの書き出し前後チェック、統合モデルによる干渉確認と結果の分類、課題管理とBCFでの共有、施工BIMへの引継ぎまで、分野間連携を進める手順を整理します。
連携の目的は「同じソフトで作ること」ではない
意匠・構造・設備の分野間連携は、全員が同じBIMソフトウェアを使うことが必ずしも目的ではありません。分野ごとに必要な作業環境が異なるためです。連携の目的は、各分野の専門性を保ちながら設計判断に必要な情報を共有し、不整合を早めに見つけることです。干渉確認のほか、空間調整、シャフトの成立確認、確認申請図書との整合にも活用します。
確認内容は設計段階で変わり、基本設計初期は方針の共有、実施設計後半は残課題の確認が中心です。深度はBEP(BIM実行計画書)の詳細度で変わるため目安として扱い、開始前に連携目的・時期、受け渡し形式、位置合わせの基準、モデル範囲、課題管理方法を合意します。
座標・基準点・階・通り芯をまず統一する
最初に確認すべき技術条件は、座標、基準点、階、通り芯です。位置がずれていると干渉確認の結果は信用できません。数百ミリのずれでも梁とダクトの干渉に影響します。
プロジェクト開始時には位置合わせの基準となる「基準モデル」を決めます。一般には意匠モデルを基準にしますが、敷地測量や施工座標との関係が重要な場合は別途座標管理資料を用意します。原点、方位、通り芯、階(階名・階高・設計GL・構造レベル)、単位、共有方法を決めます。
階名が一致していても床レベルは違うことがあります。意匠モデルの「2階」は仕上床レベル、構造モデルは躯体天端が基準の場合があり、設備モデルでは梁下の条件が重要です。交換前に確認し、BEP等に反映します。
モデル分割とファイル構成
建物全体を一つのモデルで扱うとファイルが重くなり、責任分担も複雑になります。各分野モデルが分かれることを前提に、規模や体制によっては棟別・階別・工区別・用途別にさらに分割する場合がありますが、分割しすぎると版管理が複雑になるため、作業と管理のバランスで決めます。
モデル分割と成果物の提出単位は一致しません。分割していても統合モデルを提出する場合や複数の図面・IFCを出力する場合があり、両者を混同しないようにします。
ネイティブ連携とIFC連携の使い分け
受け渡し方法にはネイティブ形式、IFC、PDF、2D図面、表形式があります。重要なのは何を確認するために受け渡すかです。
| 連携方法 | 向いている場面 | 注意点 |
|---|---|---|
| ネイティブ連携 | 同一ソフト・クラウドでの共同編集 | ソフト依存が強い |
| IFC連携 | 異なるソフト間の共有、統合確認、長期参照 | 変換・属性マッピング確認が必要 |
| PDF・2D図面 | 正式成果物、承認、説明資料 | モデルとの整合確認が必要 |
| 表計算ソフト等 | 属性一覧、面積、課題リスト | BIMモデルとのID連携が必要 |
ネイティブ連携(BIMソフトウェア固有の形式やクラウド環境を使う連携)は形状・属性を保持しやすい一方、環境依存が強く外部連携には制約が出る場合があります。IFC(異なるソフト間でBIM情報を共有するオープンな国際標準)はモデルを重ねたり長期参照したりするのに有効ですが、書き出せば情報が完全に移るわけではありません。
IFCのマッピングと書き出し前後チェック
BIMソフトウェア内の分類・属性はそのままIFCに移りません。IFCクラスやプロパティセットに対応づける「マッピング」が必要で、適切でないと壁が壁として認識されない、属性が欠落するといった問題が起きます。書き出し前と読み込み後の確認が欠かせません。
- 書き出し前:目的、IFCバージョン、MVD・書き出し設定、対象要素、座標、分類、属性、ファイル名を確認する。
- 読み込み後:位置のずれ、階、形状の欠落・変形、属性、分類、容量、課題を確認する。
IFCは変換して終わりではなく、受け手側の確認を経て初めて使えます。
モデル交換は「提出」ではなく「確認の始まり」
モデルを共有した時点で連携は完了しません。受け取ったモデルの位置、階、形状、属性、目的への適合を確認して、はじめて使える状態になります。統合モデルによる確認は、このモデル交換を前提に行います。
初回交換時は基本情報・位置・範囲・モデル構成を確認し、更新時は形状や属性の変更点を確認します。初回後は原点や階などの前提条件を安易に変更せず、必要な場合は理由・影響範囲を明示します。受け渡し日、目的、確認結果を記録に残すと、後から判断根拠を確認できます。
統合モデルと干渉確認
統合モデルは各分野のモデルを重ねて確認するモデルです(複数モデルを重ねる「フェデレーテッド情報モデル」を指す)。設計モデルの正本ではなく確認用として扱い、見つけた課題は課題リストに記録して各分野が自分のモデルへ修正を戻します。柱・梁・壁・設備ルートの位置関係、梁下と天井高さ、主要ルート、シャフト等のスペース、耐力壁・設備開口・スリーブ、各図面の不整合を確認します。
干渉チェックの結果をそのまま課題にしない
干渉チェックでは大量の干渉が検出されますが、同じ重さで扱うと重要な課題が埋もれるため、次のように分類します。
| 分類 | 内容 | 対応 |
|---|---|---|
| 重大 | 設計方針や主要寸法に影響する | 会議で優先協議 |
| 要調整 | ルート・開口・納まりの調整が必要 | 担当者と期限を設定 |
| 許容・後工程 | 施工段階で調整可能 | 引継ぎ事項として記録 |
| 誤検出 | モデル表現やチェック設定によるもの | ルールや条件を修正 |
干渉確認は実施設計の最後だけでなく基本設計初期から段階的に行い、主要な問題を早めに見つけます。詳細度が低い段階では計画条件の成立を確認し、詳細化につれ主要部材やスリーブの調整へ進みます。LOD(詳細度を示す指標)は確認深度の目安として扱います。
課題管理とBCFによる共有
分野間連携の価値は課題を見つけることだけではありません。記録し、担当者と対応方針を決め、修正し、再確認し、合意内容を残して初めて効果が出ます。課題リストには課題番号、発生日、分類、重要度、位置、内容、担当、対応方針、期限、状態、完了確認を記録します。
BCF(BIMモデル上の課題を異なるソフト間で共有する形式)は視点・コメント・対象要素等を含めて共有できますが、重要度・担当者・期限・完了条件は別途明確にする必要があります。会議は、前回課題の修正状況確認、新規課題の確認、重要度と担当者の決定、次回モデルと期限の確認、合意事項の記録という流れで進めます。
設計から施工への引継ぎ
設計BIMは設計意図、図面整合、分野間調整、発注者説明のために作られ、施工BIMは施工図、製作、数量、工程、協力会社調整のために作られます。目的が異なるため、設計BIMをそのまま施工BIMとして使えるとは限らず、引き継ぐ情報と施工側で詳細化する情報を分けます。
引き継ぐ前には、引継ぎ目的・範囲、使用形式、変換できない要素、正本(契約図・BIMモデル・参考モデルの関係)、権利・責任、未解決の課題を確認します。特殊断面等の変換できない要素は一覧化し、施工側で再入力する要素を明記して図面で補足します。
引継ぎは責任の移転ではなく情報の接続です。設計意図や確定情報を施工者が使える形で接続します。
この章で押さえること
- 分野間連携の目的は同じソフトで作ることではなく、必要な時期に必要な情報を確認できる形式で受け渡すことである
- モデル交換の前に座標・基準点・方位・階レベル・通り芯を統一し、基準モデルを決めておく
- ファイル構成とモデル分割の方針はBEPに明示し、モデル分割・作業責任・成果物提出単位を混同しない
- IFC連携は万能ではなく、書き出し前のマッピング確認と読み込み後の位置・形状・属性・分類確認が欠かせない
- モデル交換は提出で終わりではなく、受領側が使用可能な状態かを確認して初めて連携に使える
- 干渉チェックの結果はそのまま課題にせず、重大・要調整・許容や後工程・誤検出に分類してから対応する
- 設計BIMから施工BIMへの引継ぎでは、変換できない要素と未解決課題を明確にし、責任の移転ではなく情報の接続として扱う
『建築BIMマネジメントの実践(実務編)』第5章
