今週「Dynamo」で情報収集をかけてみたら、上位14件のうち、Autodesk Dynamo（Revit連携の視覚プログラミングツール）に関する記事はゼロでした。ヒットしたのはAWSのDynamoDB、BIM Automationの短い投稿、あとはサッカークラブのDynamo Bryanskの試合結果。BIM推進担当としては肩透かしですが、逆にこの状況から学べることもあったので整理します。
今週のDynamo関連トピック
DynamoDB周りが記事の大半を占めていた
ZennのDynamoDBを諦めないためのZero-ETLやGSI1本で「横断一覧」と「ID検索」を両立するシングルテーブル設計、Qiitaの今更だけど、DynamoDBの設計の勘所をサクッとまとめてみたなど、AWSのキーバリューDB「DynamoDB」の設計論が並んでいます。特に目を引いたのは、DynamoDBに追加されたベクトル検索をStreamsでベクトル化してStrands Agentsから使ってみたという記事で、DynamoDBがベクトル検索に対応した動きです。ZennのDynamoDB Vector Searchは「ベクトルDBの代替」ではないでは、同期処理の観点から従来のベクトルDBとの使い分けを論じています。
建築とは無関係に見えますが、RAG（検索拡張生成）の基盤としてこの手のDBが使われる流れは、社内BIMデータのAI活用を考えるうえで無視できません。QiitaのRAGに古い情報で答えさせないためには？は、リレーショナル・ドキュメント・ベクトルを1つにまとめる「コンバージドデータベース」の考え方を紹介していて、社内標準のマスタとRevitのモデル情報をどう繋ぐかを考えるヒントになりました。
唯一のBIM関連はタイトルだけの投稿
MediumのBIM AUTOMATIONは「Expectation vs. Reality」という一言だけで本文がほぼ無し。Dynamoによる自動化が「期待通りにいかない」という皮肉だけが残る投稿ですが、現場感覚としてはうなずけます。私も配管クリアランスチェックのグラフを組んだとき、期待は「全物件で使い回せる汎用ノード」だったのに、現実は「案件ごとに家族カテゴリの命名が違って毎回書き直し」でした。
Web検索連携LLMの進化
QiitaのBedrockのOpenAIモデルでWeb検索が使えるようになったでは、API呼び出しにtoolsを一行足すだけで最新情報を踏まえた回答が返る仕組みが紹介されていました。Dynamoスクリプトの書き方をLLMに聞いたときに、古いRevit APIの回答が返ってくる問題への対処として使えそうです。
ゼネコンBIM担当としての独自考察
今週の収穫は「Autodesk Dynamoの新機能や事例が全然出てこない」という事実そのものでした。Qiita・Zennという技術者コミュニティでDynamoといえばもうDynamoDBを指す、というのが実情。建築系Dynamoの情報が国内Web上で細っている感覚は、ここ半年ずっと感じています。
これは社内標準化を進めるうえで結構キツい話で、若手にDynamoを教えるときの参考記事が枯渇していく。うちでも「面積表自動作成」「建具リスト出力」あたりのグラフを社内テンプレとして配布していますが、メンテできる人が数人しかいなくて属人化しています。個人的には、DynamoからPython Scriptノード経由でpyRevitやC# APIに寄せていく流れが加速する気がしていて、視覚プログラミング止まりだと限界が見えてきたのかな、と感じてます。
一方で、DynamoDB×ベクトル検索×RAGの話は他人事じゃありません。過去物件の納まり事例や協力会社からの質疑応答をベクトル化して、Revit上でLLMに聞ける仕組みを作れれば、若手の質問対応工数がかなり減るはず。社内標準テンプレの更新履歴もRAGに載せておけば、「このファミリはいつから使える？」の問い合わせが減る。導入ハードルは、社内データを外部クラウドに載せる規程の壁と、Revitモデルからテキスト抽出する前処理の泥臭さ。ここは総務・情シスとの調整が本丸です。
総括
今週のDynamoトレンドは、建築業界的にはほぼ空振り。ただ、AI基盤側の記事を読み込んでおくと、来年あたりBIM×RAGの話が降ってきたときに慌てずに済みそうです。来週はpyRevitとDynamoの併用事例を自分で書いて出そうかと思ってます。情報が無いなら作る側に回るしかない。