IDS(情報要求仕様)とは — BIM に必要な情報を機械可読で指定・検証する

「納品されたモデルに、必要な情報がちゃんと入っているか?」——耐火性能、分類コード、数量、外部/内部の別。従来はこうした要求を文章(BEP など)で書き、受け取ったモデルを人の目で確認していました。それを機械が読める形で指定し、自動でチェックできるようにするのが **IDS(Information Delivery Specification、情報要求仕様)**です。

IDS とは

IDS は、buildingSMART が定める情報要求のためのオープンな仕様です。要点は「人間の言葉ではなく、ツールが解釈できる形で情報要求を書く」こと。たとえば「すべての外壁は耐火性能(FireRating)を持たねばならない」という要求を、機械可読に記述します。

すると、IDS とモデル(IFC)をツールに渡すだけで、「どの要素が要求を満たし、どれが満たさないか」を自動で判定できます。要求と検証が同じ 1 つの仕様に基づくので、「言った/言わない」「基準が人によって違う」といったブレがなくなります。

IDS の構成 — 「適用対象」と「要求」

IDS はいくつかの**仕様(specification)**の集まりで、各仕様は 2 つの部分からできています。

つまり「〈外壁〉は〈耐火性能〉を持たねばならない」のように、対象と要求をセットで書きます。要求として指定できるのは、プロパティ(Pset)・分類・材料・属性・部分-全体の関係など、モデルに含めるべき情報の種類です。

なぜ IDS か — 文章の要求から機械可読へ

これまで情報要求は、BEP(BIM 実行計画)や EIR(発注者情報要求)といった文書に文章で書かれてきました。文書は人が読む前提なので、①解釈がぶれる ②手作業でしか確認できない ③抜けに気づきにくい、という弱点があります。

IDS の狙いは、要求そのものを実行可能にすることです。要求を書いた時点で、それがそのまま検査ルールになる。人の目視に頼らないぶん、大規模なモデルでも漏れなく・素早く・同じ基準で確認できます。

Pset・分類・モデルチェックとの関係

IDS は単独で使うものではなく、これまでの記事で扱った仕組みの上に乗るものです。

• プロパティセット(Pset)・分類: IDS が「持つべき」と要求する情報の実体。標準 Pset や分類が整っているほど、IDS の要求は素直に書ける・満たせる。
• モデルチェック: IDS は「情報が揃っているか」の検証ルールを与える。幾何的な干渉チェックとは別の軸(情報の充足)で、両輪でモデルの品質を担保する。
• 数量(QTO): 数量やそのもとになる属性が要求どおり入っているかも、IDS で確認できる。

実務での位置づけ

IDS は比較的新しい標準で、対応ツールも広がりつつある段階です。実務では、発注者や BIM マネージャがプロジェクトの情報要求を IDS として定義し、各社が納品前に自分でモデルを照合する、という使い方が想定されます。これにより、「納品してから情報不足が発覚する」手戻りを前段で防げます。

文書としての BEP/EIR が消えるわけではありません。なぜその情報が要るか・どう使うかは文書で、機械が確認できる部分は IDS で——という役割分担で、要求の伝達と検証を両立させるのが狙いです。

まとめ

• IDS は、モデルに必要な情報を機械可読で指定する buildingSMART の標準。
• 各仕様は「適用対象(どの要素)」+「要求(何を持つべきか)」で構成される。
• 文章の要求と違い、そのまま自動チェックのルールになる(目視に頼らない)。
• Pset・分類が情報を入れる土台、IDS がその充足を定義・検証する層。モデルチェックの情報側の担い手。

「形はあるが情報が足りない」モデルは、下流(数量・検証・維持管理)で必ず詰まります。IDS は、その情報の過不足を要求の時点で実行可能にするアプローチです。全体像はIFC とはにまとめています。