ページの作成
親となるページを選択してください。
親ページに紐づくページを子ページといいます。
例: 親=スポーツ, 子1=サッカー, 子2=野球
子ページを親ページとして更に子ページを作成することも可能です。
例: 親=サッカー, 子=サッカーのルール
親ページはいつでも変更することが可能なのでとりあえず作ってみましょう!
テンプレート
テンプレートがありません。
BEP — BIM 運用の「決めごと」を明文化する
複数の関係者が並行してモデルを作り、統合して活用する BIM プロジェクト。詳細度・命名規則・座標基準が人によってバラバラだと、統合時に大きな手戻りが生じます。事前の取り決めをまとめた文書が BIM 実行計画(BEP)です。
この記事の要点
- BEP(BIM Execution Plan/BIM 実行計画)は、プロジェクトで BIM をどう運用するかを取り決めた文書
- 発注者が要求事項を示す EIR(発注者情報要件)に応える形で、受注者側が BEP を作成するのが基本構図
- BEP では役割分担・LOD(詳細度)・命名規則・座標基準などの「決めごと」を明文化する
- 国際規格 ISO 19650 が、EIR から BEP に至る情報マネジメントの枠組みを定めている
BIM プロジェクトは複数の関係者が並行してモデルを作り、それを統合して活用します。このとき「どんな詳細度で作るのか」「ファイル名やパラメータの付け方は」「座標の基準はどこか」が人によってバラバラだと、後で統合する段階で大きな手戻りが生じます。こうした事前の取り決めを文書としてまとめたものが BEP です。
1BEP(BIM 実行計画)とは
BEP は BIM Execution Plan の略で、日本語では「BIM 実行計画」と呼ばれます。プロジェクトにおいてBIM をどのように作成・管理・活用するかを関係者間で合意し、明文化した計画書です。
技術的なルール(命名・詳細度・座標)と、運用上の取り決め(誰が何を担当し、いつ何を提出するか)の両方を含む計画書。
「規約 + 方針 + 体制図」をひとまとめにしたもの、と考えると分かりやすいでしょう。技術面と運用面の両方をカバーする点が特徴です。
2EIR(発注者情報要件)との関係
BEP を理解するうえで欠かせないのが EIR(Employer's / Exchange Information Requirements=発注者情報要件)です。EIR は、発注者がプロジェクトに対して「どんな情報が、いつ、どんな形で欲しいか」を示す要求文書です。両者の関係は次のとおりです。
| 文書 | 誰が出すか | 内容 |
|---|---|---|
| EIR(発注者情報要件) | 発注者側 | 必要な情報・目的・提出物などの要求 |
| BEP(BIM 実行計画) | 受注者側 | EIR にどう応えるかの実行計画 |
つまり、EIR が「要求」、BEP が「それへの回答・実行計画」という関係です。EIR が曖昧だと BEP も的を射たものにならないため、両者は対になって機能します。
3BEP に書く主な取り決め
BEP で定める代表的な事項を挙げます。プロジェクトによって粒度は変わりますが、おおむね次のような項目が含まれます。
- 役割と体制:BIM マネージャー・各分野の担当・責任範囲、情報の承認フロー
- 使用ソフト・データ形式:オーサリングツール、交換フォーマット(IFC など)、CDE の運用
- 成果物と提出時期:いつ・どの状態のモデルを・誰に渡すか
- LOD(詳細度):各フェーズで要素をどこまで作り込むかの基準
- 命名規則:ファイル名・モデル名・パラメータ・レイヤーなどの統一ルール
- 座標基準:プロジェクト基準点・共有座標など、統合時の位置合わせの基準
このうち命名規則と座標基準は、複数モデルを統合(フェデレーション)する際の整合に直結するため特に重要です。座標がずれていればモデルが正しく重ならず、命名がバラバラなら集計や検索が機能しません。データ統合のためのスキーマと識別子の取り決めに相当する、と捉えると役割がはっきりします。
4ISO 19650 の枠組み
EIR から BEP に至る一連の情報マネジメントは、国際規格 ISO 19650 によって体系化されています。ISO 19650 は BIM を用いた情報マネジメントの規格群で、発注者の要求(EIR)に対して受注者が計画(BEP)を立て、共通データ環境(CDE)で情報を管理していく、という流れを定めています。
したがって BEP は単独で存在するのではなく、EIR・CDE・ISO 19650 と一体の枠組みの中で位置づけられます。プロジェクト開始時にこの枠組みに沿って取り決めを固めておくことが、後工程の手戻りを防ぐ鍵になります。
5BEP はいつ作るか
BEP は、プロジェクトの早い段階で作り始めるのが原則です。モデル作成が本格化してから命名規則や座標基準を決めようとしても、すでに作られたモデルとの整合に手間がかかるためです。一般には、受注者の選定前後や、契約・着手の段階で初版を用意し、プロジェクトの進行に応じて更新していく「生きた文書」として扱います。
体制やツール、要求が変われば改訂し、関係者が常に最新版を参照できるようにしておく
一度作って棚にしまう書類。実態と乖離した古い版が放置される
CDE 上で版管理するのが自然な運用です。BEP は「生きた文書」であることを前提に運用します。
6BEP が機能しないとどうなるか
BEP が形骸化したり省略されたりすると、典型的に次のような問題が起こります。これらはいずれも、後工程になるほど修正コストが膨らむ性質を持ちます。
座標基準が共有されておらず、統合時に各分野のモデルがずれる。
パラメータや命名がバラバラで、数量や機器の自動集計が成立しない。
LOD の合意がなく、ある分野は作り込みすぎ、別の分野は粗すぎる。
さらに「誰がどの情報に責任を持つか」が曖昧だと、不整合の修正が滞り責任の押し付け合いになりがちです。BEP は、こうした手戻りをプロジェクト開始時の合意で未然に防ぐための保険だと捉えると、その価値が分かりやすくなります。
データの視点で見る BEP
BEP の役割は、ソフトウェア開発でいう「コーディング規約 + 設計方針 + 体制図」をまとめたものに近いものです。とりわけ命名規則と座標基準は、複数のモデルを一つに統合するためのスキーマと識別子の取り決めに相当します。識別子(命名)が統一され、基準(座標)が揃っていなければ、データを正しく重ね合わせることも集計することもできません。
プロジェクト開始時にこの「決めごと」を固めておくことが、後工程でのデータ整合・自動集計を成立させる前提になります。
→次に読む
ページの作成
親となるページを選択してください。
親ページに紐づくページを子ページといいます。
例: 親=スポーツ, 子1=サッカー, 子2=野球
子ページを親ページとして更に子ページを作成することも可能です。
例: 親=サッカー, 子=サッカーのルール
親ページはいつでも変更することが可能なのでとりあえず作ってみましょう!
テンプレート
テンプレートがありません。
子ページはありません
人気ページ
- 1 建築とは — 建築物の定義・建築と土木の違い・ライフサイクルをわかりやすく解説
- 2 建築・BIM 総合Wiki — 建築の基礎からBIM・Revit・Speckleまで体系的に解説
- 3 建築図面の縮尺と寸法表記 — 1/100・1/50 の使い分けと mm 基準・面積をやさしく解説
- 4 日本のBIM動向 — 国交省BIM/CIM・建築BIM推進会議・ガイドラインをわかりやすく整理
- 5 建築プロジェクトの登場人物|施主・設計事務所・ゼネコン・サブコンと発注方式
- 6 建築入門 — 分野・登場人物・設計から竣工までの流れをやさしく整理
- 7 建築の3分野とは|意匠・構造・設備(MEP)の役割分担とBIMの分野別モデル
- 8 Speckle Automateとは|Version公開トリガーで自動QA・命名規約チェックを走らせる仕組み
- 9 Revit フェーズとデザインオプション|既存・解体・新築の段階管理と設計案比較
- 10 Revit ワークシェアリング徹底解説|ワークセット・セントラルファイル・同期(SWC)・クラウド共同作業
最近更新/作成されたページ
- Dynamo入門|Revitビジュアルプログラミング・ノードとワイヤ・Pythonノード・Dynamo Player NEW 2026-06-29 15:23:47
- 建築の3分野とは|意匠・構造・設備(MEP)の役割分担とBIMの分野別モデル NEW 2026-06-29 15:23:47
- specklepy入門|Python SDKでSpeckleClient認証・operations.send/receive NEW 2026-06-29 15:23:47
- 建築図面の縮尺と寸法表記 — 1/100・1/50 の使い分けと mm 基準・面積をやさしく解説 NEW 2026-06-29 15:23:47
- Speckle Viewerとは|Web3D表示・プロパティ確認・iframe埋め込みと@speckle/viewer NEW 2026-06-29 15:05:23
- Speckle .NET SDK入門|NuGet導入・認証・Base作成・send/receiveとRevitアドイン連携 NEW 2026-06-29 15:05:23
- 日本のBIM動向 — 国交省BIM/CIM・建築BIM推進会議・ガイドラインをわかりやすく整理 NEW 2026-06-29 15:05:23
- Speckle Automateとは|Version公開トリガーで自動QA・命名規約チェックを走らせる仕組み NEW 2026-06-29 15:03:33
- Speckleデータ連携の実務パターン|数量集計・Power BI・QA・他DB連携のパイプライン NEW 2026-06-29 15:03:33
- SpeckleとIFCの違い|標準ファイル交換とライブ連携の比較表と併用の現実解 NEW 2026-06-29 15:03:33
- Speckle Serverセルフホスト|docker-compose構成とデータ主権・運用設計 NEW 2026-06-29 15:03:33
- Speckleとは|OSSのAECデータプラットフォームをやさしく解説 NEW 2026-06-29 15:03:32
- Speckleのsend/receive|Version生成・選択フィルタ・差分とバージョン履歴 NEW 2026-06-29 15:03:32
- Speckleのコネクタ|Revit/Rhino/Grasshopper/Blender等の連携とsend/receive NEW 2026-06-29 15:03:32
- Speckleオブジェクトモデル|Base・動的プロパティ・detach・ハッシュと重複排除 NEW 2026-06-29 15:03:32
コメントを削除してもよろしいでしょうか?