Word VBAの深淵：Findオブジェクトの書式継承とメモリ管理の「正解」
Wordの`Find.Execute`メソッドを使い、文字列を置換した瞬間に「フォント設定がデフォルトに戻ってしまう」という現象に頭を抱えた経験はないだろうか。
初心者向けのチュートリアルでは「`Replacement.Font`を設定せよ」と教えるのが関の山だが、我々のようなシステムアーキテクトにとって、それは解決ではない。既存の書式を維持し、かつメモリを浪費せず、複雑な文書構造の中で確実な置換を行う。これが求められるプロフェッショナルの仕事だ。
今日は、Word VBAにおける検索と置換の「書式継承の極意」と、その裏側にあるオブジェクトライフサイクルについて解説する。
—
1. なぜ「置換」で書式が崩壊するのか
Wordの`Replacement`オブジェクトは、デフォルトで「対象文字の書式を置換後の文字列に上書きする」という仕様を持っている。これを防ぐには、単純に`Replacement.ClearFormatting`を呼ぶだけでは不十分だ。
我々がやるべきは、「置換前の書式を一時的にキャプチャし、置換後のRangeに対して再適用する」というプロセスを、VBAのオブジェクトモデル上で極めて高速に処理することである。
2. 実装の要諦：Rangeオブジェクトの局所化
検索時に`Selection`オブジェクトを動かすのは最悪手だ。画面描画を伴うためパフォーマンスが著しく低下し、マクロの実行時間が数倍に膨れ上がる。必ず`Range`オブジェクトを生成し、メモリ内で完結させよ。
以下に、書式を完全に維持しつつ文字のみを置換する、実務レベルのコードを示す。
‘ 伝説的なチーフアーキテクトによる、書式維持置換の最適解
Public Sub SmartReplace(targetDoc As Document, findText As String, replaceText As String)
Dim rng As Range
Set rng = targetDoc.Content
‘ メモリリークを避けるため、オブジェクトの明示的な初期化と解放を徹底する
With rng.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = findText
.Replacement.Text = replaceText
.Forward = True
.Wrap = wdFindContinue
.Format = False ‘ 書式による検索を行わない（柔軟性確保のため）
.MatchCase = False
.MatchWholeWord = False
‘ 置換実行：ループ処理での重みを最小限にする
Do While .Execute(Replace:=wdReplaceAll)
‘ ここで必要に応じてDocumentの再描画抑制やイベント停止を検討せよ
Loop
End With
‘ オブジェクトの解放（VBAではNothing代入が基本だが、スコープ管理が真髄）
Set rng = Nothing
End Sub
3. 【深層】レガシー環境での書式保持：属性の引き継ぎ
もし置換箇所が「単一の書式」ではなく、「文中の一部分だけ太字になっている」といった複雑な書式を持っている場合、上記の方法では不十分だ。その場合は、一度`Find`で見つけた`Range`から属性を抽出する必要がある。
‘ 高度な書式保持：Rangeのフォント情報を引き継ぐロジック
Private Sub ReplaceWithFormatPersist(rng As Range, newText As String)
Dim fontName As String
Dim fontSize As Single
Dim isBold As Long
‘ 置換前のプロパティを保持
With rng.Font
fontName = .Name
fontSize = .Size
isBold = .Bold
End With
‘ 文字列を入れ替え
rng.Text = newText
‘ 保持した書式を再適用
With rng.Font
.Name = fontName
.Size = fontSize
.Bold = isBold
End With
End Sub
4. シニアエンジニアへの提言：パフォーマンスと堅牢性
大規模文書（数百ページを超える仕様書など）を扱う場合、以下の「掟」を忘れてはならない。
- `Application.ScreenUpdating = False`を徹底せよ
Wordの描画コストは極めて高い。処理開始直後に停止し、終了直後に再開することで、実行速度は劇的に向上する。
- イベントの無効化
`Application.EnableEvents = False` を活用し、置換によってトリガーされる不要なイベントリスナーをバイパスせよ。
- Windows APIとの連携
極めて巨大なテキスト置換を行う際、VBAのメモリ管理が追いつかない場合は、`Kernel32`の`GlobalAlloc`等を利用したバッファ管理も視野に入れるべきだが、現代の64bit版Office環境では、まずは`Range`オブジェクトの効率的な移動を優先すべきだ。
結論
Word VBAにおいて「書式」を制御するということは、単にプロパティを弄ることではない。オブジェクトが持つメモリ上の状態をいかに正確にハンドリングするかという、低レイヤーな意識が不可欠だ。
初心者は「動いた」で満足する。しかし、アーキテクトは「なぜ動いたのか、そしてそれは100万行の文書でも同じ速度で動くのか」を常に自問する。
君たちがコードを叩くとき、その背後にいるユーザーが快適に作業できるかどうか。その責任の重さが、エンジニアの質を決定づけるのだ。健闘を祈る。
