先週、協力会社とのモデル調整で半日つぶれた。鉄骨のブラケット位置が意匠モデルと構造モデルで15mmずれていて、施工図の担当者が電話口で困っていた。こういう地味な擦り合わせを減らしたくてBIM標準化を進めているのだが、今週の記事を眺めていると、似たような課題に別角度から取り組んでいる人たちの動きがちらほら見えた。整理しておく。
LLMがIFCを読む日は来るのか
今週いちばん気になったのは、Gemma 3 1Bを4万件のBIMデータでファインチューニングしたという実験記事だった（LLMはIFCを理解できるのか？Gemma 3 1Bを4万件のBIMデータで学習させてみた）。IFCの構造をLLMに学習させる試みで、小型モデルでどこまでいけるかを検証している。
正直、うちの実務ですぐ使えるかというと微妙だと思ってる。IFCは属性の入り方が現場ごとにバラバラで、そもそもの入力品質が担保されていないと学習させても意味がない。ただ、モデルチェックや属性抽出をLLMに任せられるなら、社内標準テンプレの遵守チェックを自動化する道は見えてくる。テンプレを守らせるための人的レビューが今けっこう重い。
Revit上での自動化はもう動いている
アレントのLightningBIM 自動配筋の英語版リリース、それから関電工とアレントの設計自動化・根拠図作成の短縮のニュースも同時期に出ていた。RC配筋や設備の根拠図といった、手数がかかる割に創造性の低い工程から自動化が入ってきている。この方向は素直に納得できる。
クラウドBIMと「モデルはいつ使えるのか」問題
海外記事だとCloud BIM Servicesの協働改善と、When Is a BIM Model Actually Ready to Be Used?が同じ週に並んだのが象徴的だった。クラウドで協働環境は整いつつあるが、「そのモデルが実際の意思決定に使える状態か」は別問題だ、という指摘。
これは現場でも本当に痛感する。見た目は完成しているモデルが、積算に回すと数量が合わない。発注者に見せると「この壁の仕様は？」と聞かれて属性が空。LOD（詳細度）だけでなく、LOI（情報量）をどこで揃えるかを工程ごとに明文化しないと、モデルは「見るためのもの」で止まってしまう。
地場ゼネコンの15年と、AI活用の意識改革
千葉の平山建設が15年かけて残業を月40時間超から26時間台に減らしたという建設DXの記事は、地味だけど読み応えがあった。派手なBIMの話ではなく、Gmail導入から始まって積み上げてきた話。ツールより運用の粘りが効いている。
一方で建築設計事務所のAI活用を2年やってきたKOBATAKAさんの記事では、2026年に入ってからCopilotを前提にした業務設計に切り替える必要が出てきたと書かれていた。BIMもAIも、道具を入れるフェーズから業務そのものを組み替えるフェーズに来ている感覚は共有できる。
ゼネコンBIM担当としての独自考察
今週の記事群を通して、自分の担当領域で活かせそうなポイントを3つに絞って考えた。
ひとつめ、自動配筋や根拠図作成のような「手数が重い定型工程」の自動化は、社内標準テンプレとセットで導入すべきだと思ってる。ツール単体で入れても、部署ごとにテンプレがバラバラなら効果が出ない。うちの現場だと構造と設備でファミリの命名規則すら統一できていないので、まずそこから。地味だけど避けて通れない。
ふたつめ、LLMによるIFC理解の話は、モデルチェックの前段として使えるか試してみたい。今は目視と簡易チェッカーの併用だが、属性の抜けや命名違反をLLMに一次レビューさせるだけでも協力会社への差戻しが減るはず。まだ試せていないが、社内の標準ガイドラインをRAGで参照させれば、テンプレ遵守の一次スクリーニングくらいはいけそうな気がしている。
みっつめ、導入ハードルとして一番大きいのは、結局のところ協力会社側のスキルとPCスペックだ。うちがいくらクラウドBIMを整えても、鉄骨ファブや設備サブコンの担当者がモデルを開けない・触れないなら意味がない。この部分は技術というより、契約と教育の設計の話になる。ここを飛ばしてAIの話をしても現場は動かない。
総括
今週は自動化ツールの前進と、AI・LLMの実装検証、そして「モデルが本当に使える状態とは何か」という問いが同時に流れてきた週だった。派手な発表より、平山建設の15年のほうが自分には響いた。標準化は一発逆転がない領域だから、来週は社内のファミリ命名規則の棚卸しから手をつけ直そうと思う。地味な話に戻る。