オープンBIMの司令塔 buildingSMART の全貌 - 誕生の歴史からAutodeskとの関係、次世代規格IFC5の未来まで

建築・建設業界のDXやデジタルツインを語る上で避けて通れない国際非営利団体、それが buildingSMART International（bSI） です。

「IFC（Industry Foundation Classes）」の策定団体として広く知られていますが、その真の役割は単なるファイルフォーマットの管理にとどまりません。特定のソフトウェアベンダーに依存しない「データ主権」を確立し、建設業界全体の相互運用性を支える情報インフラの国際標準化機関です。

本記事では、buildingSMARTがなぜ生まれ、どのように成長してきたのかという泥臭い歴史から、巨大ベンダーとの表と裏の攻防、国交省の「BIM/CIM」との関係、都市レベルへの領域拡張、そして現在進行形で進む「IFC5」やWeb API時代への技術ロードマップ、さらには開発者が知っておくべきオープンソースエコシステムまでを徹底解説します。

誕生の歴史：1994年「IAI」の創設からグローバル標準化への歩み

buildingSMARTの歴史は、PC上で3D CADが本格的に普及し始めた1990年代初頭から、インフラまでを飲み込む現代のデジタルトランスフォーメーションに至るまで、大きく5つの転換期を経て成長してきました。

 1994年 ── Autodesk等12社により「IAI」発足 (STEP/EXPRESSベース)
   │
 1997年 ── 建築モデルの第一歩「IFC 1.0」リリース (オブジェクト指向化)
   │
 2005年 ── 「buildingSMART International」へ改称 (openBIM宣言)
   │
 2013年 ── 「IFC4」リリースと ISO 16739 としての国際標準規格化
   │
 2024年 ── 「IFC4.3」（土木・インフラ拡張）の普及と「IFC5」への移行開始

12の企業が立ち上がった「IAI」創設（1994年）

1990年代初頭、CADソフトごとに独自のデータ形式が乱立し、設計事務所・施工会社・設備業者など企業間でのデータ受け渡し時に、幾何形状の歪みや属性データの欠落が多発していました（インターオペラビリティの欠如）。

この深刻な業界課題を解決するため、1994年にAutodeskを中心として、AT&T（通信）、HOK（大手設計事務所）、Carrier（空調設備メーカー）など、建築・設備・IT分野を代表する12の主要企業・団体が結集し、IAI（International Alliance for Interoperability） を設立しました。これがbuildingSMARTの前身です。

IAIは、当時すでに製造業（航空・自動車）向けデータ交換規格として実績のあった STEP（ISO 10303） およびそのデータ記述言語 EXPRESS を技術的土台として採用し、建築オブジェクトの共通データモデルである IFC（Industry Foundation Classes） の開発へと乗り出しました。

建築共通フォーマットの産声を上げた「IFC 1.0」（1997年）

IAI発足から3年間の集中開発を経て、1997年に最初の成果物である IFC 1.0 が正式リリースされました。

それまでのDXF/DWGやIGESといった「線や面の集合体（2D/3D図形）」でしかなかったデータに対し、IFC 1.0は「壁（IfcWall）」「柱（IfcColumn）」「ドア（IfcDoor）」という建築的意味（セマンティクス）と属性を持つオブジェクト指向モデルを提示しました。

翌1998年のIFC 1.5、1999年のIFC 2.0へのアップデートを経て、CADベンダー各社がIFC入出力機能を搭載し始め、異種CAD間での3Dデータ受け渡しの実用化が一歩前進しました。

buildingSMARTへの改称とオープンBIM宣言（2005年）

2005年、団体名をIAIから現在の buildingSMART International（bSI） へと変更しました。

単に「CADデータを取り持つ技術同盟」という狭い位置づけから脱却し、「建物の企画・設計・施工・維持管理にわたる全ライフサイクルで、特定のベンダーに依存しないオープンな情報管理標準（openBIM）を主導する国際規格機関」へと自らのミッションを再定義した画期的な転換点です。

この時期から北欧、英国、ドイツなど欧州各国でナショナル支部が相次いで発足し、民間主導の技術団体から、国主導のBIM標準化を担うグローバル組織へと急速に変化していきました。

IFC4リリースとISO 16739国際標準化（2013年）

2013年、長年主流であった「IFC2x3」の後継として IFC4（ISO 16739:2013） がリリースされ、国際標準化機構（ISO）によって正式に国際標準規格として認定されました。

IFC4では、幾何形状の表現精度が向上しただけでなく、環境性能（IfcMaterialDefinition）、施工管理、ファシリティマネジメント（FM）に必要な属性構造が強化されました。

このISO化により、英国政府の「2016年までのBIMレベル2義務化方針（BIM Mandate）」をはじめ、欧州各国の公共調達仕様書において「ISO 16739（IFC）に基づくオープンBIMでのデータ納品」が要件化される強固な法的・政令的根拠が完成しました。

インフラ拡張IFC4.3とIFC5への移行（2024年〜）

2024年、ISOは道路・鉄道・橋梁・港湾・水路・地盤データを完全統合した IFC4.3（ISO 16739-1:2024） を承認しました。これにより、建築（BIM）と土木（InfraBIM/CIM）の境界が消滅し、都市インフラ全体を単一のオープンフォーマットで管理する時代が到来しました。

そして現在、buildingSMARTは1994年の創設以来使い続けてきた30年前の「STEP形式（単一の巨大テキストファイル）」を脱ぎ捨て、Web/Cloud技術・JSON・USD・APIと完全親和する次世代規格 IFC5 へのフルモデルチェンジへと歩みを進めています。

buildingSMARTの存在意義と「5つのコアソリューション」

buildingSMARTは「IFCという単一のファイルフォーマットを作る団体」と誤解されがちですが、実際にはオープンBIMエコシステムを成立させるための5つの要素（ソリューション）を連携して提供しています。

IFC (Industry Foundation Classes / ISO 16739)

• 概要: 柱、壁、ドア、設備機器、ジオメトリ（形状）、空間関係（位相）を階層構造で表現するオブジェクト指向データモデルの国際標準規格。
• 特徴: 従来の建築分野（IFC2x3, IFC4）に加え、最新の IFC4.3 では道路、鉄道、橋梁、港湾などの土木インフラ領域へとカバー範囲が大幅に拡張されています。

bSDD (buildingSMART Data Dictionary)

• 概要: 各国の国別規格（例：日本のBIM標準仕様、欧州のUniclass/OmniClassなど）や企業固有のプロパティ定義を、グローバルなセマンティクス（意味論）とマッピングするWeb辞書サービス/API。
• 特徴: 異なる言語や独自の命名規則を使っているプロパティ同士でも、bSDDのURIを介すことで「同一の意味を持つデータ」として自動識別・変換が可能になります。

BCF (BIM Collaboration Format)

• 概要: 数GBにも及ぶ重いBIMモデル全体を再送信することなく、「どの位置にどんな干渉や不具合があるか」という指摘事項（Issue）のみをやり取りするオープン規格。
• 特徴: XML/JSONベースのメッセージ通信およびRESTful API（BCF API）で構成されており、Solibri、Navisworks、Revit、Archicadなどの異種ツール間でリアルタイムにイシューを同期できます。

IDS (Information Delivery Specification)

• 概要: 発注者やプロジェクト管理者が求める情報要件（EIR/AIR）を、コンピューターが解釈・自動検証可能な形式（XMLベース）で定義する新世代の標準仕様。
• 特徴: 従来用いられていた複雑な mvdXML（Model View Definition）の反省を生かし、軽量かつわかりやすい構造で「特定の壁オブジェクトに耐火等級と型番の属性が入っているか」を自動判定・事前チェックできます。

OpenCDE-API

• 概要: 異種ベンダーのCDE（Common Data Environment：共通データ環境）同士が、プロジェクト文書やBIMデータをシームレスに相互連携するための共通REST API規格。
• 特徴: Foundation API、Documents APIなどで構成され、クラウド間でのファイル共有や認証（OAuth2）を標準化します。

巨大ITベンダーとの複雑な愛憎関係と「BIM/CIM」のゆくえ

buildingSMARTを語る上で欠かせないのが、市場で圧倒的シェアを誇るAutodeskのRevitをはじめとするプロプライエタリ（商用閉鎖型）ベンダーとの呉越同舟の関係、そして国交省が掲げてきた「BIM/CIM」施策との結びつきです。

生みの親にして最大スポンサー Autodeskのジレンマ

AutodeskはIAI設立時からの立ち上げメンバーであり、現在も最上位の戦略的パートナーとして多額の資金と技術リソースを提供しています。

しかしビジネス的観点では、ユーザーを自社のネイティブフォーマット（.rvt）やクラウド生態系（Autodesk Construction Cloud）に囲い込む、ベンダーロックインが収益の最大化につながります。「自社ツール内での使い勝手を優先したい戦略」と「他社ツールと相互運用させるオープン規格を推進する責任」というジレンマを常に抱えています。

欧州政府による政治的圧力とOpenBIM義務化

一方、英国、北欧、ドイツなどのヨーロッパ諸国やEUは、国家・自治体の重要インフラデータが特定のアメリカ系巨大IT企業1社の私的フォーマットに依存することに対して強い危機感を抱いています。

そのため、公共調達の要件において「ISO 16739（IFC）に基づくオープンBIMでのデータ納品」を法令で義務付ける戦略をとっており、buildingSMARTは「欧州のデジタル主権を守る技術的防波堤」という政治的役割も果たしています。

日本独自の用語「CIM」をめぐる分析と展望

日本において国土交通省は2012年から土木分野のDXとして「CIM（Construction Information Modeling）」を打ち出し、のちに建築（BIM）と合わせて「BIM/CIM」と称してきました。

当時「CIM」という日本独自の表記が必要だった最大の技術的理由は、「当時のIFC（IFC2x3/IFC4）が建築専用であり、土木構造物を表現する共通データモデルが存在しなかったため」です。国交省は独自の旗印として「CIM」を掲げる必要性がありました。

しかし、2024年にIFC4.3（ISO 16739-1:2024）が国際標準化され、道路・鉄道・橋梁・地盤が単一のIFCモデルに統合されたことで、技術的には建築（BIM）と土木（CIM）を分ける境界線は消失しました。

現時点で行政上の用語体系が直ちに改変されたわけではありませんが、2023年度に直轄事業でのBIM/CIM原則適用を一巡させた国交省にとっても、国際標準（IFC4.3）の完成に合わせて、独自用語『CIM』を国際標準の『BIM（ISO 19650準拠）』へと滑らかに収斂・統合させていくための理想的な政策的動機と好機が訪れていると言えます。

次世代技術ロードマップ：IFC4.3からIFC5、Web/APIシフトへ

現在、buildingSMARTは創設以来の「STEP形式（伝統的なテキストファイル）」から完全脱却し、現代的なWebアーキテクチャへと足枷を外す巨大な技術シフトを進めています。

土木・インフラ領域を完全統合したIFC4.3

2024年にISO規格として国際承認された IFC4.3 は、従来の「建築中心」だったIFCを「インフラ全般」へと拡張した歴史的アップデートです。

対応領域
道路、鉄道、橋梁、港湾・水路、地盤。

価値
国土交通省のi-ConstructionやPLATEAU、スマートシティ施策などにおいて、道路や土木構造物のデジタルツインを統一されたデータモデルで管理可能になりました。

モジュール型次世代規格IFC5の構造改革

現在開発が推進されている IFC5 は、30年前の設計であるSTEP技術を捨て、最新のデータ工学を取り入れたフルモデルチェンジ規格です。

マルチフォーマット対応
単一のテキストファイル（.ifc）だけでなく、Webと親和性の高い JSON、セマンティックWeb用の RDF/Linked Data、そしてCG・エンタメ業界の標準となった USD（Universal Scene Description / AOUSD） や glTF をネイティブに取り込める構造へ変化します。

コンポーネント指向（ECSモデル）
「形状（3Dジオメトリ）」「属性メタデータ」「物理シミュレーション/関係性」を完全にレイヤー分割。
必要な属性のみを独立して更新・取得できる非破壊的な構造を提供します。

ファイル共有からWeb API＆データ駆動へ

これまでは「数百MB〜数GBの.ifcファイルをダウンロードしてBIMソフトで読み込む」という重厚な運用が必要でした。

IFC5とWeb/APIシフトが目指す世界は、BIM REST API や GraphQL を通じて、クラウド上のデータベース内にある特定のオブジェクトGUIDへ直接HTTPアクセス（GET / PATCH）する世界です。

Webブラウザやスマートフォン、IoTデバイスが、重い3Dファイルをパースすることなく、軽量なWebメッセージ通信だけでデジタルツインデータをリアルタイムに検索・書き換えできるようになります。

建築を超えて都市・運用・行政へ：広がる推進領域

buildingSMARTの活動は、CAD/BIMのファイル交換だけにとどまりません。都市空間データとの連携、AIによる行政確認申請の自動化、建物の維持管理（FM）、人材教育までを網羅する「建設産業の総合エコシステム設計機関」として機能しています。

専門委員会（Rooms）と「自動建築確認（Digital Building Permit）」

buildingSMART内部は、産業ドメインごとに分けられた専門委員会 「Rooms」（Regulatory Room, Sustainability Room, Infrastructure Room, Airport Roomなど）によって仕様策定が進められています。

Regulatory Room（自動確認申請）
最も世界的な注目を集めている領域です。シンガポールの「CORENET X」に代表されるように、BIMデータ（IFC）を行政システムに提出するだけで、建築基準法や消防法への適合をアルゴリズムが自動チェックする 「Digital Building Permit（デジタル確認申請）」 の標準仕様化を進めています。

Sustainability Room（ESG・脱炭素）
建材ごとのCO2排出量（エンボディドカーボン）やLCA（ライフサイクルアセスメント）データをIFC属性として連携させ、建物全体の環境負荷を自動計算する共通データ構造を策定しています。

GIS（地理空間情報）との融合「GeoBIM」と都市デジタルツイン

広域の地理空間データ（GIS）と高精度な建築・施設モデル（BIM）をシームレスに結合させる技術概念が GeoBIM です。

OGC（Open Geospatial Consortium）とのアライアンス
地理空間データの国際標準団体OGCと連携し、都市モデル（CityGML / CityJSON / 3D Tiles）と施設モデル（IFC）を正確な絶対座標系で統合する座標変換仕様（IFCMapConversionなど）を定めています。

都市デジタルツイン（PLATEAU等）への展開
国土交通省の「Project PLATEAU」やスマートシティ構想において、都市スケールから建物内部（部屋・設備レベル）までシームレスにズームイン・ズームアウトできる情報共有基盤を支えています。

運用保守（O&M / FM）への拡張とCOBie

建物のライフサイクルコスト（LCC）の8割以上は、竣工後の「維持管理（FM：ファシリティマネジメント）フェーズ」で発生します。

COBie（Construction Operations Building Information Exchange）
施工完了時に、設計・施工BIMからビル管理システム（BMS/FMソフト）へ、機器の保証期間・型番・メンテナンス手順などの情報を引き渡すための標準データ仕様。

ISO 19650-3連携
建設段階（PIM: Project Information Model）から運用段階（AIM: Asset Information Model）へデータをスムーズに移行させるための運用指針を提示しています。

人材・品質の国際標準「PCERT認定」と「buildingSMART Awards」

技術規格だけでなく、「人」や「先進事例」に対する標準化と品質保証も主導しています。

• PCERT（Professional Certification Program）: 単なるBIMソフトの操作スキルではなく、openBIMの概念やISO 19650の情報管理プロセスを正しく理解・実践できる人材を世界共通基準で認定する資格制度。各国ナショナル支部を通じて展開されています。
• buildingSMART Awards: 毎年開催されるグローバルコンペティション。単に美しい3Dモデルを作るのではなく、「特定ベンダーに依存せず、オープンBIM規格を駆使していかに組織間・ツール間の壁を越えてデータ連携を行ったか」を審査・表彰する業界最高の栄誉です。

開発者・エンジニアが押さえるべきオープンソースと技術スタック

buildingSMARTが推進するオープンBIMの動きは、単なる建設業界のルール決めではなく、「CAD/BIMの閉ざされたデータをWebテクノロジー（REST API, JSON, WebGL/WebGPU）で自由に扱えるように解き放つプロセス」です。

オープンBIMエコシステムでアプリケーション開発を行うエンジニアは、以下のオープンソースライブラリや設計思想を押さえておく必要があります。

主要オープンソースエコシステム

IfcOpenShell
C++ / Python
IFCファイルの解析・作成・ジオメトリ生成を行う最も実績あるオープンソースC++ engine & Pythonラッパー。

web-ifc (That Open Company)
C++ / WebAssembly
IFCファイルをブラウザ上で超高速にパースし、Three.js等で3D表示するためのWebAssemblyライブラリ。

xBIM Toolkit
C# / .NET
Windows/C#環境でBIMデータを扱うための強力なエンタープライズ向けオープンソースフレームワーク。

IFC-LBD (Linked Building Data)
W3C / RDF
IFCのデータをグラフ構造（RDF/OWL）として記述し、SPARQLなどでセマンティック検索を可能にする技術。

今後のソフトウェアアーキテクチャの指針

特定ベンダーのAPIに過度に依存しない
Revit APIなどのベンダー固有APIのみに依存した開発は、バージョン変更やライセンス方針改定の変更リスクを直接受けてしまいます。コアロジックはIFC/openBIM準拠で設計するのが賢明です。

「形状（glTF/USD）」と「メタデータ（JSON/Graph）」の疎結合設計
3D表示用の軽量メッシュデータ（glTF/GLB等）と、ビジネス属性・プロパティデータ（JSON/bSDD）をGUIDをキーにして分離保持・管理するWeb標準アーキテクチャを採用することが、次世代の建設DX開発において最も持続可能で強力な手法となります。

建設の「データ主権」を取り戻し、オープンなエコシステムを拓く

buildingSMARTが30年以上にわたって推進してきた「openBIM」の本質は、単にファイル形式の互換性を高めることにとどまりません。それは、特定ベンダーのプロプライエタリな仕様や囲い込みからデータを解放し、社会インフラとしての建設データを真に共有可能にする「データ主権の確立」そのものです。

泥臭いアライアンスから始まった取り組みは、巨大ITベンダーとの激しい政治的攻防を経て、欧州の国策標準化、ISO規格化、そして土木インフラをも包含する「IFC4.3」へと結実しました。
さらに現在進行形の「IFC5」やWeb APIシフトは、重厚長大だったCAD/BIMの世界を、Web標準技術（JSON、REST API、WebGL/WebGPU、USD）の土俵へと引きずり出すパラダイムシフトをもたらそうとしています。

建築の確認申請から都市デジタルツイン、脱炭素、運用維持管理まで、buildingSMARTが定義するオープン規格は、建設業界全体の「共通プロトコル」として機能し始めています。
特定の商用ソフトの操作や独自プラグイン開発に閉じることなく、オープン標準とモダンなWeb/データ技術を掛け合わせることができるプレイヤーこそが、これからの建設DX市場において持続可能で決定的な価値を発揮していくはずです。