BIM を複数の会社・分野で進めると、「どのソフトで作るのか」「座標はどこ合わせか」「いつ何を出すのか」がバラバラになりがちです。これを着手前に紙で合意しておくのが BEP(BIM Execution Plan／BIM実行計画) です。モデルそのものではなく、モデルの作り方と受け渡し方のルールブックだと考えると分かりやすいです。

先に結論

BEP = 「誰が・何を・いつ・どの形式で」BIM 成果物を作るかを決める合意文書。
発注者の要求(EIR)に対して、実行側(設計・施工チーム)がどう応えるかを書いたもの。
受注前(提案時)と受注後(確定後)の2 段階で作るのが ISO 19650 の考え方。
座標・命名・分類・粒度・納期・調整プロセスなど、後で揉める点を先に決めておくのが価値。

なぜ BEP が必要なのか

BIM の失敗の多くは、技術ではなく段取りの不一致から起きます。

意匠は原点合わせ、構造は測量座標で出力 → 重ねたらモデルがずれる
片方は詳細に作り込み、片方はスカスカ → 粒度(LOD)が噛み合わず調整できない
ファイル名や分類がバラバラ → 集計・検索が成立しない
「いつ・何を出すか」が曖昧 → 締切直前に成果物が揃わない

BEP は、これらを着手前に合意して文書化することで、後工程の手戻りを防ぎます。作るのはひと手間ですが、揉めてから直すより圧倒的に安く済みます。

EIR と BEP の関係

BEP は単独では生まれません。まず発注者が「何が欲しいか」を EIR(Exchange Information Requirements／情報要求) として示し、実行側がそれに「こう応えます」と返すのが BEP です。**要求(EIR)と応答(BEP)**のペアで考えるのが基本です。

発注者 → 実行側

EIR(情報要求)

「何を・いつ・どの形式で欲しいか」
目的・用途・提出物・基準を示す
発注者(または代理)が用意する

実行側 → 発注者

BEP(実行計画)

「どう作り・どう届けるか」
体制・ソフト・手順・スケジュール
設計・施工チームが用意する

EIR(要求)に BEP(計画)で応え、その計画どおりに情報成果物を作って CDE で受け渡す

BEP に書く代表的な項目

BEP の様式は発注者やテンプレートによって様々ですが、押さえるべき中身はおおむね共通です。

🎯 目標と BIM 用途

何のために BIM を使うか(可視化・数量・干渉調整・維持管理など)。用途を絞ると粒度も決めやすい。

👥 役割と責任

誰がどのモデルを担当し、誰が調整・承認するか。BIM マネージャや各分野の責任者を明記。

📐 情報の粒度

各段階でどこまで作り込むか。形状と属性の詳しさ(LOD／情報要求レベル)をそろえる。

🧭 座標・命名・分類

共有原点と方位、ファイル命名規則、分類体系。重ねて成立する前提を先に固定。

💻 ソフトと形式

使用ソフトと交換形式(IFC など)。特定ツールに縛られない openBIM 交換を基本に。

🗓️ 成果物と納期

いつ何を出すかの計画(MIDP／TIDP)。マイルストーンごとの提出物を一覧化。

📋

MIDP / TIDP: 成果物の納期計画は、プロジェクト全体をまとめた MIDP(Master Information Delivery Plan)と、各タスクチーム単位の TIDP(Task Information Delivery Plan)に分けて管理します。要は「全体の納品カレンダー」と「担当ごとの内訳」です。

受注前 BEP と受注後 BEP

ISO 19650 では、BEP をタイミングの違う 2 段階で捉えます。

受注前 BEP(提案時)

入札・提案の段階で、EIR にどう応えるか・体制や進め方の方針を示す。まだ確定ではなく「こう取り組みます」の宣言。

受注後 BEP(確定後)

受注が決まった後、体制・スケジュール・手順を確定して詳細化する。実際に運用する版で、プロジェクト進行とともに更新する。

つまり BEP は「一度書いて終わり」ではなく、提案時の骨子 → 受注後の確定版 → 進行に合わせた更新という生きた文書です。

情報要求を機械可読にする流れ

BEP や EIR は多くの場合「文章」で書かれますが、そこで決めた必須属性や粒度を、機械で照合できる形にしておくと運用が一気に楽になります。それが IDS(情報要求仕様) で、「この要素にはこの属性が必須」といった要求を機械可読で表し、モデルチェックで自動照合できます。BEP で決めた約束を、IDS で「守られているか自動チェックする」——この組み合わせが近年の openBIM の流れです。

小さなプロジェクトでの始め方

BEP は分厚い正式文書だけのものではありません。数人のチームや小規模案件でも、軽量版で十分効果があります。

1 ページでいい: 座標原点・命名規則・使用形式・提出物と締切、これだけ先に合意するだけで事故が激減する。
座標と命名を最優先: 揉めごとの多くはここ。共有原点と方位、ファイル名の付け方を最初に固定する。
CDE の置き場を決める: 「最新はここにしかない」を徹底(CDE とは)。版とステータスを名前で表す。

💡

コツ: 完璧なテンプレートを埋めることより、「後で必ず揉める 3〜4 点(座標・命名・形式・納期)を着手前に合意する」ことが本質です。小さく始めて、必要になったら足していけば十分です。

まとめ

BEP は「誰が・何を・いつ・どの形式で」BIM 成果物を作るかを決める合意文書。
発注者の要求(EIR)に対する、実行側の応答として作る。
受注前(方針)→ 受注後(確定)→ 進行に合わせて更新という生きた文書。
座標・命名・分類・粒度・納期を着手前に合意するのが最大の価値。小さな案件でも軽量版で効く。

BEP は派手ではありませんが、フェデレーション(重ね合わせ)や干渉チェック、数量、維持管理まで、BIM の成果が出るかどうかを左右する土台です。用語の全体像はBIM・IFC 用語集、情報の置き場はCDE とはにまとめています。