金曜の夕方、協力会社から届いたIFCを社内ビューワで開いたら、鉄骨のプロパティが半分吹き飛んでいて頭を抱えました。書き出し設定のズレか、変換ソフトのバージョン違いか。こういう泥臭い作業を毎週やっていると、今週のIFC関連ニュースはどれも他人事に思えません。LLMがIFCを学習した話、軽量ビューワの登場、そして建設未来フォーラムでの「オープンBIM×AI」の議論。バラバラに見えて、一本の線でつながっている気がしています。
今週のIFC関連トピック
LLMはIFCファイルを読めるのか
LLMはIFCを理解できるのか？Gemma 3 1Bを4万件のBIMデータで学習させてみたという記事が個人的に一番刺さりました。4万件のBIMデータで小型モデル（Gemma 3 1B）をファインチューニングし、IFCのSTEP形式テキストをLLMに読ませる試み。IFCは人間には読みにくいですが、テキストベースなのでLLMとは実は相性がいい。ローカルで動く1Bクラスで検証している点も現実的で、社内サーバーで回せる規模感なのがありがたい。
軽量・オフラインのIFCビューワ
NKN IFC Viewer — A Lightweight, Offline BIM Solution for AEC Professionalsは、AEC業界のIFC共有ボトルネックに対して、オフラインで動く軽量ビューワを提案する内容。現場PCのスペックが揃っていない、ネット回線が不安定、といった条件下でIFCを開くには、こういう軽い選択肢が地味に効きます。うちも所長クラスのノートPCでRevitを立ち上げるのは酷なので、IFCだけ開ければいい局面は結構ある。
オープンBIM×AIの業界動向
第55回建設未来フォーラム「オープンBIMによるIFCデータ連携とAI活用」が日刊建設工業新聞で告知されていました。テーマ設定そのものが今の空気を表していて、IFCを「変換の受け皿」ではなく「AIに食わせる標準データ」として位置付ける流れが業界レベルで進んでいる、と読めます。
ゼネコンBIM担当としての独自考察
三つのニュースを並べて感じたのは、IFCの役割が「異なるソフト間の橋渡し」から「機械可読な設計情報の一次ソース」へ移ろうとしていること。ここにゼネコンとしての勝ち筋があると思ってます。
うちのような中堅ゼネコンだと、意匠は設計事務所、構造は別会社、設備はさらに別、というのが普通です。ネイティブファイル（.rvtや.pln）を直接もらえないケースも多く、結局IFCで受け取る。ところが冒頭に書いた通り、プロパティの欠落やGUIDのズレで数量が合わない事故が起きる。ここにLLMを噛ませられたら、というのが今の妄想です。IFCを読み込ませて「このモデルに含まれる鉄骨部材のプロパティで欠落しているものを列挙して」と聞ける仕組みができれば、受領時のQCチェックが人手でやるより速くなる可能性がある。まだ試せていないですが、Zennの記事の方向性はまさにそこに使えそうです。
社内標準化への活かし方でいうと、IFCの書き出しルール（Model View Definition、プロパティセット命名、分類コード）を先に固めておかないと、AIに読ませても結局ノイズが増えるだけ。うちでも部材分類の社内コードを整理中ですが、LLM時代を見据えるなら「人間が読みやすいテンプレ」より「機械が拾いやすいテンプレ」に軸足を移すべきかもしれない。積算チームからは「Excelに落ちてくればいい」と言われがちですが、その手前のIFC品質を上げる投資が、結果的に積算突合の工数を削る、という説明を根気強くやる必要がありそうです。
現実的なハードルは二つ。ひとつは協力会社側の書き出し環境がバラバラで、IFCの品質を発注段階で縛るのが難しいこと。もうひとつはLLMに社内BIMデータを食わせる際のセキュリティで、クラウド前提のツールは発注者との契約上NGなことが多い。だからこそ1Bクラスのローカルモデルや、軽量オフラインビューワの話が現場に刺さるわけです。
総括
IFCは長らく「とりあえず変換に使う中間フォーマット」扱いでしたが、今週のニュースを見る限り、AIに読ませる前提の一次データへと役割が変わりつつある。うちの社内標準を作り直すときの評価軸に「LLMで扱いやすいか」を一項目足そうと思ってます。来週、鉄骨IFCのプロパティ欠落パターンをまずリスト化するところから始めます。地味だけど、そこが出発点な気がしてます。