AutoCAD VBAの深淵：ObjectDBXによる「図面を開かない」高速一括処理と、その背後にあるエラー監査の極意
AutoCADの自動化において、最も犯してはならない過ち。それは「`Application.Documents.Open` をループ内で回すこと」だ。
図面を画面に描き出し、アクティブにするという行為は、メモリを食い、描画リソースを浪費し、そして何より「ユーザーの操作を阻害する」。これを繰り返せば、AutoCADは遅延し、クラッシュし、そして最後には現場のエンジニアが途方に暮れることになる。
真のプロフェッショナルは、ObjectDBX (AxDbDocument) を使う。図面をバックグラウンドでロードし、物理的な描画をバイパスしてデータモデルのみを操作する。これこそが、数千枚の図面を高速に処理するための唯一の解だ。
しかし、バックグラウンド処理には罠がある。画面が見えない分、発生したエラーは「サイレントキラー」となり、気づいた時には数百枚の処理がゴミと化している。今日は、この「暗闇の中での処理」を、堅牢な監査ログ機能で制御する術を伝授しよう。
—
1. なぜ「バックグラウンド処理」に監査ログが不可欠なのか
ObjectDBXは強力だが、デバッグが難しい。破損したDWGや、外部参照（Xref）のリンク切れ、あるいは予期せぬAutoCADの内部エラーが起きた際、プロセスが沈黙する。
「どのファイルで、なぜ止まったのか？」
この問いに対して、実行時に即座にCSVログへ吐き出す仕組みを構築しなければ、業務効率化ツールとは呼べない。以下に、実戦投入レベルの設計指針を示す。
—
2. 実装：ObjectDBXを用いた堅牢な処理アーキテクチャ
このコードは、エラーを握りつぶさず、確実にログとして残すためのテンプレートだ。
‘ ObjectDBXを使用したバックグラウンド処理テンプレート
‘ 参照設定: “ObjectDBX Common Type Library” を追加すること
Public Sub BatchProcessDrawings(filePaths As Collection, logPath As String)
Dim dbxDoc As Object
Dim filePath As Variant
Dim logFile As Integer
logFile = FreeFile
Open logPath For Append As #logFile
Print #logFile, “Timestamp,FilePath,Status,ErrorMessage”
For Each filePath In filePaths
Set dbxDoc = Nothing
On Error Resume Next ‘ 致命的なエラーの捕捉を開始
‘ 1. ObjectDBXのインスタンス生成
Set dbxDoc = CreateObject(“ObjectDBX.AxDbDocument.24”) ‘ AutoCAD 2021以降の例
‘ 2. 図面オープン
dbxDoc.Open filePath
If Err.Number <> 0 Then
‘ 破損図面や読み取り不可の場合
Print #logFile, Now & “,” & filePath & “,FAILED,” & Err.Description
Else
‘ 3. メイン処理（サブプロシージャへ切り出すこと）
ProcessDatabase dbxDoc
If Err.Number <> 0 Then
Print #logFile, Now & “,” & filePath & “,ERROR,” & Err.Description
Else
dbxDoc.SaveAs filePath
Print #logFile, Now & “,” & filePath & “,SUCCESS,”
End If
End If
On Error GoTo 0
Next filePath
Close #logFile
MsgBox “処理終了。ログを確認してください。”
End Sub
‘ 個別の図面操作ロジック
Private Sub ProcessDatabase(dbx As Object)
‘ ここにレイヤー変更やブロック置換などのロジックを記述
‘ 注意: アクティブな図面（ThisDrawing）に依存するコードは書かないこと
End Sub
—
3. プロフェッショナルのための3つの鉄則
① 「ObjectDBXのバージョン」を意識せよ
`AxDbDocument.XX` の数値はAutoCADのバージョンに依存する。これをハードコードするのは美しくない。レジストリから動的に取得するか、あるいは `CreateObject` で失敗した際に、代替バージョンを試行するフォールバックロジックを組むのが、真に「壊れない」ツールを作る者の作法だ。
② メモリ解放の徹底
VBAはメモリ管理が甘い。ループの最後で `Set dbxDoc = Nothing` を行うだけでは不十分な場合がある。`dbxDoc.Close` を明示的に呼び出し、オブジェクトの参照を確実に消去しなければ、巨大なバッチ処理中にメモリリークでAutoCADが息絶える。
③ 外部参照（Xref）への注意
ObjectDBXは、基本的に「図面を単体」で扱う。Xrefが紐づいている図面を処理する場合、パスの解決がうまくいかず、開くことすらできないことがある。必要であれば `dbxDoc.Database.XrefDatabase` を介した制御が必要になるが、まずは「読み込み専用」で開くなどの配慮を忘れないこと。
—
結論：コードは「対話」である
今回紹介したログ出力の仕組みは、単なるエラーチェックではない。それは、あなたが不在の間に、AutoCADという巨大なエンジンが「何を考え、どこで躓いたか」を教えてくれる唯一のメッセージだ。
現場のエンジニアが最も時間を浪費するのは、コードを書く時間ではない。「何が起きたか分からない不具合」の調査に費やす時間だ。
この監査ログの仕組みを組み込めば、あなたはもう暗闇の中でバグを追う必要はない。ログファイルを開けば、真実はそこに全て記述されているはずだ。さあ、今すぐ退屈な手作業を自動化し、クリエイティブな仕事へと時間をシフトしよう。
