はじめに：「Dynamo」で検索すると見えてくる、意外な景色
BIM推進担当としてRevitのDynamo（ビジュアルプログラミング）に日々触れている身からすると、「Dynamo」という単語で情報収集をかけると、実は建築系の話題は少数派だと気づかされます。今週も、AWSのDynamoDB、サッカークラブのDynamo Moscow/Dresden、そしてMediumの海外Dynamoユーザーの投稿が混在していました。
ただ、その中に「AIで建築3Dモデルを生成する時代におけるBIMの立ち位置」という、我々BIM推進担当としては見逃せないテーマの記事もあり、加えてDynamoスクリプトの高速化という実務直結のTipsも出てきています。今週はこの2軸で、建築業界視点でのDynamo関連トレンドを整理してみます。
トピック1：AI時代における「BIMの手前」の価値
今週もっとも刺さったのがこの記事です。
Claude Codeで建築物の3Dモデルを生成した筆者に対し、建築関係者が「建設業界はAIをまだ全然使えていない。極めたら金脈」と反応した、という話。単なる3D生成ではなく、BIMに至る前段階（法規チェック、ボリューム検討、初期プランニング）にこそ価値がある、という指摘は非常に的を射ています。
ここでRevit DynamoやDynamo Playerを使い倒してきた身として思うのは、「AIによる形状生成」と「Dynamoによるパラメトリック操作」は競合ではなく、補完関係にあるということ。生成AIが叩き台を出し、Dynamoが社内標準テンプレートに沿ってパラメータ整形する、という流れは十分現実的です。
関連：構成図の自動生成という発想
ZOZOのIT系記事ですが、「ドキュメントを手描きせずコードから自動生成する」という発想は、BIMから施工図・積算資料を自動生成するDynamoワークフローと本質的に同じです。「モデルを一次情報とし、二次成果物は全自動」という思想は、我々の一貫BIM構想にそのまま輸入できます。
トピック2：Dynamoスクリプトの「遅さ」に効くTips
タイトルの通り、Dynamoで「全要素をCollectorで拾ってからFilter」という書き方をしていると、大規模モデルで一気に遅くなる、という指摘。CategoryやLevelで先に絞り込むべし、という基本ですが、社内で配布しているスクリプトを見直すと、意外とこの「全部取ってから絞る」実装が多いのが実情です。
ゼネコンで扱うモデルは数十MB～数百MBが当たり前。スクリプト実行時間はそのままユーザーのストレスと標準化の失敗リスクに直結します。配布前のコードレビューに「Collector最適化」を項目として追加すべきだと感じました。
トピック3：ノイズ記事から見える「Dynamo」の情報環境
一方で、DynamoDBのGSI/LSIに関する記事や、PSGのDynamo移籍記事、Dynamo Dresden/Moscowの試合結果（Dresden-Karlsruhe、Pari-Dynamo Moscow、Dresden-Kaiserslautern）など、建築とは無関係の「Dynamo」が大半を占めます。これはRevit Dynamoが日本の建築業界内でしか話題にならないという情報の細さも示していて、社内知見の蓄積・発信の重要性を改めて感じます。
ゼネコンBIM担当としての独自考察
既存業務への応用可能性
今週のトレンドを踏まえると、Dynamoの役割は「モデル操作の自動化ツール」から、「AI生成物とBIMマスターの橋渡し役」にシフトしていくと感じます。生成AIが出した粗い形状を、社内標準の命名規則・パラメータ・カテゴリに正規化する処理は、まさにDynamoの得意領域です。
社内標準化への活かし方
- スクリプトの性能基準を明文化：Collector最適化、ノード数上限、実行時間の目安を配布前チェックリスト化する
- 「AI生成→Dynamo整形→Revit配置」のパイプライン試作：初期ボリューム検討フェーズで、設計部と共同でPoCを回す
- 協力会社への配布形態はDynamo Player＋固定