BIM・IFCブログに戻る
- 3 — 独立した検証レイヤー
- 44 — モデル品質ルール
- 6 — IDSファセット（buildingSMART 1.0）
- 0 — アップロードされるバイト数（ブラウザー内で完結）
IFCの納品をめぐる話し合いは、いずれ必ず同じ壁にぶつかります。構造設計者は「ファイルは検証ツールを通った」と言います。BIMコーディネーターはプロパティセットの半分が欠けているのを見て、「どの検証ツールで？」と聞き返します。発注者の情報交換要件（EIR）には、誰もチェックしていないIDS要件が定められています。共通データ環境（CDE）はアップロードを拒否します。そして3週間後には、そもそも「妥当（valid）」とは何を意味するのか、誰にもわからなくなっているのです。
混乱するのも無理はありません。「検証（validation）」という言葉は、同じ名前で呼ばれるまったく異なる3つの作業を指しているからです。これらを切り分けることは、BIMコーディネーターがプロジェクトのためにできる仕事のなかでも、とりわけ影響の大きいもののひとつです。
まったく異なる3つの検証の問題
建築確認申請を思い浮かべてください。審査の担当者は、3つのことを別々に確認します。図面が読みやすく漏れがないか（ファイルの整合性）、設計が建築法規を満たしているか（品質と法令適合）、そして発注者の個別の要求を満たしているか（プロジェクト要件）です。読みやすい図面でも、防火規定をまったく無視していることがあります。防火規定を満たした計画でも、発注者の音響仕様をまるごと見落としていることがあります。これらは別々の問いであり、答えも別々です。
レベル1：IFCの整合性
ファイルはISO 10303-21およびISO 16739-1に照らして妥当なIFCか？GlobalIdは一意で、形式に準拠しているか？空間階層に矛盾はないか？スキーマレベルの、合否が二択のチェックです。
レベル2：モデル品質
データは調整作業に実際に役立つか？プロパティセットは入力されているか？要素は命名規則に従っているか？分類は付与されているか？実際の納品の可否を左右するのはこのレイヤーであり、スキーマへの準拠ではありません。
レベル3：IDS検証
モデルはこのプロジェクトの契約上の情報要件を満たしているか？EIRと資産情報要件（AIR）の内容を機械可読なIDS仕様として記述し、すべての要素に対してファセットごとにチェックします。
この3つのレイヤーは完全に独立しています。プロパティセットがエクスポートされておらず調整には使えないファイルでも、レベル1のスキーマ上は妥当でありえます。GUIDの重複が400件あるモデルでも、宣言されたすべての要件についてIDSチェックに合格することがあります。Health Score（ヘルススコア）が91でも、発注者の耐火性能の要件が記述され、満たされているかどうかは何もわかりません。各レイヤーはそれぞれ別の問いに答えるものであり、正式な納品の前には3つすべてが必要です。
レベル1：IFCファイルの整合性――妥当なIFCか？
レベル1はスキーマのチェックです。このファイルはIFCスキーマ（ISO 16739-1）と物理ファイル形式（ISO 10303-21 STEP）に準拠しているか、という二択の問いに答えます。ほとんどのIFCパーサーは、レベル1のチェックに通らないファイルも黙って受け入れます。厳格に拒否すると多くのワークフローが止まってしまうため、意図的に寛容に作られているのです。その寛容さが、後工程で表面化するまで損傷を覆い隠してしまいます。
レベル1の整合性チェックでわかること
- GlobalIdの一意性：すべてのIfcRootエンティティは、IFC独自のbase64文字セットを使った22文字の一意なGlobalIdを持たなければなりません。GlobalIdの重複はスキーマ違反です。パーサーは受け入れてしまいますが、BCFのワークフロー、CDEのバージョン管理、FM（施設管理）の資産台帳を気づかないうちに壊します。
- GlobalIdの形式への準拠：妥当なIFC GlobalIdの先頭文字が表すのは0〜3の値だけです（128ビットのUUIDのうち、上位の2ビット分）。UUIDを単純に切り詰めるスクリプトは、範囲外の先頭文字を生成してしまいます。仕様上は無効で、ほとんどのパーサーは許容しますが、厳格な検証ツールでは拒否されます。
- 空間階層の完全性：IFCスキーマでは、IfcProject → IfcSite → IfcBuilding → IfcBuildingStoreyの階層が必須です。ノードの欠落（Projectの直下にBuildingがある、物理要素がIfcSiteに直接置かれている、など）はスキーマ違反であり、後工程に実害を及ぼします。
- IfcRelAggregatesの連鎖の整合性：空間ツリーを構成する関係エンティティは、実在するエンティティを参照していなければなりません。削除済みまたは存在しないエンティティを指す関係、つまりダングリング参照があると、後工程のあらゆるツールでツリーのナビゲーションが壊れます。
- IfcRelContainedInSpatialStructure：物理要素は、空間要素（通常はIfcBuildingStorey）に包含されていなければなりません。包含関係を持たない要素は孤立要素（orphan）となり、ほとんどのツールの空間ナビゲーションに表示されません。
- IfcProjectはちょうど1つ：妥当なIFCファイルには、階層のルートとしてIfcProjectがちょうど1つ含まれていなければなりません。これを省略したサブモデルもエラーなく読み込めますが、空間上の拠り所がありません。
- FILE_NAMEとFILE_DESCRIPTIONのヘッダーフィールド：STEPファイルのヘッダーには、トレーサビリティのためのメタデータが入ります。ISO 19650-2ではこれらの入力が求められますが、ほとんどのツールは空文字のままにしています。
- ジオメトリの妥当性：非多様体（non-manifold）メッシュ、面積ゼロの面、法線の向きが反転したボディ、受け手のツールで有効なソリッドにならない自己交差したB-rep（境界表現）などです。
レベル1がチェックしないこと
- プロパティセットが入力されているか、正しいか。Psetがひとつもないスキーマ上妥当なモデルでも、レベル1には合格します。
- 要素名がプロジェクトの命名規則に従っているか。
- 分類コードが存在し、正しく、一貫しているか。
- LODの数量要件（LOD 300以上でのIfcElementQuantity）が満たされているか。
- モデルがプロジェクト固有または契約上の情報要件を満たしているか。
レベル1にはbuildingSMART Validation Service
buildingSMART IFC Validation Service（validate.buildingsmart.org）は、レベル1のスキーマ準拠を判定する権威あるリファレンスです。IFCソフトウェアの認証に使われているのと同じエンジンを採用しています。使うべきなのは、独自開発のエクスポーターが出力するIFCを認証する必要があるとき、パーサーによって扱いがまちまちなファイルのトラブルシューティングをするとき、あるいは契約条項でbuildingSMARTのスキーマ証明書が明示的に求められているときです。
このサービスが行わないこと：データ品質のチェック、命名規則の検証、プロパティセットの充足度の確認、ISO 19650のメタデータ項目のチェック、モデルがプロジェクトの要件を満たすかどうかの評価。これはスキーマのためのツールであって、プロジェクトの納品ゲートではありません。
実在する複雑なIFCで、3つの検証レイヤーすべてを確かめる
Revitからエクスポートした複数階のオフィスビルです。「検証」タブを開くと、44ルールの品質レポートの全体とHealth Scoreが表示されます。続いてIDS仕様を読み込み、同じモデルでレベル3のチェックを試してみてください。
IFC4 · 14 MB
インタラクティブなIFCビューアーを開く
レベル2：モデル品質チェック――納品を実際に左右するレイヤー
BIMコーディネーターが「IFC検証」と言うとき、その名前で呼ぶことはめったにないにせよ、たいていはこのモデル品質チェックのことを指しています。問われるのは実務的なことです。データはそろっているか？正しいか？一貫しているか？後工程の誰かが、このモデルを調整、コスト計画、FMに実際に使えるか？
レベル1と違い、品質チェックは二択ではありません。モデルは単純に合格・不合格に分かれるのではなく、数十の観点にわたる品質プロファイルを持っています。Health Score（0〜100）はこれらの観点を1つの数値に集約したもので、BIM実行計画（BEP）に書き込み、改訂ごとに追跡し、納品品質の証拠として送付状（トランスミッタル）に添付できます。
44ルールの品質チェックでわかること
モデル構造の基本ルール（18）
GUIDの重複、孤立要素、誤った包含関係、壊れた集約関係、IfcProjectの欠落、空の要素名、不正な階の配置。実務でCDEに差し戻される原因として最も多いルール群です。
空間＋ファイルヘッダー（11）
IfcProjectのISO 19650メタデータ項目、FILE_NAMEの作成者・組織の入力、敷地の配置と共有座標の関係、要素と階の関連付け、建物の階構成の完全性。
LOD、分類、MEP（9）
LOD 300以上でのIfcElementQuantityの有無、構造・意匠要素へのIfcRelAssociatesClassification、設備（MEP）システムの接続性、プロキシの多用（モデル全体に占めるIfcBuildingElementProxyの割合）。
ジオメトリ＋階の整合性（6）
要素のバウンディングボックスの妥当性、階の高さの順序、地盤面より下にある要素、階に床スラブがない状態、WCS原点からの座標オフセット、干渉チェック（任意のルールで、既定ではオフ）。
Health Score：モデル品質を1つの数値で表す
Health Scoreは、対数的なペナルティの重み付けを採用しています。スキーマエラーの重みは警告の3倍、警告の重みは情報レベルのチェックの3倍です。同じ問題でも、1,000件目で差し引かれる点数は10件目よりはるかに少なくなります。これにより、根本的な問題の密度が同じなら、大規模で密なモデルが小規模でまばらなモデルより不当に悪く見えることはありません。命名の警告が800件あるモデルが83点を取る一方で、空間参照の破損が12件あるモデルは41点になります。スコアを決めるのは件数ではなく重大度です。
- 31/100 — 危険：モデル構造の破綻。納品不可
- 58/100 — 不良：大幅な修正が必要
- 74/100 — 可：社内レビューでのみ許容
- 87/100 — 良好：CDEへの納品が可能
- 96/100 — 優秀：ISO 19650のマイルストーン品質
モデル品質チェックが行わないこと
- プロジェクト固有の情報要件の確認。これはレベル3（IDS）の役割です。品質ルールは汎用的なベストプラクティスのチェックであって、プロジェクトのEIRそのものではありません。
- モデルの修正。品質チェックが生み出すのはレポートです。修正はオーサリングツール（BIMソフト）で、プロパティやGUIDの修正であればIFCプロパティエディターで行います。
- buildingSMARTの認証プログラムで求められるスキーマ準拠証明書の発行。これはレベル1として、buildingSMART Validation Serviceで行います。
- モデルが幾何学的に正しいかどうかの判定。ジオメトリの整合性チェックも一部含まれますが、品質チェッカーは干渉チェックツールでも、BIMのオーサリングツールでもありません。
レベル3：IDS検証――情報交換要件を機械可読なコードに
IDS（Information Delivery Specification）は、プロジェクト固有の情報要件を機械可読なXML形式で記述するための、buildingSMARTの規格です。Word文書であるEIRと、モデルをそれに照らして体系的にチェックできる検証エンジンとをつなぐ、これまで欠けていたピースといえます。IDS 1.0は2023年に、buildingSMARTの正式な規格となりました。
buildingSMART IDSとは何か
IDSファイルは、1つ以上の仕様（specification）を含むXML文書です。各仕様には、適用範囲（applicability：どの要素に適用するか）と要件（requirements：それらの要素が何を持つべきか）のセクションがあります。エンジンは、モデル内で適用範囲に一致するすべての要素について、すべての要件を満たしているかを確認し、要素ごと・仕様ごとに合否を報告します。その結果は、契約への適合を示す、機械が生成した監査証跡になります。
buildingSMARTのリファレンステストスイートには100の公式テストケースがあり、IDSに準拠するエンジンが示すべき挙動を定義しています。いわば、実行できる形になった仕様書です。100のテストケースすべてに合格したIDSエンジンは、.ids仕様を規格どおりに一貫して解釈できることを実証したことになります。
IDSの6つのファセット
- Entity：適用範囲や要件を、IFCのエンティティ型（IFCWALL、IFCDOOR、IFCBEAM）と、必要に応じて定義済みタイプ（predefined type）で絞り込みます。ほとんどの仕様は、まずこのフィルターから始まります。
- Attribute：エンティティに直接付いているIFCの属性値（Name、Description、ObjectType、Tag、PredefinedType）をチェックします。属性はプロパティセットとは別物で、チェックの仕方も異なります。
- Property：指定したプロパティセット内の、指定したプロパティ（Pset_WallCommon.FireRating、Pset_DoorCommon.IsExternal）をチェックします。最もよく使われるファセットで、データ型の制約や、値のパターンマッチングにも対応しています。
- Classification：要素がIfcRelAssociatesClassificationを介して分類参照を持っているかをチェックします。対象はUniclass 2015、OmniClass、NBS、独自の分類体系などで、分類体系の名称やコードのパターンを制約できます。
- Material：要素にIfcMaterial、IfcMaterialLayerSet、IfcMaterialConstituentSetのいずれかでマテリアルが割り当てられているかをチェックします。マテリアル名を制約することもでき、耐火性能やサステナビリティの要件に役立ちます。
- PartOf：要素が、必要な空間的・論理的な関係に含まれているかをチェックします。階に包含されている、建物システムに集約されている、特定の建物に属している、といった関係です。特定の要素タイプについて、空間階層への準拠を強制するファセットです。
<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
<ids:info>
<ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
<ids:description>Fire safety and classification requirements.</ids:description>
<ids:ifcVersion>IFC4</ids:ifcVersion>
</ids:info>
<ids:specifications>
<!-- All walls must carry a fire rating property -->
<ids:specification name="Wall FireRating required" minOccurs="1">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
</ids:property>
</ids:requirements>
</ids:specification>
<!-- Structural walls must carry a Uniclass 2015 classification -->
<ids:specification name="Structural wall classification" minOccurs="0">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
<ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:classification>
<ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
</ids:classification>
</ids:requirements>
</ids:specification>
</ids:specifications>
</ids:ids>
EIR → IDS：多くのチームが省いている変換ステップ
EIRは、発注者が必要とする情報を規定します。IDSは、その要件を機械がチェックできる形で記述します。この2つの間の変換こそ、ほとんど誰も行っていないステップです。EIRが求めることを過不足なくテストする仕様を書くには、情報要件とIDSのXMLスキーマの両方を十分に理解している人が必要だからです。
その結果、チームはIDSを完全に省いて納品時の非公式な目視レビューに頼るか、実際のEIRを反映していない汎用のIDSファイルを使うかのどちらかになります。どちらも誤った安心感を生みます。汎用の仕様に対するIDSチェックに合格しても、その発注者固有の要件が満たされているかどうかは何もわかりません。
プロファイルベースのIDS：実践的な出発点
すべてのチームがIDSをゼロから書いているわけではありません。実践的なのは、再利用できるIDSプロファイルのライブラリーを維持するやり方です。たとえば、ステージ3の意匠用、ステージ4の設備（MEP）用、構造の引き渡し用といった具合です。各プロファイルはそのフェーズと分野で最も一般的な要件をカバーし、プロジェクトごとに発注者固有の要件を追加して拡張します。IDSプロファイルは検証エンジンに直接読み込んで組み合わせることができ、同じモデルに対して複数の.idsファイルを実行して、結果を集約できます。
3つのレベルの連携――検証パイプライン
3つのレイヤーは、モデルが順番に通過していく品質ゲートを構成します。各レベルは実行するタイミングが異なります。レベル1はエクスポートのたびに（健全性チェック）、レベル2はCDEへのアップロード前に（品質ゲート）、レベル3は正式な納品マイルストーンの前に（契約チェック）実行します。順番を間違えると時間の無駄です。空間階層が壊れたファイルにIDSを実行しても、何の意味もありません。
┌──────────────────────────────────────────────────────┐
│ EXPORT IFC from authoring tool │
│ (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…) │
└───────────────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 1 — IFC Integrity │
│ • GlobalId uniqueness & format (leading char 0–3) │
│ • Spatial hierarchy: Project→Site→Building→Storey │
│ • IfcRelAggregates chain integrity │
│ • IfcRelContainedInSpatialStructure (no orphans) │
│ • Exactly one IfcProject │
│ • FILE_NAME header traceability fields │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix in authoring tool (or IFC property editor)
│ Pass
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 2 — Model Quality (44 rules) │
│ • Naming conventions / empty element names │
│ • Property set completeness (Pset_WallCommon etc.) │
│ • ISO 19650 metadata (IfcProject.LongName etc.) │
│ • Classification presence and consistency │
│ • LOD quantity sets, proxy audit, MEP connectivity │
│ → Health Score 0–100 │
└─────────┬────────────────────────────────────────────┘
Score<80 ◄┤ Fix properties / names in IFC editor or authoring tool
│ Score ≥ 80
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 3 — IDS Validation │
│ • Project-specific EIR / AIR requirements │
│ • .ids specification(s) for this milestone │
│ • Six facets: entity, attribute, property, │
│ classification, material, partOf │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix per IDS issue report → export BCF → remediate
│ All requirements met
▼
┌──────────────────────────────────────────────────────┐
│ DELIVER TO CDE │
│ Attach: Health Score report + IDS pass certificate │
└──────────────────────────────────────────────────────┘
比較表：レベル1・レベル2・レベル3
| 観点 | L1：IFCの整合性 | L2：モデル品質 | L3：IDS検証 |
|---|
| 答える問い | ファイルは妥当なIFCスキーマか？ | データは調整に役立つか？ | プロジェクトの情報要件を満たしているか？ |
| 規格 | ISO 10303-21（STEP）、ISO 16739-1（IFC） | BIMのベストプラクティス、ISO 19650の規範 | buildingSMART IDS 1.0（XMLスキーマ） |
| 定義する主体 | buildingSMART（固定のスキーマ） | BIMチーム／EIR（プロジェクトで合意したルール） | 発注者／委託者（プロジェクトごと） |
| 出力 | 合格／不合格＋スキーマエラーの一覧 | Health Score 0〜100＋優先順位付きの指摘事項一覧 | 仕様ごとの合格／不合格 |
| ほかのレベルを代替できるか？ | いいえ | いいえ | いいえ（3つすべてが必要） |
| 実行タイミング | IFCをエクスポートするたび | CDEへのアップロード前 | 納品マイルストーンの前 |
| 合格しても別のレベルで不合格になる例 | Psetなし・名前なし → L1は合格、L2は不合格 | 耐火性能の欠落（IDS仕様）→ L3は不合格 | GUIDの重複、階層の破損 |
| ツールの例 | bSmart Validator、IFC Viewer Online | IFC Viewer Online、Solibri、IfcOpenShell | IFC Viewer Online（IDSエンジン）、Solibri |
buildingSMART Validation Serviceを使うべきとき――率直な評価
buildingSMART IFC Validation Serviceは、複数の段階からなるエンジンで、ファイルを公式スキーマに照らしてチェックします。STEP物理ファイルの構文、IFCスキーマのEXPRESSルール、仕様から導かれたインフォーマル・プロポジション（informal proposition）のルール、そして規範的なIFC制約ルールです。レベル1のスキーマ準拠を判定するリファレンスツールといえます。
使うべき場面
- 独自開発のエクスポーターが出力するIFCを認証する：buildingSMARTのチェッカーは、ソフトウェア認証に使われるリファレンスの結果を出力します。認証の場面では、ほかのどのツールの出力もその代わりにはなりません。
- パーサー間の不一致を診断する：あるツールでは問題なく開けるのに別のツールではエラーになるファイルについて、buildingSMARTのチェッカーは、どちらの挙動がスキーマ上正しいかを明らかにします。ファイルがほかの点では問題なく使える場合でも、診断のうえで価値があります。
- 契約条項で求められている：調達仕様によっては、納品要件としてbuildingSMARTのスキーマ準拠を参照していることがあります。その場合、条項を満たすのは公式サービスが発行する証明書です。
- IDSファイルそのものを検証する：buildingSMARTのIDSスキーマバリデーターは、.idsファイルが妥当なIDS文書かどうかをチェックします。これは、モデルに対してIDSを実行するのとは別のことです。
代わりとして使うべきでないもの
- モデル品質チェック：このサービスは、プロパティセットの充足度、命名規則、分類をはじめ、データ品質のルールを一切チェックしません。
- プロジェクト固有の検証：スキーマに準拠していても、モデルが発注者のEIRを満たしているかどうかは何もわかりません。
- CDEへの納品前の最終確認：Psetが空で名前も空白の、スキーマ上は妥当なモデルは、buildingSMARTのチェッカーには合格しますが、意味のある品質ゲートにはどれも通りません。
クラウド型IFC検証ツールとブラウザー型IFC検証ツール
クラウドでの検証（ファイルをリモートサーバーにアップロード）と、ブラウザーでの検証（WebAssemblyでファイルをローカル処理）の違いは、多くのチームが思っている以上に重要です。とくに官公庁、防衛、機密性の高い民間のプロジェクトではなおさらです。
ブラウザー型の検証
- IFCファイルがデバイスの外に出ない
- 仕組み上GDPRに準拠（データ転送なし）
- オフラインで動作：現場訪問、制限されたネットワーク
- アップロード容量やファイルサイズの制限なし
- 即座にフィードバック：ネットワーク往復の遅延なし
- サーバー負荷に左右されない安定した性能
- アカウント、APIキー、サブスクリプション不要
- 政府機関の制限付きネットワーク環境でも動作
クラウド型の検証
- 処理のためにファイルをリモートサーバーへアップロード
- GDPR対応にはデータ処理契約（DPA）が必要
- CI/CDによる自動検証パイプラインに適する
- プロジェクトやチームをまたいだ一元的な監査ログ
- 納品の自動化に向けたAPI・Webhook連携
- モデルの一括処理のために水平スケールが可能
- ブラウザーセッションなしでヘッドレス実行が可能
- 過去の実行結果を横断して照会可能
クラウド型の検証が向いているケース
- 自動化されたCI/CDパイプライン：モデルがコミットまたはアップロードされるたびに、検証を自動で実行したい場合です。ソフトウェアチームが、コードをプッシュするたびに自動テストを走らせるのと同じ発想です。この場合は、Webhookを備えたクラウドAPIが適切なアーキテクチャです。
- 組織全体の監査：BIMマネージャーが、複数のプロジェクトやチームにわたる検証の実行記録を一元管理する必要がある場合です。クラウドサービスなら、端末ごとのツールではできない形で、実行結果を集約して傾向を把握できます。
- 一括処理：既存モデルのライブラリー（たとえば過去2年間にCDEへ納品されたすべてのIFCファイル）を監査するのは、クラウドの一括処理なら現実的ですが、ブラウザーで手作業で行うのは現実的ではありません。
- 機密性の低いモデル：データの取り扱い要件でクラウドへのアップロードが禁じられていないプロジェクトなら、クラウド型の検証ツールは、ブラウザー型ツールにはないCI/CD連携を提供してくれます。
ブラウザー型のほうが適しているケース
- 官公庁・防衛のプロジェクト：公共インフラ、防衛施設、セキュリティが求められる資産のモデルには、第三者のサービスへのアップロードを禁じるデータ取り扱い上の制約がつきものです。ブラウザー型の検証が、唯一コンプライアンスに適合する選択肢です。
- 機密性の高い住宅・商業プロジェクト：BIMモデルには、GDPR第4条の個人データに該当する居住者情報、所有者の住所、資産のメタデータが含まれていることがよくあります。有効なDPAと法的根拠がないまま、これらを第三者のサーバーで処理することはコンプライアンス違反です。
- 現場での利用：200MBのIFCファイルを4G回線でアップロードすると、時間がかかるうえに不安定です。ブラウザーでの検証なら、アップロード帯域に依存せず、数秒でローカル処理できます。
- クラウドへのアップロード前の事前検証：正式なゲートとしてクラウド型の検証ツールを使っているチームでも、先にブラウザー型のチェックを実行すれば、アップロードせずに明らかな問題を見つけられます。クラウドの利用コストとアップロード回数も減らせます。
BIMチームが陥りがちな6つの検証ミスと、その本当の意味
ミス1：「IDSに合格したから、モデルは問題ない」
IDSが検証するのは、.ids仕様で宣言された内容だけです。.idsファイルで壁のFireRatingを要求していても、EIRではほかにドアのIsExternal、構造要素のUniclassコード、スラブの数量セットも求めていて、それらが仕様に書かれていなかった場合、EIRの半分が未チェックのまま、エンジンは「すべての要件を満たしている」と報告します。IDSの合格は、特定の仕様に対する契約上の確認です。品質全般を保証する証明書ではありません。
ミス2：「buildingSMARTのチェッカーで妥当と出た」
スキーマの妥当性は最低条件であって、ゴールではありません。すべての要素がName=''で、プロパティセットがひとつもないファイルも、スキーマ上は完全に妥当です。IfcElementQuantityも分類もなく、すべての物理要素が階ではなくIfcSiteに直接配置されたモデルも、スキーマ上は完全に妥当です。buildingSMARTのチェッカーに合格したということは、STEPファイルの書式が正しいという意味にすぎず、データが役に立つかどうかについては何も語りません。
ミス3：「ビューアーで開けたから大丈夫」
IFCビューアーは、意図的に寛容に作られています。データ品質に関係なく、ジオメトリを表示するためのものだからです。スキーマ上無効なファイルやデータの乏しいファイルを開けないビューアーなど、使い物になりません。ジオメトリが正しく表示されても、プロパティセットの充足度、命名規則、GUIDの安定性、分類をはじめ、44の品質観点のどれについても何もわかりません。ファイルを表示することと検証することは、まったくの別物です。
ミス4：ジオメトリだけ確認して、プロパティデータを無視する
よくあるのが、IFCを開いて3Dモデルを眺め、建物が正しく見えればファイルは完成だと判断してしまうことです。IFCファイルの有用性のうち、ジオメトリが占めるのはおよそ30%にすぎません。FMシステム、積算担当者、CDEの資産台帳が実際に利用するのは、プロパティセット、分類、要素名、タイプの割り当て、数量セットです。ジオメトリが正しくても、プロパティセットが空のファイルは引き渡しで不合格になります。
ミス5：納品期限に1回だけ検証する
検証をCDEへの提出直前の最終工程として扱うと、余裕のないまま、プレッシャーの中で問題を修正することになります。期限の前日に800件の検証上の問題が見つかったモデルは、既知の問題を抱えたまま納品されるか、期限に間に合わないかのどちらかです。正しいタイミングは、レベル1はエクスポートのたびに、レベル2は社内レビューのたびに（最低でも週1回）、レベル3は正式な各マイルストーンの2週間前です。
ミス6：再エクスポートをまたいだGUIDの安定性を無視する
ファイル内のGUIDの重複はレベル1の問題で、どの検証ツールでも検出できます。しかし、再エクスポートをまたいだGUIDの不安定さ、つまりモデルをエクスポートするたびに同じ要素に異なるGlobalIdが付く現象は、単一ファイルの検証では見えません。改訂のたびにGlobalIdが変わってしまうと、BCFのコメント、CDEの要素参照、FMの資産タグがすべて、気づかないうちにダングリング参照になります。これに対処するには、単一ファイルの検証だけでなく、2つの改訂版の比較とエクスポート設定の確認が必要です。
BIMコーディネーターのための実践的な検証ワークフロー
- IFCをエクスポートするたびに：レベル1のチェックを実行します。ブラウザー型の検証ツールなら、どれでも30秒もかかりません。GlobalIdの重複、孤立要素、空間階層の破損は、改訂を重ねて問題が膨らむ前に修正しましょう。
- 社内レビューの前には毎回（毎週またはスプリントごと）：レベル2の品質チェックをひと通り実行します。Health Scoreの推移も確認しましょう。改訂ごとにスコアが下がっているなら、新しい問題が持ち込まれているということです。それが常態化する前に、原因を突き止めてください。
- 第三者から分野別モデルを受け取ったら必ず：統合する前にレベル1とレベル2を実行します。受け取ったモデルには、調整用の統合モデルにそのまま引き継がれる問題が潜んでいるかもしれません。壊れた統合モデルで3週間調整を進めてからではなく、受け取った時点ですぐに検出しましょう。
- 正式なマイルストーン納品の2週間前：3つのレベルすべてを実行します。IDSの前に、Health Score 80以上を目標にしてください。2週間あれば、プレッシャーなしに修正する時間がとれます。問題は早めに共有し、余裕期間を黙って使い切らないようにしましょう。
- CDEへアップロードする前に：レベル2とレベル3を実行します。Health Scoreの証明書とIDSの合格レポートを送付状に添付しましょう。これで文書化された監査証跡が残り、情報管理者は納品を受け入れるのに必要なものをすべて手にできます。
- オーサリングツールのバージョンアップやエクスポート設定の変更後に：連続する2回のエクスポートを比較して、GUIDの安定性のベースラインを確立し直します。Revitのアップグレードやエクスポート設定の変更によって、GlobalIdの生成方法が気づかないうちに変わることがあるからです。
実務のヒント
件数ではなくペナルティで優先順位をつける
問題は件数の多い順ではなく、Health Scoreへの影響が大きい順に修正しましょう。IfcProjectのメタデータ項目が3つ欠けているだけで、15点失うことがあります。一方、命名の警告800件で失うのは、合計でも8点程度かもしれません。重大度の内訳を見て、影響度で優先順位をつけてください。
エクスポート設定をテンプレートに固定する
エクスポート設定を手作業で設定し直すたびに、別の設定にずれていくリスクが生じます。オーサリングツールで名前付きのIFCエクスポート設定を作成してプロジェクトテンプレートに登録し、必要な設定をBEPに記載しましょう。「前回はうまくいったのに」というエクスポートの問題の大半は、この設定のずれが根本原因です。
プロジェクト開始時にEIRをIDSに変換する
プロジェクトの最初の2週間で、EIRの最も重要な条項をIDS仕様に変換しましょう。仕様が5〜6個しかない部分的な.idsファイルでも、納品時にEIRをすべて手作業でレビューするよりはましです。しかも、体系的なデータの欠落を、修正コストの低い早い段階で発見できます。
統合する前に分野別モデルをそれぞれ検証する
統合モデルでは、ある分野のモデルの問題が、別の分野のモデルの問題を覆い隠したり、互いに影響し合ったりすることがあります。入力をクリーンな状態で検証し、クリーンな状態で統合しましょう。統合後の調整モデルだけで検証すると、問題を本来の作成者に割り当てるのが難しくなります。
よくある質問
レベル1に合格すれば、レベル2は省略できますか？
いいえ。レベル1とレベル2は、ファイルのまったく異なる性質を測るものです。スキーマ上妥当なファイル（レベル1）でも、プロパティセットがひとつもなく、要素名が空で、分類もISO 19650のメタデータもないことがあり、その場合は品質チェック（レベル2）で20点しか取れません。常に両方が必要です。レベル1は「ファイルが正しく梱包されている」こと、レベル2は「梱包の中身が要求どおりである」ことだと考えてください。
IDSはbuildingSMART Validation Serviceの代わりになりますか？
いいえ。IDSがチェックするのはプロジェクト固有の情報要件（レベル3）で、buildingSMART Validation Serviceがチェックするのはスキーマへの準拠（レベル1）です。両者はまったく異なるレベルで機能し、答える問いも異なります。スキーマ検証に通らないのにIDSには合格しているモデルは、論理的に矛盾しています。レベル1の整合性が確保されていてはじめて、レベル3のチェックが意味を持つからです。
標準的なBIM納品では、どのIDSファセットを優先すべきですか？
実務のEIR要件の70〜80%は、Propertyファセットでカバーできます。ほとんどの発注者が求めるのは、特定の要素タイプに特定のプロパティセットの値が入力されていることだからです。UniclassやOmniClassに基づくプロジェクトなら、残りの大部分はClassificationファセットでカバーできます。Entityファセットは、適用範囲のフィルターとしてほぼすべての仕様に登場します。MaterialとPartOfは、特定の契約上の要件に対応するものです。まずはEntity＋Propertyから始め、EIRが求める場合はClassificationを追加し、そこから広げていきましょう。
IFCをどこにもアップロードせずに検証できますか？
はい。ブラウザー型の検証ツールは、WebAssemblyを使ってファイルをすべてブラウザー内で処理します。IFCのデータがデバイスの外に出ることはなく、44の品質ルール、Health Scoreの計算、IDSエンジン全体がクライアント側で動作します。官公庁の資産、機密性の高い住宅データ、防衛インフラなど、データの取り扱いに制約があるモデルでは、多くの場合これが唯一コンプライアンスに適合する選択肢です。
BEPにはHealth Scoreのしきい値をいくつと規定すべきですか？
CDEへの納品と設計調整では、80以上が標準的なしきい値です。LOD 300以上の実施設計段階の納品や、ISO 19650の正式なマイルストーン提出では90以上。コンセプト段階の社内レビューなら70以上で許容範囲です。60を下回るモデルにはモデル構造上の品質問題があり、どのような状況であっても外部の関係者に納品すべきではありません。
1つのツールで、3つの検証レベルすべてをカバーできますか？
できるツールもあります。IFC Viewer Onlineは、レベル1（GUID、階層、ファイルヘッダーのチェックを含む整合性ルール）、レベル2（Health Score付きの44ルールの品質チェック）、レベル3（bSI公式の全100テストケースで検証済みのIDS 1.0エンジン）をカバーしています。Solibriはより高度なルールエンジンでレベル2とレベル3をカバーしますが、ブラウザー内での処理には対応していません。buildingSMART Validation Serviceがカバーするのはレベル1のみです。IfcOpenShellは、スクリプトを書けばレベル1とレベル2に使えます。
まとめ
スキーマ上妥当でも、プロジェクト上妥当とは限らない。プロジェクト上妥当でも、EIRに準拠しているとは限らない。3つの検証レイヤーはすべて必要であり、それらを混同することこそが、正式な納品で起こる失敗の大半の根本原因です。
IFC Viewerブログ
レベル1：エクスポートのたびに実行
スキーマの整合性、GlobalIdの一意性と形式、空間階層。所要時間は30秒です。後工程でBCF、CDEのバージョン管理、FMの資産台帳を気づかないうちに壊してしまう、モデル構造上の欠陥を捕まえます。
レベル2：CDEへの納品のたびにゲートとして
44の品質ルール、Health Score、命名規則、プロパティセットの充足度、ISO 19650のメタデータ。BEPとEIRで80以上を必須にしましょう。モデルを単に読み込めるだけでなく、実際に役立つものにするのがこのレイヤーです。
レベル3：マイルストーンの前に毎回確認
EIRとAIRを機械可読な形で記述したIDS仕様です。重要な条項は、納品の前週ではなくプロジェクト開始時に変換しましょう。IDSの合格は、文書化された契約上の監査証跡になります。
まずは、今のモデルで品質チェックをひと通り実行してみてください。どのブラウザーでも30秒かからず、何もアップロードされません。次にIFC Health Scoreガイドを読んで、スコアの計算方法と、BEPに設定すべきしきい値を理解しましょう。受け取ったファイルのプロパティ値やGUIDを修正する必要がある場合は、無料のオンラインIFCエディターガイドで、オーサリングツールとの往復なしに、非破壊でプロパティを編集する方法を紹介しています。また、レベル1で差し戻される原因として最も多い構造上の不具合については、よくあるIFC検証エラー7選をご覧ください。
IFCモデルチェッカー完全ガイド：IFC検証、モデル品質、IDSのすべて
