Articles

5 mai 2026Masahiro TaimaResearchTechnology Real Estate & Construction

L'ère où les agents IA automatisent les opérations BIM : histoire et avenir de la CAO et du BIM selon les dernières recherches

Product

Commencer gratuitement (En préparation) Consulter pour Enterprise

Career

Nous recrutons activement des talents pour développer des services d'agents IA spécialisés chez mign.

Overview

CADとBIMは異なる系譜と思想から発展してきたツールであり、BIMはCADの後継ではありませんが、建築・土木のデータ連携という文脈で両者は徐々に統合されつつあります。本稿は、最新の学術研究をもとに、CADとBIMの歴史的変遷、DXFとIFCを例としたそれぞれのデータアーキテクチャとサンプルコード、両者の違い、そしてAI・IoT・XRなどの新興技術との融合による今後の展望を整理します。特に設計・施工・運用の各段階でAIエージェントとの連携が進み、生成AIと統合された「AIBIM」や自動法規適合性チェックなどの可能性が見えてきています。結論としては、AIエージェントを活用した自動設計が、これまでなかなか普及してこなかったBIMが急速に普及するきっかけになると考えられます。

はじめに

AIが徐々に普及し、日常から仕事まで多くの場面で活用されてきています。建築・土木の領域でも、様々な場面でAIの活用が期待されており、その中でも、かねてより可能性を示唆され続けてきたAIによる設計の自動化が現実的になってきています。ここで、改めてCAD（Computer-Aided Design）やBIM（Building Information Modeling）といったデジタルツールが建築・土木業界の業務を変えてきた歴史的変遷を振り返り、今後はどのように進んでいくのか、最新の学術研究を踏まえて、整理したいと思います。

CADとBIMの歴史：BIMはCADの後継ではない

ここではCADやBIMの歴史を振り返ります。前提として理解する必要がある点として、CADとBIMは異なる系譜であるため、BIMはCADの後継ではなく、特に大きな違いとして、CADは建築・土木領域以外にも応用される汎用的なツールである一方で、BIMは建築・土木領域に特化したツールであるという大きな違いがあります。

CADの歴史

1950年代 - 1960年代：概念の誕生とSKETCHPADの誕生

形状の数学的定義をする技術: CADの技術的ルーツは、1950年代後半の軍事・航空宇宙産業における製造の自動化要求に遡ります。マサチューセッツ工科大学（MIT）において、数値制御（Numerical Control：NC）工作機械のための自動プログラミングツールAPTが開発されたことが、形状の数学的定義の基礎となりました。(Ball, 2013; Weisberg, 2008)
SKETCHPADの開発: 現代のCADの真の始祖とされるのが、1963年にMITのIvan Sutherland氏が博士論文の研究として開発したSketchpadです。このシステムは、ブラウン管（Cathode Ray Tube：CRT）ディスプレイとライトペンを用いて、コンピュータと対話的に図形を描画・操作し、幾何学的な拘束（点、線、面などの要素の間の相対的な位置関係や形状的な関係性を定義・制限するルール）を与えることができる画期的なものでした。(Alin & Stăncioiu, 2024; Tornincasa & Monaco, 2010; Weisberg, 2008; Wolfe, July-Sep 2025)
大手企業での社内システム開発: 1960年代には、自動車や航空機産業の大企業が、メインフレームコンピュータを用いて独自の2D/3Dシステムを開発し始めました。ゼネラル・モーターズ（GM）によるDAC-1や、ロッキード社によるCADAM、ルノーのUNISURFなどがその代表例です。(Tornincasa & Monaco, 2010; Weisberg, 2008)

開発者であるIvan Sutherland（アイバン・サザランド）氏が、TX-2コンピュータのディスプレイ端末に座ってライトペンでSKETCHPADを操作している(Weisberg, 2008)

1970年代：商業用ターンキーシステムの台頭と基礎の確立

商業市場の幕開け: 1969年にApplicon社とComputervision社が設立されたことで、CAD技術は研究室から商業市場へと移行しました。その後、Auto-trol社やCalma社、Intergraph社などの初期の主要企業が台頭しました。(Weisberg, 2008; Wolfe, July-Sep 2025)
ターンキー・システムでの提供: 当時のCADシステムは、ミニコンピュータ（DECのPDP-11など）とストレージ管ディスプレイやデジタイザを統合したターンキー・システム（購入後、キーを回して電源を入れるとすぐに使用できる状態のシステム）として販売されていました。これらは1台あたり15万ドル以上と非常に高価であったため、主に大企業に限られた技術でした。(Weisberg, 2008; Wolfe, July-Sep 2025)
CAD/CAMの父とソリッドモデリングの胎動: Patrick Hanratty氏が設立したMCS社は、ADAMなどの設計・製造ソフトウェアを開発し、多数のベンダーにライセンス供給することでCAD普及の基盤を築きました。また、この時期にはIan Braid氏らにより、境界表現（Boundary Representation: B-Rep）や構成的立体幾何（Constructive Solid Geometry：CSG）といったソリッドモデリング（中身の詰まった立体モデルを作成する手法）の基礎研究が進展しました。(Ball, 2013; Weisberg, 2008)

1980年代：PCの普及とAutoCADの登場

PC CADによる大衆化: 1980年代に入りハードウェアの価格が劇的に低下すると、CADの市場構造は一変しました。1982年にAutodesk社がパーソナルコンピュータ（PC）向けの安価なAutoCADを発表したことで、それまでCADを導入できなかった中小企業や個人の設計者にも手が届くようになり、業界における事実上の標準となりました。(Tornincasa & Monaco, 2010; Weisberg, 2008)
ワークステーションへの移行: 一方で、より高度な処理を必要とする企業では、メインフレームからApolloやSun MicrosystemsといったUNIXベースのエンジニアリング・ワークステーションへの移行が進みました。(Weisberg, 2008; Wolfe, July-Sep 2025)
フィーチャベース・パラメトリック設計の登場: 1987年、Parametric Technology Corporation (PTC) 社がPro/ENGINEERを発表しました。これは、ユーザーの設計手順をヒストリー（履歴）として保持し、寸法などのパラメータ（変数）を変更するだけでモデル全体が自動更新されるという画期的なシステムでした。これはCAD業界の第5世代と呼ばれる大きなパラダイムシフトであり、既存のシステムを時代遅れにするほどの影響を与えました。(Tornincasa & Monaco, 2010; Weisberg, 2008)

CADが普及する前の製図業務の様子https://www.youtube.com/shorts/WgfMY4BX5zw

1990年代 - 2000年代：ミッドレンジCADの台頭とダイレクトモデリングへの進化

Windowsベースのミッドレンジ3D CAD: 1990年代半ばになると、Windows OSとIntelプロセッサの性能向上により、SolidWorks（1995年）やSolid Edge（1996年）などの、安価で操作性に優れたWindowsベースのミッドレンジ3D CAD（ハイエンドとローエンドの中間のCAD）が登場し、高価なUNIXワークステーションの市場を奪っていきました。(Tornincasa & Monaco, 2010; Wolfe, July-Sep 2025)
ダイレクトモデリング技術: パラメトリックモデリングは強力な反面、初期の拘束条件が複雑になりすぎると他者がモデルを修正しにくくなるという弱点がありました。そこで2000年代後半には、履歴に縛られず直感的に面やエッジを直接操作できるダイレクトモデリング（ヒストリーフリー）」技術が登場しました。現在では、これら両者の利点を融合させたハイブリッドCADシステムが主流となっています。(Tornincasa & Monaco, 2010)
PLMへの統合: 現代のCADは、単なる幾何学モデリングツールを越え、解析（Computer Aided Engineering：CAE）や製造（Computer Aided Manufacturing：CAM）、そして製品のライフサイクル全体を管理するPLM（Product Lifecycle Management）システムの中核として機能するようになっています。(Weisberg, 2008; Wolfe, July-Sep 2025)
BIMへの展開: 建築・建設分野においては、属性情報を持ったビルディング・インフォメーション・モデリング（BIM）へと発展し、設計から維持管理に至るまでの包括的な情報基盤となっています。(Sacks et al., 2018)

BIMの歴史

1960年代 - 1970年代：概念の誕生とプロトタイプの開発

パラメトリックデザインの未来予測： Douglas C. Englebart氏が論文『Augmenting Human Intellect』において、オブジェクトに基づくパラメトリック要素を用いて建築設計を行う未来を予測しました。(Borkowski, 2023; Hız et al., 2023)
テンプレート概念の提唱： 建築家のChristopher Alexander氏が、設計プロセスを自動化するためのテンプレート概念を提唱し、オブジェクト指向的アプローチの基礎を築きました（後のパタン・ランゲージにつながる）。(Alexander, 1977; Borkowski, 2023)
BIMの父によるBIMの元祖の開発： カーネギーメロン大学のCharles M. Eastman氏らが、現在のBIMのロジックを持つ世界初のソフトウェアBuilding Description System (BDS)を開発・発表しました。BDSは、材料やサプライヤー情報など継続的に更新されるデータベースを持ち、単一の記述から平面図、立面図、パースペクティブなどを自動的かつ一貫して生成できる画期的なシステムでした。Eastman氏はBDSに続き、同様の論理を持つGLIDEを開発し、建築ライフサイクルにおける情報モデリングの概念実証を継続しました。(Hız et al., 2023)

BIMの父であるEastmanによって1975年に発表されたBDSのデータベース内における4つの階層レベル（トポロジー、ジオメトリ、テンプレート、インスタンス）を示すコンセプト。8フィートの2x4材、ドア、ゴム製のモーターマウント、コンクリート柱などの形状が描かれてい流。(C. Eastman, 1975)

1980年代：商業化の黎明期と「ビルディング・モデリング」の登場

Radar CH（後のArchiCAD）の発表： ハンガリーのGraphisoft社が、高価なワークステーションに依存せずオブジェクトベースの3Dアプローチを提供するRadar CH（後のArchiCAD）を発表しました。同時期に英国でもRUCAPSやSONATAなどの先駆的なシステムが開発されています。(Borkowski, 2023; C. Eastman et al., 2008)
BIMの必須要件の定義： Robert Aish氏が、RUCAPSを用いたロンドン・ヒースロー空港の改修プロジェクトに関する論文において、現在我々がBIMとして知る手法をBuilding Modelling（ビルディング・モデリング）という用語で初めて表現しました。この論文では、3Dモデリング、パラメトリックコンポーネント、リレーショナルデータベース、建設プロセスの時間的フェージングといった、現代BIMの必須要件がすでに明確に定義されていました。(Borkowski, 2023; C. Eastman et al., 2008; Hız et al., 2023)

1990年代：”BIM”という用語の誕生と相互運用性への挑戦

BIMという用語の誕生： G.A. van Nederveen氏とF.P. Tolman氏が論文『Modelling multiple views on buildings』を発表しました。学術文献で初めて「Building Information Model (BIM)」というアクロニム（頭字語）が使用されたのはこの論文であると広く認識されています。(C. Eastman et al., 2008; Hız et al., 2023)
IAI（後のbuildingSMART）の設立： ベンダーごとに独自のデータ形式が乱立し、異分野間でのデータ交換（相互運用性）が大きな障壁となりました。これを解決するため、Autodesk社をはじめとする企業コンソーシアムが結成され、1995年にIAI（International Alliance for Interoperability、現在のbuildingSMART）が正式に設立されました。(C. Eastman et al., 2008; Hız et al., 2023; Laakso & Kiviniemi, 2012; Sacks et al., 2018)
IFCのリリース： IAIにより、ベンダー中立なオープンデータ標準である「IFC（Industry Foundation Classes）」の最初のバージョン（IFC 1.0）がリリースされ、異分野連携のための技術的基盤が構築されました。(Hız et al., 2023)

2000年代：業界標準としての確立と普及

Revitの誕生： Charles River Software社により、強力なパラメトリック変更エンジンを搭載したRevitが開発されました（2006年にAutodesk社が買収）。(C. Eastman et al., 2008; Hız et al., 2023)
BIMという用語の世界的普及： 著名な業界アナリストであるJerry Laiserin氏の活動や、Autodesk社が発行したホワイトペーパーを通じて、BIMという用語が世界的なブレイクスルーを果たしました。これまで各社がバーチャルビルディング等と異なる名称で呼んでいた技術が、BIMという共通言語のもとに統合されました。(Borkowski, 2023; C. Eastman et al., 2008)
BIM成熟度モデルの発表： 英国においてBIM成熟度モデル（Bew-Richards ramp）が提唱され、BIMの段階的な導入レベル（Level 0〜Level 3）が明確に定義されました。このモデルは、各国政府がBIM推進政策を策定する際の重要な指標となり、企業が自らのBIMの習熟度を測るための基準となりました。(Borkowski, 2023; Borrmann et al., 2018)

2010年代以降：国家的推進とオープン標準の進化

各国のBIM義務化： 英国政府は2011年にBIM戦略を発表し、2016年からすべての公共調達プロジェクトにおいて「Level 2 BIM」の利用を義務化しました。その他にも、シンガポール（CORENET）、米国（GSA）、フィンランドなどの北欧諸国、韓国などで、公共プロジェクトにおけるBIMやIFC形式の利用が強く推進・義務化されています。(Borkowski, 2023; Borrmann et al., 2018; Sacks et al., 2018)
openBIMの普及： Graphisoft社やTekla社などの主導により、openBIMのイニシアチブが本格化しました。これにより、特定のソフトウェアに囲い込まれるクローズドBIMから脱却し、IFCなどのオープンな標準フォーマットを介して最適なツール同士をシームレスに連携させるアプローチが広く普及しました。(Borkowski, 2023; Hız et al., 2023)

CADのデータアーキテクチャ

CADの思想はデータの設計指針や構造にあらわれます。ここではデータアーキテクチャについて整理します。

DXFの仕組み

CADのデータ交換において、事実上の標準（デファクトスタンダード）として世界中で広く利用されているのが、DXF（Drawing Interchange Format）です。Autodesk社がAutoCADのために開発したDXFは、独自の内部データ構造（DWG）の情報を他のシステムでも網羅的に読み書きできるよう、人間にも解読可能なASCIIテキスト形式（128種類の文字を7ビットの数値で表現する最も基本的かつ世界共通の文字コード規格で書かれたテキスト）として設計され、業界内で広く普及しました。(Autodesk, 1993)

グループコード方式によるデータ記述： DXFファイルの最も特徴的な仕組みは、グループコードと呼ばれる独自のデータ記述方式です。ファイル内のデータは無秩序に並んでいるのではなく、必ずグループコード（正の整数）とその値の2行1組のペアで構成されています。プログラムがDXFを読み込む際、1行目のグループコードを見るだけで、2行目に続く値のデータ型と意味を厳密に判別できるよう設計されています。具体的には、コードが「0〜9」であれば文字列、「10〜59」であればX座標やスケールなどの浮動小数点数、「60〜79」であれば整数であると定義されています。とくに「0」というコードは特別で、セクションやエンティティ（図形）の開始を宣言するマーカーとして機能します。(Autodesk, 1993)
ファイル全体の階層構造： テキストデータが無秩序に肥大化するのを防ぐため、ファイル全体は「0」と「SECTION」の記述で始まり、「0」と「ENDSEC」で終わる、論理的な「セクション」に分割して格納されます。主要なセクションは以下の4つです。(Autodesk, 1993)
- HEADER（ヘッダー）セクション：図面のバージョン情報（$ACADVER）や、図面の限界座標（$EXTMIN、$EXTMAX）といったシステム変数が、変数名を意味する「9」のグループコードに続いて保存されます。
- TABLES（テーブル）セクション：線種、画層（レイヤー）、文字スタイルなど、図面内で繰り返し使用される名前付きの設定リストを保持します。各テーブルの開始時には要素の最大数が宣言され、読み込み側が効率的にメモリを割り当てられるよう工夫されています。
- BLOCKS（ブロック）セクション：複数の図形を一つにまとめた「ブロック」の定義を格納します。図面内で同じ図形群を再利用するための元データとなり、外部参照ファイルへのパス情報なども記録されます。
- ENTITIES（エンティティ）セクション：実際に画面に描画される線分や円、テキストなどの幾何学図形データの実体を記述します。ファイルは最後に「0」と「EOF（End of File）」というマーカーで締めくくられます。
形状データの格納： ENTITIESセクションには、線（LINE）や円（CIRCLE）といった図形の座標やプロパティが格納されますが、テキストファイルの肥大化を防ぐための最適化が施されています。たとえば、図形の色や線種といったプロパティが「BYLAYER（画層の設定に従う）」などのデフォルト値と同じである場合、そのデータはファイルに書き出されず、記述自体が省略されます。読み込み側のプログラムは、データが省略されている場合は自動的にデフォルト値を補って解釈する仕組みになっています。また、長いテキストデータ（MTEXTなど）は、255文字ごとのチャンクに分割されて保存されるといった文字列表現の制約も存在します。(Autodesk, 1993)
3D空間表現の軽量化： DXFでは、3D空間上の図形データを保存する際にも、独自の圧縮概念を用いています。3次元の絶対座標（ワールド座標系：WCS）をすべてそのまま記録するのではなく、「エンティティ座標系（ECS）」というローカルな2D平面を基準にしてデータを格納します。たとえば円やテキストなどの平面的な図形は、その図形が乗っているECS上の2D座標（X, Y）と、WCSからの高さ（Elevation）として記録されます。そして、その平面が3D空間上でどの方向を向いているかを示すため、「Z軸方向の押し出しベクトル」だけを追加で記録します。データを読み込むプログラムは、「任意の軸アルゴリズム（Arbitrary Axis Algorithm）」という数学的な計算ルールを用いて、このZ軸ベクトルから一貫したX軸とY軸を自動生成し、元の3D空間での図形の姿勢を正確に復元します。これにより、データ量を大幅に削減しています。(Autodesk, 1993)
外部データの付加： DXFは幾何学的な図形を保存するだけでなく、サードパーティのソフトウェアが独自の非幾何学的データ（属性情報など）を図形に付与できる「拡張エンティティデータ（XDATA）」という柔軟な仕組みを備えています。XDATAには1000番台の特別なグループコード（例えば1000は文字列、1040は実数など）が割り当てられており、登録されたアプリケーション名を先頭にして、独自の情報を図形の中に埋め込むことが可能です。(Autodesk, 1993)
データ読み書きの高速化： ASCIIテキスト形式であるDXFは、人間が読める透明性を持つ一方で、ファイルサイズが大きくなり、浮動小数点数の丸め誤差や読み込み速度の遅さが課題となる場合があります。これを解決するため、Autodesk社は「バイナリDXF」フォーマットも提供しています。これは、ASCII版と同じデータ構造（グループコード方式）を保ちつつ、データを2進数のバイナリ値（IEEE倍精度浮動小数点など）で直接記述するものです。これにより、データの精度を完全に保ちながらファイルサイズを約25%削減し、読み書きの速度を約5倍に向上させています。(Autodesk, 1993)

サンプルコード

グループコードのサンプル
グループコードに関して、以下に例を記載します。DXFの形式を役所への申請書に例えます。
—
役所への申請書は次のように記述されるとします。
1番欄（氏名）：山田太郎
2番欄（生年月日）：1990年1月1日
3番欄（住所）：東京都千代田区...
—
これをそのまま番号と内容を交互に並べる形式で書くと、こうなります。
—
1
山田太郎
2
1990年1月1日
3
東京都千代田区...
1行目が番号、2行目がその番号の内容。これがDXFのグループコード方式の基本構造です。
—
DXFファイルでは上記申請書での番号のことをグループコード、上記申請書での内容のことを値と呼びます。
—
0 ← グループコード（エンティティ（要素）の種類を示す）
LINE ← 値（線です、という意味）
8 ← グループコード（レイヤーを示す）
0 ← 値（レイヤー名は「0」）
10 ← グループコード（始点のX座標）
0.0 ← 値（X = 0.0）
20 ← グループコード（始点のY座標）
0.0 ← 値（Y = 0.0）
11 ← グループコード（終点のX座標）
100.0 ← 値（X = 100.0）
21 ← グループコード（終点のY座標）
0.0 ← 値（Y = 0.0）
—
これは、(0,0)から(100,0)に線を1本引いた、という情報となります。

ファイル全体の階層構造のサンプル
ファイル全体の階層構造について、以下は例となります。CADで描いた図面を保存するファイル（DXF）は、5段の引き出しがある書類キャビネットのようなものになります。
┌─────────────────────────┐
│ ▼ DXFファイル（キャビネット）
│
│ ┌─ SECTION ─┐
│ │ HEADER │ ← 図面全体の基本情報
│ └───ENDSEC──┘
│
│ ┌─ SECTION ─┐
│ │ TABLES │ ← よく使う設定の登録
│ └───ENDSEC──┘
│
│ ┌─ SECTION ─┐
│ │ BLOCKS │ ← 再利用する部品の登録
│ └───ENDSEC──┘
│
│ ┌─ SECTION ─┐
│ │ ENTITIES │ ← 実際に描かれた図形
│ └───ENDSEC──┘
│
│ EOF ← キャビネットを閉じる
└─────────────────────────┘
各引き出しには名前があり、引き出しの最初に「0 SECTION」（ここから引き出しを開けます）、最後に「0 ENDSEC」（この引き出しは閉じます）と書かれています。

HEADER（ヘッダー）のサンプル
ここはファイル全体のメタ情報です。図面そのものの中身ではなく、この図面はどんな図面か、の説明書きです。身近な例としては、本の表紙にあたります。

著者
出版社
出版年

DXFのHEADERには

AutoCADのバージョン（$ACADVER）
図面の表示範囲（$EXTMIN、$EXTMAX）
単位（mm / m / inchなど）
現在のレイヤー設定

実物のサンプルは以下のようになります。
—
0
SECTION
2
HEADER
9
$ACADVER ← 変数名「AutoCADのバージョン」
1
AC1027 ← 値「2013年版」
9
$EXTMIN ← 変数名「図面の左下隅」
10
0.0 ← X座標
20
0.0 ← Y座標
9
$EXTMAX ← 変数名「図面の右上隅」
10
1000.0
20
500.0
0
ENDSEC
—
ここで初めて出てくるグループコードである9 は、変数名（システム変数）を示します。

TABLES（テーブル）：よく使う設定の登録名簿
ここは繰り返し使う名前付き設定を登録する場所です。身近な例としては会社の電話帳です。

営業部 A：内線100
経理部 B：内線200

文書本体で、Aさんに連絡、と書きたいとき、毎回、A（営業部、東京本社、1990年入社…）」と書くのは面倒。だから事前に名前と詳細を登録しておきます。これが TABLES の役割です。
DXFのTABLESには

レイヤーテーブル：レイヤー名と色、線種の対応
線種テーブル：「破線」「一点鎖線」などのパターン定義
文字スタイルテーブル：フォント、サイズ
寸法スタイルテーブル

が書かれます。
実物のサンプル（レイヤーテーブルだけ抜粋）は以下のようになります。
—
0
SECTION
2
TABLES

0
TABLE
2
LAYER ← レイヤーテーブル開始
70
3 ← レイヤーが3つあります（最大数の宣言）

0
LAYER
2
0 ← レイヤー名「0」
62
7 ← 色番号7（白）
6
CONTINUOUS ← 線種「実線」

0
LAYER
2
Wall ← レイヤー名「Wall」
62
1 ← 色番号1（赤）
6
CONTINUOUS

0
LAYER
2
Door ← レイヤー名「Door」
62
3 ← 色番号3（緑）
6
CONTINUOUS

0
ENDTAB ← レイヤーテーブル終了
0
ENDSEC
—

BLOCKS（ブロック）のサンプル
ここは複数の図形をまとめた部品を登録する場所です。身近な例としては、レゴブロックの部品箱です。

窓ユニット（フレーム＋格子＋ラベルがセット）
ドアユニット（枠＋扉＋取っ手がセット）
タイトルブロック（図面の右下にある、図面名・縮尺・日付の枠）

これらを部品として一度登録しておけば、図面のあちこちで何度でも使い回せます。100箇所にドアを描くとき、毎回ドアの形を最初から描かず、ドアユニットをここに置く、と指定するだけで済みます。
—
実物のサンプル:
0
SECTION
2
BLOCKS

0
BLOCK
2
DoorUnit ← ブロック名「DoorUnit」
10
0.0 ← ブロックの基準点（X）
20
0.0 ← 基準点（Y）

0
LINE ← このブロックを構成する線1
8
0
10
0.0
20
0.0
11
800.0
21
0.0

0
LINE ← このブロックを構成する線2
8
0
10
0.0
20
0.0
11
0.0
21
2100.0

0
ENDBLK ← ブロック「DoorUnit」終了

0
ENDSEC
—
そして本文（ENTITIES）では、こう書きます。
—
0
INSERT ← ブロックを挿入
2
DoorUnit ← 「DoorUnit」を呼び出す
10
1000.0 ← 配置位置X
20
0.0 ← 配置位置Y
—
これだけで、その位置にドアが描かれます。

ENTITIES（エンティティ）のサンプル
ここがメインの引き出しです。画面に実際に描かれている線・円・テキストなどが並びます。身近な例としては、志望理由書の本文になります。ENTITIESがファイルの主役です。
実物のサンプル
—
0
SECTION
2
ENTITIES

0
LINE ← 1本目の線
8
Wall
10
0.0
20
0.0
11
1000.0
21
0.0

0
LINE ← 2本目の線
8
Wall
10
0.0
20
0.0
11
0.0
21
500.0

0
CIRCLE ← 円
8
Door
10
500.0
20
250.0
40
50.0

0
INSERT ← 「DoorUnit」を呼び出して配置
2
DoorUnit
10
800.0
20
0.0

0
TEXT ← 文字
8
Annotation
10
500.0
20
600.0
40
20.0
1
LIVING ROOM

0
ENDSEC
—
これは壁を2本、ドアを示す円を1個、ドア部品を1個、LIVING ROOMという文字を1つ描いた状態です。ここに書かれている内容が、CADの画面に見えているものそのもの（線、円、文字など）になります。

EOF（End of File）のサンプル
最後に、ファイルの終わりを示すマーカーがあります。
—
0
EOF
—
これが書かれていないファイルは、CAD側が「途中で切れている」と判断してエラーを出します。本の最後の、以上、終わり、のページに相当します。

CADで図面が描画されてDXFに保存されるまでのプロセス

CADにおいて、図面が描画され、それが異機種間でデータ交換可能なDXF（Drawing Interchange Format）として保存されるまでのプロセスは、精緻な計算とデータ変換の連続によって成り立っています。

幾何学的図形の配置（作図プロセス）： 設計者はCADという電子化された製図板の上で、線分、円弧、テキストといった幾何学的図形（プリミティブ）を組み合わせて図面を描画します。BIMとは異なり、CADシステム自体は描かれた線が「壁」であるといった意味情報を理解せず、純粋なグラフィック要素（線と文字）の集合体として処理します。(Ball, 2013; C. M. Eastman, 1989)
ファイルの論理的なセクション分割： DXF形式への保存（エクスポート）が開始されると、データは無秩序に書き出されるのではなく、HEADER（システム変数）、TABLES（画層や線種の設定）、BLOCKS（再利用可能な図形群）、ENTITIES（実際の図形実体）などの論理的なセクションに厳密に分割されてテキストファイルに出力されます。(Autodesk, 1993)
グループコード方式によるデータの直列化：ファイルに書き出されるすべてのデータは、グループコード（正の整数）とその値の2行1組のペアとして直列化（シリアライズ）されます。たとえばコード「10」の次にはX座標、「8」の次には画層名が続くといったルールにより、他のプログラムがテキストデータを読み込む際に値のデータ型と意味を正確に解釈できるようになっています。(Autodesk, 1993)
デフォルト値の省略によるデータ最適化： ASCIIテキスト形式はデータが肥大化しやすいため、出力時に自動的な最適化が行われます。図形の色や線種などのプロパティがBYLAYER（画層の設定に従う）といったデフォルト値と同じである場合、その記述自体をファイルから省略することでファイルサイズを抑えます。(Autodesk, 1993)
ECSを用いた空間表現の軽量化： 3D空間の図形を保存する際、すべての絶対座標を記録するのではなく、エンティティ座標系（ECS）というローカルな2D平面上の座標と、Z軸の押し出しベクトルのみを記録します。読み込み時には任意の軸アルゴリズム（Arbitrary Axis Algorithm）を用いて数学的に元の3D姿勢を復元することで、データ量を大幅に削減しています。(Autodesk, 1993)

このように、CADからDXFへの保存プロセスは、描画された幾何学データを独自のグループコードやECSといった仕組みを用いて最適化し、外部プログラムで読み取り可能な標準化されたテキストデータへと変換する精緻な処理となっています。

BIMのデータアーキテクチャ

BIMの思想はデータの設計指針や構造にあらわれます。ここではデータアーキテクチャについて整理します。

IFCデータモデルの4層アーキテクチャ構造図(Laakso & Kiviniemi, 2012)

IFCの仕組み

IFC（Industry Foundation Classes）は、buildingSMARTが開発し、ISO 16739として国際標準化されている、ベンダー中立なBIMデータ交換のためのオープンフォーマットです。従来のCADデータが主に幾何学的な図形情報の集合体であったのに対し、IFCは建物やインフラ構造物の意味情報（セマンティクス）、形状情報（ジオメトリ）、オブジェクト間の複雑な関係性を包括的に記述できるオブジェクト指向のデータモデルとして設計されています。

EXPRESS言語によるオブジェクト指向のデータ定義：IFCのデータスキーマ（データ構造の定義）は、ISO 10303（STEP標準）で定められたデータモデリング言語EXPRESSを用いて記述されています。EXPRESSはオブジェクト指向の概念を取り入れており、クラス（エンティティ）、属性、そして継承関係を厳密に定義することができます。また、IFCのスキーマを視覚的に表現するためには、EXPRESS-Gというグラフィカルな記述法も用いられています。(Ball, 2013; Borrmann et al., 2018)
4つの階層による厳格なスキーマアーキテクチャ：IFCのスキーマは、膨大で複雑な建設プロジェクトの情報を効率的に管理し、将来の拡張性を保つために、厳格な依存ルール（上位層から下位層への参照のみ許可）を持つ4つのレイヤー（階層）に分割されています。(Borrmann et al., 2018)
- リソース層（Resource Layer）： 最下層に位置し、幾何学表現、トポロジー、材質、数量などの基礎的なデータ構造を提供します。この層のデータは独自のIDを持たず、上位層のオブジェクトから参照される形でのみ存在します。
- コア層（Core Layer）： データモデルの骨格となる層です。すべての物理的・概念的要素の根源となる抽象クラスIfcRootやIfcObjectなどが含まれ、要素のグローバル一意識別子（GUID）や変更履歴などのメタデータを保持します。
- 共有／相互運用性層（Shared/Interoperability Layer）： 建築や設備など、複数の専門分野で共通して使用される「壁（IfcWall）」や「スラブ」などの一般的な要素を定義します。
- ドメイン層（Domain Layer）： 最上位に位置し、建築、構造解析、空調（HVAC）など、特定分野に特化した高度に専門的なクラス群を定義します。
意味（セマンティクス）と形状（ジオメトリ）の完全な分離：IFCにおけるデータ格納の核心的な特徴の一つが、”オブジェクトの意味的定義”と”幾何学表現”の完全な分離です。たとえば、あるオブジェクトが「壁である」という意味情報（セマンティクス）は、その形状データとは独立して定義されます。これにより、単一の意味を持つ壁オブジェクトに対して、BIMオーサリングツール向けの精緻な3Dソリッドモデル、エネルギー解析向けの簡略化された面モデル、あるいは平面図用の2Dシンボルなど、用途の異なる複数の形状表現を同時に紐付けることが可能となっています。(Borrmann et al., 2018)
関係性のオブジェクト化（Objectified Relationships）：IFCの最も革新的なアプローチが「関係性のオブジェクト化」です。IFCでは、要素同士を直接の属性ポインタで結びつけるのではなく、関係性そのものを独立したオブジェクト（IfcRelationshipのサブクラス）として定義・格納します。例えば、「壁の中に窓が組み込まれている」という状態は、壁と窓を直接リンクするのではなく、「開口部を埋める関係（IfcRelFillsElement）」という独立した関係性エンティティを介して記録されます。また、「建物が複数の階を集約している」といった空間的な階層構造も、集約関係を示す「IfcRelAggregates」として記録されます。これにより、要素同士がなぜ関連しているのかという論理的な理由をモデル内に明示的に保存できるのです。(Borrmann et al., 2018)
プロパティセット（Property Set）による動的な拡張性：地域やプロジェクトごとに異なる無数の属性要件（特定の耐火性能値やメーカー情報など）をすべて標準スキーマに組み込むと、データモデルが肥大化してしまいます。これを防ぐため、IFCはプロパティセットという仕組みを用いています。独自の属性群はIfcPropertySetとして定義され、関係性オブジェクト（IfcRelDefinesByProperties）を用いて、後から対象の要素に動的に割り当てられます。この仕組みにより、スキーマ自体を変更することなく、柔軟なメタデータの追加が可能となっています。(Borrmann et al., 2018)
STEP物理ファイルおよびifcXMLによる物理的格納形式：メモリ上に構成されたIFCデータが実際のファイルとして保存される際、最も標準的に用いられるのが、STEPクリアテキストエンコーディング（ISO 10303-21）に基づくASCIIテキストファイル（拡張子 .ifc）です。このファイル内はHEADERセクションとDATAセクションに分かれています。DATAセクションに格納されるデータは1行ごとに記述され、各行には「#123」といった一意のインスタンスIDが付与されます。ファイル内の各オブジェクトは、このIDをポインタとして用いて互いを参照し合うことで、フラットなテキストファイル上に複雑なデータネットワークを再構築します。また、Webサービス等との連携を容易にするために、XML技術をベースとした「ifcXML」形式でもデータ格納・交換が可能です。(Borrmann et al., 2018)
MVD（Model View Definition）による用途別データ抽出：実際のデータ交換において、巨大なIFCモデルの全情報をやり取りするのは非効率です。そのため、「誰が、いつ、どのような情報を必要としているか」という業務要件をIDM（Information Delivery Manual）として定義し、それを技術的に実装可能なIFCのサブセット（情報のフィルタリング条件）に翻訳したMVDという仕組みが用いられます。ソフトウェアは特定のMVD（例：Coordination Viewなど）に準拠してデータを選択的に出力・格納することで、ファイルサイズの肥大化を防ぎつつ、過不足のない確実なデータ交換を実現しています。(Borrmann et al., 2018)

サンプルコード

CADファイル（DXF）が建物の見た目を描いた絵だとすれば、IFCは建物の戸籍と相関図です。

DXF：ここに線がある、ここに別の線がある
IFC：ここに「壁」という人物がいる、別の場所に「窓」がある、この2つは「組み込まれている」という関係にある

戸籍には「誰が誰と親子で、誰と結婚していて、どこに住んでいるか」という関係が記録されています。IFCも同じです。建物の構成要素の関係性が表現されます。これを念頭に、サンプルコードを整理します。

EXPRESS言語によるオブジェクト指向定義のサンプル

これは、学校のクラス分けに似ています。
—
人間（基本クラス）
├─ 生徒（人間を継承、学籍番号を追加）
│ ├─ 小学生（生徒を継承、ランドセル属性を追加）
│ └─ 高校生（生徒を継承、自転車通学属性を追加）
└─ 先生（人間を継承、教科属性を追加）
—
ここで、「小学生」は「生徒」の特徴を全部持っていて、その上に独自の特徴を追加する。
IFCで同じことを書くと以下のようになります。
—
IfcRoot（すべての根、GUIDと履歴を持つ）
├─ IfcObjectDefinition
│ └─ IfcObject
│ └─ IfcProduct（位置と形を持つ）
│ ├─ IfcElement（建物の物理要素）
│ │ ├─ IfcWall（壁）
│ │ ├─ IfcSlab（床）
│ │ ├─ IfcColumn（柱）
│ │ └─ IfcWindow（窓）
│ └─ IfcSpatialElement（空間要素）
│ ├─ IfcSite（敷地）
│ ├─ IfcBuilding（建物）
│ └─ IfcBuildingStorey（階）
—
「壁（IfcWall）」は「建物の物理要素（IfcElement）」の特徴を全部持っていて、その上に壁固有の属性が追加されています。
実際のIFCのスキーマ（簡略化）は以下のようになります。
—
ENTITY IfcWall
SUBTYPE OF (IfcBuildingElement);
PredefinedType : OPTIONAL IfcWallTypeEnum;
END_ENTITY;
—
「IfcWallはIfcBuildingElementを継承し、PredefinedTypeという属性を追加で持つ」と書いてあります。

4階層のアーキテクチャ

IFCのスキーマは4層の建物のように構造化されていて、上から下へしか参照できないルールがあります。例えれば、会社の組織図のような階層です。
—
[上層] ドメイン層（建築特有・構造特有・設備特有）
   ↓ 参照できる
[中層] 共有層（壁、床など共通の建物要素）
   ↓ 参照できる
[中層] コア層（IfcRoot、IfcObjectなど抽象クラス）
   ↓ 参照できる
[下層] リソース層（座標、材料、数量など部品的データ）
—
ルール：上層は下層を使ってよいが、下層は上層を知りません。これは「専門部署は共通部署のサービスを使えるが、共通部署は特定の専門業務を知らなくていい」という、健全な組織設計に似ています。

・ドメイン層（特定分野に特化）は以下のようになります。
—
# IfcSensor（センサー）は設備分野（HVAC, BMS）で使う
sensor = IfcSensor(global_id="xyz789", name="TempSensor1")
—

・共有層（複数分野で使う要素）は以下のようになります。
—
# IfcWall（壁）は建築でも構造でも設備でも使う
wall = IfcWall(global_id="abc123", name="W1")
—

・コア層（IfcRootを継承する抽象的なオブジェクト）は以下のようになります。
—
# IfcRoot は全ての要素の祖先
class IfcRoot:
    GlobalId # GUID（一意ID）
    OwnerHistory # 誰がいつ作ったか
    Name # 名前
    Description # 説明
—

・リソース層（最下層、ID無しの部品的データ）は以下のようになります。
—
# IfcCartesianPoint（座標）
point = IfcCartesianPoint(coordinates=[0.0, 0.0, 0.0])
# IfcMaterial（材料）
material = IfcMaterial(name="Concrete")
—

意味（セマンティクス）と形（ジオメトリ）の分離

IFCでは「これは壁である」という意味と「壁の形はこういう四角形」という形を、別々に記録します。これは、人物紹介に似ています。

Aさんという人がいるとき、用途別の複数の写真が紐づいているイメージです。

顔写真A：履歴書用の正面写真
顔写真B：パスポート用の白背景写真
顔写真C：SNSアイコン用の自然な笑顔

IFCでも同じです。「これは壁である」という1つの意味的存在に、用途別の複数の形を紐づけられます。

# まず「壁である」という意味的存在を作る
wall = IfcWall(
global_id="abc123",
name="LivingRoomWall_W1"
)

# 次に、その壁にいろんな形を紐づける
# 形1: 詳細な3Dソリッド（BIMビューワー用）
representation_3d = IfcShapeRepresentation(
type="SweptSolid",
items=[detailed_solid_geometry]
)

# 形2: 簡略化された面（エネルギー解析用）
representation_simple = IfcShapeRepresentation(
type="Surface",
items=[simple_surface]
)

# 形3: 平面図用のシンボル（2D図面用）
representation_2d = IfcShapeRepresentation(
type="Annotation2D",
items=[wall_symbol]
)

# 1つの壁に3つの表現を紐づける
wall.Representation = IfcProductDefinitionShape(
representations=[representation_3d, representation_simple, representation_2d]
)

これによって以下のように活用できます。

BIMビューワーは「3Dソリッド」を表示
エネルギー解析ソフトは「簡略化された面」を使って計算
図面出力ツールは「2Dシンボル」を使って平面図を作成

すべて同じ壁から派生するので、壁を移動すれば全部の表現が同期します。

関係性のオブジェクト化

「Aの中にBがある」という関係を、AとBを直接結ぶのではなく、「関係そのもの」を独立した存在として記録します。これは、結婚の記録に似ています。

婚姻関係
  ├─ 当事者A
  ├─ 当事者B
  ├─ 婚姻日: 2020年10月10日
  └─ 婚姻地: XXX city

「壁の中に窓がある」関係を、IFCで書くとこうなります。

・壁、窓、開口を記述
pythonwall = IfcWall(global_id="wall001", name="W1")
window = IfcWindow(global_id="win001", name="WIN1")
opening = IfcOpeningElement(global_id="op001", name="OP1")

・「壁に開口がある」という関係
pythonrel_voids = IfcRelVoidsElement(
    global_id="rel001",
    relating_building_element=wall, # 開口が空いている要素 = 壁
    related_opening_element=opening # その開口 = OP1
)

・「開口に窓が入る」という関係
pythonrel_fills = IfcRelFillsElement(
    global_id="rel002",
    relating_opening_element=opening, # 埋められる開口 = OP1
    related_building_element=window # 開口を埋める要素 = WIN1
)

これで「壁→開口→窓」という関係が、3つの関係オブジェクトを介して記録されます。

関係をオブジェクトにすることで以下の利点があります。

関係そのものに属性を付けられる（例：「いつ追加された関係か」「誰が承認したか」）
関係の理由を残せる（「この壁とこの梁が接続しているのは構造上の理由から」）
関係を後から検索できる（「この壁に関連する全ての関係を取得」）

プロパティセットによる動的拡張

地域や用途で必要な属性は無数にあります。すべてをスキーマに含めると肥大化するので、後から自由に属性を追加できる仕組みが用意されています。スマートフォンのアプリストアに似ています。

本体（スキーマ）：標準機能だけを持つ
アプリ（プロパティセット）：必要に応じて追加する
ユーザーごとに必要なアプリだけを入れる

すべての機能を最初から本体に入れたら、本体が肥大化してしまう。

標準のIfcWallが持っている属性は以下の通りです。

pythonwall = IfcWall(
    global_id="wall001",
    name="W1",
    description="リビング南壁"
)

追加で属性を持たせたいときは、プロパティセットをつくります。例えば、壁の性能に関しての属性を追加する場合は以下のようになります。
—
fire_props = IfcPropertySet(
    global_id="ps001",
    name="Pset_WallCommon",
    has_properties=[
        IfcPropertySingleValue(name="FireRating", value="1H"),
        IfcPropertySingleValue(name="ThermalTransmittance", value=0.35),
        IfcPropertySingleValue(name="AcousticRating", value="D-45")
    ]
)
—
関係性オブジェクトで壁にプロパティセットを紐づけます
—
rel_defines = IfcRelDefinesByProperties(
    global_id="rel003",
    related_objects=[wall], # 対象の壁
    relating_property_definition=fire_props # 紐づけるプロパティセット
)
—
これで壁に「耐火1時間、熱貫流率0.35、遮音D-45」という情報が後付けで追加されます。

これには以下の利点があります。

スキーマ本体を変更せずに属性を追加できる
国・地域・プロジェクト固有の要件に対応できる
同じプロパティセットを複数の要素に共有できる
buildingSMARTが標準プロパティセット（Pset_*）を多数定義しており、業界共通の語彙が育っている

物理ファイル形式（.ifc / ifcXML）

メモリ上のIFCデータは、STEP物理ファイル形式（STandard for the Exchange of Product model data（ISO 10303）は、異なる3D CADソフト間で形状データを正確に受け渡すために設計された国際標準の中間ファイルフォーマット）でテキストファイルとして保存されます。#1、#2のようなIDで互いを参照し合います。

実物の.ifcファイルはこんな見た目です（簡略化）。
—
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('example.ifc','2025-05-05T10:00:00',('Author'),('Org'),'IFC4','Software','');
FILE_SCHEMA(('IFC4'));
ENDSEC;

DATA;
#1=IFCPROJECT('0YvctVUKr0kugbFTf53O9L',$,'ExampleProject',$,$,'ExampleProject',$,(#10),#5);
#2=IFCSITE('1xS3BCk291UvhgP2dvNMKI',$,'Site',$,$,#15,$,$,.ELEMENT.,$,$,$,$,$);
#3=IFCBUILDING('2YeQrjMKTBLRrCu0v9wTAF',$,'Building',$,$,#20,$,$,.ELEMENT.,$,$,$);
#4=IFCBUILDINGSTOREY('1aAabcDeFgHiJkLmNoPqRs',$,'Level 1',$,$,#25,$,$,.ELEMENT.,0.);

#10=IFCWALL('3xYzAbcDe1234567890fGh',$,'W1','LivingRoomWall',$,#30,#40,$,.STANDARD.);
#11=IFCWINDOW('4xYzAbcDe1234567890fGh',$,'WIN1','LivingRoomWindow',$,#31,#41,$,1.5,1.0,.WINDOW.);

#50=IFCRELCONTAINEDINSPATIALSTRUCTURE('5relA12345',$,$,$,(#10,#11),#4);
#60=IFCRELVOIDSELEMENT('6relB12345',$,$,$,#10,#70);
#70=IFCOPENINGELEMENT('7opA12345',$,'OP1',$,$,#32,#42,$,.OPENING.);
#80=IFCRELFILLSELEMENT('8relC12345',$,$,$,#70,#11);

ENDSEC;
END-ISO-10303-21;
—
読み方

#1=IFCPROJECT(...) → ID #1はプロジェクト
#2=IFCSITE(...) → ID #2は敷地
#10=IFCWALL(...) → ID #10は壁W1
#11=IFCWINDOW(...) → ID #11は窓WIN1
#50=IFCRELCONTAINEDINSPATIALSTRUCTURE(...,(#10,#11),#4) → 「#10と#11の要素は#4（Level 1）に含まれる」という関係
#60=IFCRELVOIDSELEMENT(...,#10,#70) → 「#10（壁）に#70（開口）が空いている」という関係
#80=IFCRELFILLSELEMENT(...,#70,#11) → 「#70（開口）に#11（窓）が入っている」という関係

すべての要素がフラットな行として並び、IDで互いを参照する。これでネットワーク構造（意匠・構造・設備などの各データが独立せず、壁、柱、配管などの要素が属性（サイズ、材料、コスト等）を持ち、それらが相互に関連し合っている状態）を表現しています。

MVD（Model View Definition）による用途別データ抽出

IFCファイルは情報量が膨大なので、用途に応じて必要な部分だけを抽出する仕組み（MVD）があります。これは、履歴書と職務経歴書の違いに似ています。

履歴書：基本情報、学歴、職歴の概要（人事部向け）
職務経歴書：プロジェクト詳細、技術スタック、実績数値（技術面接官向け）
マイナンバー登録書：法的な個人識別情報（行政向け）

つまり、すべて同じ「自分」の情報ですが、相手によって渡す情報のセットが違います。

IFCには標準的なMVDがいくつかあります。以下はよく使われるMVDです。
—
CoordinationView 2.0
  目的: 設計者間の協調・衝突検査
  含まれる情報: ジオメトリ、空間構造、要素の関係
  含まれない: 詳細パラメータ、製造情報

ReferenceView
  目的: 参照閲覧用（軽量化）
  含まれる情報: 簡略ジオメトリ、識別情報
  含まれない: 詳細プロパティ

DesignTransferView
  目的: 設計データの双方向交換
  含まれる情報: ほぼすべて
  含まれない: 限定的

BasicFMHandoverView
  目的: ファシリティマネジメント引渡し
  含まれる情報: 設備、空間、運用情報
  含まれない: 詳細ジオメトリ
—

実際のRevitの「IFCに書き出す」ダイアログでは、こういう選択肢があります:
—
[書き出し設定]
IFCバージョン: [IFC4 ▼]
MVD: [Reference View ▼]
  選択肢:
    - Coordination View 2.0
    - Reference View
    - Design Transfer View
    - Basic FM Handover
    - GSA Concept Design BIM 2010
—
選んだMVDによって、生成されるIFCファイルの中身が変わります。Reference Viewなら軽量、Design Transfer Viewなら情報量が多い、というトレードオフがあり、用途によって使い分けることができます。

上記、全体を1つのコード例で表現

ここまでの全特徴をまとめた、最小限のIFCモデル作成コードは以下のようになります。（Pythonのifcopenshellライブラリ）
—
pythonimport ifcopenshell
from ifcopenshell.api import run

# 新しいIFCファイルを作成
model = ifcopenshell.file(schema="IFC4")

# プロジェクト → 敷地 → 建物 → 階の階層を作る
project = run("root.create_entity", model, ifc_class="IfcProject", name="ExampleProject")
site = run("root.create_entity", model, ifc_class="IfcSite", name="Site")
building = run("root.create_entity", model, ifc_class="IfcBuilding", name="Building")
storey = run("root.create_entity", model, ifc_class="IfcBuildingStorey", name="Level 1")

# 階層関係を「集約関係」として記録
run("aggregate.assign_object", model, relating_object=project, product=site)
run("aggregate.assign_object", model, relating_object=site, product=building)
run("aggregate.assign_object", model, relating_object=building, product=storey)

# 壁を作る
wall = run("root.create_entity", model, ifc_class="IfcWall", name="W1")

# 壁を階に含める（関係をオブジェクト化）
run("spatial.assign_container", model, product=wall, relating_structure=storey)

# 壁に耐火性能などのプロパティを追加
pset = run("pset.add_pset", model, product=wall, name="Pset_WallCommon")
run("pset.edit_pset", model, pset=pset, properties={
"FireRating": "1H",
"ThermalTransmittance": 0.35
})

# .ifcファイルとして保存
model.write("example.ifc")
—

上記のコード1つで、これまで説明した特徴がすべて表現されています。

オブジェクト指向：IfcWallはIfcRootから継承
4階層：IfcWall（共有層）がIfcRoot（コア層）を継承し、IfcCartesianPoint（リソース層）を使う
意味と形の分離：壁の意味は作成済み、形は別途追加可能
関係性のオブジェクト化：aggregate.assign_object、spatial.assign_containerが裏で関係オブジェクトを作っている
プロパティセット：pset.add_psetで動的に属性追加
物理ファイル：model.write("example.ifc")でSTEP形式に保存

BIMで図面が描画されてIFCに保存されるまでのプロセス

BIMにおいて、図面が作成（描画）され、それが国際標準のデータ交換フォーマットであるIFCに保存されるまでのプロセスは、従来のCADにおける「線を引く」作業とは全く異なる、高度なデータベース処理の仕組みに基づいています。

統合データベースの構築と図面の「抽出」
- パラメトリック・モデリングによる仮想建築の構築： BIM環境では、設計者はキャンバスに図形を描くのではなく、「壁」や「ドア」といった意味情報（セマンティクス）と幾何学情報（ジオメトリ）を持つインテリジェントなオブジェクトを仮想空間に配置し、建物の統合データベースを構築します。(Azhar, 2011; C. M. Eastman, 1991)
- レポートとしての図面生成： Eastman氏らが指摘するように、BIMにおける平面図、断面図、立面図といった図面は、この単一の3Dモデルに対して仮想的な切断面を設け、そこから動的に抽出される「特別にフォーマットされたレポート」として機能します。(C. M. Eastman, 1991)
- 双方向の更新と一貫性の担保： 図面はモデルの特定のビュー（視点）に過ぎないため、3Dモデル上で一部を変更すると、関連するすべての図面や数量表が自動的に更新され、設計情報における完全な一貫性が保証されます。(C. Eastman et al., 2008)

IFCへのエクスポートとMVDによるフィルタリング
- データ交換要件の定義（IDM）： BIMモデルを他のシステムに渡す際、すべてのデータを書き出すとファイルが肥大化してしまいます。そのため、ISO 29481（IDM：Information Delivery Manual）の概念に基づき、「どの業務プロセスで、どのような情報が必要か」が定義されます。(Borrmann et al., 2018; Sacks et al., 2018)
- MVDによる情報の抽出： この要件をソフトウェアが処理できる技術的な仕様に翻訳したものがMVD（Model View Definition）です。システムは、指定されたMVDに従って、巨大なBIMデータベースの中から対象の用途に必要なオブジェクトや属性のサブセットのみをフィルタリングして抽出します。(Borrmann et al., 2018; Sacks et al., 2018)

意味と形状の分離およびデータ構造のマッピング
- オブジェクト指向スキーマへの変換： 抽出されたデータは、ISO-STEPのEXPRESS言語で定義されたIFCの厳密なデータスキーマへとマッピングされます。この際、オブジェクトが「壁である」という「意味情報」と、「その3D形状」という「幾何学表現」は、データ構造上完全に分離された上で互いに結び付けられます。さらに、要素間のつながりも「関係性オブジェクト」として独立して定義されます。(Borrmann et al., 2018)

STEP物理ファイルへのシリアライズ（保存）
- テキストファイルへの直列化： メモリ上に構成された複雑な情報のネットワークは、最終的に「STEPクリアテキストエンコーディング（ISO 10303-21）」に基づくASCIIテキストファイル（拡張子 .ifc）として保存（シリアライズ）されます。(Borrmann et al., 2018; Laakso & Kiviniemi, 2012)
- インスタンスIDによるネットワークの再構築： ファイル内はHEADERセクションとDATAセクションに大別されます。DATAセクションに書き出されるすべてのオブジェクト（物理要素、関係性、形状データなど）には、1行ごとに「#124」のような一意のインスタンスIDが付与されます。そして、各データがこのIDを用いたポインタ参照によって互いを結びつけ合うことで、平坦なテキストファイル上に元の複雑なネットワーク構造が正確に記録されます。(Borrmann et al., 2018)

このように、BIMからIFCへの保存プロセスは、図形を描画・保存する作業ではなく、インテリジェントな仮想モデルから用途に合わせて情報を動的に抽出し、高度に構造化されたオブジェクトのネットワークとして国際標準規格のテキストに翻訳・記録するという、非常に精緻なデータエンジニアリングの過程となっています。

CADとBIMの違いの整理

建築・建設（AEC）業界におけるデジタル化を牽引してきたCADとBIMですが、両者は”図面を描くプロセス”と”データを保存するファイル構造”において全く異なるアプローチをとっています。

基本概念とデータ構造の相違
- CAD（図形の集合体）： 従来の製図板をデジタル環境に移行させた”電子的な製図板”として発展してきました。CADデータは、線分、円弧、面といった幾何学的な図形（プリミティブ）の集合体として表現され、システム自体はその線が”壁”や”配管”であるといった意味情報（セマンティクス）を理解しません。(Borkowski, 2023; Borrmann et al., 2018)
- BIM（意味を持つ統合データベース）： 幾何学情報（ジオメトリ）だけでなく、非幾何学的な属性や意味情報（セマンティクス）を内包するインテリジェントなデジタル仮想モデルの構築を目的としています。建物は、寸法、材質、性能といったパラメータを持つオブジェクトの集まりとして、一つの統合されたデータベース上に構築されます。(Borkowski, 2023; Borrmann et al., 2018; Deng et al., 2021; C. Eastman et al., 2008; Liu et al., 2019)

図面作成プロセスの相違
- CAD（手作業による作図）： 設計者が2Dまたは3Dのキャンバス上に、一本ずつ線や図形を明示的に配置して図面を描画します。図面間で設計変更が生じた場合、関連するすべての図面を手作業で個別に修正する必要があります。(Borrmann et al., 2018)
- BIM（モデルからの抽出）： BIM環境において、平面図や断面図といった図面は手作業で描かれるものではありません。単一の統合3Dモデルに対して仮想的な切断面を設け、そこから動的に抽出されたレポートとして生成されます。モデルの一部を変更すれば、すべての図面や数量表が自動的に更新されるため、情報の完全な一貫性が保証されます。(Borrmann et al., 2018; C. Eastman et al., 2008)

データ保存・交換フォーマットの相違
- CAD（DXF）： 事実上の標準フォーマットであるDXFは、幾何学的な形状を正確かつ効率的に伝達することに特化しており、フラットなリスト構造を用いて図形データを保存します。(Autodesk, 1993)
- BIM（IFC）： 国際標準であるIFCは、建物の情報を交換するためのオブジェクト指向データモデルです。オブジェクトの意味的定義と幾何学表現を厳密に分離して保存し、要素間の関係性（例：「窓が壁に開けられた穴に収まっている」など）自体も独立したデータとして複雑なネットワーク状に格納します。(Borrmann et al., 2018; Laakso & Kiviniemi, 2012)

プロジェクトにおける役割の相違
- CAD（作図支援ツール）： 主に設計段階における図面作成の自動化や、幾何学的なモデリング作業の効率化を目的とする受動的なツールとして用いられます。(Ball, 2013; C. Eastman et al., 2008)
- BIM（コラボレーション基盤）： 設計から施工、維持管理（FM）、解体にいたる建物のライフサイクル全体を通じた「情報の資産化」と、プロジェクト参加者間のコラボレーションを促進する能動的なプラットフォームとしての役割を担います。(Borkowski, 2023; Deng et al., 2021; C. Eastman et al., 2008; Olawumi et al., 2017)

結論として、CADが「幾何学的な図形のデジタル化と作図の効率化」に特化した技術であるのに対し、BIMは「建物の意味情報と関係性を統合し、ライフサイクル全体で管理・共有する」という全く異なる認識論に基づく情報プラットフォームであると言えます。

CADとBIMの未来

CADとBIMは異なる系譜から発展し、近年、建築設計という領域で交わるようになりました。ここでは、今後のCADとBIMの未来について述べます。

CADとBIMはどのように進展するか

建築・土木（AEC）業界におけるコンピュータ支援設計（CAD）とビルディング・インフォメーション・モデリング（BIM）は、これまで、いかに効率よく正確な図面やモデルを作成するかという目的に特化して発展してきました。しかし現在、これらの技術は人工知能（AI）、モノのインターネット（IoT）、拡張現実・仮想現実（XR）などの新興技術と融合し、自律的で知的な情報プラットフォームへと進化しようとしています。
要点は以下のようになります。

クラウドコンピューティングとコラボレーションの強化： 従来、個人の高性能なワークステーションに依存していたCADソフトウェアは、クラウドベースのプラットフォームへと移行しつつあります。ハードウェア技術の進歩に伴い、巨大なモデルの処理や集中的な解析・シミュレーションをクラウド上で高速に実行できるようになり、世界中のプロジェクトチームが単一のデータソースにリアルタイムでアクセスし、同時に協働することが容易になります。(Alin & Stăncioiu, 2024)
BIMによるCADの包含とパラダイムシフト： AEC業界において、CADはかつて紙と鉛筆を置き換えたように、現在ではBIMによってその役割を置き換えられつつあります。単純な線分や面（2D/3D）を描画する従来のCADシステムは、意味情報を持つオブジェクトベースのBIM環境に統合され、CAD単体としての発展から、BIMプラットフォームを構成する幾何学モデリング・エンジンとしての役割へとシフトしていくと考えられます。(Borrmann et al., 2018; Hız et al., 2023)

IoTとの統合によるデジタルツインの実現： BIMの最も重要な進展の一つは、IoTセンサーとの統合によるデジタルツインの構築です。現実の建物やインフラ施設に設置されたセンサーから、温度、湿度、エネルギー消費量、設備の稼働状況といったデータがリアルタイムでBIMモデルにフィードバックされます。これにより、BIMは単なる静的な設計データベースから、建物の状態をリアルタイムで反映し、自律的な維持管理や異常予測を行う生きているモデルへと進化します。(Borrmann et al., 2018; Deng et al., 2021; Izbash & Babayev, 2024)
AIと機械学習によるAI BIMと自動化の推進： 2030年代に向けて、BIMは人工知能（AI）や機械学習（ML）と深く統合された「AI BIM」の時代に突入すると予測されています。AIは過去の膨大なデータを学習し、エネルギー効率の高いデザインを自律的に提案したり、複雑な建築基準法への適合性をリアルタイムで自動チェック（自動法規チェック）したりすることが可能になります。これにより、設計者は煩雑な法規確認や反復作業から解放され、より創造的な業務に専念できるようになります。(Borrmann et al., 2018; Deng et al., 2021; Sacks et al., 2018)
ロボティクスおよび無人航空機（UAV）との協働： 建設現場では、BIMデータがロボットやドローンの制御基盤として直接利用されるようになります。カメラやレーザースキャナを搭載したドローン（UAV）が自律的に現場を巡回し、取得した3D点群データをBIMモデルと比較することで、施工の進捗や品質を人間を介さずに自動評価します、。さらに、BIMデータを読み込んだ建設ロボットや大型3Dプリンターが、現場や工場で自律的に建物を組み立てていく技術も実用化に向けて進展しています。(Borrmann et al., 2018; Izbash & Babayev, 2024)
XR（VR・AR・MR）技術による直感的な環境の構築： BIMモデルは、仮想現実（VR）や拡張現実（AR）、複合現実（MR）といったXR（Extended Reality）技術と統合されます。設計段階では、クライアントや設計者がヘッドマウントディスプレイを装着して仮想空間内で建物を体験し、直感的な意思決定を行うことができます。また、施工や維持管理の現場では、作業員がARグラスを通して目の前の空間にBIMの隠れた配管のルートや作業手順を重ね合わせて表示させることで、正確で安全な施工が支援されます。(Izbash & Babayev, 2024; Sacks et al., 2018)
プレファブリケーションとモジュラー建築の高度化： BIMが提供する正確で矛盾のない3Dデータを基盤として、建設業は製造業に近いプレファブリケーション（事前工場生産）やモジュラー建築へと急速にシフトしていきます、。CNC（コンピュータ数値制御）工作機械とBIMが直接連動することで、複雑な形状の部材であっても工場で高精度に大量カスタマイズ生産（マス・カスタマイゼーション）することが可能になり、現場での作業時間の大幅な削減と品質の均一化が実現します。(Sacks et al., 2018)
GISとの統合によるスマートシティへの拡張： BIMの適用範囲は、単一の建物という枠組みを超え、都市レベルへと拡大しています。地理情報システム（GIS）とBIMが統合されることで、周囲のインフラや自然環境のビッグデータと連携したシミュレーションが可能になります、。これにより、地域コミュニティや都市全体におけるエネルギー消費や交通の動きをシミュレーションし最適化を図る「スマートシティ（CIM：City Information Modeling）」の中核的な情報基盤として機能することになります。(Borkowski, 2023; Borrmann et al., 2018; Deng et al., 2021)

CADとBIMはAIエージェントとどのように関わるか

特にAIに関してはこちらで詳しく記載します。設計段階、施工段階、運用・維持管理段階それぞれで整理します。

BIMモデルとIoT（リアルタイム・ダイナミック・モデル）、共通データ環境（CDE）、ビッグデータ分析、ブロックチェーン、オントロジーなど様々な技術との連携(Hız et al., 2023)

設計段階
- ジェネレーティブAIとの融合（AIBIM）： 今後、BIMはジェネレーティブAI（生成AI）と統合され、「AIBIM（AI-Driven BIM）」という概念へと進化します。設計者が要望を入力するだけで、AIエージェントがGAN（敵対的生成ネットワーク）などを用いて何千もの設計案を自動生成し、顧客のニーズや環境に最適化されたデザインをリアルタイムで提案するようになります。(Izbash & Babayev, 2024)
- 自動法規適合性チェックと継続的コンプライアンス： 建築基準法などの複雑なルールを機械可読な形式に変換することで、AIアルゴリズムがBIMモデルを解析し、法規違反がないかを自動的かつ継続的にチェックするようになります。これにより、設計の初期段階から規制に準拠した設計が保証され、AIエージェントが違反を予測し、解決策を自律的に提案することも可能になります。(Izbash & Babayev, 2024)
- セマンティック・エンリッチメント（意味情報の自動付与）： AIエージェントは、機械学習やニューラルネットワークを用いて、CAD由来の単なる幾何学データやレーザースキャンによる点群データを解釈し、「これは壁である」といった意味情報や関係性を自動的（または半自動的）に推論してBIMモデルに付与する役割を担います。(Sacks et al., 2018)

施工段階
- AI駆動型マシンのプロジェクト参加： 従来、建設プロジェクトは人間同士のコラボレーションが中心でしたが、今後はAIエージェントを搭載した機械やロボット、ドローンがプロジェクトの「利害関係者（ステークホルダー）」として参加し、BIMデータをもとに洞察を提供し、意思決定を下し、タスクを実行するようになります。(Izbash & Babayev, 2024)
- 自律的な進捗・品質管理： コンピュータビジョンを備えたドローンが建設現場を自律的に巡回し、取得したデータをBIMモデルと直接比較することで、アズビルト（施工後）モデルの自動生成や、施工の進捗・品質の評価を人間の介入なしに行うようになります。(Borrmann et al., 2018; Izbash & Babayev, 2024)
- 施工計画の自動最適化： ALICE（Artificial Intelligence Construction Engineering）のようなAIツールが登場しており、BIMモデルをもとに様々な工法や作業員規模を考慮した膨大な数の施工計画を自動生成し、最適なスケジュールをAIが特定・提案します。(Sacks et al., 2018)

運用・維持管理段階
- 次世代デジタルツインによる建物の自律制御： BIMとIoTセンサーが統合されたデジタルツインの最終段階（Level 5）において、AIエージェントは現実のデータを分析するだけでなく、最適化戦略に基づいて空調や照明などの建物システムを自動的かつリアルタイムにフィードバック制御するようになります。(Deng et al., 2021)
- 機械学習による予測的メンテナンス： AIエージェントはIoTセンサーからのデータや過去の保守記録を学習し、設備（MEPコンポーネント）の将来の劣化状況やライフサイクルコスト（LCC）を予測し、最適なメンテナンス計画を自律的に立案します。(Deng et al., 2021)
- 歴史的建造物のAI診断（HBIM）： 歴史的建造物を管理するHBIM（Heritage BIM）の分野でも、AIエージェントがドローン画像や3Dモデルを解析し、建物のひび割れや材料の劣化、構造的損傷を自動で迅速に検知・診断する技術の実用化が進んでいます。(Zhang & Zou, 2022)

おわりに

CADとBIMの歴史を振り返ると、系譜や思想が異なる形で両者が発展してきましたが、建築・土木の構造物のデータとの連携という文脈で徐々に近づき、統合されていく状況にあることがわかります。そして、様々なデータが統合していくとともに、近年の進歩が著しいAIエージェントとどのように連携していくのか、その可能性が様々見えてきます。そして、多くの企業にとって、AIエージェントを活用した自動設計を活用するために、これまでなかなか普及してこなかったBIMが急速に普及するきっかけとなるのではないかと思われます。

参考文献

Alexander, C. (1977). A pattern language: towns, buildings, construction. https://jrap.neduet.edu.pk/arch-journal/JRAP_2020(SecondIssue)/JRAP-2020(2ndIssue).pdf#page=52
Alin, S., & Stăncioiu, E. L. (2024). The evolution and impact of cad in modern industries: A comprehensive review. Fiability & Durability/Fiabilitate Si Durabilitate, 33(1). https://search.ebscohost.com/login.aspx?direct=true&profile=ehost&scope=site&authtype=crawler&jrnl=1844640X&AN=180240802&h=LyYzjst2wir3oNUfK%2BbvGNC0RDfEWIJ9hJYlcYGGKxjKf91F6BEHeQ6Mg%2BTTF7s5zzdOnldnQ%2FJbUL6JgYjYeQ%3D%3D&crl=c
Autodesk, I. (1993). DXF reference. Autodesk.
Azhar, S. (2011). Building information modeling (BIM): Trends, benefits, risks, and challenges for the AEC industry. Leadership and Management in Engineering, 11(3), 241–252.
Ball, A. (2013). Preserving Computer-Aided Design (CAD). DPC Technology Watch Report. https://scholar.google.com/citations?user=efU9l9oAAAAJ&hl=en&oi=sra
Borkowski, A. S. (2023). Evolution of BIM: Epistemology, genesis and division into periods. Journal of Information Technology in Construction. https://repo.pw.edu.pl/info/article/WUT82f55e934e0f47e09076418a8834e008
Borrmann, A., König, M., Koch, C., & Beetz, J. (2018). Building information modeling: Why? What? How? In Building Information Modeling (pp. 1–24). Springer International Publishing.
Deng, M., Menassa, C. C., & Kamat, V. R. (2021). From BIM to digital twins: a systematic review of the evolution of intelligent building representations in the AEC-FM industry. Journal of Information Technology in Construction, 26, 58–83.
Eastman, C. (1975). The use of computers instead of drawings in building design. AIA Journal. https://www.researchgate.net/profile/Charles-Eastman/publication/234643558_The_Use_of_Computers_Instead_of_Drawings_in_Building_Design/links/54aff5690cf2431d3531c7a7/The-Use-of-Computers-Instead-of-Drawings-in-Building-Design.pdf
Eastman, C. M. (1989). Architectural CAD: a ten year assessment of the state of the art. Computer Aided Design, 21(5), 289–292.
Eastman, C. M. (1991). The evolution of CAD: Integrating multiple representations. Building and Environment, 26(1), 17–23.
Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2008). BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors. https://doi.org/10.5555/1796500
Hız, Y., Altunel, E., Güngör, S., & Öztürk, S. (2023). Current research in architecture, planning and design. Gece Kitaplığı.
Izbash, Y., & Babayev, V. (2024). Digital evolution in AEC industry: Bridging BIM, building codes, and future technologies. IOP Conference Series. Earth and Environmental Science, 1376(1), 012004.
Laakso, M., & Kiviniemi, A. (2012). The IFC standard-A review of history, development, and standardization. Journal of Information Technology in Construction, 17, 134–161.
Liu, Z., Lu, Y., & Peh, L. C. (2019). A review and scientometric analysis of global Building Information Modeling (BIM) research in the architecture, Engineering and construction (AEC) industry. Buildings, 9(10), 210.
Olawumi, T. O., Chan, D. W. M., & Wong, J. K. W. (2017). Evolution in the intellectual structure of Bim research: A bibliometric analysis. Journal of Civil Engineering and Management, 23(8), 1060–1081.
Sacks, R., Eastman, C., Lee, G., & Teicholz, P. (2018). BIM handbook: A guide to building information modeling for owners, designers, engineers, contractors, and facility managers. https://books.google.com/books?hl=en&lr=&id=IU9mDwAAQBAJ&oi=fnd&pg=PR17&dq=BIM+Handbook+(3rd+ed.).+Wiley&ots=NgnvMw1vyJ&sig=vsq2-kPApnCwXaHInBfGTu7pVag
Tornincasa, S., & Monaco, F. D. (2010). THE FUTURE AND THE EVOLUTION OF CAD. tmt.unze.ba. https://tmt.unze.ba/zbornik/TMT2010/Keynote-Tornincasa.pdf
Weisberg, D. E. (2008). The engineering design revolution: the people, companies and computer systems that changed forever the practice of engineering. Cyon Research Corporation.
Wolfe, L. S. (July-Sep 2025). How CAD Became Universal. IEEE Annals of the History of Computing, 47(3), 14–25.
Zhang, Z., & Zou, Y. (2022). Research hotspots and trends in heritage building information modeling: A review based on CiteSpace analysis. Humanities & Social Sciences Communications, 9(1), 394.

À lire ensuite ↓