BIM・IFCブログに戻る
納品とISO 19650 · 2026-08-07 · 9分
質の低いIFC納品を確実に防ぐ、BEPに書くべき条項
ほとんどのBEPには、モデルは「適切な品質」でなければならないとしか書かれていません。だから品質をめぐる議論は終わらないのです。そのまま貼り付けて使える4つの短い条項で、意見を検証可能な条件に変えましょう。
質の低いIFC納品を確実に防ぐ、BEPに書くべき条項 — IFC Viewer Online article cover
適当なBIM実行計画（BEP）を開いて情報納品のセクションを見ると、たいてい次のような一文が見つかります。「すべてのモデルは適切な形式で納品され、意図された用途に対して適切な品質を有するものとする。」誰もがこれに署名します。これで不合格になる人は誰もおらず、これを強制できる人も誰もいません。
プロジェクトでIFCの品質をめぐる議論がこれほど険悪になるのは、この一文のせいです。指し示せる根拠が何もないのです。コーディネーターはモデルが使い物にならないと言い、作成者は問題ないと言う。どちらも意見を述べているにすぎません。契約が「品質」を、誰もが検証できる条件に落とし込んでいないからです。
不合格になり得ない品質条項は、条項ではありません。条項番号の付いた願望にすぎません。
強制力のある条項の条件
条件は3つあります。すでにBEPに書かれている条項も、これに照らしてチェックしてみる価値があります。
- テストを明示していること。「良好な品質」ではなく、特定の方法で実行され、特定の出力を生む、特定のチェックを指定します。
- しきい値を明示していること。数値、件数、あるいは二値の条件など、レビュー担当者が主観的な判断なしに照合できるものです。
- しきい値を満たさなかった場合にどうなるかを明示していること。結果の伴わない条項は、要件ではなく単なる文書です。
以下の4つの条項は、3つの条件をすべて満たしています。あえて短くしてあります。誰も読まない品質条項には効果がありませんが、半ページに収まる条項なら相手に引用して突きつけられます。それこそが狙いです。
条項1：発行前の自動チェック
Every IFC container issued to the CDE at status S2 (Shared) or above shall
have been checked with the project's agreed rule set within the 24 hours
preceding issue. The check report shall be issued alongside the container.
Containers issued without a check report may be rejected without review.
効いているのは最後の一文です。これがなければ、この条項は義務を課すだけで、それを省いても何のコストも生じません。そして工程が厳しい週には省かれます。それこそ、チェックが最も重要になる週なのですが。
置き場所に注目してください。公開時ではなく、S2の時点です。何かが公開される頃には、3つの専門分野がそれを前提に調整を済ませています。そこで構造上の欠陥が見つかれば、やり直すのは自分の作業ではなく、他分野の作業です。納品前チェックの経済性はすべて、作業中（Work in progress）から共有（Shared）への境界で問題を捉えられるかどうかにかかっています。
まだルールセットを決めていないなら、どのバリデーターでも実行される標準的なチェックから始めましょう。よくあるIFC検証エラーで、実際の不合格理由の大半をカバーできます。これらのエラーはモデリングのスタイルではなくエクスポート設定から生じるため、どこでも同じです。
条項2：品質の最低しきい値
IFC containers shall achieve a Health Score of at least 80/100 under the
project rule set. Containers scoring below the threshold may be issued only
with the prior written agreement of the Information Manager, recording the
findings concerned and the reason.
真似する価値のある設計上の判断が2つあります。1つ目は、例外の抜け道を明示していることです。しきい値を下回るモデルでも、どうしても共有しなければならない場面はあります。正当な例外を認めないルールは、守られるのではなく無視されます。2つ目は、例外を文書に残すよう求めていることです。これにより「見逃すことで合意した」が、日付と作成者の入った記録に変わります。
しきい値は慎重に選んでください。スコアは、レポート全体をカテゴリーと重大度で重み付けしてひとつの数値に圧縮したものです。契約条件にする前に、その中身を理解しておく価値があります。何がスコアをどれだけ動かすのかは、IFC Health Score（ヘルススコア）ガイドで解説しています。
条項3：識別子の安定性
IFC GlobalIds shall be persistent for the life of the project: the identifier
of an element shall not change between revisions unless the element itself is
deleted and replaced. Task teams shall configure authoring and export tools
accordingly, and shall report any event that invalidates identifiers (model
recreation, round-trip import, template migration) at the time it occurs.
この記事から1つだけ条項を追加するなら、これにしてください。しきい値の条項は納品の平均的な品質を引き上げます。識別子の条項は、後から修復できない種類の損害を防ぎます。
エクスポートのたびにGlobalIdが変わると、3つのものが同時に、気づかないうちに壊れます。指摘事項は起票の対象だった要素から外れ、すべての要素が新規に見えるため改訂版の比較は虚構になり、資産データは元のモデルと照合できなくなります。どれもエラーメッセージは出ません。後に残るのは、誰も調整の履歴をいまひとつ信用できず、その理由を誰も説明できないプロジェクトです。
最後の一文にある報告義務は、見た目以上に重要です。GUIDの入れ替わりは、たいてい誰かが把握しているプロセス上の出来事が原因です。モデルを作り直した、ファイルを別のツールに通して戻した、といったことです。それがいつ起きたかがわかっていれば、ログに一行書けば済みます。わからなければ、原因究明の調査が必要になります。具体的な原因はエクスポートのたびにIFCのGUIDが変わる理由を、2つの要素が1つの識別子を共有してしまう関連の不具合についてはIFCファイルのGUID重複をご覧ください。
条項4：共通座標と単位
All task teams shall use the project shared reference point and rotation
defined in {document}, and shall deliver in metric SI length units. Storey
names and elevations shall follow the agreed level schedule without local
variation.
これは、モデルを統合して初めて効果を発揮する条項です。各専門分野のモデルがそれ自体では完璧でも、統合モデルとしては使い物にならないことがあります。モデル同士を重ねるまで見えない不具合が3つあるからです。異なる原点を基準にしたモデル、ヤード・ポンド法で作られた1つのファイル、そして人が手作業で対応表を管理しなければならない、専門分野ごとに異なるレベル（階）の定義です。
派手な失敗を生むのは、ジオリファレンスの側です。建物が敷地から数百キロメートル離れた場所に現れたり、回転していたりします。その仕組みはIFCの座標とジオリファレンスで解説しています。
これらの条項をどこに書くか
| 文書 | 記載すべき内容 |
|---|
| EIR（発注者側） | 発注者が求めるもの：各納品の目的、分類体系、引き渡し時に期待する資産データ。 |
| BEP（納品チーム） | それをどう満たすか：この4つの条項、指定のルールセット、エクスポート設定の参照先、責任分担表。 |
| BEPの付録 | 受入基準表：基準ごとに1行とし、最初の納品までにプロジェクトとしての方針を記入しておく。 |
| 送付状（トランスミッタル） | 納品ごとの記載事項：改訂番号、適合性コード（suitability）、スコア、ルールセット、合意のうえで受け入れた指摘事項。 |
条項はそれだけではあまり役に立ちません。受け手がそれを適用する場、つまり受入基準表が必要です。その表が次の記事のテーマです。IFCの受入基準：議論せずにモデルを受理・却下する方法。そして情報コンテナが合格したら、次は何を一緒に渡すかが問題になります。それについてはIFCモデルと一緒に引き渡すもので取り上げています。
1段落にまとめた版
BEPがすでに完成していて、今さら見直すのは政治的にコストが高いという場合は、情報納品のセクションに次の1段落を追加するだけで、価値の大半を得られます。
IFC containers issued at S2 or above shall be checked with the project rule
set immediately before issue, shall reach a Health Score of at least 80/100,
and shall carry persistent GlobalIds between revisions. The check report
shall accompany the container; exceptions require the written agreement of
the Information Manager.
こうした要件を確定させる前に実際にどうなるかを知りたければ、すでに納品したモデルでチェックを実行してみてください。納品前のモデルチェックのワークフローなら1ファイルあたり約1分で終わり、その結果から、80というしきい値が自分のプロジェクトにとって甘いのか、野心的なのかがわかります。
質の低いIFC納品を確実に防ぐ、BEPに書くべき条項