先週、協力会社から受け取ったRebroのモデルをRevit側に取り込む作業で半日潰しました。IFC経由で入れると要素がジェネリックモデルに落ちてしまい、MEPとしての属性が飛ぶ。この手戻りが毎案件のように起きていて、ゼネコン側のBIM担当としては地味に重い課題です。今週はそのモヤモヤに刺さるRebro関連の記事が複数出ていたので、まとめてみます。
今週のRebro関連トピック
1. Revit APIでIFC(T-fas/Rebro)をRevit MEPに変換する試み
Qiitaに上がっていた個人検証記事。IFCからJSONを経由してRevit APIでダクトの直線部を生成する、というアプローチが公開されました(【Revit API】IFC要素をRevit MEP要素へ置換する方法の模索をした)。
現状はダクト直線部の生成までで、端点接続の自動化は未完成とのこと。ただ「IFC→JSON→Revit API」という中間フォーマットを噛ませる発想は、設備BIMの相互運用で誰もが一度は考える道筋で、それを実コードで公開してくれた点がありがたい。継手やフィッティングの復元、系統情報の保持あたりが次のハードルになりそうです。
2. SPIDER+のBIM機能がRebroビュワーと連携
施工管理アプリのSPIDER+が、清水建設らとの共同開発でRebroビュワーとの連携機能を出しました(SPIDER+のBIM活用機能が「Rebro」ビュワーと連携、清水建設らと共同開発)。
詳細機能は元記事の範囲でしか分かりませんが、現場で撮った写真や指摘事項をRebroモデル上の位置と紐づけられる方向のはず。設備の是正指示を紙やExcelで回している現場が多い実態を考えると、これは効きそう。
3. ANDPADがRebro2025とのデータ連携を開始
ANDPAD側からもRebro2025との連携開始のアナウンスが出ています(建築設備専用CAD「Rebro2025」とのデータ連携を開始)。施工管理SaaS側からRebroに寄っていく流れがはっきりしてきました。
SPIDER+とANDPAD、両方向から同時期に連携が進んでいるのは、設備施工の現場アプリ側にとってRebroが事実上の基準点になりつつあることの表れだと感じてます。
ゼネコンBIM担当としての独自考察
3つの記事を並べて眺めると、Rebroを軸にした「上流(設計・干渉調整)」と「下流(施工管理・是正)」の両側からの引力が同時に強まっている、という構図に見えます。うちの社内標準の議論に落とすと、正直悩ましい話です。
意匠・構造をRevitで、設備をRebroで、というハイブリッド運用は現実的な妥協解として社内でも定着しつつあります。ただ発注者から「一貫BIMで納品」と言われた瞬間、RebroモデルをどうRevit側の総合モデルに統合するかで毎回消耗する。Qiitaの検証記事のようなIFC→JSON→APIの経路が実用レベルになれば、少なくともダクト・配管の直線部分だけでも自動で置換できる余地が出てきます。うちの現場だと、系統色分けとフィッティング情報が保持できるかが分かれ目になりそう。まだ試せていないので、来週あたり社内のダミーモデルで挙動を見てみるつもりです。
SPIDER+やANDPADとの連携については、協力会社の設備業者さんがRebroモデルをそのまま使い続けられる、という点で導入ハードルが低いのが強み。ゼネコン側がRevitに寄せろと号令をかけても、専門工事会社の実務はRebroで回っている。だったら現場アプリ側でRebroを扱えるようにする方が、全体としての工数削減効果は大きいはずです。社内標準テンプレも「Rebroモデルをそのまま使える前提」で施工段階のフローを組み直す時期に来ていると感じてます。
導入ハードルとして残るのは、やはり積算との突合。ビュワー連携で数量や属性まで拾えるのか、それとも見るだけなのか。ここは各ツールの実装をもう少し追う必要があります。
まとめ
Rebroを中心にした連携が、上流(Revit相互変換の試み)と下流(SPIDER+・ANDPAD)から同時に厚くなってきた一週間でした。一貫BIMという言葉に振り回されるより、Rebroが強い設備領域はRebroのまま流し、繋ぎ目をどう自動化するかを考えたほうが早い。来週は社内の設備担当と、Qiita記事のアプローチを試す時間を取ります。