buildingSMART規格群② IDS - BIMの「属性チェック」を自動化する品質管理ルール

buildingSMART規格群の第2の核であるIDS（Information Delivery Specification：情報納品仕様書）について解説します。

BCFが「BIMのコミュニケーション（課題・会話）を効率化する規格」だったのに対し、IDSは「BIMデータの品質チェック（属性情報が必要通りに入っているか）を自動化・標準化する規格」です。

一言でいうとIDSとは？

IDSとは、「発注者やBIMマネージャーが要求するデータ要件（どの部材に、どんな属性・型番・性能値を入力してほしいか）を、人間にもコンピューターにも理解できるXMLルールとして定義する共通規格」です。

これを使うことで、納品された巨大なIFCデータ（BIMモデル）の中に、「必要な情報が不足なく入っているか」をボタン一つで自動検証できるようになります。

なぜIDSが必要なのか？（従来の問題点）

BCFの時と同様に、IDSがない従来のBIM現場では、以下のような過酷な「データ検査の非効率」が発生していました。

PDFやExcelの「発注者要件書（EIR）」は誰も読まない・守れない

発注者が「この属性を入力して納品してください」と数百ページのPDF（EIR：発注者情報要件）を配っても、設計者や施工者は見落とします。結果、納品段階になって属性の未入力や表記揺れ（例：「RC」と「鉄筋コンクリート」の混在）が大発生します。

目視・手作業によるモデル検査の限界

BIMモデル内の何千・何万という部材に対し、「すべてのドアに耐火等級（FireRating）が入っているか？」「すべてのエアコンにメーカー名と型番が入っているか？」を目視でチェックするのは物理的に不可能です。

従来のMVD（Model View Definition）が難しすぎた

IDSが登場する前は「MVD」という仕組みでデータ要件を定義しようとしていましたが、仕様が複雑で巨大すぎたため、現場で気軽に使いこなせるものではありませんでした。その反省から「シンプルで誰もが使える属性要件定義」として開発されたのがIDSです。

IDSの仕組み：どうやってチェックするのか？

IDSは「If (条件) -> Then (要求)」という単純明快なロジックで書かれます。

• 条件（Applicability）： 「もし対象の部材が『壁（IfcWall）』であり、用途が『外壁』なら…」
• 要求（Requirements）： 「その壁には『耐火等級（FireRating）』属性が必ず存在し、値は『1時間耐火』などの文字列が入っていなければならない」

このルールを .ids という拡張子のXMLファイルとして保存し、検証ソフト（Solibri、BIMcollab ZOOM、Bonsaiなど）に読み込ませます。すると、ソフトがIFCモデルを自動スキャンし、「要求を満たしていない部材」を赤くハイライトして即座に検出してくれます。

IDSとBCFの「決定的な連携（黄金パターン）」

IDSと第1回で解説したBCFは、セットで使うことで真価を発揮します。

1. IDSで自動検証： 納品されたIFCモデルをIDSルールで自動チェック。
2. エラーの抽出： 「属性が入っていないドア」が50箇所見つかる。
3. BCFとして書き出し： エラー結果をワンクリックで「BCF課題」に変換。
4. 設計者へ修正依頼： BCFを受け取った設計者は、自分のBIMソフトでエラー箇所へジャンプし、属性を正しく入力。

この一連のフローにより、「データ検証」から「修正依頼・解決」までが完全に自動化・標準化されます。

3Dグラフィックから真のBIM（データベース）への脱却

IDSがなぜこれほど注目を集めているのか。その本質を理解するためには、建設業界が直面している「BIMの本質的な課題」に目を向ける必要があります。

BIM（Building Information Modeling）という言葉には「Information（情報）」が含まれています。しかし、現実の現場で流通しているモデルの多くは、見た目こそ精巧な3Dモデル（CGグラフィック）であっても、中身の属性データがスカスカであるケースが少なくありません。

属性データが欠落した「ハリボテBIM」のリスク

例えば、画面上ではリアルに描かれたドアが存在していても、そのドアのオブジェクトに以下のような属性データが入っていなかったらどうなるでしょうか？

耐火等級（Fire Rating）
防火区画の検証がBIM上で自動計算できない

音響性能（Acoustic Rating）
遮音計画の確認のために結局2D図面や仕様書を開くハメになる

メーカー・型番・仕上げ
積算（数量拾い）や維持管理（FM）システムへの連携が途切れる

このように、見た目だけが立体で属性情報が入っていないBIMは、後工程で何倍もの手戻りを生み出します。設計段階では3D形状の干渉チェック程度にしか使えず、施工・維持管理フェーズへデータを引き継ぐことができません。

IDSは、BIMを単なる「3Dの絵」から「信頼できる検索可能なデータベース」へと引き上げるための、厳格な品質管理ルール（データチェック警察）として機能するのです。

IDSの内部構造：人間にもコンピューターにも優しい記述ルール

IDSの技術的な美しさは、「人間が自然言語で理解できるルール」と「コンピューターが自動処理できるXML構造」が完全に1対1で対応している点にあります。

IDSファイル（.ids）の内部は、大きく分けて以下の2つの要素で構成されています。

① 適用条件（Applicability：もし〜ならば）

「どの部材をチェック対象にするか？」
モデル全体から、検証したい特定オブジェクトを絞り込む条件です。

• IFCエンティティの種類： IfcWall（壁）、IfcDoor（ドア）、IfcPipeSegment（配管）など
• 特定の属性値： 「用途属性が『外壁』であるもの」「特定分類コードが付与されているもの」など

② 要求事項（Requirements：〜でなければならない）

「その部材にどんな属性・データが入っているべきか？」
条件に該当した部材に対して、存在すべき属性や数値を強制するルールです。

• 存在チェック（Presence）： 指定したプロパティセット（Property Set）や属性名が「存在する」こと
• 値の制限（Values）： 属性に入力される値の制限。例えば「文字列のみ」「数値の範囲（厚みが100mm以上）」「指定したリスト（例：A種, B種, C種）からの選択」など
• データ型の指定： テキスト型、数値型、Boolean型（True/False）などの整合性

このシンプルな「If -> Then」の条件付けを組み合わせることで、「施工フェーズで積算に必要な属性」「納品時にビル管理システムが必要とする仕様データ」など、用途に応じた検査パッケージを簡単に作成できます。

MVD（従来手法）との違い：なぜIDSが革命的なのか？

BIMに詳しい方であれば、「属性の標準化や検証なら、昔からMVD（Model View Definition）という仕組みがあったのでは？」と思われるかもしれません。

確かにMVDもbuildingSMARTが定めた規格ですが、MVDとIDSでは「アプローチの目的」と「運用の手軽さ」が根底から異なります。

簡単に言えば、MVDは「BIMソフト同士がIFCを正しくやり取りするための巨大な通信プロトコル（インフラ）」であり、IDSは「現場のプロジェクトごとに『この属性を入れてね』と指示するための軽快なチェックシート」です。

この役割分担が明確になったことで、プログラミング知識を持たないBIMマネージャーであっても、自社のBIM運用要件を簡単にデジタルルール化できるようになりました。

現場にIDSを導入するための3ステップ

「IDSが便利なのは分かったけれど、実際にどうやって作成・運用すればいいのか？」

自前でXMLコードを書く必要はありません。現在では直感的なツールやクラウド環境が整い始めています。

ステップ1：EIR（発注者情報要件）の整理

まずはデジタル化する前の「人間側の要求」を整理します。「どの設計段階で、どの部材に、何の属性が必要か」をExcelなどでリストアップします。

• 例：「基本設計完了時には、すべての構造柱にコンクリート強度（fc値）が入力されていること」

ステップ2：IDS Editorでルールファイル（.ids）を作成する

整理した要件をIDSファイルに変換します。現在はWebブラウザ上で動作する無料の「IDS Editor」や、buildingSMART公式の作成ツールが用意されています。

画面上で「対象部材（例：IfcColumn）」を選び、「必須属性（例：Pset_ColumnCommon.Reference）」を追加して保存ボタンを押すだけで、専門知識がなくてもルールファイル（.ids）が自動生成されます。

ステップ3：モデル検証ソフト（Checker）で自動判定を実行する

作成した .ids ファイルと、設計者から提出された .ifc ファイルを検証ツールに読み込ませます。

• 対応している主な検証ツール：
  • Solibri: 最高峰のモデル検証ソフト。IDSルールを読み込んで一括チェック可能。
  • BIMcollab ZOOM: 軽快な動作で人気のBIMビューア/チェッカー。IDS検証に完全対応。
  • Bonsai（旧BlenderBIM）: オープンソース環境でもIDSの作成・検証機能がネイティブ実装されている。
  • That Open Company（Webコンポーネント）: ブラウザ上でIDS検証を完結させる自作Webアプリの構築が可能。

検証ボタンを押せば、わずか数秒〜数分で「合格」「不合格（未入力・入力エラー）」が色分けされて一覧表示されます。不合格の項目は、第1回で紹介したBCF形式で即座に書き出し、設計担当者へ修正タスクとして自動割り振りします。

IDSがもたらす「openBIMエコシステム」の未来

IDS（データ検証）とBCF（課題管理）、そして次回解説するbSDD（データ辞書）が揃うことで、openBIMはこれまでの「絵に描いた餅」から「実務で強烈な業務効率化を生み出すインフラ」へと進化を遂げました。

IDSの普及によって、今後BIMの現場では以下のような不可逆な変化が起こっていきます。

手作業による納品検査の「完全自動化」

これまで納品期限の直前にBIMマネージャーが徹夜で行っていた「属性の目視チェック」や「Excelとの照合業務」は過去のものになります。ボタン一つで何万もの部材属性が自動判定され、エラーのないデータだけが次のフェーズ（施工や維持管理）へ流れるようになります。

「AI×BIM」時代の高品質なトレーニングデータ確保

今後、生成AIやLLMをBIMデータと連携させる試みが加速します。しかし、元となるBIMデータの属性が不統一であれば、AIは正しく構造を理解できません。IDSによって厳格に標準化された高品質なBIMデータ（構造化データ）があって初めて、AIによる自動積算や高度なエネルギーシミュレーションが実現します。

発注者（施主）のBIM活用ハードルの劇的な低下

「BIMで納品されたけれど、データがバラバラで活用できない」と悩んでいた発注者は、あらかじめ自社の運用ルールをIDSとして定型化し、受注者に配布するだけで済みます。これにより、発注側のBIM活用能力やITリテラシーに関わらず、常に一定水準以上の高品質なデジタルツイン（FMデータ）が入手できるようになります。

まとめ：データ品質を制する者がBIMを制する

buildingSMART規格群の第2弾として解説した「IDS（Information Delivery Specification）」は、BIMにおける「Information（情報）」の価値を決定づける極めて重要な規格です。

• BIMを単なる3Dモデルではなく「信頼できるデータベース」に変える
• 人間が読める要件定義（EIR）と、コンピューターが処理できる自動検証（XML）を直結する
• IDSでエラーを自動検出し、BCFで修正依頼を回す「黄金の自動化フロー」を構築できる
• 専門知識がなくても、無料のIDS Editor等を使って明日から実務に導入可能

「納品されたモデルの属性がぐちゃぐちゃで困っている」「BIMモデルを施工や維持管理で本格活用したいけれどデータ品質が担保できない」とお悩みの方は、ぜひIDSを使った「自動データ検証」の仕組みをプロジェクトに取り入れてみてください。

IDSによって「どの属性を入力すべきか」を定義・検証できるようになりました。しかし、ここで新たな問題が浮上します。「そもそも『耐火等級』や『コンクリート』という用語の定義や表記揺れはどう統一すればいいのか？」

次回は、buildingSMART規格群の第3弾として、グローバルな用語定義とセマンティック（意味論）データを繋ぐ超重要データベース「bSDD（buildingSMART Data Dictionary）」について詳しく解説します。どうぞお楽しみに！