【テクニカル・上級編】【上級プロ向け】Application.Optimization = True を駆使した超高速バッチ処理とメモリリーク完全防止のメモリ管理術 – CorelDRAW VBA解析バイブル

CorelDRAW VBA

2026.11.03

描画エンジンを制する者は、計算資源を制する：CorelDRAW VBAにおける極限のバッチ処理とメモリ管理術
If VBA7 Then
Else
End If
1. 4. アーキテクトの視点：さらなる高みへ
2. 結論

描画エンジンを制する者は、計算資源を制する：CorelDRAW VBAにおける極限のバッチ処理とメモリ管理術

数百ページに及ぶ巨大なCDRファイル、数千のレイヤー、そして複雑に絡み合うガイド線。これらを自動処理しようとした際、多くのエンジニアが直面するのは「処理速度の指数関数的な低下」と、突如として発生する「アプリケーションの強制終了（Crash）」である。

世の多くの技術書は、`Application.Optimization = True` を単なる「画面更新の停止」として紹介している。しかし、それは表層的な理解に過ぎない。我々プロフェッショナルが向き合うべきは、CorelDRAWの描画エンジン、COM（Component Object Model）のライフサイクル、そしてWindows OSレベルでのメモリ管理である。

本稿では、単なる「速いコード」の書き方ではない。システムとしての堅牢性と、計算資源の極限までの最適化を両立させるための、アーキテクトとしての知見を共有する。

1. `Application.Optimization` の真実と、描画エンジンの停止

CorelDRAWの描画エンジンは、オブジェクトの属性が変更されるたびに、画面上のピクセルを再計算し、再描画（Redraw）を試みる。ループ処理の中で数千のガイド線を配置する場合、この再描画コストが処理時間の9割を占めることになる。

`Application.Optimization = True` は、この再描画命令をキューに蓄積し、明示的な `Refresh` が呼ばれるまで描画プロセスを抑制する。しかし、ここには致命的な罠がある。

罠：描画キューの肥大化とメモリ圧迫

描画を抑制している間、CorelDRAWの内部エンジンは「次に何をすべきか」という命令（描画コマンド）をメモリ上に保持し続ける。数百ページの処理において、このキューが肥大化しすぎると、描画指示そのものがメモリを食いつぶし、結果として `Out of Memory` を引き起こす。

解決策：
大規模処理においては、一定の閾値（例：10ページごと、あるいは100オブジェクトごと）で `Application.Optimization = False` $\rightarrow$ `Application.Refresh` $\rightarrow$ `Application.Optimization = True` と、描画エンジンを定期的にフラッシュ（掃出し）させる設計が必要である。

2. COMオブジェクトのライフサイクルと「幽霊オブジェクト」の排除

VBAはガベージコレクション（GC）を持つが、CorelDRAWのような高度なCOMオートメーション環境においては、その挙動は極めて不透明である。

特に、`Page`、`Layer`、`Guide` といったオブジェクトをループ内で生成・操作する場合、変数に `Nothing` を代入しただけでは、背後のC++層で保持されているリソースが即座に解放されないケースが多々ある。これが「メモリリーク」の正体である。

鉄則：スコープの最小化と明示的破棄

オブジェクトの参照は、可能な限り短いスコープ（`With` ステートメントや、ループ内のローカル変数）に留めるべきである。そして、ループの各ステップの終わりに、参照を確実に断ち切るコードを記述する。

3. 実装：極限のバッチ処理アーキテクチャ

以下に、数百ページのページ追加、レイヤー生成、およびガイド線配置を、メモリ効率を最大化しながら実行するテンプレートを示す。

Option Explicit

' Windows APIの宣言: プロセスのワーキングセットを強制的に最小化する
' これにより、大量のオブジェクト操作後にOSレベルでメモリを整理させる
If VBA7 Then
    Private Declare PtrSafe Function EmptyWorkingSet Lib "psapi.dll" (ByVal hProcess As LongPtr) As Long
    Private Declare PtrSafe Function GetCurrentProcess Lib "kernel32" () As LongPtr
Else
    Private Declare Function EmptyWorkingSet Lib "psapi.dll" (ByVal hProcess As Long) As Long
    Private Declare Function GetCurrentProcess Lib "kernel32" () As Long
End If

Sub ExtremeBatchProcessing()
    Dim doc As Document
    Dim pg As Page
    Dim lyr As Layer
    Dim g As Guide
    Dim i As Long, p As Long
    Dim batchCounter As Long
    
    On Error GoTo ErrorHandler

    Set doc = Application.ActiveDocument
    If doc Is Nothing Then Exit Sub

    ' --- 1. 最適化フェーズの開始 ---
    ' 描画停止、およびイベント発生の抑制（イベントによる再計算を防ぐ）
    Application.Optimization = True
    ' 注意: CorelDRAWのバージョンによりEventsEnabledの制御方法は異なるが、
    ' 基本的にOptimizationをTrueにすることで描画イベントは抑制される
    
    batchCounter = 0

    For p = 1 To 500 ' 500ページを想定した過酷なループ
        
        ' ページ追加
        Set pg = doc.AddPages(1)
        
        ' --- 2. オブジェクト操作フェーズ ---
        ' レイヤーの追加
        Set lyr = pg.CreateLayer("Automation_Layer_" & p)
        
        ' ガイド線の自動配置（大量のオブジェクト生成）
        For i = 1 To 50
            ' 座標計算を最小限にし、直接生成
            Set g = lyr.Guides.Add(i * 10, cdrHorizontal)
            
            ' 参照の管理: 
            ' ループ内でのオブジェクト生成は、スコープを意識する
            ' ここではgは次のループで上書きされるが、明示的にNothingを推奨
            Set g = Nothing 
        Next i
        
        ' レイヤー参照の解放
        Set lyr = Nothing
        
        ' --- 3. メモリ・フラッシュ戦略 ---
        ' 10ページごとに描画エンジンをリフレッシュし、メモリ内の描画キューを解放する
        batchCounter = batchCounter + 1
        If batchCounter Mod 10 = 0 Then
            Application.Optimization = False
            Application.Refresh
            Application.Optimization = True
            
            ' Windows APIによる物理メモリの整理（オプション・極めて強力）
            ' 大規模処理の合間に実行することで、OSへのメモリ返還を促す
            Call EmptyWorkingSet(GetCurrentProcess())
        End If
        
        ' ページ参照の解放
        Set pg = Nothing
    Next p

    ' --- 4. クリーンアップフェーズ ---
    Application.Optimization = False
    Application.Refresh
    
    MsgBox "Batch Process Completed Successfully.", vbInformation
    Exit Sub

ErrorHandler:
    ' エラー発生時も必ず最適化を解除しなければ、CorelDRAWは「死んだ」状態になる
    Application.Optimization = False
    Application.Refresh
    MsgBox "Critical Error: " & Err.Description, vbCritical
End Sub

4. アーキテクトの視点：さらなる高みへ

上記のコードは、標準的なVBA開発者が書くものとは一線を画している。特に以下の3点に注目せよ。

I. Windows API `EmptyWorkingSet` の活用

VBAの `Set obj = Nothing` は、あくまで「VBAから見た参照」を消すに過ぎない。CorelDRAWの内部プロセスが確保した物理メモリ（Working Set）は、OSが回収するまで残り続ける。`psapi.dll` の `EmptyWorkingSet` を呼び出すことで、プロセスが保持している不要なページを強制的にスタンバイリストへ退避させ、メモリ不足によるクラッシュを劇的に回避できる。

II. 描画キューの「定期的なフラッシュ」

`Optimization = True` を最初から最後まで維持するのは、初心者の犯す最大の過ちである。描画コマンドはメモリを消費する「データ」である。これを一定量溜まったら `Refresh` で掃き出す。この「バッチ・リフレッシュ・サイクル」の設計こそが、数千ページを処理する際の生命線となる。

III. エラーハンドリングの絶対性

`Optimization = True` の状態でエラーが発生し、そのままマクロが終了した場合、CorelDRAWのUIは凍結（フリーズ）したように見える。これは描画エンジンが停止したままだからである。`ErrorHandler` 内で必ず `Optimization = False` を実行する構造は、単なる作法ではなく、システムの生存戦略である。

結論

CorelDRAW VBAにおける真の高速化とは、単にコードを短くすることではない。CorelDRAWの内部アーキテクチャがどのようにリソースを消費し、どのように描画を管理しているかを理解し、それに対して「制御（Control）」を行使することである。

メモリのライフサイクルを支配し、描画エンジンを意図的に制御する。この一歩を踏み出したとき、君のコードは単なるスクリプトから、堅牢なシステムへと昇華する。