BIM・IFCブログに戻る
- 44 — チェックする品質ルール
- 100 — 最高スコア（常に目標とは限らない）
- 80+ — 共通データ環境（CDE）への納品の目標値
- 0バイト — 検証のためにアップロードされるデータ
IFC Health Scoreとは何か、そして何ではないか
どのBIMプロジェクトでも、BEPには曖昧な品質要件が書かれています。「高品質なIFCを納品すること」。モデルがCDEで差し戻されたり、孤立要素のせいで干渉チェックの会議が無駄になったり、引き渡しパッケージに資産データが半分しか入っていなかったりするまで、それが何を意味するのかを誰も定義しません。IFC Health Scoreは、この曖昧な要件を具体的なものにするためにあります。毎回、どのマシンでも、それを実装したどのツールでも同じ方法で計算される、ひとつの数値です。
ところが、最もよくある誤りは、これをパーセンテージとして扱うことです。スコアはパーセンテージではありません。73点は、何かの73%が正しいという意味ではないのです。重大度で重み付けし、対数スケールで調整した品質シグナルです。この違いを理解すると、しきい値の決め方も、結果の読み方も、IFCファイルを直接扱わないプロジェクト関係者への品質の伝え方も変わります。
Health Scoreであるもの
- 構造品質とデータ品質を重み付けして要約した0〜100の値
- 契約に盛り込める成果物の基準（EIRに記載すべきもの）
- 判断のシグナル：このモデルを今日納品できるか？
- 検証を実行するたびに更新される進捗の指標
- モデルのバージョン、分野、チームメンバーをまたいで比較できるもの
- 重大度に左右されるもの（エラーは警告より大きく減点される）
- 対数スケールのもの（名前の警告10,000件 ≠ 名前の警告1件 × 10,000）
Health Scoreではないもの
- 合格した検証ルールの割合
- 設計の正しさやプロジェクトとしての正確さの尺度
- IDS／EIRへの適合チェックの代わり
- プロパティ値が意味的に正しいことの保証
- BIMコーディネーターによる専門的なレビューの代わり
- 絶対的な尺度（しきい値はプロジェクトと段階によって異なる）
- ツール固有のスコア（同じルールを実装したツールなら、同じモデルは同じスコアになる）
従来の検証レポートが判断を麻痺させる理由
中程度の複雑さのRevitエクスポートを検証した標準的なレポートには、通常8〜12のルールカテゴリーにわたって200〜1,200件の指摘事項が並びます。すべてを伝えているようで、何も伝えていないのです。インフォメーションマネージャーは847件という数を見てモデルを差し戻します。BIMコーディネーターはレポートを開き、620件の命名規則の警告（すべて同じルール）をスクロールして読み飛ばし、12ページ目に埋もれた本当に致命的なエラー3件をようやく見つけます。
問題は、重大度による重み付けがなければ、指摘事項の件数そのものからは何もわからないことです。命名の警告が800件あっても構造エラーがゼロのモデルと、空間階層の破綻が12か所あり、IfcProjectも欠けているモデルとは、まったく別物です。Health Scoreはこの違いを、行動につなげられるひとつの数値に凝縮します。そしてその下にあるルール別の内訳が、優先順位付きの対応リストになります。
847件の指摘事項が並ぶレポートは、問題があることを教えてくれます。74点というHealth Scoreは、今日納品できるかどうかを教えてくれます。そして34点なら、修正が終わるまで調整作業を止めるべきだと教えてくれます。
IFC Viewer Blog
Health Scoreの計算方法
計算は100点から始まり、ルール違反があるたびに点数を差し引きます。スコアが単なる指摘件数の集計にならないよう、2つの仕組みが働いています。
重大度による重み付け
スキーマエラー（IfcProjectの欠落、集約関係の破綻、循環参照といった構造的な不備）の減点は、品質に関する警告（名前が空、分類の欠落など）の3倍です。これは実際の影響の大きさを反映しています。構造的な不備は下流のツールを動かなくしますが、命名の警告はそうではありません。
対数的な減衰
あるルールの違反は、1件目のほうが1000件目よりも多く減点されます。重複したGUIDが10件のモデルと10,000件のモデルとでは重大さが違いますが、1,000倍も違うわけではありません。対数スケールによって、ファイルの大きさが品質シグナルを歪めるのを防いでいます。
Conceptual scoring model:
score = 100
for each failing rule:
base_penalty = rule.severity_weight × log(1 + issue_count)
score -= base_penalty
Severity weights:
schema_error → 3.0× (missing IfcProject, broken hierarchy, duplicate GUIDs)
quality_error → 1.5× (missing property sets, wrong container placement)
warning → 1.0× (naming conventions, missing classifications)
info → 0.3× (optional metadata gaps, non-critical omissions)
score = max(0, score)
Note: The actual formula is proprietary to each tool implementation.
This is the conceptual model — the penalty shape, not the exact coefficients.
スコアを左右する11の品質の観点
44の検証ルールは、11の品質の観点に分類されます。どの観点がスコアを下げているのかがわかれば、次の検証までにどこへ修正の労力を集中すべきかが見えてきます。
- スキーマの整合性：ファイルにIfcProjectがちょうど1つ含まれているか。すべての集約関係が実在するエンティティを指しているか。空間参照に循環はないか。
- GlobalIdの一意性と形式：ファイル内のすべてのGlobalIdが一意か。先頭の文字が、IFCのBase64アルファベットで有効な0〜3の範囲に収まっているか。
- 空間階層：すべての要素について、Project → Site → Building → Storey → 物理要素という包含の連鎖が途切れていないか。
- 要素の包含：空間コンテナを持たない孤立した物理要素はないか。階ではなく、IfcBuildingやIfcSiteの直下に配置された要素はないか。
- 要素の命名：物理要素やスペースを表すすべてのIfcRootエンティティで、NameとDescriptionが入力されているか。
- プロパティセットの充足度：想定される標準のプロパティセット（Pset_WallCommon、Pset_SpaceCommonなど）が、それを必要とする要素タイプに存在し、値が入力されているか。
- ISO 19650のメタデータ：IfcProject.LongName、Description、ObjectTypeが入力されているか。FILE_NAMEヘッダーの作成者と組織のフィールドが空になっていないか。
- 分類：物理要素がIfcRelAssociatesClassificationの関係を持っているか。分類体系がファイル全体で統一されているか。
- マテリアルの割り当て：構造・意匠・仕上げの要素に、マテリアルレイヤーセットまたはマテリアルプロファイルセットが定義されているか。
- ジオメトリの整合性：干渉チェックや数量拾いで不具合を起こす、縮退した面、自己交差する曲面、非多様体のジオメトリはないか。
- LODの一貫性：プロパティセットの密度が、宣言された詳細度（LOD）と合っているか。面積と体積の数量が欠けたLOD 300の納品は、このチェックに不合格になります。
スコア帯：各帯の意味と取るべき対応
- 97/100 — 優秀：ISO 19650の提出に対応
- 89/100 — 非常に良好：CDEへの納品に対応
- 77/100 — 許容範囲：正式な納品の前に要確認
- 61/100 — 不良：大幅な修正が必要
- 38/100 — 致命的：納品不可
| スコア範囲 | スコア帯 | 解釈と対応 |
|---|
| 95 – 100 | 優秀 ✅ | ISO 19650の提出を含む、すべての正式な納品に適しています。ルール違反は軽微か、まったくありません。対応は不要です。 |
| 85 – 94 | 非常に良好 🟢 | データの完全性に軽微な問題があります。通常の調整作業であればCDEに提出できる状態です。LOD 300以上に進む前に、残りの違反を解消してください。 |
| 70 – 84 | 許容範囲 🟡 | データ品質に無視できない欠落があります。社内レビューや構想設計には許容できます。分野間の調整やCDEへのアップロードの前に、必ず見直して改善してください。 |
| 50 – 69 | 不良 🟠 | 構造またはデータに重大な問題があります。調整作業には使えません。まずスキーマエラーをすべて修正し、その後、影響の大きいデータ品質ルールから対処してください。 |
| 50未満 | 致命的 🔴 | 根本的な構造の不備：孤立要素、階層の破綻、IfcProjectの欠落、循環参照。オーサリングツール（BIMソフト）に戻って修正してください。いかなる場合も納品してはいけません。 |
これらの範囲は、出発点となる枠組みです。プロジェクトに適したしきい値は、納品段階、契約上の要件、そして受け手側のツールがどこまで許容できるかによって決まります。GISシステム向けにインフラのIFCファイルを受け入れる道路管理者であれば、すべての受け渡しで90以上を求めるかもしれません。社内で調整を行う小規模な住宅設計事務所であれば、設計段階は70以上で十分にやっていけるでしょう。上のスコア帯は業界で一般的な合意を反映したもので、唯一の固定されたルールではありません。
3つの実例：プロジェクトの文脈で見るHealth Score
抽象的なしきい値も、実際のモデルに当てはめた例を見れば使いやすくなります。以下のシナリオは、意匠・設備（MEP）・インフラのIFC納品でよく見られるパターンを組み合わせたものです。
シナリオ1：意匠のIFC、95点
中規模の商業オフィスビル、LOD 300、ArchiCAD 27からのエクスポート。検証レポートの指摘事項は43件です。汎用的な注釈要素に対する命名規則の警告が38件（説明的な名前ではなく「Annotation-001」になっている）、カーテンウォールのパネルでマテリアルの割り当てが欠けているものが5件。スキーマエラーはありません。重複したGUIDもありません。空間階層は保たれています。IfcProjectのメタデータはすべて入力されています。ISO 19650のファイルヘッダーも完全です。スコアは95点で、BEPではCDEへの納品に85以上を求めています。判断：このまま納品し、命名の問題は送付状（トランスミッタル）に納品を妨げないコメントとして記載し、マテリアルの割り当ての修正は次の改訂で行うよう予定を組みます。
シナリオ2：設備（MEP）のIFC、68点
Revit 2025 MEPからエクスポートした機械・電気設備の全体モデル、LOD 250。スコアは68点です。ルール別の内訳は、原因を優先度順に示しています。重複したGlobalIdが214件（重大度：高。Revitのエクスポート設定でGUIDが再生成され、古いリンクモデルからコピーした要素と衝突した）、階ではなくIfcBuildingの直下に配置された要素が89件（空間包含の不備。複数階を貫く空調のライザーが、地下階に紐付けられず建物レベルに配置されていた）、分類のないIfcFlowTerminal要素が44件（EIRではUniclassが必須）、分電盤に対する命名の警告が312件。空間包含の不備と重複したGUIDはスキーマレベルの問題で、BCFの参照を壊し、FM向けのエクスポートを失敗させます。このモデルは納品すべきではありません。GUIDを修正し（自動修正可能）、ライザーの階への配置を直し、分類を追加してから再検証します。修正後の予想スコアは83以上です。
シナリオ3：インフラのIFC、82点
カスタムエクスポーターを介してCivil 3DからエクスポートしたIFC4.3の道路線形モデルで、排水施設と縁石を含む4kmの道路区間を対象としています。スコアは82点です。主な減点要因は、分類のない要素が67件（Uniclass Table Jが必須）、104個の縁石要素で数量セットが欠落（契約ではBaseQuantitiesに長さを明示することが求められている）、IfcProject.LongNameの不整合（ヘッダーに正式なプロジェクト名ではなくファイル名が表示されている）です。構造的なエラーはありません。重複したGUIDもありません。発注者の仕様では、施工中のモデルの受け渡しに最低80点を求めています。このモデルは合格です。コーディネーターは、しきい値が90に上がる正式な設計凍結時の提出までに修正すべき3つの点を記録しておきます。
プロジェクトのライフサイクル全体でHealth Scoreを活用する方法
Health Scoreが最も役に立つのは、納品時だけに使うのではなく、プロジェクトの日常のリズムに組み込んだときです。ブラウザーで開けるモデルなら、検証にかかる時間は30秒未満。実行の手間はほぼゼロです。一方、実行しなかった場合の手間、つまりCDEのゲートや調整会議で構造的な不備が発覚したときの手間は、日単位で数えることになります。
設計段階での毎週のQA
モデル作成が活発に進んでいる期間は、毎週検証を実行しましょう。スコアの推移はプロジェクトログに記録します。ある金曜日から翌週の金曜日までにスコアが15点下がったなら、何かが変わったということです。モデルが2倍複雑になる6週間後よりも、今のほうがはるかに原因を突き止めやすいはずです。
調整会議の前に毎回
各分野は会議の前に、それぞれのしきい値（社内なら70以上、分野間なら80以上）をクリアしておくべきです。60未満のファイルから組み立てたNavisworksやIFCの統合モデルでは、意味のない干渉ばかりが出てきます。誤った位置にある要素、参照できない孤立した設備の配管・ダクト、何も指していないBCFの指摘事項などです。
IDS／EIRの検証の前に
IDS検証は、構造的に正しく、データが揃ったベースモデルを前提としています。空間階層が破綻していたり、GUIDが重複していたりするモデルにIDSチェックをかけても、信頼できる結果は得られません。IDSエンジンが要素を誤認したり、包含関係に基づく適用条件を取りこぼしたり、誤って合格と判定したりするおそれがあります。信頼できる結果を得るために、IDSを実行する前の条件として75以上を求めましょう。
モデルを受け渡す前に毎回
すべての送付状に、Health Scoreをヘッダー項目として記載しましょう。受け手の分野はファイルを開く前にすぐ状況を把握でき、プロジェクト全体を通じたモデル品質の推移が監査証跡として残ります。カスタムのメタデータ項目に対応したCDEもあり、これは活用する価値のある項目です。
CDEへの納品ゲート
妥協できないチェックポイントです。モデルはアップロード前に、BEPで定めたしきい値を満たしていなければなりません。インフォメーションマネージャーは、検証されていないモデルを手作業でレビューすべきではありません。スコアレポート（タイムスタンプ、ツールのバージョン、スコアを含む）を、送付状の必須の添付資料にしましょう。しきい値に満たないモデルは作成者に差し戻します。スコアがその客観的な理由になります。
- GUIDを維持する設定を有効にして、オーサリングツールからIFCをエクスポートします。
- ブラウザーの検証ツールで開きます。ほとんどのプロジェクトモデルでは、検証は30秒以内に終わります。
- スコアを確認します。その段階のしきい値を下回っていれば、ルール別の内訳を開きます。
- 指摘事項の一覧を重大度順（エラーが先）に並べ替えます。データの警告より先に、スキーマエラーに対処します。
- 自動修正が可能なもの（GUIDの重複、形式エラー）には自動修正を適用します。階層や命名の問題は手作業で修正します。
- 修正した設定（GUIDの維持、正しい階への配置）でオーサリングツールから再エクスポートし、再検証します。
- しきい値を満たしたら、スコアレポートを送付状に添付してCDEにアップロードします。
品質スタックの全体像：スコア → ルール → IDS → BCF → 納品
Health Scoreは、4層からなる品質スタックの1つの層です。各層は異なる問いに答えるもので、互いの代わりにはなりません。このスタックを理解することが、堅牢なBIMのQAワークフローを組み立てるための概念的な土台になります。
┌──────────────────────────────────────────────────────────────────┐
│ IFC Model File │
│ (exported from authoring tool) │
└──────────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ 44 Quality Rules → Health Score (L1 + L2) │
│ Schema · GUIDs · Hierarchy · Names · Psets · ISO 19650 │
│ Question: Is this model well-formed and data-complete? │
│ Output: 0–100 score + prioritised rule-level issue list │
└──────────────────────────┬───────────────────────────────────────┘
│ if score ≥ stage threshold
▼
┌──────────────────────────────────────────────────────────────────┐
│ IDS Validation (L3 — Level 3) │
│ Project-specific EIR/AIR information requirements │
│ Question: Does this model satisfy our contractual spec? │
│ Output: Pass / Fail per IDS spec + element-level evidence │
└──────────────────────────┬───────────────────────────────────────┘
│ on failures found
▼
┌──────────────────────────────────────────────────────────────────┐
│ BCF Issue Report │
│ Structured coordination issues linked to elements │
│ Question: What specifically needs to change, and who owns it? │
│ Output: BCF 2.1 file shared across authoring tools │
└──────────────────────────┬───────────────────────────────────────┘
│ when all layers pass
▼
┌──────────────────────────────────────────────────────────────────┐
│ Formal CDE Delivery │
│ Model + score evidence + IDS report on transmittal │
└──────────────────────────────────────────────────────────────────┘
レイヤー1〜2：Health Score
スキーマの整合性、GUIDの一意性、空間階層、プロパティの充足度、命名、ISO 19650、分類、ジオメトリ、マテリアルにわたる44のルール。これは普遍的な品質の最低ラインであり、プロジェクトの種類に関係なく、すべてのIFCファイルに適用されます。80未満のモデルはこの最低ラインのチェックに不合格で、次の層に進むべきではありません。
レイヤー3：IDS検証
EIRの作成者が機械可読なXMLで記述した、プロジェクト固有の要件です。ファセットは6つあります。Entity（どの要素タイプか）、Attribute（どの属性か）、Property（どのPsetの値か）、Classification、Material、PartOfです。Health Scoreが普遍的であるのに対し、IDSは個別仕様です。プロジェクトごと、分野のパッケージごとに別の仕様になります。
BCFによる課題管理
Health ScoreのルールやIDSのチェックで不合格があると、その指摘事項はBCFトピックになります。要素の参照、ビューポイント、担当者を含む、構造化された調整項目です。BCFは検証スタックで見つかった品質の指摘事項を調整ワークフローへと運び、そこで担当を割り当て、追跡し、解決できるようにします。
CDEへの納品
スタックの終着点です。Health ScoreのゲートとIDSのゲートを通過したモデルには、品質を裏付ける文書上の証拠があります。スコアレポートとIDSの検証結果が、送付状に添付される正式な品質の証拠になります。インフォメーションマネージャーは推測に頼るのではなく、検証できる材料を手にすることになります。
BEPとEIRでのしきい値の設定
契約上の拠り所がないHealth Scoreのしきい値は、ただの願望にすぎません。EIR（Employer Information Requirements：発注者情報要件）は契約文書であり、BEP（BIM Execution Plan：BIM実行計画）はEIRを実行に移すための納品計画です。しきい値は両方に記載すべきですが、強制力を持つのはEIRの記載です。
── EIR clause (contractual, enforceable) ─────────────────────────────────────
5.4 Model Quality — IFC Health Score
All IFC information deliveries shall achieve a minimum Health Score
as specified below, validated prior to upload to the Common Data
Environment. The Health Score shall be calculated using [agreed tool]
with [agreed rule set version]. The validation report (including score,
timestamp, and tool version) shall be attached to the transmittal as
evidence of compliance.
Models that do not meet the applicable threshold shall be returned to
the Originator for remediation. Re-upload shall reset the revision
counter and generate a new transmittal record.
Minimum thresholds by LOD and delivery type:
Internal model review (LOD 100–150): ≥ 70
Cross-discipline coordination (LOD 200): ≥ 75
Detailed design CDE delivery (LOD 300): ≥ 80
Construction issue (LOD 350+): ≥ 85
As-built / FM handover (LOD 400+): ≥ 90
── BEP clause (operational, implementation plan) ─────────────────────────────
3.2 Validation Procedure
Prior to each CDE upload, the Information Originator shall:
1. Export IFC with stable GlobalId settings (see Section 4.1).
2. Run the agreed validation tool against the exported file.
3. Confirm the Health Score meets or exceeds the applicable threshold.
4. Attach the score report (PDF or JSON) to the transmittal record.
IFC Health Scoreにまつわる6つのよくある誤解
誤解1：「高ければ高いほど良い。100を目指すべき」
適切なスコアは、納品段階によってまったく異なります。構想設計なら目標は70以上であって、95以上ではありません。初期段階のボリュームモデルを何時間もかけて95まで引き上げるのは、労力の配分を誤っています。せっかく直した命名も、3週間後に計画が変われば置き換えられてしまいます。段階に見合ったしきい値を定め、それを目標にしましょう。労力は、変更のコストが高くつくLOD 300以降のスコア向上のために取っておくべきです。
誤解2：「100点ならモデルに問題はひとつもない」
100点とは、構造品質とデータ品質に関する44のルールすべてに合格したという意味です。プロパティ値が事実として正しいか、モデルがプロジェクトのEIRを満たしているか、設計意図が正確に表現されているか、形状の干渉があるかどうかについては、何も語りません。すべてのPsetにプレースホルダーの文字列が入ったモデルでも100点になります。スコアが確認するのは構造の健全性であり、内容を保証するものではありません。
誤解3：「Health ScoreはIDS検証の代わりになる」
両者は別々の問いに答えます。Health Scoreの問いは「このファイルは普遍的な品質基準に照らして構造的に正しく、データが揃っているか」。IDSの問いは「このモデルは、このプロジェクトとこの分野パッケージ固有の情報要件を満たしているか」です。EIRで求められるUniclass 2015の分類が欠けていたり、IfcBuildingStoreyの名前がプロジェクトのBEPで合意した階の命名規則に合っていなかったりすれば、95点のモデルでもIDS検証には不合格になります。両方のチェックが常に必要です。両者は重なり合うものではなく、補い合うものです。
誤解4：「スコアを見れば何を直せばいいかわかる」
スコアが示すのは、納品すべきかどうかです。何を直すべきかを示すのは、その下にあるルールレベルの内訳です。指摘事項の内訳なしに68点という数字だけを見るのは、地図もないまま壊れた燃料計を眺めているようなものです。ルールの詳細を開き、重大度順に並べ替え、要素の件数と説明を読み、重大度の高い違反から修正しましょう。次に検証を実行すれば、スコアはすぐに更新されます。スコアと内訳という2つの情報は、常にセットで使います。
誤解5：「Health ScoreがあればBIMコーディネーターのレビューは要らない」
自動検証が捉えるのは、構造的な不備、データの欠落、形式の違反です。設計基準への適合、空間的な成立性、工程との整合性、施工性まではレビューできません。構造的に成立しない転換構造を含むモデルでも、92点なら92点のままです。BIMコーディネーターやインフォメーションマネージャーによる専門的なレビューが、スコアに取って代わられることはありません。スコアはレビューを支えるものです。チェックリスト上のノイズを取り除き、レビュー担当者が本当に重要な点に集中できるようにします。
誤解6：「Revitでエラーなく開けたから、このモデルは問題ない」
ツールでエラーなく開けるというのは、考えうる最低限のハードルにすぎません。IFCパーサーは意図的に寛容に作られていて、読み込めるものは読み込み、読み込めないものは黙って破棄するか補正します。Revit、ArchiCAD、Navisworksで問題なく開けるファイルでも、重複したGUIDが300件（すべての分野でBCFが壊れる）、孤立要素が80件（どの干渉レポートにも現れない）、IfcProject.LongNameがない（ISO 19650のトレーサビリティを満たさない）という状態が同時に起きていて、Health Scoreは41点ということもありえます。「開けた」は品質チェックではありません。
IFC Viewer OnlineにおけるHealth Scoreの実装
IFC Viewer OnlineのHealth Scoreは、44の品質ルールすべてを、どんなIFCファイルに対してもブラウザー内で30秒以内に実行します。何もアップロードされません。実装がカバーする内容は次のとおりです。
44の検証ルール
L1のスキーマ整合性とL2のデータ品質を完全に網羅：GlobalIdの一意性と形式、空間階層、孤立要素の検出、命名の充足度、ISO 19650のメタデータ、プロパティセットの有無、分類、マテリアルの割り当て、ジオメトリの整合性のチェック。
重大度で重み付けしたHealth Score
スキーマエラーの減点は警告の3倍です。対数スケールにより、大きなモデルのスコアが不当に低くなることを防ぎます。同じモデルは実行するたびに同じスコアになるため、再現性があり、監査も可能です。
要素の件数付きのルール別内訳
不合格となった各ルールについて、指摘件数、重大度、影響を受ける要素タイプ、修正方法の説明を表示します。重大度で並べ替えれば、作業の優先順位を付けられます。内訳が対応リストであり、スコアが判断のシグナルです。
GUIDの自動修正
重複したGlobalIdや範囲外のGlobalIdは、ワンクリックで自動修正できます。正しいIFCのBase64アルファベットを使い、先頭の文字が有効な0〜3の範囲に収まる、仕様に準拠した22文字の新しいGUIDが生成されます。
非破壊のプロパティ編集
受け取ったファイルの名前、プロパティ値、分類を、オーサリングツールに戻らずに修正できます。元に戻す／やり直しにも完全対応。変更はGlobalIdをキーとするEditDiff[]として保存され、エクスポート時に適用されます。元のファイルがその場で書き換えられることはありません。
IDS検証とBCFエクスポート
Health Scoreのゲートを通過したら、6つのファセットすべて（Entity、Attribute、Property、Classification、Material、PartOf）でプロジェクト固有のIDS検証を実行します。不合格の項目はBCF 2.1としてエクスポートし、Revit、ArchiCAD、Solibriをはじめ、BCFに対応したあらゆる調整ツールに配布できます。
実際のRevitエクスポートでHealth Scoreを試す
この14MBのオフィスモデルはRevitからエクスポートしたもので、中規模の意匠設計の納品として典型的な例です。開いてみると、Health Score、カテゴリー別のルールの内訳、そして商業プロジェクトの納品前の検証レポートが実際にどのようなものかを確認できます。
IFC4 · 14 MB
インタラクティブなIFCビューアーを開く
トラブルシューティング：スコアが改善しないとき
Revitで修正したのにスコアが変わらない
最もよくある原因は、Revitモデルでは修正したものの、IFCを再エクスポートしていないことです。検証はオーサリングモデルではなく、IFCファイルに対して実行されます。オーサリングモデルを修正したら必ず再エクスポートし、前回修正したのと同じファイルではなく、新しくエクスポートしたIFCを検証してください。
2回のエクスポートの間にスコアが81から47に急落した
改訂の間にスコアが20点以上下がった場合、ほぼ間違いなくエクスポート設定が変わっています。具体的には、GUIDの生成設定が「Keep Existing」から「Generate New」に変わったケースです。これによって数千もの新しいGlobalIdが生まれ、検証ツールはそれを範囲外、あるいは以前のリンクファイルと重複していると判断します。IFCエクスポーターの設定を確認し、GUIDを安定して出力する設定に戻してください。
スコアは76だが、インフォメーションマネージャーは80を求めている
ルール別の内訳を開き、指摘件数ではなく減点への寄与度で並べ替えてください。80まであと4点の差は、ほぼ確実に1〜2のルールに集中しています。減点の大きいルール違反から修正しましょう。多くの場合、空間包含のエラーか、特定の要素タイプでのプロパティセットの欠落です。その2つのルールに対処し、再エクスポートして再検証します。減点の構造が非線形なので、スコアは予想以上に上がるのが普通です。
スコアは95なのにIDS検証に不合格になる
これは想定どおりで、正しい挙動です。Health ScoreとIDSは、別々の層を扱っています。95点とは、モデルが構造的に優れているという意味です。IDSで不合格になるのは、プロジェクト固有の要件（Psetの値、分類コード、マテリアルレイヤーの厚さなど）を満たしていないということです。IDSの不合格レポートを確認してください。該当する要素、期待される値、実際の値が正確に示されています。オーサリングツールで修正するか、受け取ったファイルであれば非破壊のプロパティ編集を使いましょう。
よくある質問
IFCのHealth Scoreとは何ですか？
44の検証ルールに照らして、モデルの構造の整合性とデータの完全性をまとめた、重み付きの0〜100の品質シグナルです。パーセンテージではありません。重大度で重み付けし、対数スケールで調整したスコアで、スキーマエラーはデータの警告より重く扱われ、あるルールの1件目の違反は1000件目よりも大きく減点されます。
どのように計算されますか？
スコアは100から始まります。ルール違反があるたびに、その違反の重大度の重みと指摘件数の対数に基づいて点数が差し引かれます。スキーマエラー（構造的な不備）の減点は、品質に関する警告の3倍です。対数スケールにより、根本的な問題の密度が同じであれば、大きなモデルが小さなモデルより不当に悪く見えることはありません。
BEPではどのHealth Scoreを指定すべきですか？
通常のCDEへの納品と分野間の調整では80以上。ISO 19650の正式なマイルストーン提出とLOD 300以上の納品では90以上。構想段階の社内レビューでは70以上。BEPだけでなく、EIR（契約文書）にも明記してください。法的な強制力を持つ品質ゲートになるのはEIRだけです。
100点のモデルでも品質に問題があることはありますか？
あります。スコアが対象とするのは、構造品質とデータ品質に関する44のルールです。IDSへの適合（プロジェクト固有の要件）、意味上の正しさ（プロパティ値が事実として正確かどうか）、設計意図は対象外です。すべてのプロパティセットにプレースホルダーの値が入ったモデルでも100点になります。スコアが確認するのは構造の健全性であり、内容を保証するものではありません。
Health Scoreが高ければ、IDS検証は省略できますか？
いいえ。両者は別々の問いに答えます。Health Scoreは「このモデルは構造的に正しく、データが揃っているか」。IDSは「このモデルは、このプロジェクト固有の情報要件を満たしているか」。95点なのにIDSチェックに不合格というのは、よくある想定どおりの結果です。IDSの不合格項目を修正してから、両方を再検証しましょう。
すべてのモデルで100を目指すべきですか？
いいえ。段階に見合ったしきい値を設定してください。構想設計の段階で100を追い求めるのは、設計段階に回すべき労力の無駄遣いです。目標は「このモデルは、この納品段階のしきい値を満たしているか」です。プロジェクトの開始時にBEPとEIRでしきい値を定め、理論上の最大値ではなく、そのしきい値に照らして検証しましょう。
まとめ
Revitでエラーなく開けたモデルは、品質チェック済みのモデルではありません。たまたまパースできただけの、未チェックのモデルです。その2つを分けるのがHealth Scoreであり、手元のモデルがどちらなのかは30秒でわかります。
IFC Viewer Blog
数値の意味を理解する
Health Scoreは、重大度で重み付けし、対数スケールで調整した判断のシグナルです。80以上ならCDEに提出可能。60未満なら構造的な問題があります。パーセンテージではなく、品質の判定です。
契約に組み込む
段階に見合ったしきい値は、EIR（契約）とBEP（運用）に記載します。EIRに条項がなければ、しきい値に強制力はありません。最初の納品より前、プロジェクトの開始時に盛り込みましょう。
日常のリズムに組み込む
設計段階では毎週検証。調整会議の前には事前チェック。CDEへのアップロード前にはゲートチェック。すべての送付状にスコアレポートを添付します。スコアを納品日に慌てる原因ではなく、プロジェクトの習慣にしましょう。
スタック全体を使う
Health Score → IDS → BCF → 納品。各層は異なる問いに答えます。スコアが床なら、IDSは天井です。両方を使い、不合格の項目はBCFにエクスポートして、調整ワークフローの中で追跡・解決できるようにしましょう。
44のルールが3つの検証レベルにどう整理されているかの技術的な解説は、IFCモデルチェッカーの完全ガイドをご覧ください。ブラウザーかクラウドかというアーキテクチャーの問題、つまり機密性の高いプロジェクトデータにはどんなときにローカル処理が適しているのかについては、ブラウザーベースとクラウドのIFC検証の比較で取り上げています。受け取ったIFCファイルのプロパティ値、GUID、命名を検証前に修正する必要がある場合は、無料のオンラインIFCエディターのガイドで、オーサリングツールを往復せずに非破壊で編集する方法を解説しています。スコアを70未満に押し下げる代表的な構造的不備については、IFC検証でよくある7つのエラーをご覧ください。
IFC Health Score決定版ガイド：BIMコーディネーター・BIMマネージャー向け
