月曜の朝、協力会社から「このDWG、うちのAutoCAD 2024だと開けるけど挙動が怪しい」と電話が来た。年版違いの開発環境を社内で揃える話は、BIM標準化の裏側で地味に響いてくる。今週のAutodesk関連ニュースを眺めていて、まさにこの話題を正面から扱った記事があったので、そこを起点に整理してみます。
AutoCADまわりの開発環境が、思った以上に分岐している
tanoue2715氏が立て続けに公開した3本の記事が、現場で地味に役立つ内容でした。
年版判定とUpdate識別
AutoLISPでAutoCADの製品年式とUpdateを判定する：ACADVERと_VERNUM では、`ACADVER`で製品リリース、`_VERNUM`でビルド番号を取る方法が紹介されています。AutoCAD 2026.1.2なら`ACADVER`が”25.1s (LMS Tech)”になる、といった具体例付き。社内配布のLISPで「このバージョンでは分岐処理を入れる」といった制御を書くとき、Update単位で判定できるかどうかは意外と大きい。
ObjectARXと.NET APIの世代マップ
現在入手可能なAutoCAD向けObjectARX（C++）開発環境一覧 と 現在入手可能なAutoCAD向け.NET API開発環境一覧 は、AutoCAD 2024〜2027を対象に、Visual Studio・Platform Toolset・SDK・バイナリ互換の対応表を整理したものです。.NET側は.NET Framework 4.8 → .NET 8 → .NET 10と3世代が並走していて、2026年には2025系と新しい版が同じ社内に共存する状況になる。社内製アドインを保守している身からすると、「どの年版まで同一ソースでいけるか」を決めるのに使える資料です。
AutodeskのAI戦略：AU 2026とTransparency Cards
「何を使うか」から「何を解決するか」へ、Autodeskが描くAI時代の設計／製造 では、AU 2026のキーノートでFusionによる反復作業削減や、部品供給不足に対応するエージェント型PLMが紹介されたと報じられています。製造寄りの話ではあるものの、ツール選定より課題解決に軸を置くというメッセージは、AEC領域にも当然響いてきます。
同時期に AI Transparency Cards の拡充も公表された。生成AIが設計成果物に関わってくると、発注者から「このモデルのどこがAI生成か」を問われる場面が確実に出てくる。説明責任のための仕様書が整備されるのは、社内承認フローを設計するうえでありがたい動きです。
ゼネコンBIM担当としての独自考察
開発環境の記事を読みながら考えていたのは、社内アドインの保守方針です。うちは積算連携のためにAutoCAD上で動く社内製の数量拾いツールを長年使っていて、.NET Framework 4.8のまま塩漬けになっています。協力会社に配るときはAutoCAD 2024〜2026が混在するので、どの版をビルドターゲットにするかで毎回揉める。.NET 8と.NET 10が並走する今の状況だと、「どこかで一度プロジェクトを分割する決断がいる」というのが正直な感想です。tanoue2715氏の対応表は、その決断材料として社内資料にそのまま貼りたいレベル。
AI Transparency Cardsのほうは、発注者対応で使えそうだと感じています。公共案件だと「このBIMモデルの作成プロセスを説明してほしい」と求められることがあり、生成AIを部分的に使った場合の説明テンプレが社内にまだない。Autodeskが公式に出している仕様書を参照する形にしておけば、少なくとも「野良の生成物ではない」ことは示せる。まだ試せていないが、Transparency Cardsを社内BIM標準の付録にぶら下げる運用は現実的だと思ってます。
一方でAU 2026で発表されたエージェント型PLMのような話は、ゼネコン側がすぐに取り込めるかというと怪しい。協力会社の多くはいまだにPDF図面が主戦場で、エージェントが動く前提のデータ構造になっていない。社内先行で検証して、効果が出た部分だけ協力会社向けのテンプレに落とす、という二段構えが現実解になりそうです。
総括
今週のAutodesk関連は、派手なAI新機能の発表と、足元の開発環境整理が同時に走っていた週でした。前者は社内説明用の材料として、後者は社内アドイン保守の判断材料として、それぞれ別の棚にしまっておく。来週、積算チームとの定例で.NETの世代問題を切り出してみるつもりです。