先週、社内の若手数人と現場合宿的に既存改修案件の点群データを触っていた。データ容量は50GBを超え、Revitに載せるだけで一苦労。設計担当からは「壁芯どこ？」、積算からは「これで数量拾えるの？」と質問が飛ぶ。点群は撮れば済むものではなく、その後の使い道で価値が決まると改めて思った週だった。今週の記事群は、その「使い道」を考えるヒントになった。
今週拾った動き
点群を「使える3Dモデル」に変換するアプローチ
アイサンテクノロジーが第8回 国際 建設・測量展で示した提案は、点群データをそのまま渡すのではなく、設計・維持管理で使える3Dモデルへ変換する部分に軸足を置いている(点群データを設計・維持管理で”使える3Dモデル”に アイサンテクノロジーの新提案)。うちでも点群→CAD/BIM変換の外注費が案件ごとに膨らんでおり、ここを内製化できるか否かが標準化の分かれ目になっている。
計測の「壊れる場所」を先に押さえる発想
furuse氏の紙面計測PoCは、真値をあらかじめ紙面に仕込んで画像計測がどこで破綻するかを可視化する試み(紙面の計測館 ―― 真値を自分で仕込んで、画像計測の「壊れる場所」を先に知る)。同じ著者のFullseyeでは、古典画像処理を”説明できるスキル”として蓄える方向性が語られている(説明できる古典画像処理を「スキル」として1000個持ち歩く)。点群やSfMも似た構図で、精度が落ちる条件を先に把握しておくことが、後工程での手戻りを防ぐ。反射面、暗所、細長い部材まわりで点が抜ける癖は現場でも経験済みで、事前に「壊れ方カタログ」を持っておく発想は真似したい。
大規模地形の測量を継続する実例
ゲーム地形をマイクラで再現するために一年半ひたすら測量を続けたという記事(mcfunctionでマイクラの地形生成を自動化する)は、趣味の話に見えて、大量の測点を扱う運用ノウハウという意味では参考になる。地形データをmcfunctionという実行形式に落として自動生成する流れは、点群→IFCやRevit family化を自動パイプラインにする発想と近い。
ゼネコンBIM担当としての独自考察
点群測量の話題は毎年出るのに、社内で本当に定着している用途は改修前の現況確認と出来形検査くらい、というのが正直な現状。設計・積算・施工管理まで一貫して使えている案件は数えるほどしかない。今週の記事を踏まえて、うちの業務に落とすなら三つの方向があると思ってます。
一つ目は、変換工程の内製化。アイサンの提案のように「使える3Dモデル」を出口に据えると、点群を撮って終わりではなく、面・エッジ・部材単位でBIM化するところまで自社の標準フローに組み込む必要がある。ここを外注に丸投げしている限り、案件ごとにモデル粒度がばらつき、積算との数量突合で毎回もめる。社内標準テンプレに「点群由来モデルのLOD定義」を追記するのが次の一手だと考えてます。
二つ目は、精度保証の仕組み化。furuse氏の「真値を仕込む」発想は、現場でも検証ターゲットを事前配置して事後に誤差評価する運用に置き換えられる。協力会社の測量業者ごとに機材も手順も違うので、共通の検証プロトコルを渡せば、成果物の品質を揃えやすい。まだ試せていないが、次の改修案件でパイロット運用したい。
三つ目は、発注者説明での使いどころ。点群ビューアをそのまま見せると「重い」「わかりにくい」と言われがちで、結局スクリーンショットのPDFに戻る。設計・維持管理で使えるモデルまで落とし込めば、発注者側のFMシステムへの引き渡しも楽になる。ここは営業段階から握っておかないと、成果物仕様が固まってから慌てることになる。
導入ハードルとしては、機材費より人材と時間。点群を扱える若手が社内に片手で数えるほどしかいなくて、案件が重なると回らない。教育コンテンツを整備しつつ、変換の自動化ツールに投資するのが現実解だと思ってます。
総括
点群は撮るフェーズから、使うフェーズへ論点が移ってきた。今週の記事はどれも「計測データをどう次工程に渡すか」を問うている。うちの一貫BIM推進でも、点群を独立したツールではなく設計・積算・FMまで貫くデータ源として位置づけ直す時期に来ている。来月の社内勉強会で、点群由来モデルのLOD定義案を叩き台として出してみるつもり。