IFC5という革命

建築業界を長年縛り続けてきた「重くて、開かなくて、崩れるBIMデータ」の時代が、ついに終わろうとしています。

現在策定が進む「IFC5（NEXT）」は、単なるマイナーアップデートや機能追加ではありません。
1990年代のレガシー技術（STEPフォーマット）を完全に脱ぎ捨て、現代のWeb標準、DevOps、さらにはゲーム開発の最先端思想を取り入れた、オープンBIM史上最大にして最もアグレッシブな構造改革です。

IFC5で起きる変化の本質は、以下の5つの地殻変動に集約されます。

拡張子 .ifc（STEP形式）の物理的消滅
1990年代から使われていたレガシーな規格「STEP（ISO 10303-21）」の単一テキストファイル表現を捨て去ります。
これにより、.ifcファイル自体が消滅し、巨大な単一ファイルをメールやストレージで送り付ける時代は終わります。
今後は、JSON-LD形式やグラフデータベース、Web API（REST/GraphQL）をベースとし、「必要なオブジェクトだけをGitのように差分更新する」モダンな開発体験へとシフトします。

属性（Semantic）と幾何（Geometry）の完全な分離
見た目の形状データ（glTF等）と、建築的・ビジネス的な属性情報（IFC）が完全に疎結合化され、用途に応じた自由なデータ活用が可能になります。

3D形状の劇的な軽量化と最適化
パラメトリックなマスターデータと表示用メッシュを完全に分離。「コードをビルドして画面に描画する」Web的なパイプラインにより、Webブラウザや現場のiPadでも巨大モデルがストレスなくサクサク動く環境が整います。

ECS（Entity Component System）構造の全面導入
ゲームエンジンのコア技術である「ECS」をBIMデータモデルに採用。従来の「硬直した巨大なクラス継承（階層構造）」を解体し、データ（Component）とロジック（System）を疎結合化することで、これまでにない超高速な検索・処理性能とデータ構造の柔軟性を実現します。

差分更新（Delta Update / Modular Update）
「巨大なファイルを毎回丸ごと送信する」運用から、「変更された壁のパラメータだけを差分更新する」運用が可能になり、Gitのように軽量なバージョン管理が実現する。

これは、建築データが「独自の特殊なデータ」であることをやめ、ITやゲーム業界の最先端エコシステムと直接つながる未来への第一歩です。今回の記事では、IFC5がどのような技術によってBIMの不都合な真実を塗り替えていくのか、その全貌を解き明かします。

これまでのIFCが抱えていたモノリシック構造の限界

こうして土木領域までカバーし、単一ファイル形式としての完成系を迎えたIFC4.3ですが、その裏側ではこれまでのデータ構造に起因する致命的な課題が浮き彫りになっていました。

従来のIFC（IFC2x3、IFC4、最新のIFC4.3まで）は、3D幾何形状、空間構造、材料、属性、オブジェクト間の関係性をすべて1つの.ifcファイルに抱え込む「モノリシック（巨大な一体型）構造」を採用してきました。

近年のデジタルツインやWebブラウザベースの活用が進む中で、以下の限界に直面しています。

ファイルサイズの肥大化
高精度な3D形状や膨大な属性情報を含むと、1ファイルが数ギガバイトに達し、Webブラウザやモバイル端末での読み込みが困難になる。

差分更新の不可能性
「壁のコストを1箇所書き換えただけ」「仕上げ属性だけ更新したい」場合でも、巨大なIFCファイル全体を書き出し直さなければならない。

リアルタイム連携の限界
施工現場の進捗データやIoTセンサーから送られる動的データを、巨大な固定ファイルへリアルタイムに書き込むことは不可能。

これらの課題を解決するために考案されたのが、次世代規格「IFC5」です。

ECS（Entity Component System）的アプローチとデータの外部化

IFC5における最大の変更点は、「データ（形状や属性）を単一ファイルから分離・外部化し、モジュールとしてリンクする」という設計思想への転換です。

ゲームエンジンや高度な3Dグラフィックスの世界で採用されているECS（Entity Component System）の思想を取り入れることで、データ構造を役割ごとに切り離します。

何が「外部化」されるのか？

3D幾何形状（ジオメトリ）の外部化

重厚な3Dメッシュや形状データ自体をIFC内に直接保持せず、Pixarが開発し業界標準となりつつある USD（Universal Scene Description） や、Web向け軽量3D規格 glTF などの外部ファイルへリンク・参照させます。

属性・プロパティ情報の外部化

型番、コスト、維持管理データなどの属性情報を JSON / JSON-LD 形式などで独立して保持します。3D形状データを重くロードすることなく、属性データベースだけを高速に参照・更新することが可能になります。

形状も属性も外部化されたら、IFC内に何が残るのか？

ここで当然の疑問が生じます。3D形状も属性データもすべて外部化してしまったら、IFCという規格の内部には一体何が残るのでしょうか？
答えは、「オブジェクトのID」と「関係性のネットワーク」だけです。

IFC5の実体が保持するのは、以下のような最小限の情報です。

Entity（実体のID）
「これがスラブA（UUID: xxx-1234）」という存在の定義。

関係性（Rel）
「スラブAは、2階フロアに属し、壁Bと接している」という空間・構造のネットワーク。

外部データへの参照ポインタ（URI）:

• 形状データ ➔ https://.../geometry/slab_A.usd
• 属性データ ➔ https://.../data/slab_A_properties.json
• センサー ➔ https://.../iot/temperature_sensor_A

つまり、IFC5本体は巨大なデータそのものを抱え込む「箱」ではなく、分散したデータ同士を正しく結びつけるための「ハブ（目次 / データ空間の骨組み）」として機能することになります。

ファイルフォーマットから規格への脱皮

データが外部化され、関係性だけで記述されるようになると、BIMデータの扱い方は根本から変わります。

これまでは.ifcというファイルをメールやクラウドストレージで手渡しするファイル交換による運用でしたが、IFC5の時代には、Web APIやグラフデータベース（Graph DB）を介して、必要なデータだけをストリーミング取得・更新するという運用へ移行します。

技術スタックの完全な近代化

この転換に伴い、1990年代から使われてきた古いデータ記述言語（EXPRESS / ISO 10303-11）は廃止され、Web技術と親和性の高いモダンな技術スタックへと刷新されます。

• スキーマ定義: JSON Schema / TypeSpec
• データ表現: JSON-LD（Linked Data）
• 3Dストリーミング: OpenUSD / glTF

これにより、WebエンジニアやITシステム開発者が、特殊なBIMソフト用ライブラリを使わずとも、標準的なWeb技術（REST APIやGraphQLなど）を使って簡単にBIMデータへアクセス・操作できるようになります。

パラメトリック表現と3Dポリゴンの共存

BIMデータの文脈において「パラメトリックな表現」とは、建築要素を単なる「固定された3Dの形状（ポリゴン）」としてではなく、寸法・ルール・関係性を保持した「計算可能なデータ」として定義する手法を指します。

一般的な3D CGやゲームなどで使われるデータは、ポリゴンと呼ばれる表面の三角形の集まりに過ぎず、中身は空洞の「見せかけの形」です。一方、IFCにおけるパラメトリック表現では、例えば1枚の壁を「2Dの基準線、断面プロファイル、高さ、厚み」という数値パラメータと生成ルールによって表現します。

なぜパラメトリック表現が必要なのか？

単なる3Dメッシュではなく、建築要素を数学的・パラメトリックに定義する表現（2D断面の押し出し、CSG、B-Rep等）が必要とされる理由は以下の通りです。

編集性と相互依存性
壁の厚み、高さ、位置などを数値で柔軟に変更するため。また「壁に窓を配置すると自動で穴が開く」「壁同士の取り合いを判定する」といった要素間の幾何学的依存関係を保持するため。

建築的意味と計算処理
コンクリート体積の自動算出（数量積算）、構造計算、精密な貫通孔の干渉チェックなど、厳密なソリッド形状を前提とした計算処理を行うため。

なぜパラメトリックデータは描画が重いのか？

従来のIFC（IFC2x3やIFC4）において表示が重く、フリーズが多発していた原因は「パラメトリック表現そのもの」ではなく、配信と計算の構造にありました。

端末側での都度計算
パラメトリックな幾何定義（「このパスに沿って断面を押し出す」など）を、受信したスマホやWebブラウザ側がいちいち数学的に解釈・計算して3Dメッシュに展開（レンダリング）していました。

巨大な単一ファイル（STEP形式）
モデル全体の全データが1つの巨大な .ifcファイルにまとまっていたため、一部を見るだけでも全体を読み込んで解釈・計算する必要がありました。

IFC5における「パラメトリック → glTF」自動生成の流れ

IFC5では、ソフトウェア開発のDevOps（CI/CD）に類似した「マスター（原本）とビルド生成物（表示用データ）の分離」という現代的なアーキテクチャを採用しています。

[設計者/CAD]
     │ (API / Diff Push)
     ▼
[マスターデータ (IFC5 / JSON-LD)] ─── パラメトリック情報（属性・関係性）を保持
     │
     │ (クラウド/サーバー上の自動パイプラインで自動ビルド)
     ▼
[表示用データ (.glb / glTF)] ─────── 軽量な描画用ポリゴンデータ
     │
     ▼
[Webブラウザ / iPad / VR] ──────── 超高速描画 ＆ タップでIFC属性を参照

パラメトリックは捨てない
マスターデータ側にはパラメトリックな定義や属性が厳密に保持される。

自動ビルドパイプライン
パラメトリックデータが更新（Commit/Push）されると、サーバー裏側で表示専用の軽量glTFが自動生成・更新される。

Webストリーミング
クライアント端末は重い幾何演算を行う必要がなく、ビルド済みの軽量glTFを受け取るだけで即座にサクサク描画できる。

直接glTFを紐付けるルートとその理由

ただし、IFC5では「必ず先にパラメトリックありき」ではなく、最初からglTF（メッシュ）を直接IFCのオブジェクト（ID）に紐付けるルートも対等な選択肢として用意されています。
それは以下のような事例では、パラメトリックな形状が存在しないか、作成のコストが割に合わないためです。

Scan to BIM（点群・スキャンデータ）
レーザースキャナー等で取得した既存建物の複雑なメッシュ形状。

メーカー提供の設備部品
照明器具、衛生機器、受変電設備など、無理にパラメトリック化するとデータが超重量化してしまう既製品。

土木・地形・不規則形状
トンネル削孔形状や自然地形など、シンプルな押し出しパラメータ等で表現できないデータ。

紐付けの仕組み（グラフ構造）

IFC5ではデータ構造がグラフ化（JSON-LD / RDF）されたため、以下のように1つの IFC ID（属性データ）に対して、幾何データの表現方法を自由にリンクできます。

パターンA（パラメトリック）
[IFC ID] ──＞ [パラメトリック定義] ──(自動生成)──＞ [glTF]

パターンB（直接紐付け）
[IFC ID] ──＞ [外部glTFファイル]

どちらのパターンであっても、ユーザーが画面上の3D形状（glTF）をタップすれば、紐付いた IFC ID の属性情報（メーカー名、型番、メンテナンス履歴等）にアクセスできます。

IFC5の現在と今後のタイムライン

現在はアルファ版開発フェーズ
buildingSMART Internationalの公式GitHub（buildingSMART/IFC5-development）において、JSON Schemaを用いた初期ドラフト（IFC5 Alpha）が公開されており、データ構造や設計原則の議論・検証が進められています。

実務での利用はまだ先
現在ゼネコンや設計事務所の現場実務で普及しているのは、IFC2x3や最新のIFC4.3です。IFC5が実際の工事・納品で「実用化」されるまでには、規格の正式承認や主要BIMベンダーの対応を待つ必要があるため、まだ数年の期間を要します。

開発者・ベンダーによる検証が進行中
ACCA Softwareなどの先駆的なソフトウェアベンダーが、IFC5 Alphaに対応したWebベースのビューアや実験的プラットフォーム（usBIM.ifc5など）を発表するなど、次世代基盤としての技術検証が進行しています。

なぜ単一の「正式導入年」がないのか？

従来のIFC2x3やIFC4では、国際標準（ISO）として仕様を一括で固め、数年かけてCADベンダーが対応し、ある日突然「今日から新バージョンです」と切り替える方式でした。しかし、これだと規格策定に何年もかかり、時代遅れになってしまいます。

そのため、IFC5ではWebソフトウェア開発と同じ段階的なリリース（インクリメンタル・リリース）手法が採られています。
上述の通り、現在は、buildingSMART InternationalのGitHub上でアルファ版（IFC5-development）などの仕様策定・コード開発がオープンに行われています。
今後、コアとなる最小限のデータ構造（コアAPIやJSON/ECSの基盤）が先行してリリースされ、その後、ドメインごとの機能がモジュールとして順次追加されていきます。

実際の運用・普及のタイムライン

基礎仕様のリリース後、BIMツール（Revit、Archicadなど）やWebプラットフォームへの機能実装が進むため、実務で日常的に本格活用されるのは2020年代後半となる見通しです。

このようにしてIFC5は「ある年に一斉に切り替わる」のではなく、「Web APIや対応ソフトから使える機能順にどんどん現場に入ってくる」という形で普及していきます。

まとめ：データがつながり、建築の未来が加速する

IFC5（NEXT）へのアップデートは、単なるBIMデータの仕様変更にとどまりません。1990年代から建築業界を縛り続けてきた「重くて、開かなくて、崩れるBIMデータ」の時代に終止符を打ち、建築データを現代のWeb・IT標準およびゲームエンジンの最先端エコシステムへ直結させる歴史的転換点です。

IFC5によってデータが解き放たれ、デジタルツインやIoT、施工管理ツールとシームレスにつながる未来――オープンBIMの新しい可能性は、すぐそこまで来ています。