BIM・IFCブログに戻る
ほとんどの人はIFCをエクスポートしたら、そのまま送っています。事前にチェックする人はほとんどいません。気にしていないからではなく、「IFCを検証する」という言葉が本当に曖昧だからです。何に照らして検証するのか。スキーマなのか、プロジェクトの要件なのか、それともコーディネーターのツールで開けるかどうかなのか。これらは3つの異なる問いで、使うツールもそれぞれ違います。この3つを混同していることこそ、共通データ環境（CDE）で多くのモデルが差し戻される理由です。
本記事はそのための実務的な見取り図です。「有効」とは何を意味するのか、それを確認する3つの方法、それぞれが検出できるもの・できないもの、そして送信ボタンを押す前の10分間で実行すべきチェックリストを紹介します。
60秒でわかる結論
締め切り前にとにかくモデルをチェックしたいなら、ワークフローはこれだけです。
- ローカルのフォルダーにエクスポートする CDEへ直接エクスポートするのは避けてください[iso19650]。
- ブラウザー上の検証ツールでファイルを開く 解析はローカルで行われるため、何もアップロードされません。
- Health Score（ヘルススコア）を確認し、重大度順に並べ替える 見るべきは件数ではなく重大度です。重大な指摘事項1件は、軽微な指摘事項が多数あるよりも重要です。
- オーサリングツール（BIMソフト）で原因を修正し、再エクスポートする Revit、ArchiCAD、Teklaなど、モデルを作成したツールで行います。
IFCのテキストを手作業で編集してはいけません。GUIDや参照が壊れることが多く、しかも元の問題よりはるかに見つけにくい形で壊れます。
- 再チェックし、スコアを添えてアップロードする Health Scoreが80以上であることを確認し、送付状（トランスミッタル）に記録します。
以降では、各ステップがなぜ必要なのか、そして手早い方法では足りないときにどのツールを使うべきかを説明します。
「有効」とは実際に何を意味するのか
検証には2つの層があり、それぞれ独立しています。一方に合格しても、もう一方で不合格になることがあります。
スキーマの妥当性
ファイルがIFC規格（ISO 10303-21の構文、IFCスキーマ、MVDのルール）に適合しているか。スキーマ上は有効でも、コーディネーションにはまったく使えないファイルもあります。
実務上の健全性
下流の工程で実際に使えるか。安定したGUID、正しい空間階層、名前の付いた要素、妥当な座標、揃ったプロパティセット。モデルが差し戻される原因はこちらにあり、スキーマチェッカーが測っているのはこの部分ではありません。
この2つの層の上に、3つ目の層があります。buildingSMART IDS[ids]を使って、プロジェクト独自の情報要件に照らしてモデルをチェックする層です。これはファイルそのものではなく情報交換要件（EIR）に属するもので、専用のガイドがあります。詳しくはIFCモデルチェッカー完全ガイド：スキーマ、品質、IDSをご覧ください。本記事では、どの納品の前にもクリアしなければならない2つの層に絞って解説します。
方法1：buildingSMARTのValidation Service
buildingSMART International[bsi-validate]が提供する、公式かつ無料のWebサービスです。IFC規格[ifc-schema]への適合性を判定し、STEP構文、スキーマへの準拠、規範ルール、buildingSMART Data Dictionaryとの整合をチェックします。信頼性の高い合否レポートを出力するため、スキーマの正しさについてはこれが基準になります。
- 向いている用途：ファイルがIFC規格に適合していることの証明。特に、スキーマへの適合性を正式に、あるいは契約上主張する場合に適しています。
- できないこと：「コーディネーションに使えるレベルか」を示す実務的なスコアは出ません。また、ファイルをサービスにアップロードする必要があるため、第三者に送れない機密性の高いプロジェクトデータには使えません。
方法2：IfcOpenShell（開発者向け）
Pythonが書けるなら、IfcOpenShell[ifcopenshell]を使ってコマンドラインから検証できます。「python -m ifcopenshell.validate model.ifc」を実行するだけです。スクリプト化でき、無料で、ローカルで動作し、QAを自動化しているチームならCIパイプラインにも組み込めます。
# Validate an IFC file locally with IfcOpenShell
python -m ifcopenshell.validate path/to/model.ifc
# Pipe the results into your own pre-delivery checks
python validate_and_score.py model.ifc
- 向いている用途：スクリプトやビルドパイプラインの中で検証を行いたい開発者やBIM自動化チーム。
- できないこと：3D表示もワンクリックのレポートもありません。モデルに問題がないかを知りたいだけのコーディネーターが、そのためにわざわざPythonをインストールすることはないでしょう。
方法3：ブラウザー上のヘルスチェック（30秒）
IFCをビューアーにドラッグするだけです。WebAssemblyによってクライアント側で解析され（何もアップロードされません）、バックグラウンドスレッドで44の実務的な検証ルールが実行されます。結果として、0〜100の単一のHealth Scoreと、3Dモデル上で確認できる指摘事項ごとの内訳が返されます。これはほかの2つがカバーしていない層です。モデルを送ってよい状態かどうかを、速く、プライベートに、実務的な観点で判断できます。
モデルをその場で検証する
buildingSMARTのDuplexモデルを開いて、問題のないHealth Scoreとレポートがどう見えるかを確認し、次にご自身のエクスポートファイルをドロップして納品前にチェックしましょう。ファイルがお使いのマシンの外に出ることはありません。
IFC2x3 · 2.4 MB
インタラクティブなIFCビューアーを開く
各ツールが実際に検出できるもの
3つの方法は、1つの問いに対する競合する答えではありません。それぞれ異なる不具合をカバーしています。正直に整理すると、次のとおりです。
| チェック項目 | buildingSMARTのサービス | IfcOpenShell | ブラウザーでのヘルスチェック |
|---|
| STEP / スキーマへの適合性 | 対応（公式の基準） | 対応 | 基本的な整合性のみ |
| 規範ルールとbSDD | 対応 | 一部 | 非対応 |
| GlobalIdの重複・形式不正 | 一部 | 一部 | 対応 |
| 空間階層と孤立した要素 | 非対応 | 一部 | 対応 |
| 原点から離れた座標 | 非対応 | 非対応 | 対応 |
| プロパティセットや名前の欠落 | 非対応 | 非対応 | 対応 |
| 納品可否を示す単一のスコア | 非対応 | 非対応 | 対応（Health Score 0〜100） |
| 3Dモデル上で指摘事項を確認できる | 非対応 | 非対応 | 対応 |
| ファイルをアップロードせずに実行できる | 非対応 | 対応 | 対応 |
| CIでスクリプト化できる | API経由 | 対応 | 非対応 |
2026年8月時点の対応状況。「一部」は、不具合自体は検出できるものの、名前付きの対処可能な指摘事項としては報告されないことを意味します。どれを、いつ使うか
ブラウザー上のヘルスチェックを使うべきなのは…
- モデルを送ってよい状態か、今すぐ知りたいとき
- ファイルが機密で、どこにもアップロードできないとき
- 送付状やBIM実行計画（BEP）に記載する数値が必要なとき
- ログだけでなく、3Dモデル上で指摘事項を確認したいとき
- 開発者ではなく、コーディネーターであるとき
buildingSMART / IfcOpenShellを使うべきなのは…
- 信頼性の高いスキーマ適合性の証明が必要なとき
- CIパイプラインの中でQAを自動化しているとき（IfcOpenShell）
- Pythonを書けて、スクリプト化できるチェックが欲しいとき
- 契約で、規格への適合を正式に表明することが求められているとき
- 特にMVD / bSDDへの準拠が必要なとき
実務で使える送信前チェックリスト
どのツールを使うにしても、実際にモデルが差し戻される原因は次のとおりです。いずれも検証ルールに対応しており、それぞれにステップごとの修正ガイドがあります。
- GlobalIdの重複や範囲外の値がない。
- すべての物理要素がいずれかの階に含まれており、サイトや建物の直下に置かれていない。
- ルートにIfcProjectがちょうど1つあり、空間階層が完全である。
- 孤立した要素や壊れた集約関係がない。
- 座標が妥当である。モデルが何kmも離れた場所ではなく、ワールド原点の近くにある。
- 標準プロパティセットが揃っており、要素に名前が付いている。
- CDEへアップロードする前に、Health Scoreが80以上である。
スコアが低かったときは
スコアが低くても、それはモデルそのものへの判定というより、エクスポート設定に目を向けるべきだというサインであることがほとんどです。不具合のほぼすべては5つの原因のいずれかにさかのぼり、どれもIFCではなくオーサリングツール側で修正します。
| レポートの内容 | よくある原因 | 修正する場所 |
|---|
| 前回の発行からGlobalIdが変わっている | エクスポート時にGUIDを保持せず、再生成している | オーサリングツールのエクスポート設定 |
| どの階にも属さない要素がある | エクスポート時にレベルが「Building Story」として指定されていない | Revitのレベル設定 |
| モデルが原点から離れている | 共有座標やプロジェクト座標ではなく、測量座標でエクスポートしている | エクスポート前の座標設定 |
| IfcBuildingElementProxyの割合が高い | IFCクラスがマッピングされていないファミリがある | IFCエクスポートのマッピングテーブル |
| プロパティセットが欠落している | Psetのエクスポートが無効、またはパラメータが一度もマッピングされていない | エクスポートの構成設定 |
それぞれに専用の解説記事があります。IFCのGUIDがエクスポートのたびに変わる理由、RevitのIFCエクスポートがおかしくなる理由、IFCの座標がずれる問題、エクスポート後にIFCのプロパティが消える問題をご覧ください。
チェックをルールにする
誰かが実行を覚えているかどうかに左右されるチェックは、品質プロセスとは言えません。しきい値をBEPに明記し、その証拠を納品物に添付しましょう。
| 納品段階 | 最低Health Score | 添付する証拠 |
|---|
| 社内の構想段階レビュー | 70 | スコアのみ |
| 調整ラウンド / CDEへのアップロード | 80 | スコア＋指摘事項レポート |
| ISO 19650のマイルストーン、LOD 300以上 | 90 | スコア＋指摘事項レポート＋解決済み指摘事項のログ |
しきい値が合意できれば、あとは同じことの繰り返しです。ローカルにエクスポートし、検証し、原因を修正し、再エクスポートして、スコアを添えて納品する。プロジェクト全体で品質とは何を意味するのか、より広い視点についてはIFC品質の完全ガイドをご覧ください。
IFCファイルを送る前に検証する方法（無料・アップロード不要）
