今週、社内の定例で「来期の施工管理テンプレ、どこまでFormaに寄せるか」という話題が出た。ちょうどそのタイミングで清水建設の「20億、2人」構想とAU 2026の発表が重なり、議事録を取る手が止まった。描くBIMから判断するBIMへ、という文脈が一気に具体化してきた印象がある。今週のAutodesk関連記事を、現場の視点で整理しておきたい。
AU 2026で見えたAI機能の方向性
AU 2026では、Fusion・Inventor・Vaultに対する新しいAI機能が発表された（Autodesk、FusionなどのAI機能を発表 設計作業の自動化や設計資産の再利用を支援）。部品編集や組立、製造工程の自動化、PLMとの連携強化が柱で、設計資産の再利用に軸足を置いた作りに見える。
建設側では、Autodesk副社長のニコラ・マンゴン氏が「BIMを描くからAIで判断するへ」というメッセージを出している（Autodesk副社長が語る「BIMを描くからAIで判断するへ」）。Formaをデータ分断の解消基盤に据え、AIが最適解のモデルを提案するという絵姿だ。今までDynamoやスクリプトで無理やり繋いでいた部分を、プラットフォーム側で面倒を見ますよ、という宣言と受け取っている。
清水建設「20億、2人」とForma
個人的に一番刺さったのが清水建設の事例（Forma活用で「20億規模の現場を2人で運営」）。20億円規模の現場を常駐2人で回すという数字を、Formaを基盤にBIMデータと「言葉」を結びつけたAIで実現しようとしている。鉄筋の納まり判断や製造連携まで視野に入れているのが面白い。
うちの現場で20億を2人は正直想像しにくい。ただ、配筋検査や段取り打合せに割いている時間を思い出すと、判断支援のAIが入れば1〜2人分の工数は確実に浮く余地はある、と感じてる。
XLBとFusion ― エッジでAutodeskが広げている領域
開発者コミュニティ側の動きも押さえておきたい。ShibataRyoichi氏の連載では、Autodeskが公開するLBM流体解析ライブラリ「XLB」の活用が続いている（例題rotating_sphere_3d.pyの分析、Warp導入方法と動作確認、multires_windtunnel_3d.pyの分析、Neon導入方法とマルチ解像度例題）。NVIDIA Warp、JAX、Autodesk Neonをバックエンドに選べるPython製で、GPUで高速化した3次元流体解析が手元のWSL環境で動かせる。
もうひとつ、Claude Code経由でFusionを操作しトゥールビヨン腕時計を設計したという記事もあった（Claude Opus 5.5が三日三晩でトゥールビヨン腕時計を設計した話）。LLMがCADを叩く世界は、建築のファミリ作成や詳細図整備にも地続きだと思ってる。
ゼネコンBIM担当としての独自考察
「判断するBIM」という言葉は響きが良いが、うちの社内に落とすとき最初に問われるのは、誰の責任で判断するのか、という点になる。鉄筋の納まりをAIが提案したとして、構造設計者の承認フローとどう接続するか。協力会社との施工図調整で、AIが出した案を鉄筋屋さんが拒否したときに戻るべき元データがどこにあるか。Formaが「言葉」をデータに紐づける方向に進むのは理に適っているが、社内標準化の観点ではタグ辞書や属性命名ルールを先に整備しないと、学習させる前に泥沼になる気がしている。
既存業務への応用で現実的なのは、まず数量と干渉チェックの一次判断だと思う。積算との数量突合は今でもExcel往復が多く、ここをFormaとAIで自動化できれば、月次の工数レポートで効果を示しやすい。発注者への説明資料も、モデルから自動生成できる範囲が広がれば、週報作成の負担が下がる。
一方でハードルも見える。協力会社がFormaのライセンスを持っていないケースが大半で、ビューワ運用で済ませる現状のまま「判断するBIM」に乗せるのは難しい。XLBのような解析ツールも魅力的だが、設計部門との役割分担をはっきりさせないと「BIM推進が解析まで巻き取る」状態になりかねない。うちの体制ではまず熱環境や換気の初期検討に絞って試す、くらいが現実的な線だと見てる。
まとめ
今週のAutodeskは、Formaを核にした「判断するBIM」のビジョンと、XLBやFusion×LLMといった足元の技術層が同時に進んでいることを示した一週間だった。ビジョンに乗る前に、属性命名と協力会社の運用環境を整える。来週の社内会議で、まずその2点を議題に上げようと思う。