AutoCAD VBAを掌握する極限の知見：Versionプロパティによる実行環境の動的制御と互換性担保のアーキテクチャ
AutoCAD VBA（Visual Basic for Applications）による開発の現場において、最も避けて通れない、そして最も多くのエンジニアを苦しめる悪夢がある。それが「バージョン差異による突然のクラッシュ（実行時エラー）」だ。
ある部署のAutoCAD 2021では完璧に動作する自動化スクリプトが、別の部署のAutoCAD 2025では`Object doesn’t support this property or method`（オブジェクトは、このプロパティまたはメソッドをサポートしていません）という無慈悲なエラーを吐いて沈黙する。この現象の根源は、AutoCADが毎年バージョンアップを重ねる中で、COM（Component Object Model）インターフェースの拡張、非推奨機能の削除、さらには内部データ構造の刷新を行っている点にある。
今回は、`AcadApplication.Version`プロパティを起点として、異なる実行環境を完全に把握し、バージョン依存の爆弾をスマートに回避する堅牢なコード設計の極意を伝授する。
—
1. なぜ「内部バージョン番号」を知る必要があるのか
AutoCADのバージョンを語るとき、私たちはついつい「AutoCAD 2024」「AutoCAD 2025」といったプロダクト名（西暦）を使いがちだ。しかし、VBAの裏側で動いているCOMサーバー、すなわち `AcadApplication` が認識しているのはプロダクト名ではない。返されるのは 「内部バージョン文字列」 である。
主要なAutoCADバージョンの内部マッピングを以下に記す。
- AutoCAD 2022: `24.0`
- AutoCAD 2023: `24.2` （※24.1は存在しない、または内部ビルド）
- AutoCAD 2024: `24.3`
- AutoCAD 2025: `24.4` （※一部環境やマイナービルドによる変動あり）
「なぜ西暦と番号が一致しないのか」といった疑問に時間を割く必要はない。重要なのは、VBAコードは実行瞬間の `Application.Version` を評価し、その数値に基づいて動的にロジックを分岐させなければならないという厳然たる事実だ。
—
2. 【実践】バージョン分岐アーキテクチャの実装パターン
単に `If Version = “24.3” Then` と書くだけのコードは、保守フェーズに入った途端に破綻する。マイナーアップデートや将来のバージョン（例えば2026以降）を見据えた、拡張性の高い堅牢なプロシージャの設計を見ていこう。
以下のコードは、現在の実行環境のメジャー・マイナーバージョンを正確に数値として抽出し、バージョンごとの処理差異を安全に吸収するアーキテクチャの模範解答である。
Option Explicit
‘ ==============================================================================
‘ 模範的アーキテクチャ: バージョン依存処理を安全にカプセル化するプロシージャ
‘ ==============================================================================
Public Sub ExecuteVersionAwareProcess()
On Error GoTo ErrorHandler
Dim appVersionStr As String
Dim majorVersion As Double
‘ 1. Applicationオブジェクトからバージョン文字列を取得
appVersionStr = ThisDrawing.Application.Version
‘ 数値演算を行えるようにDouble型へキャスト（例: “24.3” -> 24.3）
majorVersion = Val(appVersionStr)
Debug.Print “検知されたAutoCAD内部バージョン: ” & appVersionStr
‘ 2. バージョンに応じた機能分岐
Select Case majorVersion
Case Is >= 24.4
‘ AutoCAD 2025以降の最新機能（例: 新しいクラウド連携やAI関連APIなど）
Call ProcessForModernAutoCAD(ThisDrawing)
Case 24.3
‘ AutoCAD 2024専用の最適化処理
Call ProcessForAutoCAD2024(ThisDrawing)
Case Is <= 24.2 ' AutoCAD 2023以前のレガシー環境に対するフォールバック処理 Call ProcessForLegacyAutoCAD(ThisDrawing) Case Else ' 未知の将来バージョンに対するデフォルト動作 MsgBox "未検証のAutoCADバージョン (" & appVersionStr & ") です。基本モードで実行します。", vbExclamation, "互換性警告" Call ProcessForLegacyAutoCAD(ThisDrawing) End Select Exit Sub ErrorHandler: MsgBox "予期せぬエラーが発生しました: " & Err.Description, vbCritical, "システムエラー" End Sub ' --- 各バージョン別の実処理カプセル化 --- Private Sub ProcessForModernAutoCAD(ByVal doc As AcadDocument) ' AutoCAD 2025以降でのみサポートされるプロパティやメソッドを使用 MsgBox "最新のAutoCAD 2025+ 最適化ルーチンを実行します。", vbInformation ' 例: doc.NewFeatureMethod2025 (...) End Sub Private Sub ProcessForAutoCAD2024(ByVal doc As AcadDocument) ' AutoCAD 2024固有の処理 MsgBox "AutoCAD 2024向けルーチンを実行します。", vbInformation End Sub Private Sub ProcessForLegacyAutoCAD(ByVal doc As AcadDocument) ' 2023以前の環境で安全に動作する枯れたコードパス MsgBox "レガシー互換モードで実行します。", vbInformation ' 新しいメソッドの代わりに、古くから存在する確実なメソッド（SendCommand等）を使用する End Sub ---
3. シニアエンジニアが知るべき「COMの遅延バインディング」という究極の防衛策
もしあなたのVBAプロジェクトが、AutoCAD 2020から2025までを「単一の `.dvb` ファイル」で完全に網羅しなければならない極限の環境にあるなら、通常の参照設定（早期バインディング）だけでは限界が訪れる。
異なるバージョン間で削除されたインターフェースやメソッドシグネチャの変更に直面したとき、遅延バインディング（Late Binding）の技術が救世主となる。
早期バインディングの罠
開発PC（例: AutoCAD 2024）で参照設定を行ってビルドしたコードは、型情報（TLB）がコンパイル時に固定される。これをAutoCAD 2022の環境へ持ち込むと、型ライブラリの不整合により、コードの実行以前にロードエラーを引き起こす可能性がある。
遅延バインディングによる完全な動的制御
オブジェクトを `Object` 型として宣言し、実行時に `CreateObject` または既存のアプリケーションコンテキストから安全にフックする。これにより、コンパイル時の型チェックから解放され、バージョン差異によるロードクラッシュを物理的に根絶できる。
Public Sub ExecuteLateBindingSafely()
Dim acadApp As Object
Dim docName As String
‘ 実行中のAutoCADインスタンスを安全に取得
On Error Resume Next
Set acadApp = GetObject(, “AutoCAD.Application”)
On Error GoTo 0
If acadApp Is Nothing Then
MsgBox “AutoCADが起動していません。”, vbCritical
Exit Sub
End If
‘ バージョンに応じた動的なメソッド呼び出しの切り替え
Dim ver As Double
ver = Val(acadApp.Version)
If ver >= 24.3 then
‘ 2024以降向けの処理をセーフに実行
Call ExecuteViaLateBinding(acadApp, “ModernMethod”)
Else
‘ レガシー向けの処理
Call ExecuteViaLateBinding(acadApp, “LegacyMethod”)
End If
‘ 【重要】COMオブジェクトの明示的解放
‘ VBAといえども、外部COM参照を持つ変数は確実にNothingを代入してメモリリークを防ぐ
Set acadApp = Nothing
End Sub
Private Sub ExecuteViaLateBinding(ByVal appObj As Object, ByVal actionName As String)
Select Case actionName
Case “ModernMethod”
‘ 存在しないかもしれないメソッドをCallByNameで安全にたたく
‘ これによりコンパイルエラーを回避できる
CallByName appObj.ActiveDocument, “NewFeature”, VbMethod
Case “LegacyMethod”
CallByName appObj.ActiveDocument, “Save”, VbMethod
End Select
End Sub
—
4. メモリ最適化とオブジェクトライフサイクルの鉄則
AutoCAD VBAにおいて、メモリ管理の甘さはそのままCADプロセスのクラッシュ（致命的な例外エラー）に直結する。特にバージョン差異を吸収するような複雑なラッパーコードを書く際、以下の鉄則を忘れてはならない。
1. グローバルな `ThisDrawing` への過度な依存を断つ
複数図面を開いた状態でバージョン判定やバッチ処理を行う場合、`ThisDrawing` はアクティブ図面が変わることで予期せぬ挙動を示す。必ず明示的に `AcadDocument` オブジェクト変数に格納し、処理後は即座に `Set doc = Nothing` を実行せよ。
2. イベントハンドリングの解除
`AcadApplication` や `AcadDocument` のイベント（`AcadDocumentEvents` など）を監視するクラスモジュールを書く場合、アプリケーションの終了やバージョン切り替え時にイベント接続を完全に切断しないと、AutoCADのプロセスがバックグラウンドに残り続け（ゾンビプロセス）、メモリリークを引き起こす。
—
結言
AutoCAD VBAはレガシーな技術と揶揄されることもあるが、背後にあるCOMアーキテクチャの本質を理解したエンジニアが操れば、いまだに最強かつ最速の自動化ツールである。
`AcadApplication.Version` による環境の特定は、単なる条件分岐の道具ではない。それは、「多様なクライアント環境の断片化」という現実からシステムを護るための、極めて高度な防衛プロトコルなのである。
コードの隅々にまで意図を行き渡らせ、バージョンという時間の壁を軽々と超える堅牢なシステムを構築してほしい。
