buildingSMART規格群③ bSDD -表記揺れをなくすBIMのための世界共通辞書

buildingSMART規格群の第3の柱であるbSDD(buildingSMART Data Dictionary)について解説します。
BCFが「コミュニケーション(課題・会話)」、IDSが「データ検証(ルールチェック)」だったのに対し、bSDDは「言葉と意味の定義(辞書・辞書サーバー)」を担うインフラです。
一言でいうとbSDDとは?
bSDD(buildingSMART Data Dictionary)とは、「建設業界で使われるあらゆる専門用語・分類体系・属性の定義を、オンライン上で一元管理・検索できるWebベースの『国際オープン単語帳(辞書データベース)』」です。
モデルデータそのものを保持する場所ではなく、「この言葉(属性や分類)はどういう意味で、どんな単位や選択肢を持つのか」というデータ構造の意味(セマンティック)を管理しています。
なぜbSDDが必要なのか?(従来の問題点)
BCFやIDSがあっても、「言葉の揺らぎや定義の違い」があるとデータ連携は破綻します。
「表記揺れ」によってコンピューターが同一部材と認識できない
- 設計者A:「コンクリート」
- 設計者B:「RC」
- 設備担当C:「Concrete」
人間が見れば同じものを指していると分かりますが、コンピューターやAI、積算ソフトから見ればこれらはすべて「全く別のデータ」として認識されてしまい、自動集計や検索ができません。
国や標準分類(Uniclass / OmniClass / CCI等)ごとの壁
国や地域、発注機関によって使われている分類体系(Uniclass、OmniClass、NL-SfB、日本独自の分類など)が異なります。異なる国や企業間でデータを共有する際、一から手作業で対応表(マッピング)を作る必要があり、莫大なコストがかかっていました。
言語の壁(多言語対応の限界)
日本語の「耐火等級」と英語の「Fire Rating」が同じ概念であることを、BIMソフト側が認識できないと、グローバルなプロジェクトや多国籍なチームでの情報共有が滞ります。
bSDDで解決できること・仕組み
bSDDは、オンラインのAPI(bSDD Search API)を通じてBIMソフトと直接つながり、言葉の意味を共通化します。
① 「URI(一意のWeb識別子)」による概念の固定
bSDDに登録された単語には、それぞれ固有のWebアドレス(URI)が付与されます。
- 例:「ドア(Door)」という概念に対して固有のURIを割り当て、そこに日本語「ドア」、英語「Door」、フランス語「Porte」などの訳語を紐付けます。
- これにより、BIMデータ内には名前だけでなく「URI」が記録されるため、言語や文字表記が違っても「同じ概念を指している」ことがコンピューターに100%伝わります。
② 各国の分類体系やメーカーカタログの「相互マッピング」
bSDDの中には、UniclassやOmniClassといった標準分類体系だけでなく、建築材料メーカーの製品データ(ETIMやCoClassなど)も登録されています。bSDDを経由することで、「このUniclassコードは、OmniClassで言えばこれ」という対応関係が自動的に参照可能になります。
③ BIMソフトの入力補完(ドロップダウン化)
設計者がRevitやArchicadで属性を入力する際、bSDDからAPI経由で用語候補を取得することで、「手入力によるタイポ(打ち間違い)」を未然に防ぎ、選択肢から選ぶだけで正しい表記とURIが自動入力されます。
buildingSMART「3大規格」の連携フロー(完成形)
BCF、IDS、bSDDの3つが揃うことで、openBIMのデータ連携は完全に完結します。
- bSDD で「正しい用語と定義」を定義・検索
- IDS で「その用語がモデルに正しく入っているか」をルール検証
- BCF で「不合格箇所の修正やり取り」をチャット感覚で解決
セマンティックWeb(意味論)とBIM:なぜ「URI」で概念を固定するのか?
bSDDの核心にある技術的思想が、Web技術の進化系である「セマンティックWeb(Semantic Web)」の考え方です。
従来のBIMデータは、属性名や分類を「単なるテキスト文字列」として記憶していました。しかし、文字だけでデータを管理しようとすると、先述した「コンクリート」「RC」「Concrete」といった表記揺れを原理的に防ぐことができません。コンピューターにとっては、文字列が1文字でも違えば「全く異なる不完全なデータ」として判断されてしまうからです。
文字列(String)からURI(Web固有識別子)へのパラダイムシフト
bSDDはこの問題を解決するため、登録されているすべての「クラス(分類)」「プロパティ(属性)」「選択肢の値」に対して、インターネット上で一意に特定できるURI(Uniform Resource Identifier)という固有のWebアドレスを割り当てます。
Plaintext
【文字列管理(従来)】
・「コンクリート」 ← 人間にはわかるが、英語圏やAPI連携で破綻
【URIによる管理(bSDD)】
・https://identifier.buildingsmart.org/uri/.../class/concrete
└─ この固有のWebアドレス(URI)に対し、
日本語: 「コンクリート」
英語: 「Concrete」
オランダ語: 「Beton」
許容されるデータ型: テキスト、数値(密度等)
などのあらゆる定義情報をWeb上で紐付ける
このように、BIMモデルの内部には「文字」だけでなく「bSDDのURI」が埋め込まれます。
これにより、BIMソフトの表示言語が日本語であれ英語であれ、あるいは多国籍なチームが開発した積算システムや維持管理プラットフォームであれ、データを受け取るシステム側はURIを参照することで「この部材は間違いなく1時間耐火のコンクリート構造体である」と100%正確に解釈(理解)できるようになります。これこそが「セマンティック(意味論的)データ」の真価です。
多国籍・異種分類をつなぐ「相互マッピング(データ翻訳)」の仕組み
建設業界には、国や地域、または分野ごとに様々な標準分類体系が存在します。
- Uniclass(イギリス): 官民で広く普及している高度な分類体系
- OmniClass(北米): 北米を中心に普及している建設分類
- NL-SfB(オランダなど): ヨーロッパの伝統的な分類手法
- 日本独自の分類体系(公共建築工事標準仕様等): 国内の実務で使われる分類
従来、海外の設計事務所と連携したり、グローバル展開する企業の工場・オフィスを建設したりする際、これらの異なる分類体系を一致させる作業は手作業(Excelによる突合)で行われており、莫大な時間とヒューマンエラーの原因となっていました。
bSDDが「ハブ」となって自動翻訳する
bSDDは単一の辞書ではなく、あらゆる辞書や分類体系を登録し、それら同士の関係性(マッピング)を記憶できる「マルチディクショナリー・ハブ」として設計されています。
bSDD内部では、「Uniclassのこのコード」=「OmniClassのこのコード」=「IFCのこのエンティティ」という対応関係がグラフデータベースとして構築されています。そのため、BIMソフト側でいずれか一つの分類を選択・付与するだけで、bSDDのAPIを経由して他の分類体系コードやIFC属性へと自動で変換・補完が行われます。
さらに、建材メーカーや設備機器メーカーが自社製品のカタログデータ(ETIMやCoClass対応データ等)をbSDDに登録しておけば、設計者はBIMソフトから直接メーカーの標準化された属性データを一発でモデルに読み込むことが可能になります。
実務での活用手順:BIM設計者はどう使うのか?
「高度なデータベース構造やURIの話はわかったけれど、日々の設計実務で設計者が複雑なWeb操作をする必要があるのか?」と不安に思うかもしれません。
答えは「NO」です。現場の設計者がプログラミングやWeb検索をする必要はありません。
直感的なBIMプラグインによる運用フロー
現在、Revit、Archicad、BIMcollab ZOOM、Bonsaiなどの主要なBIMツールやビューアには、「bSDD Connector(プラグイン)」が組み込まれつつあります。
- 検索と選択: 設計者はBIMソフト内のパネルから「bSDD検索」を開き、キーワード(例:「ドア」や「耐火壁」)を入力。
- 属性の自動補完: bSDDから最新の定義がリアルタイムで呼び出され、必要なプロパティセットや入力選択肢(ドロップダウンリスト)が画面に提示される。
- 誤入力ゼロの属性付与: ドロップダウンから選んで適用を押すだけで、正しい属性名・正しい値・および国際標準のURIがBIMオブジェクトへ一括付与される。
手入力によるタイポ(打ち間違い)や、プロジェクトごとに勝手なプロパティ名を作ってしまう問題が根本からシャットアウトされ、誰が作っても国際規格に完全準拠した高品質なBIMデータが自然に仕上がる仕組みが提供されます。
buildingSMART「3大規格」が織りなすオープンBIMの完全体
ここまで3回にわたり、buildingSMARTが誇る主要規格を解説してきました。ここで今一度、これら3つの規格がどのように組み合わさり、一つの巨大な「オープンBIMエコシステム」を形成しているのかを整理してみましょう。
bSDD(Data Dictionary)
役割:データの「意味(セマンティック)」を定義する共通辞書。
「耐火等級(FireRating)」という属性の意味と選択肢を定義し、URIを付与して多言語・表記揺れを防止。
IDS(Information Delivery Specification):
役割:データの「品質(納品要件)」を自動チェックする検査官。
「外壁オブジェクトには、bSDDで定義された FireRating 属性を必ず入力して納品すること」と指示。
BCF(BIM Collaboration Format):
役割:データに関わる「人間同士の対話」を軽量化する対話プロトコル。
「IDS検査で FireRating 未入力の壁が3箇所見つかりました」と軽量データで設計者へ送信し、3D画面へ即ジャンプして修正。
どれか一つが欠けても、真のデータ連携は成り立ちません。
「正しい言葉で定義し(bSDD)」、「ルール通りに入っているか自動で検証し(IDS)」、「不備があれば即座にチャット感覚で修正する(BCF)」。この3本柱が連携することで、建設業界は初めて「ソフトウェアの壁を超えた、真のデータの流動性(Interoperability)」を手に入れることができるのです。
まとめ:AIとデジタルツインの時代に向けた「言葉のインフラ」
シリーズ第3弾として解説した「bSDD(buildingSMART Data Dictionary)」は、一見すると地味な「辞書データベース」に思えるかもしれません。しかしその実態は、今後のBIM活用を左右する最も重要な「言葉のインフラ」です。
- 「コンクリート」や「RC」といった表記揺れを排し、コンピューターが正しく意味を理解できるセマンティックデータへ変換する
- URIによって概念を世界共通化し、多言語・異種分類体系のマッピングを自動化する
- BIMソフトのプラグインを介することで、現場の設計者は知識ゼロでも正しい属性入力が可能になる
- BCF(対話)× IDS(ルール)× bSDD(辞書)の3大規格が揃うことで、openBIMの自動化運用が完結する
今後、建設業界でも生成AIによる自動設計や、BIMとIoT・FM(施設管理)システムを連携させたリアルタイムなデジタルツインの構築が急速に進んでいきます。
その時、AIや外部システムが最も必要とするのが「一貫性があり、意味が厳密に定義された高品質な構造化データ」です。bSDDという世界共通の単語帳を活用し、今日からモデルのデータ品質を「意味のレベル」から整えてみてはいかがでしょうか。
全3回にわたってお届けした「buildingSMART規格群」の解説はいかがでしたでしょうか。
- BCFによる軽量な課題管理
- IDSによる属性データの自動チェック
- bSDDによる標準化されたデータ辞書
特定のベンダーツールに縛られることなく、自由で拡張性の高いデジタル建設プロセスを実現するために、openBIMの最新規格をぜひ皆様のプロジェクトや社内標準化にお役立てください!
関連記事

buildingSMART規格群② IDS - BIMの「属性チェック」を自動化する品質管理ルール
IDS(Information Delivery Specification)は、BIMモデルに必要な属性要件を機械可読なルールとして定義し、自動検証するbuildingSMARTのopenBIM規格です。本記事では、ApplicabilityとRequirementsの仕組み、EIR・MVDとの違い、BCF連携、対応ツール、実務導入まで体系的に解説します。

buildingSMART規格群① BCF - 重いデータと別れを告げる課題管理のオープン標準
BCF(BIM Collaboration Format)は、BIMモデル本体を送らず、指摘・質問・修正依頼を軽量に共有するopenBIM標準です。本記事では、BCFの仕組み、GUIDやビューポイント、BCF 3.0、BCF API、BIMcollabなどの対応ツール、ファイル交換とクラウド同期の運用方法まで体系的に解説します。

IFC5という革命
IFC5(NEXT)は、従来の巨大な単一IFCファイル中心の運用から、Webネイティブでモジュール化されたOpenBIMへ進化する次世代構想です。本記事では、ECS、JSON-LD、OpenUSD、glTF、差分更新、パラメトリック表現、Web API、実用化までのロードマップを整理します。
