Word VBAの深淵：メモリリークを排除し、数万ページの文書を「秒」で捌くための極限最適化
Word VBAで数千ページ規模の文書を処理した際、プロセスのメモリ消費量が右肩上がりに増大し、最終的に「Wordが応答しません」と沈黙する……。この地獄を見たことがあるだろうか。
多くの者は「VBAの限界」と片付けるが、それは誤りだ。Wordのメモリリークの正体は、VBAエンジンそのものではなく、WordのCOMオブジェクトモデルに対する「無知」と「放置」にある。
本稿では、レガシー環境を支配し、大規模文書処理を完璧に制御するための「オブジェクト生存戦略」を授ける。
—
1. なぜ「Selection」を使ってはいけないのか
初学者が犯す最大の過ちは、`Selection`オブジェクトをループ内で使い倒すことだ。
`Selection`はUIと直結している。これを使うたびに、Wordは描画更新（ScreenUpdating）を伴うオーバーヘッドを発生させ、さらにカーソル位置の追跡という重い処理を強いる。大規模文書における`Selection`は、CPUを焼くための燃料に過ぎない。
絶対の原則：
- `Selection`を排除し、`Range`オブジェクトのみを使え。
- `Range`はUIの描画を伴わず、メモリ内の構造体としてメモリ効率が圧倒的に高い。
—
2. オブジェクトライフサイクルとメモリ解放の真実
VBAはガベージコレクションを備えていない。オブジェクトを参照する変数は、明示的に `Nothing` を代入するまで、COMの参照カウントを保持し続ける。
大規模処理における「メモリリーク」の正体
ループ内で`Range`を生成し、参照を適切に破棄しなかった場合、Wordの内部スタックには無数の「ゴミ参照」が蓄積される。これが蓄積すると、Wordは新しいRangeを生成するたびにメモリの断片化（フラグメンテーション）を引き起こし、挙動が極端に遅くなる。
【禁忌】やってはいけないループ処理
‘ 悪夢のようなコード：ループのたびにRangeがメモリに残り続ける
For Each para In ActiveDocument.Paragraphs
Dim rng As Range
Set rng = para.Range ‘ ここで毎回新しいメモリ領域が確保される
‘ …処理…
‘ 破棄していないため、ループ終了までメモリは解放されない
Next para
【極意】正しいオブジェクトの破棄
Dim para As Paragraph
Dim rng As Range
For Each para In ActiveDocument.Paragraphs
Set rng = para.Range
‘ 処理内容
‘ 重要：次のループへ進む前に確実に開放する
Set rng = Nothing
Next para
—
3. パフォーマンスを極限まで引き出す「3つの鉄則」
大規模文書の自動化において、プロのエンジニアは以下の設定を「定石」として刻んでいる。
1. ScreenUpdatingの完全無効化
画面描画を停止させるだけで、処理速度は5倍〜10倍に跳ね上がる。
2. COM参照の再利用（Reuse, Don’t Recreate）
ループ内でオブジェクトを生成し続けるのではなく、既存のRangeの`Start`と`End`を動的に書き換えることで、メモリ確保の回数を減らす。
3. 明示的なDocumentオブジェクトの保持
`ActiveDocument`を参照し続けるのは危険だ。文書の切り替えや予期せぬポップアップで「現在地」がズレる可能性がある。必ず `Set doc = ActiveDocument` として、特定のメモリ領域を固定せよ。
—
4. 実践的コード：数千段落を秒で捌くテンプレート
以下は、大規模文書処理における「メモリを汚さない」ための標準実装パターンである。
Public Sub OptimizedParagraphProcess()
Dim doc As Document
Dim para As Paragraph
Dim rng As Range
‘ 描画停止による高速化
Application.ScreenUpdating = False
Set doc = ActiveDocument
‘ 処理の本体
For Each para In doc.Paragraphs
‘ 既存のRangeオブジェクトを使い回す
Set rng = para.Range
‘ 段落の条件判定
If rng.Style = “見出し 1” Then
rng.Font.Color = wdColorRed
End If
‘ 【重要】次のループの前に確実に開放
Set rng = Nothing
Next para
‘ 終了処理
Application.ScreenUpdating = True
Set doc = Nothing
MsgBox “処理完了。メモリ解放済み。”
End Sub
—
5. チーフアーキテクトからの助言：Windows APIの活用
もし、Wordの標準機能では到達できない領域（例：特定のプロセスのみの強制メモリ解放、あるいは外部DLLとの連携）が必要な場合、`kernel32`の `SetProcessWorkingSetSize` を活用せよ。
これは、プロセスに割り当てられた物理メモリを強制的にOSへ戻すための劇薬だ。
If VBA7 Then
Private Declare PtrSafe Function SetProcessWorkingSetSize Lib “kernel32” _
(ByVal hProcess As LongPtr, ByVal dwMinimumWorkingSetSize As LongPtr, _
ByVal dwMaximumWorkingSetSize As LongPtr) As Long
Private Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
End If
‘ メモリを強制的にOSへ返却するメソッド
Public Sub FlushMemory()
SetProcessWorkingSetSize GetCurrentProcess(), -1, -1
End Sub
このコードを重い処理の節目で実行することで、Wordは驚くほど軽快な状態を維持し続ける。ただし、乱用は禁物だ。OS側が「頻繁にメモリを要求するプロセス」と判断し、逆に動作が重くなる可能性がある。
—
結びに：伝説のエンジニアたるために
コードとは、単に動けばいいというものではない。それは、コンピューターのリソースに対する「礼儀」である。
Word VBAはレガシーだが、その設計思想の根底にあるCOMの仕組みを理解すれば、現代の言語では不可能なレベルの深い操作が可能だ。メモリ管理を疎かにする者は、いつか必ずシステムに牙を剥かれる。
「オブジェクトを制する者は、Wordを制する」。この言葉を胸に、貴殿の書くコードが、次の世代まで語り継がれる堅牢なものであらんことを。
