CorelDRAW VBAを掌握する：巨大ドキュメントの「メモリ地獄」を突破する設計論
CorelDRAWのVBA開発において、数百ページのドキュメントを愚直にループ処理させることは、自殺行為に等しい。CorelDRAWのDOM（Document Object Model）は、その華麗な機能の裏で、メモリ空間を貪欲に喰らい尽くす「メモリの食いしん坊」だ。
特に、数千のオブジェクトが配置された巨大ファイルを処理する際、`Application.Documents.Open`で全てをロードし、`For Each p In doc.Pages`を回すような実装は、メモリリークとGC（ガベージコレクション）の遅延により、いずれ必ず`Out of Memory`で沈没する。
今日は、この「限界」を突破するためのアーキテクチャを伝授する。
—
1. 巨大ファイルに対する「単一ドキュメント」の幻想を捨てる
メモリ枯渇の最大の要因は、ドキュメントを「巨大な単一のオブジェクト」としてメモリ上に常駐させ続けることにある。
シニアエンジニアとして取るべき戦略は「ページ単位の動的ロードと解放」だ。しかし、CorelDRAWの仕様上、ページ単体でのインポート・エクスポートにはコストがかかる。ここで我々が活用すべきは、「一時ファイルへの分割」と「COM参照の明示的破棄」である。
オブジェクト解放の鉄則
VBAにはGCが存在しない。`Set obj = Nothing`を書けば安心だと思っているなら、それは大きな誤解だ。`Nothing`はあくまで「参照を消す」だけであり、COMオブジェクトのデストラクターを即座に呼ぶ保証はない。
‘ 厳密なメモリ解放ルーチン
Public Sub ForceClearObject(ByRef obj As Object)
If Not obj Is Nothing Then
‘ ドキュメントや複雑なオブジェクトは明示的にClose/Deleteを呼ぶ
On Error Resume Next
obj.Close ‘ ドキュメントの場合
Set obj = Nothing
End If
‘ 念のためWindows APIで強制的にメモリの整理を促す
‘ (SetProcessWorkingSetSize)
End Sub
—
2. Windows APIによるメモリの強制開放
VBA単体では、CorelDRAWが抱え込んだメモリをOSに返還させることは難しい。そこで、`kernel32.dll`の`SetProcessWorkingSetSize`を呼び出し、プロセスのワーキングセットを最小化する手法が有効だ。
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
End If
‘ メモリを強制的にOSへ戻すための極限手段
Public Sub TrimMemory()
Call SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1)
End Sub
この処理をページ処理のループ毎に挟むことで、メモリ消費量を一定ライン以下に抑え込むことが可能になる。
—
3. 実践：バッチ処理の堅牢なデザインパターン
数百ページの処理を完遂するための、防御的なメインループの雛形を提示する。
Public Sub BatchProcessHugeDocument(ByVal filePath As String)
Dim doc As Document
Dim i As Long
Dim totalPages As Long
‘ ファイルを開く際は読み取り専用かつ不可視でロードする
Set doc = Application.OpenDocumentEx(filePath, cdrOpenReadOnly + cdrOpenNoWindow)
totalPages = doc.Pages.Count
doc.Close
‘ ページ単位で再ロードして処理する
For i = 1 To totalPages
‘ 1. 必要なページだけを切り出した一時ドキュメントを作成
‘ 2. 処理を実行
‘ 3. ファイルを保存/エクスポート
‘ 4. 明示的な破棄
Call ProcessSinglePage(filePath, i)
‘ 5. メモリの強制解放
If i Mod 5 = 0 Then TrimMemory
Next i
End Sub
—
4. チーフアーキテクトからの提言：レガシーとの付き合い方
CorelDRAW VBAはVBA 7.1以前の制約を強く引きずっている。特に「名前空間の汚染」と「オブジェクト参照のネスト」は、プログラムの生存期間を縮める。
- イベントの無効化: `Application.Optimization = True`を必ず使用し、描画更新とイベントの発火を止めろ。これはメモリ消費を劇的に抑える。
- API連携の最適化: 外部システムと連携する場合、JSONやXMLのパースをVBA内で行うな。処理が重く、メモリを断片化させる。外部の軽量な実行ファイル(C#で書かれたCLIツールなど)にデータを渡し、結果を受け取るパイプライン構造を構築すべきだ。
最後に
システムが落ちるのは「CorelDRAWが悪い」のではない。「メモリのライフサイクルを設計者が管理できていない」ことが原因だ。
数百ページであろうと数万ページであろうと、アーキテクチャさえ正しければVBAは十分に耐えうる。メモリを制御し、COMオブジェクトの寿命を支配せよ。それが、真に「巨大ドキュメントを制御する」ということだ。
この知見が、貴殿の極限の自動化システムの礎とならんことを願う。
