【テクニカル・上級編】【上級プロ向け】大量ページのPDFエクスポート時に、メモリ不足（OOM）を回避するためページ範囲を分割してガベージコレクションを強制実行 – CorelDRAW VBA解析バイブル

CorelDRAW VBA

2026.10.30

【極限の知見】CorelDRAWにおける巨大PDF出力のメモリ管理術 ― OOMを回避する分割エクスポートと決定論的クリーンアップ

【極限の知見】CorelDRAWにおける巨大PDF出力のメモリ管理術 ― OOMを回避する分割エクスポートと決定論的クリーンアップ

数千ページに及ぶ製本データ、高解像度のビットマップ、複雑に重なり合ったベクターパス。これらを扱うエンジニアが直面する最大の敵は、ロジックの誤りではない。「メモリ不足（Out of Memory: OOM）」という名の、不可避な物理的限界である。

一般的なスクリプトエンジニアは、`Export`メソッドを呼び出し、エラーが出なければ成功だと考える。しかし、プロフェッショナルなアーキテクトは知っている。CorelDRAWのような大規模なグラフィックアプリケーションにおいて、長時間のバッチ処理は、オブジェクトの参照カウントの不整合とメモリ断片化を確実に引き起こし、最終的にプロセスを沈黙させることを。

本稿では、数千ページのPDFエクスポートを完遂させるための、メモリ管理の極致について解説する。

1. なぜCorelDRAWは「力尽きる」のか

CorelDRAWのVBAエンジンはCOM（Component Object Model）に基づいている。VBA上で `Set obj = Nothing` を実行することは、あくまで「参照カウントを一つ減らす」ことに過ぎない。

問題は、CorelDRAWの内部エンジン（C++レイヤー）が、エクスポート処理中に生成する一時的なキャッシュや、VBAから操作されたオブジェクトの「見えない参照」にある。これらはVBAのガベージコレクション（GC）の対象外であったり、GCが走るタイミングが遅すぎたりするため、メモリ使用量が右肩上がりに増大し、最終的にOSからメモリ割り当てを拒否される。これがOOMの正体だ。

これを回避するには、「メモリの断片化を防ぐために、処理を細かく分割し、各セグメントの終了時にエンジンの状態を可能な限りリセットする」という戦略が必須となる。

2. 戦略：分割統治（Divide and Conquer）と決定論的クリーンアップ

単一の巨大なエクスポートジョブを投げるのではなく、以下の三段階のレイヤーで制御を行う。

1. ページ範囲のセグメント化: 1,000ページを一括ではなく、例えば50ページ単位の「チャンク」に分割して出力する。
2. 明示的なオブジェクト解放とDoEvents: ループの各ステップで、使用したオブジェクトを明示的に解放し、OSに制御を戻してイベントキューを消化させる。
3. Windows APIによるメモリ強制回収: VBAの限界を超える場合、Windows APIを用いてプロセス全体のワーキングセットを整理する。

3. 実装例：堅牢な分割エクスポート・モジュール

以下に、シニアエンジニアが実戦で投入すべき、堅牢な設計思想に基づいたコードを示す。

Option Explicit

' Windows APIの宣言: ワーキングセットの整理をOSに要求する
' これにより、物理メモリへの負荷を軽減し、断片化したメモリを整理する
Private Declare PtrSafe Sub SetProcessWorkingSetSize Lib "kernel32" ( _
    ByVal hProcess As LongPtr, _
    ByVal dwMinimumWorkingSetSize As LongPtr, _
    ByVal dwMaximumWorkingSetSize As LongPtr)

' プロセスハンドル取得用
Private Declare PtrSafe Function GetCurrentProcess Lib "kernel32" () As LongPtr

''' <summary>
''' 巨大なドキュメントを分割してPDFエクスポートする
''' </summary>
''' <param name="chunkSize">1回のエクスポートあたりのページ数</param>
Public Sub RobustMassivePDFExport(ByVal chunkSize As Integer)
    Dim doc As Document
    Dim totalPages As Integer
    Dim startPage As Integer
    Dim endPage As Integer
    Dim currentPage As Integer
    Dim pdfExport As PDFExportFilter
    Dim filePath As String
    Dim baseName As String
    
    On Error GoTo ErrorHandler
    
    Set doc = ActiveDocument
    If doc Is Nothing Then Exit Sub
    
    totalPages = doc.Pages.Count
    baseName = doc.FilePath & doc.FileName & "_"
    
    ' 描画更新を停止（パフォーマンス向上とメモリ節約）
    Optimization = True
    
    For startPage = 1 To totalPages Step chunkSize
        endPage = startPage + chunkSize - 1
        If endPage > totalPages Then endPage = totalPages
        
        ' 出力ファイル名の生成
        filePath = baseName & "Part_" & startPage & "_" & endPage & ".pdf"
        
        Debug.Print "Exporting: " & startPage & " to " & endPage
        
        ' --- エクスポート処理の開始 ---
        ' PDF出力フィルタの生成
        ' 注意: フィルタオブジェクトはスコープを限定し、使い捨てにする
        Set pdfExport = doc.PDFExportSheets.Add
        
        With pdfExport
            .PageRange = startPage & "-" & endPage
            .PDFVersion = pdfPDFVersion15 ' 必要に応じてバージョン指定
            .ColorMode = pdfCMYK ' 印刷用途ならCMYKを明示
            ' その他の詳細設定...
            .Finish filePath
        End With
        
        ' --- 決定論的クリーンアップ ---
        ' 1. フィルタオブジェクトの明示的解放
        Set pdfExport = Nothing
        
        ' 2. OSに制御を戻し、CorelDRAW内部のメッセージキューを処理させる
        ' これを行わないと、内部のメモリ解放処理がスタックする
        DoEvents
        
        ' 3. Windows APIによるメモリ整理（重要）
        ' プロセスのワーキングセットを最小化するようOSに促す
        Call ForceMemoryReclamation
        
        Debug.Print "Chunk " & startPage & " completed."
    Next startPage

    Optimization = False
    MsgBox "All chunks exported successfully.", vbInformation
    Exit Sub

ErrorHandler:
    Optimization = False
    MsgBox "Critical Error: " & Err.Description, vbCritical
End Sub

''' <summary>
''' Windows APIを利用してプロセスのメモリ負荷を軽減する
''' </summary>
Private Sub ForceMemoryReclamation()
    Dim hProcess As LongPtr
    hProcess = GetCurrentProcess()
    ' 最小・最大ともに -1 を指定することで、OSに適切なメモリ管理を委ねつつ整理を促す
    Call SetProcessWorkingSetSize(hProcess, -1, -1)
End Sub

4. 技術的深掘り：なぜ `DoEvents` と `API` が必要なのか

`DoEvents` の真価

VBAのループ内で `DoEvents` を呼び出すことは、単なる「待ち時間」ではない。これは、CorelDRAWのメインスレッドに制御を戻し、「溜まっていた描画命令、メモリ解放の通知、OSからのメッセージ」をすべて処理させるためのトリガーである。これがないと、VBAのロジックだけが先行し、CorelDRAWの内部状態が追いつかずにメモリリークが加速する。

`SetProcessWorkingSetSize` の役割

このAPIは、プロセスが使用している物理メモリ（ワーキングセット）をOSの管理下に強制的に戻す。これにより、アプリケーションが確保したものの、実際には解放待ち（あるいは断片化）となっているメモリ領域を、OSが再利用可能な状態へと整理する。巨大なバッチ処理における「生存率」を劇的に向上させる、極めて強力な手段である。

5. アーキテクトとしての最終的な提言

もし、上記の対策を講じてもなおOOMが発生する場合、それはVBAの範疇を超えている。その時は、「プロセスの分離」を検討せよ。

1. 外部コントローラー（VB.NETやPython）の導入: VBA内で完結させず、外部プログラムからCorelDRAWを起動し、1つのチャンクごとにCorelDRAWのプロセス自体を一度終了させ、再度起動する。
2. メモリの完全リセット: プロセスをキルすることは、最も確実で、最も暴力的なメモリ解放方法である。

「ソフトウェアのバグ」と「物理的なリソースの限界」を混同してはならない。エンジニアの仕事は、限界を理解し、その限界が訪れる前に、システムを制御下に置くことにある。