BIM・IFCブログに戻る
納品とISO 19650 · 2026-08-07 · 10分
IFCの受入基準：揉めることなくモデルを受け入れ、差し戻す方法
「このモデルは使えない」と「モデルに問題はない」。この言い争いに終わりはありません。最初の納品前に合意した1ページの受入基準表があれば、それを5分で終わるチェックに変え、結果を記録に残せます。
IFCの受入基準：揉めることなくモデルを受け入れ、差し戻す方法 — IFC Viewer Online article cover
どのプロジェクトにも、コーディネーターが納品されたモデルを開き、20分かけてそれが使えないことを突き止め、「残念ながら」で始まるメールを書く瞬間があります。その後どうなるかは、ほぼ1つのことにかかっています。受け入れ可能な納品物とはどういうものかを、誰かが事前に書き出していたかどうかです。
書き出してあれば、そのメールは短く、事実に基づき、揉める余地のないものになります。書き出していなければ、そのメールは「どちらの基準を適用するのか」をめぐる交渉の第一手となり、プロジェクトが終わるまで、ステージゲートのたびに蒸し返されることになります。
受け入れはチェックリストであって、意見ではない
発想の転換はわずかですが、それがすべてを変えます。納品物のレビューとは品質を評価することではなく、合意した基準をファイルに適用することです。そこから、はっきり述べておく価値のある3つの帰結が生まれます。
- レビュー担当者には、合意した表以上の権限は必要ありません。モデル作成者の力量を判断しているのではなく、結果を報告しているだけです。
- 作成者は、発行する前に結果を予測できます。予測できることは防げます。それこそが、この仕組みの目的のすべてです。
- 意見の相違が起きたとしても、それは基準についての議論になります。毎月、納品の最中に繰り返すのではなく、一度だけ冷静に話し合えば済む議論です。
相手が合意していない基準を満たしていないことを理由に、納品物を差し戻すことはできません。差し戻せるのは、双方が合意した基準を満たしていない場合だけです。
受入基準表
肝心の表がこれです。10行、1ページで、BIM実行計画（BEP）または情報交換要件（EIR）に添付します。3列目はあえて空欄にしてあります。最初の納品前にプロジェクトで記入するもので、その記入作業こそが本当の合意の場になります。
| 基準 | 差し戻す条件 | プロジェクトの方針 |
|---|
| 構造的な整合性 | 重要度「エラー」のスキーマまたは空間構造に関する指摘事項がある | 差し戻し／注記付きで受け入れ |
| Health Score（ヘルススコア） | 合意したしきい値を下回る | しきい値：__ /100 |
| チェックのカバレッジ | 未実行または失敗と報告されたチェックがある | 差し戻し／再実行が必要 |
| 識別子の安定性 | 改訂間のGUIDの入れ替わりが、合意した割合を超える | 最大入れ替わり率：__% |
| 命名 | ファイル名が合意した命名規則に従っていない | 差し戻し／名前を変更して記録 |
| ジオリファレンス | モデルがプロジェクトの共有基準点に合っていない | 差し戻し |
| 単位 | 長さの単位がメートル法ではない | 差し戻し |
| 分類 | 分類の参照を持たない要素がある | 適用開始段階：__ |
| プロパティセット | 宣言した情報要求レベルに対して、必要なPsetが欠けている | Pset一覧：__ |
| スペース | 名称、LongName、床面積のいずれかが欠けているスペースがある | 適用開始段階：__ |
この表の目的は厳しくすることではなく、事前に決めておくことです。全員が合意した緩い表のほうが、差し戻しのメールと一緒に届く厳しい表よりも優れています。重要なのは最初の3行で、同時に最も抜け落ちやすい行でもあります。そもそもこれらをBEPに盛り込むための条項については、不良なIFC納品を確実に防ぐBEPの条項で解説しています。
3行目を掘り下げる：チェックのカバレッジ
受入基準表の多くは、検証の実行結果をチェックします。しかし、その実行が実際に行われたかどうかまでチェックしているものはほとんどありません。そこには、納品物がまるごと素通りできるほど大きな穴があります。
実行されなかったチェックは、合格したチェックとまったく同じに見えます。どちらも指摘事項はゼロだからです。大きなファイルがタイムアウトする、ワーカーがクラッシュする、形状に依存するチェックが黙って処理を諦める。それでもレポートはきれいなまま、満点のスコアで返ってきます。そして納品物は、名ばかりのチェックを経て受け入れられてしまうのです。
| カバレッジの状態 | 意味 | 受け入れ時の対応 |
|---|
| 実行済み | チェックは完了しています。指摘事項ゼロは、本当にゼロという意味です。 | 結果を信頼してよい。 |
| 未実行 | 試行されたものの、結果が出ていません。多くはタイムアウトか、実行のキャンセルが原因です。 | 受け入れる前に再実行する。決して合格とみなさない。 |
| 失敗 | チェックがエラーになりました。 | 報告する。失敗したチェックを含むスコアは、正常な実行のスコアとは比較できない。 |
納品物を5分でレビューする
- コンテナーを開き、プロジェクトのルールセットを実行します。ほとんどの分野別モデルなら1分もかかりません。
- まずカバレッジを確認し、結果はその次に見ます。実行されていないチェックが1つでもあれば、そこで止めてください。まだレビューは成立していません。
- スコアをしきい値と照らし合わせ、次に重要度「エラー」の指摘事項を確認します。それ以外はすべて注記であり、ゲートの判定対象ではありません。
- 前回の改訂と比較します。新たな指摘事項こそが注目すべき点であり、解消された指摘事項は、前回のレビューが反映されたことの証明になります。
- 結果を送付状（トランスミッタル）または共通データ環境（CDE）のコメントに記録します。スコア、ルールセット、カバレッジ、そして合意のうえで受け入れた指摘事項を残しておきます。
ステップ1は、送り手が発行前に実施しておくべきだったのと同じ手順です。送り手側から見た手順は、納品前にIFCモデルをチェックする方法で詳しく解説しています。送り手と受け手が同じチェックを実施すれば、レビューは検査ではなく確認作業になります。
差し戻しの書き方
内容と同じくらい大切なのが、書き方のトーンです。受け取る側はたいてい予定より遅れていて、個人的に責任があることはまれだからです。ルールは3つあります。モデルではなく、基準を名指しすること。症状だけでなく、原因を示すこと。何が、どのくらいの期間止まるのかを伝えること。
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
書かれていないものに注目してください。モデルについての形容詞も、なぜそうなったかの憶測も一切ありません。あるのは1つの数値、2つのルールID、考えられる原因、そして影響だけです。誰も自己弁護する必要のないメッセージだからこそ、エスカレーションされずに対応されるのです。
不合格のモデルを受け入れるべきとき
それでも「受け入れる」が正解の場合もあります。欠けている情報がその段階の情報要求レベルの範囲外である、サプライヤーからの納品がまだである、あるいは受け入れなければプロジェクトが止まってしまう、といった場合です。不合格の納品物を受け入れるのは正当な判断です。しかし、黙って受け入れるのはそうではありません。
免除した指摘事項には、3つの情報を添える必要があります。理由、同意した人、そして日付です。受け入れた指摘事項と無視された指摘事項の違いはそれだけであり、同じ問題が2段階後に危機として再発見されるのを防ぐのも、この3つです。
こうした免除の記録は、レポートをはじめコンテナーと一緒に送るものすべてとともに、送付状に含めます。詳しくはIFCモデルと一緒に引き渡すべきものをご覧ください。
IFCの受入基準：揉めることなくモデルを受け入れ、差し戻す方法