Findオブジェクトの亡霊を断つ：Word VBAにおけるRange再定義の極意
Word VBAの自動化において、最も初歩的かつ、中級者が必ず膝を折る壁が「Findオブジェクトの無限ループ」である。
ドキュメントの末尾まで検索し、ラップアラウンド（再検索）の設定を誤ったまま次の置換処理へ移行すれば、検索結果は永遠に同じ地点をループする。あるいは、置換文字列が検索文字列を含んでいる場合、再帰的な置換によってメモリを圧迫し、Wordをフリーズさせることも珍しくない。
今日は、場当たり的な「フラグ管理」でこの問題を解決する素人臭い手法を捨て、「Rangeオブジェクトを論理的に再定義することで、検索空間を数学的に制御する」極限のアルゴリズムを伝授する。
—
1. なぜ「Find.Execute」は暴走するのか
Wordの`Find`オブジェクトは、ドキュメントの「現在のカーソル位置（またはRangeの開始点）」を起点に探索を行う。置換を行うたびに、Wordは検索範囲の終端を動的に計算するが、この挙動は特に「Rangeがドキュメント全体を跨ぐ場合」に不安定になる。
多くのエンジニアが陥る罠は、`ActiveDocument.Content.Find`をそのまま使い回すことだ。これはWordの内部ポインタを常に書き換えるため、処理の追跡が不可能になる。
解決策：再定義アルゴリズムの基本原則
検索範囲を`Range`オブジェクトとして完全に独立させ、「置換完了地点を新たな始点としてRangeを縮小・再構築する」というアプローチを取る必要がある。
—
2. 検索の重複を根絶する実装例
以下のコードは、文書全体を走査しつつ、メモリリークを排除し、かつ「置換の連鎖」を物理的に遮断するプロフェッショナルな実装だ。
Option Explicit
”’
”’
Public Sub SecureFindAndReplace(ByVal targetDoc As Document, _
ByVal findText As String, _
ByVal replaceText As String)
‘ メモリ管理: オブジェクト変数の明示的宣言
Dim rngSearch As Range
Set rngSearch = targetDoc.Content
‘ 最適化: 画面描画とバックグラウンド処理の切り離し
Application.ScreenUpdating = False
‘ Findオブジェクトの初期化とパラメーター設定
With rngSearch.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = findText
.Replacement.Text = replaceText
.Forward = True
.Wrap = wdFindStop ‘ ここが重要：ドキュメント末尾で停止させる
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchByte = False
.MatchAllWordForms = False
.MatchSoundsLike = False
.MatchWildcards = False ‘ 正規表現を使う場合はTrueにする
End With
‘ ループ制御：Rangeを前進させながら検索範囲を縮小させる
Do While rngSearch.Find.Execute
‘ 置換後のRangeの終端を次の検索開始位置にする
rngSearch.Collapse Direction:=wdCollapseEnd
‘ 注意: ここでRangeの範囲を再拡張して次の探索を行う
‘ 置換後の文字列に検索対象が含まれていても、このCollapse処理により
‘ 次の探索は置換後の文字列の「後ろ」から始まる
Loop
‘ 終了処理
Application.ScreenUpdating = True
‘ メモリ解放の徹底
Set rngSearch = Nothing
End Sub
—
3. なぜ「.Collapse」が伝説的な安定感をもたらすのか
`rngSearch.Collapse Direction:=wdCollapseEnd` を実行すると、`Range`は「直前の検索結果の末尾」という一点に収束する。
この一点から、再度ドキュメント末尾までの`Range`を再設定することで、「置換したばかりの文字列を、二度と検索対象に含めない」という物理的な制約をシステムに課すことができる。これは、再帰的な置換ループを論理的に排除する唯一無二の解法だ。
—
4. 上級者への警鐘：Windows APIとパフォーマンス
もし貴方が数千ページのドキュメントを処理しようとしているなら、VBA単体のループでは遅すぎる。
1. DoEventsの弊害: 長時間のループで`DoEvents`を安易に挟むな。これはスタックを不安定にし、Wordの描画スレッドを競合させる。
2. APIの活用: 処理速度を追求するなら、`LockWindowUpdate`（user32.dll）を呼び出し、Windowsレベルでウィンドウ描画をフリーズさせる方が、`Application.ScreenUpdating`よりも遙かに低負荷である。
3. オブジェクトの解放: VBAはガベージコレクションが極めて脆弱だ。`Set Nothing`を怠れば、COMオブジェクトの参照カウントが積み上がり、Wordがゾンビプロセス化する。
最後に
VBAは「レガシーな言語」などではない。「OSの深淵（COM/ActiveX）を直接叩ける、極めて強力なスクリプトエンジン」である。
Findオブジェクト一つを制御できないエンジニアは、APIを叩く資格がない。Rangeの伸縮を自在に操り、メモリの状態を可視化できているか。それが、このコードが貴方の現場で「伝説」になるか、ただの「バグの温床」になるかの分かれ道だ。
コードは嘘をつかない。論理が破綻していれば、必ずどこかでWordは沈黙する。その沈黙を恐れず、Rangeを再定義し続けよ。
