【上級者向け】Word VBA 検索・置換処理における「メモリリーク」を完全排除するオブジェクト管理術
Word VBAによる数万ページ規模のドキュメント群のバッチ処理や、システム間連携における自動生成・置換パイプラインにおいて、最も恐れられている現象は何か。それは、処理の途中で突如発生する「メモリ不足（Out of memory）」エラー、そしてCOMコンポーネントの解放漏れによるプロセスのゾンビ化である。
世にあふれるVBAの入門書やブログ記事は、「`Selection.Find`を使えば簡単に置換できる」といった表層的なコードばかりを並べ立てる。しかし、実務で数時間、数日単位の連続稼働が求められるエンタープライズ環境において、`Selection`オブジェクトの乱用や、`Range`オブジェクトの不適切なライフサイクル管理は、確実にシステムを死に至らしめる。
本稿では、Word VBAの検索・置換エンジン（`Find` / `Replacement`）の深部にあるCOMのメモリ管理メカニズムを解き明かし、極限環境下でも1バイトのリークをも許さない、プロフェッショナルなオブジェクト管理術を提示する。
—
1. なぜWord VBAの検索・置換はメモリをリークするのか
VBAは一見するとガベージコレクタ（GC）が存在するような高級言語の顔をしているが、その実体はCOM（Component Object Model）のラッパーである。VBAコードからWordのオブジェクト（`Document`, `Range`, `Find`等）を操作するたびに、裏ではCOMの参照カウンタ（Reference Counter）がインクリメントされている。
Selectionオブジェクトの呪縛
多くの開発者が犯す最大の過ちは、ドキュメントの操作に `Selection` オブジェクトを使用することだ。
`Selection` はUI（ユーザーインターフェース）の状態と同期するため、画面描画のオーバーヘッドが発生するだけでなく、Wordアプリケーション内部のグローバルな状態を書き換える。ループ内で `Selection.Find.Execute` を繰り返すと、Wordの内部バッファやUndoスタック、そして裏で生成される一時的なCOMオブジェクトの参照が適切に解放されず、ヒープ領域を徐々に圧迫していく。
Rangeオブジェクトのスコープと参照の残骸
`Range` オブジェクトは `Selection` よりも高速で安全だが、こちらもライフサイクルを意識的に制御しなければリークの温床となる。
特に、`Find` 操作を実行した際に `Range` オブジェクトの範囲が暗黙的に再定義される挙動（テキストの伸長など）や、ループの各イテレーションで生成される参照がローカル変数のスコープを抜けても即座にCOM解放されない現象は、長時間のバッチ処理において致命傷となる。
—
2. 検索・置換における鉄則：UIからの完全な遊離
メモリリークを排除するための大前提は、「`Selection` を一切使わず、すべて `Range` ベースで処理を完結させること」である。さらに、ループ内では変数のスコープを極限まで絞り、不要になったオブジェクトは即座にメモリからパージ（解放）する必要がある。
以下のコードは、数千回〜数万回の置換処理を行ってもメモリ消費量を完全にフラットに保つ、極限まで最適化された置換エンジンのテンプレートである。
Option Explicit
‘ —————————————————————–
‘ チーフアーキテクト特製：メモリリーク完全排除型 高速置換エンジン
‘ —————————————————————–
Public Sub ExecuteEnterpriseReplace(ByVal targetDoc As Document, ByVal findText As String, ByVal replaceText As String)
Dim targetRange As Range
Dim foundCount As Long
foundCount = 0
‘ 1. ドキュメント全体の範囲を表すRangeオブジェクトを取得
Set targetRange = targetDoc.Content
‘ 2. Findオブジェクトの設定（Withブロックで参照をスコープ内に閉じ込める）
With targetRange.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = findText
.Replacement.Text = replaceText
.Forward = True
.Wrap = wdFindStop ‘ 文書の最後まで来たら終了（ループ暴走を防ぐ）
.Format = False
.MatchCase = True
.MatchWholeWord = True
.MatchWildcards = False
‘ 3. 効率的な一括置換実行
‘ 一度に見つかったすべてを置換する場合
.Execute Replace:=wdReplaceAll
End With
‘ 4. 明示的なオブジェクトの破棄
‘ ※VBAでは変数をNothingに設定することでCOM参照カウンタをデクリメントさせる
Set targetRange = Nothing
‘ 5. メモリのフラグメンテーションを防ぐための小休止（必要に応じてAPIを呼ぶ）
DoEvents
End Sub
—
3. 複雑な条件分岐を伴うループ処理でのオブジェクト管理
単純な一括置換（`wdReplaceAll`）ではなく、マッチしたテキストの前後に条件分岐を挟むような高度な処理では、`Range.Find.Execute` をループさせる必要がある。この時、「検索がヒットするたびに新しいRangeが生成・変化する」という仕様を理解していないと、無限ループやメモリリークの罠に嵌まる。
以下のコードは、個別にヒットしたRangeを操作しながらメモリを確実に解放する実装パターンである。
Public Sub ExecuteAdvancedIterativeReplace(ByVal targetDoc As Document)
Dim searchRange As Range
Set searchRange = targetDoc.Content
‘ 検索条件の構築
With searchRange.Find
.ClearFormatting
.Text = “【要機密確認】”
.Forward = True
.Wrap = wdFindStop
.MatchCase = True
End With
‘ ループ内で使用する変数を事前に定義（ループ内での暗黙のオブジェクト生成を抑制）
Dim foundFlag As Boolean
Do
‘ 検索実行
foundFlag = searchRange.Find.Execute
If foundFlag Then
‘ ヒットした場合、その瞬間のRangeに対して処理を行う
‘ searchRange自体がヒットしたテキストの範囲に縮小/移動する
‘ 例：ヒットした箇所のフォントカラーを赤に変更し、太字にする
searchRange.Font.Color = wdColorRed
searchRange.Font.Bold = True
‘ 【重要】次の検索を開始するためには、Rangeの開始位置を
‘ 「ヒットしたテキストの末尾」に移動させなければならない。
‘ これを行わないと無限ループに陥る。
searchRange.Collapse wdCollapseEnd
Else
‘ 見つからなければループ抜け
Exit Do
End If
Loop
‘ 終了後の確実な解放
Set searchRange = Nothing
‘ ガベージコレクションを促すための明示的解放（VBAランタイムへのヒント）
Application.ScreenRefresh
End Sub
—
4. 極限環境のためのメモリ最適化とAPI連携
数日間に及ぶ大規模なバッチ処理や、サーバーサイド（Windows Server等のヘッドレス環境）でWordプロセスをオートメーション化する場合、VBAのランタイムだけではCOMの解放タイミングが遅れ、徐々にメモリが枯渇していくことがある。
この問題を完全に解決するためには、明示的なオブジェクトの解放に加えて、Windows APIを活用したメモリの強制開放（Garbage Collectionの強制発火）が不可欠となる。
1. ワーキングセットの最小化（API呼び出し）
Windowsはプロセスが使用するメモリ（ワーキングセット）を効率のために保持し続けようとする。VBAからWindows APIを呼び出し、Wordプロセス（WINWORD.EXE）のメモリフットプリントを強制的にOSへ返還させることで、長時間のバッチ処理でもメモリ使用量をフラットに維持できる。
If VBA7 Then
‘ 64bit/32bit環境に対応したAPI宣言
Declare PtrSafe Function SetProcessWorkingSetSize Lib “kernel32” ( _
ByVal hProcess As LongPtr, _
ByVal dwMinimumWorkingSetSize As LongPtr, _
ByVal dwMaximumWorkingSetSize As LongPtr) As Long
Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
Else
Declare Function SetProcessWorkingSetSize Lib “kernel32” ( _
ByVal hProcess As Long, _
ByVal dwMinimumWorkingSetSize As Long, _
ByVal dwMaximumWorkingSetSize As Long) As Long
Declare Function GetCurrentProcess Lib “kernel32” () As Long
End If
‘ —————————————————————–
‘ プロセスのメモリ使用量をOSに強制返還するプロシージャ
‘ —————————————————————–
Public Sub FlushMemory()
Dim handle As LongPtr
handle = GetCurrentProcess()
‘ ワーキングセットの最小・最大サイズを一時的に縮小させることで、
‘ 未使用メモリをOSに強制解放させる
Call SetProcessWorkingSetSize(handle, -1, -1)
End Sub
2. バッチ処理アーキテクチャへの組み込み
数万ファイルのドキュメントを連続処理するメインループでは、一定数のファイルを処理するごとに `Set = Nothing` の徹底と `FlushMemory` の呼び出しを挟む設計が必須となる。
Public Sub BatchProcessDocuments(ByVal folderPath As String)
‘ 擬似的なバッチ処理ループ
Dim fileCount As Long
fileCount = 0
‘ … ファイル列挙処理 …
‘ ドキュメント処理のたびに以下を実行
‘ Set doc = Documents.Open(filePath)
‘ (検索・置換処理)
‘ doc.Close SaveChanges:=True
‘ Set doc = Nothing
fileCount = fileCount + 1
‘ 50ファイル処理するごとにメモリを強制フラッシュ
If fileCount Mod 50 = 0 Then
FlushMemory
DoEvents
End If
End Sub
—
5. チーフアーキテクトからの提言：レガシーの呪縛を断ち切れ
Word VBAにおける検索・置換は、一歩間違えればリソースを食いつぶす「システム破綻の爆弾」になり得る。しかし、オブジェクトのライフサイクルを正確に理解し、`Selection` を排除して `Range` を適切にスコープ管理、さらに必要に応じてOSレベルのメモリ管理（API連携）を取り入れることで、エンタープライズの荒波にも耐えうる堅牢な自動化基盤へと昇華させることができる。
「動けばいい」という妥協を捨て去り、一滴のメモリリークも許さないコードを書くこと――それこそが、真のプロフェッショナルエンジニアに課された責務である。
