BIM・IFCブログに戻る
納品とISO 19650 · 2026-08-07 · 9分
IFCモデルと一緒に引き渡すべきもの（IFCファイル以外）
納品とは「このモデルは、この改訂版において、この目的に適している」という主張です。その主張を、受け手が同じ作業を繰り返さずに確認できるものに変えるのがエビデンスであり、同じ議論が二度起きるのを防ぐのもエビデンスです。
IFCモデルと一緒に引き渡すべきもの（IFCファイル以外） — IFC Viewer Online article cover
IFCの納品はすべて、「このモデルは、この改訂版において、この目的に適している」という主張です。ファイル自体がその主張を含んでいるわけではありません。ファイルが運ぶのはジオメトリとデータです。主張を確認できるようにするものはすべて、ファイルに添えて届けるしかありません。そして、ほとんどのプロジェクトでは、そのほぼ何も添えられていません。
だからこそ、同じやり取りが二度繰り返されます。1回目は、誰かがモデルをチェックして問題なしと判断します。2回目は1か月後、別の担当者が別の審査段階で、もう一度チェックします。1回目のチェックについて、誰もが頼れる記録が残っていなかったからです。
5つの資料、うち4つはすでに手元にある
| 資料 | 答える問い | 読み手 |
|---|
| 検証レポート | 何をチェックし、何が見つかったか | 受け取る側のコーディネーター |
| チェック記録 | まさにこのファイルに対して、この時点でチェックが行われたこと | 情報マネージャー、発注者、監査担当者 |
| 指摘事項ファイル（BCF） | 何が未修正で、どこを見ればよいか | 対応しなければならない担当者 |
| 資産データ（COBie） | 建物に何が含まれているか（データとして） | 発注者とFM（施設管理）チーム |
| 送付状 | 改訂番号、ステータス、スコア、ルールセット、適用除外 | 関係者全員、そして記録として |
5つすべてを揃える作業は、最初に10分ほどかかり、2回目以降はそれよりずっと短く済みます。納品1回あたり約4通のメールが不要になり、そのまま受け入れられる納品と、議論が始まってしまう納品との分かれ目になります。
1. 検証レポート
レポートはエクスポートして添付し、メール本文で言い換えないでください。実行時にその場にいなかった人にとってレポートが役立つかどうかは、次の3つの性質で決まります。
- 結果だけでなく、ルールセットが明記されていること。ルールセットのわからないスコアは解釈できず、次の改訂版と比較することもできません。
- 対象範囲、つまりどのチェックを実行し、どれを実行しなかったかが明記されていること。「合格」と「未実施」を区別できないレポートは、マーケティング資料にすぎません。
- 要素の識別子が含まれていて、指摘事項を探し回らずに特定できること。自分で探しに行かなければならないレポートは、誰も二度と使いません。
レポートの指摘事項のうち、どれが報告に値し、どれがノイズなのか判断に迷う場合は、IFCモデルでよくあるエラーが妥当なトリアージリストになります。受け手が気にするのは、そのうち構造的なエラーです。
2. チェック記録
あらゆる品質プロセスの最も弱い部分は、チェックと主張が別物だという点です。「モデルのスコアは92でした」と言うだけなら誰にでもできます。チェック記録は、その数値を特定のファイルに結びつけます。記録されるのは、ファイル固有のフィンガープリント、ルールセット、スキーマ、タイムスタンプ、スコアです。
こうした記録がパネルのスクリーンショット以上の価値を持つのは、次の2つの性質があるからです。
- ファイルの内容から導き出されていること。そのため、モデルを1バイトでも変更して同じ記録のまま再発行すれば、それを検出できます。
- 受け手が、あなたを介さずに独立して検証できること。自社のソフトウェアでしか確認できない記録は約束にすぎず、エビデンスにはなりません。
3. 指摘事項ファイル
BCFは、指摘事項があなたの画面を離れても失われないようにするための仕組みです。その価値はすべてビューポイントにあります。カメラ位置、選択要素、コメントの組み合わせによって、受け手は問題を10分ではなく10秒で見つけられます。
対応してもらえるBCFファイルと無視されるBCFファイルを分けるのは、次の2つの慣習です。
- トピックは要素ごとではなく、原因ごとに1つにする。プロパティセットが欠落している4,000個の要素は、代表的なビューポイントを付けた1つのトピックにまとめます。4,000個のトピックに分けると、ファイルが開けなくなってしまいます。
- トピックのタイトルには、症状ではなくルールの識別子と修正方法を書く。「プロパティセットの欠落：必要なPsetをエクスポートテンプレートに追加する」なら対応できますが、「プロパティがない」では単なる苦情です。
4. 資産データ
COBie、あるいは発注者が求める何らかの一覧表は、モデルの品質が商業的に目に見える形になる地点です。受け取るのは、モデルを一度も開かず、言い訳を読み解くすべも持たない人だからです。
しかも資産データは、検証ツールそのものを検証する役割も果たしてくれます。名前のないスペース、メーカーが設定されていないタイプ、どのスペースにも割り当てられていないコンポーネント。こうした欠落は空欄の列として届き、ファシリティマネージャーはひと目で気づきます。モデルからCOBieを書き出して人に見せられない結果になるなら、ジオメトリがどう見えようと、そのモデルはまだ納品できる状態ではありません。
5. 送付状
わずか6行で、納品をめぐる紛争の大半を防げます。
Container: {filename}
Revision/status: {rev} - {suitability code}
Schema: {IFC2X3 | IFC4 | IFC4X3}
Checked: {date} - rule set {name} - {n} of {n} checks completed
Health Score: {score}/100
Open by agreement: {rule id - reason - agreed with - date}
Not suitable for: {e.g. quantity take-off, fabrication}
最後の行は多くの人が省略しますが、あなたを守ってくれるのはまさにその行です。コンテナが何に適さないかを明記するのは、保身ではありません。それは情報要求レベル（Level of Information Need）の定義そのものであり、誰かが実際に目を通す唯一のタイミングで、それを届けているのです。
まとめ
ここで紹介したものに新しい技術は何もなく、まだ持っていないツールも必要ありません。必要なのは、納品を「ほかの誰かが確認できなければならない主張」として扱うことです。これは姿勢のわずかな変化にすぎませんが、差し戻される納品の数に対しては、不釣り合いなほど大きな効果をもたらします。
受け手がこれらすべてに適用する基準はIFCの受入基準で、それを拘束力のあるものにする条項は質の低いIFC納品を確実に防ぐ、BIM実行計画（BEP）に書くべき条項で解説しています。3つすべてに関わるISO 19650の枠組みについては、ISO 19650準拠のIFC納品チェックリストをご覧ください。
IFCモデルと一緒に引き渡すべきもの（IFCファイル以外）