BIM モデルは「見た目が正しそう」でも、中身のデータが要件を満たしているとは限りません。属性が空だったり、命名規則がバラバラだったり——こうした問題を人の目だけで見つけるのは限界があります。そこで使うのが**モデルチェック（Validation）**です。
- モデルチェック＝モデルが 要件を満たしているかを機械的に検証する作業
- 「必須属性の欠落」「値の範囲外」「命名規則違反」などをルールで自動チェック
- 干渉チェック（クラッシュ）とは別物 — あちらは"物理的なぶつかり"、こちらは"データの正しさ"
- 早く・繰り返し回すほど、後工程の手戻りを減らせる
なぜ目視確認では足りないのか
数千〜数万の要素を持つモデルで、「すべての防火扉に防火性能の属性が入っているか」を目視で確認するのは現実的ではありません。人手のチェックは、見落とし・属人化・再現性の低さという弱点を抱えます。
モデルチェックは、この確認をルールとして定義し、機械的に一括検証します。同じルールを何度でも、誰がやっても同じ結果で回せるのが価値です。
どんなルールでチェックするのか
代表的なチェックの型は次の通りです。
✅ 必須属性
「防火扉には防火性能が必須」など、入っているべき属性の欠落を検出。
📐 値の範囲
「壁厚は 50〜1000mm」など、妥当な範囲を外れた値を検出。
🔤 値の一致
「用途は決められた語彙から選ぶ」など、規定値との一致を確認。
🏷️ 命名規則
要素名・分類コードが規約どおりか。集計や連携の前提を守る。
ツールによっては、組み込みの整合性チェック（階に属さない要素、宙に浮いた開口など）に加えて、プロジェクト独自のルールを定義できます。Bimly も組み込みチェックとユーザー定義ルール（必須・範囲・一致）の両方を評価します。
干渉チェックとの違い
混同されがちですが、目的が違います。
データの正しさ
- 属性・命名・値の妥当性を検証
- 「情報が要件を満たすか」を問う
物理的なぶつかり
- 要素同士の衝突（設備×構造など）を検出
- 「形が干渉していないか」を問う
両方とも品質を守る活動ですが、見ている対象が「データ」か「形状」かで分かれます。
実務での進め方
要件をルール化
発注者要件や社内標準を、検証可能なルール（必須・範囲・一致など）に落とす。
早く・繰り返し回す
提出直前ではなく、モデリングの途中から定期的にチェックする。
指摘を共有して修正
見つかった問題を Issue（BCF） として担当に共有し、解決まで追跡。
納品前に最終検証
提出時のルールセットで通ることを確認し、結果を記録に残す。
まとめ
- モデルチェック（Validation）は、モデルが要件を満たすかを機械的に検証する作業。
- 必須属性・値の範囲・一致・命名規則などをルールで自動チェックする。
- データの正しさを見る点で、物理的衝突を見る干渉チェックとは別物。
- 早く繰り返し回すほど、後工程の手戻りを減らせる。
「見た目が正しい」と「データが正しい」は別です。モデルチェックは、BIM を”使えるデータ”に保つための地味で効く工程です。要求そのものを機械可読で書いて自動照合するIDS(情報要求仕様)は、この考え方をさらに前に進める新しい標準です。