金曜の夜、いつも通り「Dynamo」でニュース検索をかけたら、AutodeskのビジュアルプログラミングツールDynamoの記事はゼロ件だった。出てきたのはAWSのDynamoDB、NVIDIAのGPU、そしてMLSのヒューストン・ダイナモ。建築業界の狭さというより、IT側の「Dynamo」の情報量に押し流されている感覚がある。せっかくなので今週は視点を変えて、周辺で盛り上がっていた話題から、社内のBIM推進に持ち帰れそうな断片を拾ってみます。
今週のDynamo関連記事、実は建築の話がゼロ
データベース系Dynamoの話題が中心
今週の目玉は、AWSのDynamoDB絡みで2本。【DynamoDB】GSI1本で「横断一覧」と「ID検索」を両立するシングルテーブル設計は、1つのテーブルに複数の用途を詰め込みつつ、GSI（グローバルセカンダリインデックス）1本で検索経路を確保するという設計論。OLTP脳でBigQueryに入門してみた（PostgreSQL・DynamoDB経験者向け）は、トランザクション処理に慣れた頭で分析基盤に触れたときのギャップを書いている。
個人開発の連載記事、【Day2】クラウドプラクティショナー取得後の第一歩！サーバーレス読書記録アプリを1週間で作ってみたもDynamoDBを使ったバックエンド構築の話。名前の重なりで検索に引っかかってきただけなのだが、読んでみるとBIMのデータ設計に通じる話が多い。
ハードウェア側のニュース
IntelがNVIDIA・AMDに逆張り — 高価なHBMを捨てLPDDR5Xで480GB大容量を実現した次世代AI GPU「Crescent Island」、NVIDIA「Groq 3 LPX」が量産へ、3,431トークン/秒が変えるAI推論の2本。BIMと直接は関係ないが、AI推論の速度と容量が一段上がると、点群処理やDynamoスクリプトのAI補助生成が現実味を帯びる。
スポーツのDynamo
ヒューストン・ダイナモ対サンノゼ・アースクエイクスの試合速報とHouston Dynamo 2。同名のMLSクラブの試合結果で、今回は割愛。
ゼネコンBIM担当としての独自考察
DynamoDBの「シングルテーブル設計」がRevitモデルの整理と重なる
ma_sa_shiさんの記事を読んでいて、うちの社内で運用している共有パラメータの設計と話がそっくりだと感じました。1本のテーブル（=1つのRevitモデル）に複数種類のデータ（意匠・構造・設備・仕上げ・積算属性）を突っ込みつつ、GSIに相当する「タグ付け」や「ビューフィルタ」で検索経路を作る。DynamoDBの世界では当たり前の設計思想らしいのだが、Revit+Dynamo（Autodesk版）でパラメータ設計する時にも同じ発想が効くはず。
実際、先月協力会社に配った建具の集計スクリプトで、パラメータの命名がバラバラだったせいで積算部門との数量突合が半日つぶれた。あの時「検索キーを1本に統一する」という視点があれば、GSI的な発想で先に設計できたと思ってます。
社内標準化への活かし方
Dynamo（Autodesk）スクリプトを社内展開すると、必ず「誰も触れない秘伝のノード群」が生まれます。DynamoDBのシングルテーブル設計で言われている「アクセスパターンを先に決めてから設計する」という順番は、そのままDynamoスクリプトの標準化にも使える。何を入力に、何を出力するかを先に決めてからノードを組む。当たり前だが、うちの若手（自分含む）はつい先にノードから触ってしまう。
現実的な導入ハードル
この手の設計論を社内標準に落とし込もうとすると、必ず「で、既存プロジェクトのパラメータ全部揃え直すの？」という話になる。答えはNoで、新規案件から段階的に、が現実解。ただ協力会社のRevitリテラシーがバラバラな以上、テンプレート配布だけでは徹底できない。DynamoスクリプトのGUI化（Data-Shapesなど）で「触らせない・見せるだけ」の運用に倒すのが、うちの規模だと落としどころかもしれません。
総括
建築側のDynamoニュースがゼロの週は、逆に周辺のIT記事を読む余裕ができる。DynamoDBの設計思想は、Revit＋Dynamoのパラメータ設計と骨格が近い。来週は社内の共有パラメータ表を引っ張り出して、アクセスパターンから逆算し直してみます。ノードを触るのはその後。