タイトル: BEP（BIM実行計画）
SEOタイトル: BEP（BIM実行計画）とは — EIR・LOD・命名規則・座標基準とISO 19650の枠組みを解説
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 の役割は、ソフトウェア開発でいう「コーディング規約 ＋ 設計方針 ＋ 体制図」をまとめたものに近いものです。とりわけ命名規則と座標基準は、複数のモデルを一つに統合するためのスキーマと識別子の取り決めに相当します。識別子（命名）が統一され、基準（座標）が揃っていなければ、データを正しく重ね合わせることも集計することもできません。
プロジェクト開始時にこの「決めごと」を固めておくことが、後工程でのデータ整合・自動集計を成立させる前提になります。