PowerPoint VBAにおけるメモリ管理の冷酷な現実
私たちが日々対峙するOfficeアプリケーションの中でも、PowerPointは特にメモリ管理において脆弱な構造を抱えている。
ExcelやWordと異なり、PowerPointは「ビジュアル（描画オブジェクト）」のレンダリングに最適化された設計思想を持つ。スライド、シェイプ、テキストフレーム、エフェクトといった個々の要素は、内部的に重厚なC++オブジェクトとして構築されており、VBA側からはCOM（Component Object Model）ラッパーを介してこれらを操作することになる。
数百枚におよぶスライド、あるいは数千個のシェイプを走査・更新するような大規模バッチ処理を愚直なループで実行すると、タスクマネージャー上の `POWERPNT.EXE` のプライベートバイト（Private Bytes）は瞬く間にギガバイト単位へと膨れ上がり、最終的には「メモリが不足しています」という無慈悲なシステムエラー（エラーコード `7`）とともにクラッシュする。
このクラッシュは、単に「PCの物理メモリが足りない」から起きるのではない。32bit版のOffice環境（未だ多くのエンタープライズ環境に残存している）における「2GBの仮想アドレス空間制限」、あるいは64bit環境であってもCOM参照カウンタの解放漏れによって発生する「論理的なメモリリーク」が本質的な原因である。
本稿では、このメモリリークのメカニズムを解剖し、ガベージコレクションを擬似的に制御するVBAの実装パターンと、Windows APIを組み合わせた極限の最適化アルゴリズムを提示する。
—
メモリ肥大化の真犯人：COMの幽霊とUndoスタック
大規模処理におけるメモリ肥大化の要因は、大きく分けて2つ存在する。
1. ドット連結による「COMの幽霊（Implicit Reference）」
VBA開発者が最も頻繁に犯す過ちは、以下のような「ドットで連結されたオブジェクト参照」である。
‘ メモリリークを誘発する典型的なコード
ActivePresentation.Slides(i).Shapes(j).TextFrame.TextRange.Text = “Data”
一見すると簡潔で美しいコードに見えるが、COMアーキテクチャの観点からは最悪の振る舞いを示す。
この1行を実行する際、VBAランタイムは内部で以下の「暗黙的な中間オブジェクト」を生成している。
1. `Slide` オブジェクト
2. `Shape` オブジェクト
3. `TextFrame` オブジェクト
4. `TextRange` オブジェクト
VBAのガベージコレクションは参照カウンタ方式（Reference Counting）である。明示的な変数に代入されずに生成されたこれらの中間オブジェクト（幽霊）は、参照カウンタの減算タイミングがVBAランタイムの制御下に置かれ、ループが終了するか、あるいはプロシージャを抜けるまでメモリ上に残り続ける。ループの内部でこの記述を何千回と繰り返せば、メモリ空間が幽霊オブジェクトで埋め尽くされるのは必然である。
2. 巨大化する「Undo（元に戻す）バッファ」
PowerPointは、VBA経由で行われたオブジェクトの追加・削除・プロパティ変更の履歴を、すべて内部の「Undoスタック」に蓄積する。
ユーザーがGUIから手動で元に戻せるようにするための親切設計だが、大量のデータをバッチ処理するシステムにとっては、この親切設計が致命的な足枷となる。
PowerPoint VBAには、Excelの `Application.Undo` を直接クリアするような軽量なメソッドが存在しない。そのため、処理中にUndoスタックを強制的に破壊、または蓄積させない工夫が必要となる。
—
極限の最適化：3つのアーキテクチャ設計
この冷酷な現実に立ち向かうため、私たちは以下の3つの設計原則を導入しなければならない。
原則1：変数スコープの極小化と「1ドット・1変数」ルール
すべてのCOMオブジェクトを個別の明示的変数に格納し、用が済んだら即座に `Set = Nothing` で解放する。
「1行にドットは1つ（または最小限）まで」を徹底する。
Dim oSlide As PowerPoint.Slide
Dim oShape As PowerPoint.Shape
Dim oTxtFrame As PowerPoint.TextFrame
Dim oTxtRange As PowerPoint.TextRange
Set oSlide = oPres.Slides(i)
Set oShape = oSlide.Shapes(j)
Set oTxtFrame = oShape.TextFrame
Set oTxtRange = oTxtFrame.TextRange
oTxtRange.Text = “Optimized Data”
‘ 逆順で厳密に解放（参照カウンタを確実にゼロにする）
Set oTxtRange = Nothing
Set oTxtFrame = Nothing
Set oShape = Nothing
Set oSlide = Nothing
原則2：プレゼンテーションの非表示起動（WithWindow:=msoFalse）
PowerPointの描画エンジン（Render Engine）は極めて重い。スライドが画面上に描画されるたびに、GDI/DirectXの描画リソースが消費される。
これを回避するため、バッチ処理対象のプレゼンテーションは必ず「非表示（`WithWindow:=msoFalse`）」で開く。これだけで、描画リソースの消費と処理時間を劇的に削減できる。
原則3：Win32 APIを用いた物理メモリ（Working Set）の強制回収
VBAが内部的に解放したメモリ領域は、即座にOSに返却されるわけではない。メモリアロケータ（Heap）にプールされたままとなり、プロセスのワーキングセット（Working Set）を占有し続ける。
これを解決するため、カーネルレベルでプロセスの物理メモリをトリミングするWindows API `EmptyWorkingSet` を定期的に呼び出す。
—
【完全版】大規模スライド一括処理エンジンの実装
以下に、これらすべての知見を凝縮した堅牢なVBAコードを示す。
数万個のオブジェクトを処理しても、メモリ消費が一定値（フラットライン）を維持するように設計された、プロダクション環境仕様の処理エンジンである。
Option Explicit
‘ —————————————————————————–
‘ Windows API 宣言（32bit / 64bit 両対応）
‘ —————————————————————————–
If VBA7 Then
Private Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
Private Declare PtrSafe Function EmptyWorkingSet Lib “psapi.dll” (ByVal hProcess As LongPtr) As Long
Else
Private Declare Function GetCurrentProcess Lib “kernel32” () As Long
Private Declare Function EmptyWorkingSet Lib “psapi.dll” (ByVal hProcess As Long) As Long
End If
‘ メモリ解放を行うインターバル（スライド何枚ごとにメモリをクリーンアップするか）
Private Const MEMORY_CLEANUP_INTERVAL As Long = 20
”’
”’
Public Sub ExecuteMassiveSlideProcessing()
Dim sFilePath As String
‘ テスト用パス（環境に合わせて変更してください）
sFilePath = “C:\Temp\MassiveSlidesPresentation.pptx”
‘ 画面更新の抑制（PowerPointでは限定的だが、警告ダイアログ抑制等に有効）
Application.DisplayAlerts = ppAlertsNone
Dim tStart As Double
tStart = Timer
On Error GoTo ErrorHandler
‘ 1. 処理実行
ProcessPresentation sFilePath
MsgBox “処理が正常に完了しました。” & vbCrLf & _
“実行時間: ” & Format(Timer – tStart, “0.00”) & ” 秒”, vbInformation, “システム通知”
ExitPath:
Application.DisplayAlerts = ppAlertsAll
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “エラー”
Resume ExitPath
End Sub
”’
”’
Private Sub ProcessPresentation(ByVal filePath As String)
Dim oPres As PowerPoint.Presentation
‘ プレゼンテーションを「非表示(WithWindow:=msoFalse)」で開く
‘ これにより、描画エンジンのオーバーヘッドを完全にバイパスする
Set oPres = Application.Presentations.Open(filePath, WithWindow:=msoFalse)
Dim lSlideCount As Long
lSlideCount = oPres.Slides.Count
Dim i As Long
For i = 1 To lSlideCount
‘ 個別のスライド処理をカプセル化されたプロシージャに委譲する
‘ これにより、プロシージャ境界でのローカル変数の自動解放を期待できる
ProcessSingleSlide oPres, i
‘ 定期的なメモリの強制クリーンアップ
If i Mod MEMORY_CLEANUP_INTERVAL = 0 Then
‘ 途中で一度保存を挟むことで、PowerPoint内部のUndoバッファとキャッシュを部分的にフラッシュさせる
oPres.Save
‘ OSレベルでの物理メモリトリミングを実行
ForceGarbageCollection
DoEvents
End If
Next i
‘ 最終保存とクローズ
oPres.Save
oPres.Close
Set oPres = Nothing
‘ 最終クリーンアップ
ForceGarbageCollection
End Sub
”’
”’
Private Sub ProcessSingleSlide(ByRef oPres As PowerPoint.Presentation, ByVal lSlideIndex As Long)
‘ 呼び出し元の参照を保持する変数は厳密に管理
Dim oSlide As PowerPoint.Slide
Set oSlide = oPres.Slides(lSlideIndex)
Dim oShapes As PowerPoint.Shapes
Set oShapes = oSlide.Shapes
Dim oShape As PowerPoint.Shape
Dim i As Long
‘ Shapesコレクションの走査
For i = oShapes.Count To 1 Step -1
Set oShape = oShapes.Item(i)
‘ テキストを持つShapeに対する処理例
If oShape.HasTextFrame = msoTrue Then
Dim oTxtFrame As PowerPoint.TextFrame
Set oTxtFrame = oShape.TextFrame
If oTxtFrame.HasText = msoTrue Then
Dim oTxtRange As PowerPoint.TextRange
Set oTxtRange = oTxtFrame.TextRange
‘ ————————————————————-
‘ 業務ロジック：ここではダミーの文字列置換処理を実行
‘ ————————————————————-
Dim sTemp As String
sTemp = oTxtRange.Text
oTxtRange.Text = “Processed: ” & sTemp
‘ ————————————————————-
‘ 子階層オブジェクトから順番に明示的解放
Set oTxtRange = Nothing
End If
Set oTxtFrame = Nothing
End If
‘ ループ内での参照解放
Set oShape = Nothing
Next i
‘ 親階層オブジェクトの解放
Set oShapes = Nothing
Set oSlide = Nothing
End Sub
”’
”’ 物理メモリ消費量を最小化する
”’
Private Sub ForceGarbageCollection()
#If VBA7 Then
Dim hProcess As LongPtr
Dim lResult As Long
hProcess = GetCurrentProcess()
lResult = EmptyWorkingSet(hProcess)
#Else
Dim hProcess As Long
Dim lResult As Long
hProcess = GetCurrentProcess()
lResult = EmptyWorkingSet(hProcess)
#End If
‘ デバッグ用メッセージ（必要に応じてイミディエイトウィンドウに出力）
‘ Debug.Print “Working Set Trimmed. Result Code: ” & lResult
End Sub
—
アーキテクチャの解説と技術的真髄
上記のコードには、一般的なVBAチュートリアルでは決して語られない、エンタープライズレベルの防御手法が組み込まれている。
1. プロシージャの分割によるスタックフレームの活用
メインのループ処理（`ProcessPresentation`）と、個別スライドの処理（`ProcessSingleSlide`）を厳密に分離している。
VBA（およびその基礎となるVB6ランタイム）は、プロシージャを抜ける際に、そのプロシージャのスタックフレームに割り当てられたローカル変数（COMラッパー）の参照カウンタを自動的に減算する。
すべてを一つの巨大なループで処理しようとすると、エラー発生時などに解放ロジックを迂回してしまうリスクが高まるが、このように「1スライド＝1プロシージャ」にカプセル化することで、ランタイムレベルでの自然なクリーンアップを確実に誘発させることができる。
2. `EmptyWorkingSet` APIの真価と誤解
`EmptyWorkingSet` は、指定したプロセスの物理メモリ（ワーキングセット）に割り当てられている不要なページを物理メモリから解放し、必要に応じて仮想メモリ（ページファイル）にスワップアウトするAPIである。
これについて、「単にメモリの見た目の数値を減らしているだけで、根本的な解決になっていない」という批判がなされることがある。しかし、これは半分正しく、半分は誤りである。
32bitアプリケーションの仮想メモリ空間（2GB）において、クラッシュを引き起こす直接の引き金は「アドレス空間の断片化（フラグメンテーション）」と「物理メモリの枯渇による割り当て失敗」である。
`EmptyWorkingSet` を定期的に呼び出し、OSのメモリマネージャーに対して「このプロセスは今、大量のメモリを必要としていない（アクティブではないページが多い）」と明示的に通知することで、OSは断片化したメモリプールを再編成し、物理メモリの割り当てを最適化する。
これにより、長時間のバッチ処理における「突然の死（サイレントクラッシュ）」の確率を極限まで下げることが可能となる。
3. `oPres.Save` による内部キャッシュの破棄
コード内のループ中に `oPres.Save` を実行している。一見するとディスクI/Oが発生して処理速度が低下するように思えるが、これには大きな意味がある。
PowerPointは、ドキュメントが「未保存（Dirty）」の状態である間、すべての操作履歴（Undo情報）とレンダリングキャッシュをメモリ内に保持し続ける。
一度 `Save` を実行すると、ドキュメントのステートが「保存済み（Clean）」になり、それまでに蓄積されていたUndoスタックが強制的にクリアされ、内部のテンポラリバッファも解放される。
処理速度（ディスクI/O）と安定性（メモリ消費）はトレードオフの関係にある。数百枚規模の処理においては、20〜50枚に1回程度の頻度で `Save` を挟むことが、システムを完走させるための現実的な最適解となる。
—
終わりに：COMという巨大な遺産と対話するために
私たちがVBAを通じて操作しているのは、1990年代に設計された頑強にして繊細なCOMという巨大な遺産（レガシー）である。
現代の .NET Core や Go、Rust といったメモリ安全性の高い言語に慣れたエンジニアにとって、VBAのメモリ管理は前時代的で、不条理に満ちているように見えるかもしれない。
しかし、そのアーキテクチャの底流にある「参照カウンタ」と「Windows OSのメモリ管理手法」を深く理解すれば、VBAは今なお強力で、Officeドキュメントを直接制御するための最も手軽で鋭利な刃物となる。
「幽霊オブジェクトを生まない」「用が済んだら即座に Nothing」「OSのAPIを恐れず叩く」。
この3つの原則を魂に刻み、堅牢なOfficeソリューションを構築していただきたい。
