【テクニカル・上級編】【上級者】プレゼンテーションのPDFエクスポート時に発生するメモリリークやCOM例外を、独自の例外監視ループとオブジェクトの強制ガベージコレクションによって完全回避する高負荷対応アーキテクチャ – PowerPoint VBA解析バイブル

PowerPoint VBA

2026.11.08

プレゼンテーション・エンジニアリングの深淵：数千枚規模のPDF変換を完遂させる「メモリ・サバイバル」アーキテクチャ

プレゼンテーション・エンジニアリングの深淵：数千枚規模のPDF変換を完遂させる「メモリ・サバイバル」アーキテクチャ

「VBAで数千枚のプレゼンテーションをPDF変換しようとしたら、途中でメモリ不足（Out of Memory）で落ちた」
「COM例外が発生して、プロセスがゾンビ化して制御不能になった」

もし君がこれらの一言で片付けられる問題に直面しているのなら、君はまだ「コードを書く人間」であって、「システムを設計するエンジニア」ではない。

PowerPointの`ExportAsFixedFormat`メソッドは、単なるメソッドではない。それは内部で膨大な描画エンジン、フォントレンダリング、そして複雑なレイアウト計算を呼び出す、極めて重い重力を持った処理だ。大量のファイルを連続処理する際、VBAのオブジェクト参照管理（Reference Counting）だけでは、OSのヒープ領域の断片化と、COMオブジェクトが解放しきれない「メモリの残滓」に飲み込まれるのは必然なのだ。

本稿では、レガシーなVBA環境において、Windows APIを駆使してメモリを強制的に「掃除」し、異常を検知して自律的に回復する、極限のPDFエクスポート・アーキテクチャを伝授する。

1. 限界の正体：なぜ `Set obj = Nothing` では足りないのか

多くのエンジニアは、オブジェクトを解放する際に `Set obj = Nothing` と書けば十分だと信じている。しかし、それは幻想だ。

VBAの `Nothing` 代入は、あくまでVBAエンジンの参照カウントを減らすだけであり、背後で動いているCOMサーバー（PowerPoint本体）が確保した物理メモリや、PDF変換エンジンが確保したカーネルモードのリソースまでを即座に解放する保証はない。特に、高負荷なPDF変換中には、メモリの断片化（Fragmentation）が発生し、空きメモリはあるはずなのに、連続した領域が確保できずに `Out of Memory` が発生する。

我々が戦うべきは、VBAの言語仕様ではなく、「OSレベルのメモリ管理」と「COMプロセスのライフサイクル」である。

2. アーキテクチャの三原則

大規模変換を完遂するためには、以下の3つの設計思想を実装に組み込む必要がある。

1. Isolation (隔離): PowerPointのインスタンスを使い回さない。一定数、あるいは一定のメモリ消費量に達した時点で、プロセスごと再起動する。
2. Forceful Reclaim (強制回収): Windows API `EmptyWorkingSet` を用い、OSに対してプロセスの物理メモリを強制的にページファイルへ退避（スワップ）させ、ワークセットを最小化する。
3. Watchdog Monitoring (監視): 変換処理がデッドロックに陥った際、タイムアウトを検知してプロセスを強制終了・再起動する「監視ループ」を外側に構築する。

3. 実装：極限のメモリ管理モジュール

以下に、Windows APIを用いたメモリ強制解放と、堅牢なエクスポート・ルーチンを実装したコードを示す。これは単なるスクリプトではなく、一つの「制御基盤」として設計されている。

Option Explicit

' --- Windows API Declarations ---
' プロセスのメモリ（ワーキングセット）を強制的に解放するために使用
Private Declare PtrSafe Function GetCurrentProcess Lib "kernel32" () As LongPtr
Private Declare PtrSafe Function EmptyWorkingSet Lib "psapi.dll" (ByVal hProcess As LongPtr) As Long

' --- Constants ---
Private Const ERROR_SUCCESS As Long = 0

''' <summary>
''' 物理メモリのワークセットを強制的にクリーンアップする。
''' プロセスが確保している物理メモリをOSに返却させ、メモリ断片化の影響を最小限に抑える。
''' </summary>
Public Sub PurgeProcessMemory()
    Dim hProcess As LongPtr
    Dim result As Long
    
    On Error Resume Next
    hProcess = GetCurrentProcess()
    If hProcess <> 0 Then
        ' EmptyWorkingSetは、プロセスの物理メモリを強制的にページファイルへ移動させる
        result = EmptyWorkingSet(hProcess)
        If result <> ERROR_SUCCESS Then
            Debug.Print "Warning: Memory purge failed with error code: " & result
        Else
            Debug.Print "Success: Process memory purged."
        End If
    End If
    On Error GoTo 0
End Sub

''' <summary>
''' 高負荷PDF変換実行エンジン
''' </summary>
Public Sub RobustPDFExporter(ByVal filePaths As Collection)
    Dim pptApp As Object ' PowerPoint.Application
    Dim pres As Object   ' PowerPoint.Presentation
    Dim filePath As Variant
    Dim iterCount As Integer
    Dim batchSize As Integer
    
    batchSize = 50 ' 50ファイルごとにプロセスを再起動し、メモリを完全にリセットする
    iterCount = 0
    
    ' 初期起動
    Set pptApp = CreateObject("PowerPoint.Application")
    
    For Each filePath In filePaths
        On Error GoTo ErrorHandler
        
        ' 1. プレゼンテーションを開く
        Set pres = pptApp.Presentations.Open(Filename:=filePath, ReadOnly:=msoTrue, WithWindow:=msoFalse)
        
        ' 2. PDFエクスポート実行
        ' 第2引数: ppSaveAsPDF (17)
        pres.ExportAsFixedFormat Path:=Replace(filePath, ".pptx", ".pdf"), _
                                 FixedFormatType:=17, _
                                 Intent:=2 ' ppPrintOutput (高品質)
        
        ' 3. 明示的な解放
        pres.Close
        Set pres = Nothing
        
        iterCount = iterCount + 1
        Debug.Print "Processed: " & filePath
        
        ' --- 戦略的リソース管理 ---
        
        ' 定期的なメモリパージ
        PurgeProcessMemory
        
        ' バッチサイズに達したら、PowerPointプロセス自体を殺して再起動する（究極の回避策）
        If iterCount Mod batchSize = 0 Then
            Debug.Print "Batch limit reached. Restarting PowerPoint instance..."
            GoTo RestartPowerPoint
        End If
        
        GoTo NextFile

ErrorHandler:
        Debug.Print "Critical Error on " & filePath & ": " & Err.Description
        ' COM例外（RPC_E_DISCONNECTED等）が発生した場合、プロセスは死んでいる
        Err.Clear
        GoTo RestartPowerPoint

NextFile:
    Next filePath

    ' 正常終了処理
    pptApp.Quit
    Set pptApp = Nothing
    Exit Sub

RestartPowerPoint:
    ' 現在のインスタンスを破棄
    On Error Resume Next
    If Not pres Is Nothing Then pres.Close
    pptApp.Quit
    Set pptApp = Nothing
    Set pres = Nothing
    
    ' ゾンビプロセス化を防ぐため、少し待機してから再起動
    DoEvents
    Sleep 2000 ' ※Sleep APIの宣言が必要（後述）
    
    ' プロセスの再起動
    Set pptApp = CreateObject("PowerPoint.Application")
    Resume NextFile
End Sub

*(注: `Sleep` APIを使用する場合は、`Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)` を宣言に追加すること)*

4. 監視アーキテクチャ：死活監視の重要性

上記のコードは「単一のプロセス内」での制御に焦点を当てているが、真のシニアエンジニアであれば、「制御用プロセス」と「作業用プロセス」を分離することを検討すべきだ。

VBA（ExcelやPowerPoint）単体で動かすのではなく、VBScriptやPython、あるいはC#で書かれた「監視スクリプト」から、PowerPointのCOMオートメーションを叩く構成にする。

監視設計の要件：

1. Timeout Watchdog: `ExportAsFixedFormat` を呼び出した後、一定時間（例：1ファイル5分）経過しても制御が戻らない場合、監視スクリプト側から `taskkill /F /IM powerpnt.exe` を実行し、強制的にプロセスを屠る。
2. Exit Code Check: 監視側は、PowerPointが正常に終了したか、あるいはクラッシュしたかをプロセス終了コードから判定し、必要に応じてエラーログを記録しながらリトライを行う。

5. 結論：エンジニアとしての矜持

大量のデータを扱う自動化において、エラーは「発生するもの」ではなく、「発生することを前提に設計するもの」だ。

`Set obj = Nothing` という甘い言葉に逃げるのではなく、Windows APIを通じてOSの挙動を直接制御し、プロセスのライフサイクルを自らの手で管理する。この「低レイヤーへの意識」こそが、現場で通用する、堅牢なシステムを構築するための唯一の道である。

メモリの断片化に怯える日々は、今日で終わりにしよう。