AutoCAD VBAの深淵：`ExportLayout`自動化におけるメモリ管理とオブジェクトライフサイクルの極意
AutoCADのオートメーションにおいて、最も「厄介」かつ「強力」な機能の一つが `ExportLayout` コマンドだ。ペーパー空間のレイアウトをモデル空間に抽出するこの処理は、一見単純なコマンドに見えるが、システム統合や大規模な図面マイグレーションの現場では、メモリリークやCOMオブジェクトのゾンビ化を招く地雷原でもある。
本稿では、単なるコマンドのラッパーを超え、レガシー環境で安定稼働させるための「堅牢なアーキテクチャ」を伝授する。
—
1. なぜ「ExportLayout」はメモリを食い荒らすのか
AutoCAD VBAにおいて `ThisDrawing.SendCommand` を多用するのは、初心者の入り口だ。しかし、`ExportLayout` は非同期的な挙動や、一時的なデータベースメモリの確保を行うため、単純なコマンド送信ではプロセスがハングアップするリスクがある。
シニアエンジニアが意識すべきは以下の3点だ。
- COMスレッドの競合: `SendCommand` はAutoCADのメッセージループに依存する。重い図面でこれを実行すると、COM呼び出しがブロックされる。
- オブジェクトの解放: `ExportLayout` が内部で生成するDocumentオブジェクトは、明示的にハンドルを追跡しない限り、AutoCADのセッション終了までメモリを圧迫し続ける。
- バージョン互換性: 新旧AutoCAD間では、図面ファイルのデータベース構造に微妙な差異がある。保存時の `AcSaveAsType` を明示的に制御せねば、後続のシステムで読み込みエラーを誘発する。
—
2. 実践：高信頼性 `ExportLayout` 自動化モジュール
以下に、エラーハンドリングを完備し、オブジェクトを確実に解放する実装例を示す。
‘ ————————————————————————-
‘ 機能: 指定レイアウトをモデル空間へエクスポートし、指定フォーマットで保存
‘ ————————————————————————-
Public Sub ExportLayoutToModel(ByVal layoutName As String, ByVal outputPath As String)
Dim doc As AcadDocument
Dim activeDoc As AcadDocument
Set activeDoc = ThisDrawing
On Error GoTo ErrorHandler
‘ 1. コマンド実行前にレイアウトの存在確認を行う（型安全性）
If Not LayoutExists(layoutName) Then Err.Raise vbObjectError + 1, , “Layout not found”
‘ 2. SendCommandの非同期対策：必要に応じてDoEventsで待機
‘ ExportLayoutは図面ファイルを作成するため、ファイルロックに注意
activeDoc.SendCommand “-EXPORTLAYOUT ” & layoutName & vbCr
‘ 3. 生成された図面を制御下に置く
‘ 通常、ExportLayout直後はファイル名が「Layout1.dwg」等のデフォルトになる
‘ ファイル操作はFileSystemObjectを使用して確実に待機（Polling）する
WaitUntilFileExists outputPath
‘ 4. バージョン互換制御：AcSaveAsTypeを明示
‘ ACAD2018_DWG: 61, ACAD2013_DWG: 48, ACAD2010_DWG: 36
Dim exportDoc As AcadDocument
Set exportDoc = Application.Documents.Open(outputPath)
exportDoc.SaveAs outputPath, ac2018_dwg
exportDoc.Close False
‘ 5. メモリ解放（重要）
Set exportDoc = Nothing
Exit Sub
ErrorHandler:
MsgBox “Critical Error: ” & Err.Description, vbCritical
End Sub
Private Function LayoutExists(name As String) As Boolean
Dim l As AcadLayout
For Each l In ThisDrawing.Layouts
If l.Name = name Then LayoutExists = True: Exit Function
Next
End Function
—
3. シニアエンジニアのための最適化の極致
Windows APIによるプロセス制御
大量の図面をバッチ処理する場合、`DoEvents` に頼り切るのは危険だ。Windows APIの `Sleep` を用いてCPU負荷を下げつつ、確実にファイルI/Oの完了を待機すべきである。
If VBA7 Then
Private Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As LongPtr)
Else
Private Declare Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
End If
なぜ `SendCommand` を避けるべきか（アーキテクトの視点）
究極的には、`SendCommand` は避けるべきだ。可能であれば、ObjectARX (.NET API) の `LayoutManager.ExportLayout` メソッドをラップしたDLLを呼び出すのがベストプラクティスである。VBAはあくまで「糊（グルー）」として使い、重い処理はC#のマネージドコードに委譲する。これが、レガシー環境を延命させつつ、現代的なシステム間連携を実現する唯一の解だ。
—
4. 結び：技術の真髄は「クリーンアップ」にある
VBAエンジニアとしての熟練度は、コードの長さではなく、「いかにリソースを汚さずに去るか」で決まる。`ExportLayout` のような破壊的なコマンドを使用する際、常に「もし途中でエラーが起きたら、この図面は開きっぱなしにならないか？」を自問自答せよ。
システム管理者の諸君、泥臭い自動化こそが、図面データという資産を守る最後の砦だ。この実装をベースに、各社の環境に合わせた堅牢なパイプラインを構築してほしい。
技術は裏切らない。ただ、設計の甘さが技術を裏切るだけだ。健闘を祈る。
