先週、協力会社から届いたDWGをRevitに取り込む段で、通り芯のレイヤ名が案件ごとにバラバラで半日溶かしました。DWGは死なない、というより、しばらく死ねない。そう再確認した週に、AutoCAD周辺で面白い記事がいくつか出ていたので整理しておきます。
今週の注目トピック
点群からDXFを吐く、NumPyだけの鉄筋計測
NumPyで点群データから鉄筋の軸を自動計測するは、壁から突き出したD51鉄筋の点群（LAS）を読み込んで、1本ずつ切り分け、軸ベクトルと直径を出し、壁面法線に対する水平・鉛直ずれと角度を計算、CSVとDXFに書き出すという内容です。NumPyと標準ライブラリのみ、外部の重いライブラリに寄らない構成が実務的でした。
デコイチ（D51）の位置精度は、施工検査で毎回もめるポイントです。トータルステーションで1本ずつ当たっている現場もまだあるので、点群→自動計測→DXFで検査図に重ねる流れがそのまま業務に刺さりそうだと感じました。出力先がDXFなのが渋くて、AutoCAD LTしか入っていない検査担当のPCでも開けます。
DWGをGeoPackage化してGISへ橋渡し
CADとGISをつなぐ ── LibreDWG × GDALでDWGをQGIS/ArcGIS pro 対応GeoPackageへ変換するは、GNU LibreDWGとGDAL/OGRを組み合わせて、DWGをGeoPackageに変換するDocker環境の話です。河川図・道路図・施設台帳あたりは、元がCADで管理されつつ最終的にGISで解析、というパターンが多く、DWG直読みで詰まった経験がある人には刺さる構成だと思います。
土木案件で発注者から渡される平面図をQGISに載せる作業、うちでも地味に発生します。Dockerでパイプライン化されていれば、案件フォルダに放り込んで一括変換、という運用に載せやすい。
Text to CADは設計の入口をどこまで変えるか
テキストを入力するだけでCADモデルが完成——Text to CAD の今と、設計現場が変わる未来では、SolidWorksやAutoCAD、Fusion 360の習得コストを前提に、テキスト入力からモデルを生成する潮流を紹介しています。建築より製造寄りの文脈ですが、スケッチ→フィーチャ積み上げのプロセスを言語で置き換える発想は、建築のファミリ作成や汎用部材のモデリングにも波及しそうです。
ゼネコンBIM担当としての独自考察
既存業務への効きどころ
点群→鉄筋自動計測の話は、うちの品質管理フローにそのまま乗る余地があると思ってます。今は3Dスキャナで撮った点群を、外注で報告書化してもらっているのですが、コアな計測処理がNumPyレベルで書けるなら、社内の検査テンプレDXFに重ねて出力するところまで内製化できるかもしれない。まだ試せていませんが、D51以外の径にパラメータを振れば、そのまま横展開できそうです。
DWG→GeoPackageのパイプラインは、造成・外構・インフラ工事で効くはずです。発注者提供の地形DWGと、自社のBIMモデル（IFC）を、GIS側で重ねて土量や周辺影響を見る、という用途は積算段階で需要があります。
社内標準化への活かし方
共通するのは「DWGを中間フォーマットとしてどう扱うか」という論点です。うちの一貫BIM標準では、Revit中心の運用を掲げつつ、協力会社との受け渡しは当面DWGが残る前提で組んでいます。だとすれば、DWGを入口・出口の両面で自動処理する仕組み（点群→DXF、DWG→GeoPackage）を社内ツール群に組み込むほうが現実的です。Revitで全部やる、と旗を振るより、DWGとの共存を前提にした方が普及します。
導入ハードル
点群処理もDocker運用も、書ける人が社内に少ない。ここが一番きついです。BIM推進室にPython書ける若手が数人いる程度で、現場に配ると誰も触れない未来が見えます。GUIラッパを被せて「フォルダに点群を入れたらDXFが出る」くらいまで落とし込まないと定着しない。Text to CADも、和文の建築用語対応や社内ファミリライブラリとの接続を考えると、まだ様子見の段階だと感じてます。
総括
今週の3本は、AutoCADそのものの新機能というより、DWG/DXFを軸にした周辺エコシステムの動きでした。派手さはないですが、うちみたいに協力会社との連携でDWGが残る現場では、こういう地味な自動化のほうが効きます。まずは点群→DXFのスクリプトを、来月の壁配筋検査で試してみるつもりです。