PowerPoint VBAの限界を突破せよ：巨大プレゼンテーションPDF変換におけるメモリ枯渇との戦い
PowerPoint VBAによる自動化において、数百枚規模のスライドを扱うPDF変換処理は、多くの開発者が「PowerPointのフリーズ」という壁に突き当たる魔の領域だ。
VBAの参照カウンタ（Reference Counting）に依存したメモリ管理は、オブジェクト階層が複雑化する巨大ファイルにおいて、致命的なメモリリークを引き起こす。なぜなら、VBAのガベージコレクションは「非決定的」であり、COMオブジェクトの解放タイミングを制御できないからだ。
本稿では、レガシーなVBAの限界をWindows APIで補完し、メモリ使用量を監視・制御しながら変換を完遂する「堅牢なアーキテクチャ」の真髄を伝授する。
—
1. なぜVBAはメモリを解放し損ねるのか
VBAの`Set obj = Nothing`は、単に変数から参照を切り離すだけであり、COMオブジェクトの実体（スタック上のメモリ空間）が即座に解放される保証はない。特に`ExportAsFixedFormat`などの重いメソッドを連続して呼び出すと、PowerPointのプロセス内ヒープ領域は断片化し、最終的に「システムリソース不足」でクラッシュする。
我々が取るべき戦略は一つ。「処理単位の隔離」と「COMオブジェクトの強制的な再構築」である。
2. 実装の要：プロセス監視と強制解放のアーキテクチャ
以下に示すコードは、Windows APIを駆使してプロセスのメモリ使用量を監視し、閾値を超えた場合に即座にクリーンアップを行うための基幹モジュールである。
‘ Windows API: メモリ使用量の取得用
Private Declare PtrSafe Function GetProcessMemoryInfo Lib “psapi.dll” ( _
ByVal hProcess As LongPtr, ppsmemCounters As PROCESS_MEMORY_COUNTERS, ByVal cb As Long) As Long
Private Type PROCESS_MEMORY_COUNTERS
cb As Long
PageFaultCount As Long
PeakWorkingSetSize As LongPtr
WorkingSetSize As LongPtr ‘ 現在の物理メモリ使用量
‘ … 他構造体定義は省略
End Type
‘ メモリ監視の閾値（Byte単位：例えば500MBで強制再構築）
Private Const MEM_THRESHOLD As LongPtr = 500 1024 1024
Public Sub RobustExportToPDF(filePath As String)
Dim pptApp As Application
Dim pptPres As Presentation
‘ 1. プロセスを個別に立ち上げ、処理後にプロセスごと殺すのが最も安全
‘ 巨大ファイル連続処理時は、1ファイルごとにインスタンスを作り直す
Set pptApp = New Application
Set pptPres = pptApp.Presentations.Open(filePath, WithWindow:=msoFalse)
‘ 2. メモリチェック
If GetCurrentUsage() > MEM_THRESHOLD Then
‘ 閾値超過時は適宜、スリープを入れるかログを残す
End If
‘ 3. PDF変換
pptPres.ExportAsFixedFormat …
‘ 4. 徹底的な解放手順（重要）
pptPres.Close
Set pptPres = Nothing
‘ インスタンスを強制終了し、COMの残骸をヒープから追い出す
pptApp.Quit
Set pptApp = Nothing
‘ 強制的にガベージコレクションをトリガーする（DoEventsの活用）
DoEvents
End Sub
Private Function GetCurrentUsage() As LongPtr
Dim pmc As PROCESS_MEMORY_COUNTERS
pmc.cb = LenB(pmc)
‘ カレントプロセスのハンドルを取得し、メモリ使用量を戻す
‘ … 実装詳細
End Function
3. シニアエンジニアが守るべき3つの鉄則
① 「Set Nothing」を信じるな、プロセスを殺せ
数GBの巨大ファイルを扱う場合、VBAの内部的なメモリリークを完璧に追うことは不可能に近い。処理単位（例えば1プレゼンテーション単位）で`Application`オブジェクトを個別に生成し、処理終了後に`Quit`させる。これが、PowerPointがメモリを解放しないという仕様に対する唯一無二の解法である。
② DoEventsの戦略的配置
VBAはシングルスレッドで動作する。重いメソッドの前後には必ず`DoEvents`を配置せよ。これにより、OS側に溜まったメッセージキューを処理させ、COMオブジェクトの破棄信号がより確実に送られるようになる。
③ 64bit版Officeの活用を前提とする
32bit版Officeの限界（2GBの仮想アドレス空間）は、現代の肥大化したプレゼン資料にはあまりにも狭すぎる。可能な限り64bit版への移行を推奨する。もしレガシー環境が必須であれば、上記のように「メモリ使用量を監視し、閾値でタスク再起動」を行う監視プロセスを親として実装せよ。
4. 結びに：安定したシステムを構築するために
自動化とは、単にコードを書くことではない。「予測不可能なリソース消費を、いかに制御下に置くか」という戦いそのものだ。
メモリリークを恐れて自動化を諦める必要はない。Windows APIとプロセス分離のアーキテクチャさえあれば、VBAは今なお最強の業務自動化ツールであり続ける。もし貴殿のシステムが不安定であるなら、それはコードのせいではなく、設計段階での「リソース管理の甘さ」に起因している。
さあ、その巨大なプレゼンテーションファイルを、安定した自動化の彼方へ送り届けよう。
