【上級プロ向け】CorelDRAW VBAプロセス終了時のメモリリークを根絶する！厳格なオブジェクト参照破棄とガベージコレクション制御
VBAによるデスクトップアプリケーションの自動化において、最も忌むべき存在は「メモリリーク」である。特にCorelDRAWをエンジンとした数千ファイル規模のバッチ処理において、タスクマネージャーのメモリ使用量が右肩上がりに増大し、最終的にVBAの実行時エラーやCorelDRAW自体のフリーズ（ゾンビプロセスの残存）を引き起こした経験を持つエンジニアは少なくないはずだ。
本稿では、CorelDRAW VBA（および外部COMラッパー）の裏側でうごめくCOMオブジェクトのライフサイクルの真実を暴き、何日でも無停止で稼働し続ける極限のメモリ管理アーキテクチャを提示する。
—
1. CorelDRAW VBAにおける「見えないメモリリーク」の正体
VBAのランタイムは、一見するとガベージコレクション（GC）のような機構を備えているように見えるが、実態は参照カウンティング（Reference Counting）に依存した厳格なメモリ管理を行っている。
特にCorelDRAWのオブジェクトモデル（`Application`, `Document`, `Shape`, `Layer`など）は、内部でC++ベースの膨大なネイティブメモリとCOM（Component Object Model）インスタンスを抱えている。
循環参照とインターフェースの解放漏れ
VBAで以下のようなコードを書いた瞬間、メモリリークの罠が仕掛けられる。
‘ 【悪手】絶対にやってはいけない記述
Dim doc As Document
Set doc = Application.ActiveDocument
doc.Pages(1).Layers(1).CreateRectangle 0, 0, 10, 10
このコードの問題点は、`Application.ActiveDocument` や `doc.Pages(1)` といった暗黙的なオブジェクトの参照がチェーン状に生成され、VBAのスタックまたはヒープ上に宙ぶらりんになる点にある。
VBAはプロシージャ終了時にローカル変数を解放しようとするが、複雑なCOMオブジェクトの参照階層（インターフェースポインタ）が絡み合うと、参照カウントが「0」に落ちず、CorelDRAWのプロセス空間内にメモリが永遠に残留する。
これが、バッチ処理を数時間走らせただけでPCのメモリが枯渇する根本原因である。
—
2. 厳格なオブジェクト参照破棄（Explicit Deallocation）の鉄則
メモリリークを根絶するための第一歩は、「すべてのCOMオブジェクト変数に `Nothing` を代入し、生成した逆順で明示的に解放する」という鉄の掟の遵守だ。
以下に、数万ファイルのCDRファイルを読み込み、エクスポートして閉じる処理における、メモリリークを完全に排除したモジュールの骨格を示す。
実装例：極限まで最適化されたバッチ処理ルーチン
Option Explicit
Public Sub ExecuteRobustBatchProcessing(ByVal targetFolder As String)
Dim cdrApp As CorelDRAW.Application
Set cdrApp = New CorelDRAW.Application
‘ バッチ処理中は画面描画とイベントを完全に抑制し、メモリとCPUの無駄な消費を防ぐ
cdrApp.Optimization = True
cdrApp.EventsEnabled = False
On Error GoTo ErrorHandler
‘ 対象ファイルの取得ループ（簡略化）
Dim filePath As String
filePath = Dir(targetFolder & “.cdr”)
Do While filePath <> “”
ProcessSingleFile cdrApp, targetFolder & filePath
filePath = Dir()
Loop
CleanUp:
‘ 終了時の確実に状態を戻す処理
On Error Resume Next
If Not cdrApp Is Nothing Then
cdrApp.EventsEnabled = True
cdrApp.Optimization = False
cdrApp.Quit
Set cdrApp = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
Private Sub ProcessSingleFile(ByRef appRef As CorelDRAW.Application, ByVal fullPath As String)
Dim targetDoc As CorelDRAW.Document
Dim activePage As CorelDRAW.Page
Dim exportFlt As CorelDRAW.ExportFilter
Set targetDoc = appRef.OpenDocument(fullPath)
‘ ドキュメントに対する何らかの処理
Set activePage = targetDoc.ActivePage
‘ 例: ページサイズ変更やシェイプ操作など
‘ エクスポート処理
Dim exportPath As String
exportPath = Left(fullPath, InStrRev(fullPath, “.”)) & “png”
Set exportFlt = targetDoc.ExportBitmap(exportPath, cdrPNG, cdrSelection, cdrHighResPale, 300, 300)
exportFlt.Finish
‘ 【重要】ドキュメントを保存せずに閉じる
targetDoc.Close
‘ — 【極めて重要】生成したすべてのオブジェクトの参照を逆順で明示的に破棄 —
Set exportFlt = Nothing
Set activePage = Nothing
Set targetDoc = Nothing
‘ ガベージコレクションを強制的に誘発（VBA単体では完全ではないが、COMカウンタの整理に寄与）
DoEvents
End Sub
—
3. Windows APIを活用したガベージコレクションの強制制御
VBAの `Set obj = Nothing` だけでは、COMコンポーネントが内部で保持しているアロケーション領域や、Windowsのヒープフラグメンテーションを完全に回収しきれない場合がある。
ここで、Windows APIである `CoFreeUnusedLibraries` や、VBAランタイムのメモリクリーンアップを強制する手法が有効となる。さらに、CorelDRAWプロセス自体が肥大化した場合は、一定ファイル数処理するごとにCorelDRAWのプロセスを丸ごと再起動するアーキテクチャこそが、実務における唯一にして最強の防衛策となる。
ゾンビプロセスを生まないためのAPI連携とプロセス管理
大量のファイルを処理するシステムでは、CorelDRAWを立ち上げっぱなしにするのではなく、「100ファイル処理したら `Quit` してプロセスを完全に殺し、VBA（または外側のVBScript / .NET Wrapper）から再起動する」というラウンドロビン方式を採用すべきだ。
もしVBA単体でCOMの解放漏れを確認・強制終了したい場合は、Windows APIを使用してプロセスID（PID）を監視・制御するアプローチが考えられる。
‘ Windows APIの宣言（必要に応じてプロセス制御に使用）
If VBA7 Then
Private Declare PtrSafe Function SetProcessWorkingSetSize Lib “kernel32” (ByVal hProcess As LongPtr, ByVal dwMinimumWorkingSetSize As LongPtr, ByVal dwMaximumWorkingSetSize As LongPtr) As Long
Private Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
Else
Private Declare Function SetProcessWorkingSetSize Lib “kernel32” (ByVal hProcess As Long, ByVal dwMinimumWorkingSetSize As Long, ByVal dwMaximumWorkingSetSize As Long) As Long
Private Declare Function GetCurrentProcess Lib “kernel32” () As Long
End If
‘ プロセス自体のワーキングセット（物理メモリ割り当て）を縮小させる荒技
Public Sub TrimMemoryFootprint()
Dim lngResult As Long
lngResult = SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1)
End Sub
※注意: `SetProcessWorkingSetSize` はOSに対してメモリのページアウトを促すものであり、メモリリーク自体の根本解決ではないが、バッチ処理中のメモリひっ迫によるOS全体のスワップ発生を防ぐ応急処置としては極めて強力である。
—
4. シニアエンジニアが実践すべき設計チェックリスト
CorelDRAWを用いた大規模自動化システムを設計・保守するにあたり、以下のチェックリストを必ずクリアしていることを確認せよ。
1. 暗黙の参照チェインを排除しているか？
`Debug.Print ActiveDocument.Pages(1).Shapes(1).Name` のような、変数に格納せずに行うプロパティの多重呼び出しは、参照を解放する手段がないため厳禁。必ず各階層を変数に受け、個別に `Nothing` を代入すること。
2. エラーハンドリング時（`On Error Goto`）にも確実にメモリ解放が行われるか？
例外発生時にオブジェクトが残ったままプロシージャを抜けると、確実にメモリリークする。エラー時も必ず `CleanUp:` ラベルへジャンプし、全変数を破棄するフローを組むこと。
3. `Optimization = True` の戻し忘れはないか最適化されているか？
最適化モード中にエラーで終了すると、CorelDRAWのUIやイベントハンドラが壊れた状態のままプロセスが残留する。エラー時も含めて必ず元の状態に戻すこと。
4. 定期的なプロセスリサイクル設計はあるか？
数千ファイルを超えるジョブでは、アプリケーションの世代交代（一定数処理ごとの再起動）を前提としたオーケストレーション層を外側に持たせること。
結言
CorelDRAW VBAにおけるメモリ管理は、単なるコーディングの作法ではなく、インフラストラクチャの安定稼働を左右するエンジニアリングそのものである。オブジェクトのライフサイクルを完全に支配し、メモリの息吹までコントロールできた時、あなたの書く自動化スクリプトは、何日稼働させようともビクともしない「要塞」へと昇華する。
