はじめに：今週の「IFC」は少し騒がしい
BIM推進担当として日々IFC（Industry Foundation Classes）と格闘していますが、今週ネット上の「IFC」関連トレンドを追ってみると、AWSが発表したInfrastructure from Code（IfC）関連の記事が大量にヒットして驚きました。建築のIFCとは全く別物ですが、せっかくなので両者を整理しつつ、私たち建築側にとって本命のニュース——AWSがIFCをRDFグラフに変換して生成AIで活用するアーキテクチャ——を中心に、今週の動向をまとめます。
トピック1：本命ニュース — IFC × 生成AI × Amazon Neptune
今週、建築BIM界隈で最も注目すべき発信は間違いなくこれです。
ポイントは、IFCのSTEPファイルをRDF（Resource Description Framework）グラフに変換し、グラフDBであるAmazon Neptuneに格納、自然言語クエリ（生成AI）で問い合わせるという構成です。
なぜグラフDBなのか
IFCは本来、エンティティ同士が参照関係で複雑に絡み合ったセマンティックなデータ構造を持っています。これをリレーショナルDBで扱うと関係性が失われがちですが、グラフDBなら「この壁に取り付く建具」「この空間に属する設備」といった関係性をそのまま扱える。生成AIとの相性も非常に良い、というのが肝です。
トピック2：紛らわしい「IfC」 — AWS Blocksの登場
同じ綴りで紛らわしいですが、今週Qiitaを賑わせた「IfC」はこちらでした。
- 【AWS Blocks 入門】AWSのIfCツール「AWS Blocks」を体験してみた！
- 3つの特徴で理解する AWS Blocks 〜IFC・Conditional Exports・CDKの拡張〜
- Infrastructure from Code（IfC）本番運用の現実：生存フレームワーク比較と段階的移行戦略
- AWSに繋げなくてもテストできる？新サービス「AWS Blocks」を触ってみた
こちらのInfrastructure from Codeは「アプリのコードを書けばインフラ構成が自動で導出される」という思想。建築のIFCとは無関係ですが、「上位の記述から下位の構成を自動生成する」という発想自体は、設計BIMから施工・積算用モデルを派生させたい我々にも示唆的です。
ゼネコンBIM担当としての独自考察
1. 既存業務への応用可能性
IFC×グラフDB×生成AIの構成は、絵空事ではなく実務に効く可能性があると感じています。具体的に効きそうなのは以下です。
- 協力会社からのIFC受領時のチェック：「IfcWallで耐火仕様プロパティが空のものを抽出」といった検査を自然言語で実行できれば、属人化したチェック作業が激減する
- 積算・施工計画との接続：部材と空間、工区、工程の関係性をグラフで保持できれば、現状エクセル台帳で管理している「どの部材がどの工区か」を一気通貫で扱える
- 発注者対応：「2階の防火区画を構成する部材を全部出して」といった問い合わせに即答できる
2. 社内標準化への活かし方
このアーキテクチャを活かすには、IFC出力時のプロパティセット標準化が大前提です。グラフDBに入れても、プロパティ命名がバラバラなら自然言語クエリは機能しません。逆に言えば、「生成AIで引ける状態」をゴールに設定した社内IFC運用ルールを作れば、標準化の説得材料になります。「なぜPset命名を統一するのか」を現場に説明する強力な口実になるはずです。
3. 現実的な導入ハードル
- IFCの品質問題：各設計BIMソフトからのIFC出力は依然として揺れがあり、RDF化以前の段階でつまずくリスク
- セキュリティ：プロジェクトデータをクラウドのグラフDBに上げる際の発注者承認
- 運用コスト：Neptune＋生成AIのランニングコストを、どのプロジェクト予算で持つか
結局、技術より「誰が金を出し、誰がデータ品質を担保するか」という、いつものゼネコン課題に行き着きます。
総括
今週は「IFC」と「IfC」が検索結果で入り乱れる珍しい週でしたが、建築側にとってはAWSのIFC×RDF×生成AI事例こそが本丸です。一貫BIMを進める我々にとって、IFCは単なる中間ファイルから「クエリ可能なナレッジグラフの原資」へと役割を変えつつあります。まずは社内のPset標準を「グラフ化前提」で見直すところから、地に足のついた一歩を踏み出したいところです。