Word VBAを掌握する極限の知見：変更履歴オン環境における「罠」と、安全置換のアーキテクチャ
Word VBAにおける`Find`および`Replacement`オブジェクトの挙動は、Excelのそれとは一線を画す。特に、法務文書や官公庁向け仕様書などで必須となる「変更履歴の記録」が有効な文書において、安易な置換処理を実行することは、システムに爆弾を抱えるようなものだ。
変更履歴がオンの状態で標準的な`.Execute Replace:=wdReplaceAll`を叩いたとき、背後で何が起きているか。Wordのドキュメント構造（StoryRanges）、削除・挿入されたテキストのXML断片、そして変更者メタデータの肥大化。これらを理解せずして、エンタープライズレベルのWord自動化を語ることはできない。
本稿では、変更履歴を維持したまま、メモリリークや意図しない履歴の肥大化を防ぎ、安全に一括置換を完遂するための実装テクニックを、アーキテクトの視点から解説する。
—
1. 変更履歴オンの置換における「構造的罠」
なぜ、単純な置換マクロが実務で破綻するのか。原因はWordの内部エンジンとオブジェクトモデルの仕様にある。
履歴の二重生成とパフォーマンスの劣化
変更履歴が有効な場合、Wordは文字列を単に書き換えるのではなく、「削除されたテキスト（Deletion）」と「挿入されたテキスト（Insertion）」のデルタ（差分）をXMLノードとして文書の内部ストリームに記録する。
これを一括置換（`wdReplaceAll`）で大量に行うと、Rangeオブジェクトのポインタが狂い、最悪の場合、Wordプロセスがメモリリークを起こしてハングアップするか、文書構造（Storage）が破損する。
「一括置換」の誘惑を捨てよ
シニアエンジニアとしての第一歩は、`wdReplaceAll`の使用を原則禁止とする判断にある。変更履歴を正確に残し、かつ意図した範囲のみを安全に処理するためには、`Find.Execute`をループさせ、1件ずつヒット箇所を特定して置換処理を明示的にコントロールする「イテレーティブ・置換アプローチ」を採用しなければならない。
—
2. 実装アーキテクチャ：安全な履歴維持置換エンジン
以下に、変更履歴の整合性を完全に担保しつつ、オブジェクトのライフサイクルを厳密に管理した実践的なVBAコードを提示する。
Option Explicit
‘ ==============================================================================
‘ 模块名: ModSecureReplacer
‘ 概要 : 変更履歴をオンにした状態で安全に文字列置換を行うプロ仕様のエンジン
‘ 著作権: Enterprise Architecture LAB
‘ ==============================================================================
Public Sub ExecuteSecureReplacement()
Dim targetDoc As Document
Set targetDoc = ActiveDocument
‘ 1. 前提条件のチェックと環境のロック
If Not targetDoc.TrackRevisions Then
Dim answer As VbMsgBoxResult
answer = MsgBox(“変更履歴がオフです。オンにして実行しますか？”, vbYesNo + vbExclamation, “アーキテクチャ警告”)
If answer = vbYes Then
targetDoc.TrackRevisions = True
Else
Exit Sub
End If
End If
‘ 画面描画とバックグラウンド処理を停止し、パフォーマンスを最大化
Application.ScreenUpdating = False
Application.DisplayAlerts = wdAlertsNone
Dim targetString As String
Dim replaceString As String
targetString = “旧システム名”
replaceString = “新基幹システム”
‘ 2. 検索範囲（Range）の初期化
Dim searchRange As Range
Set searchRange = targetDoc.Content
‘ 3. Findオブジェクトの構成
With searchRange.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = targetString
.Replacement.Text = replaceString
.Forward = True
.Wrap = wdFindStop
.Format = False
.MatchCase = True
.MatchWholeWord = False
.MatchWildcards = False
End With
‘ 4. イテレーティブ・置換ループ（メモリ最適化を伴う）
Dim matchCount As Long
matchCount = 0
‘ 最初の検索実行
Do While searchRange.Find.Execute
‘ 変更履歴が有効な状態での安全な置換処理
‘ Rangeを直接書き換えることで、 Wordの履歴エンジンに正しいデルタを認識させる
searchRange.Text = replaceString
matchCount = matchCount + 1
‘ 処理の肥大化を防ぎ、ポインタの暴走を回避するため、Rangeを置換後末尾に再設定
searchRange.Collapse wdCollapseEnd
‘ 定期的なメモリ解放（大量ヒット時のCOMメモリ肥大化対策）
If matchCount Mod 100 = 0 Then
DoEvents
End If
Loop
‘ 5. クリーンアップと環境の復元
Application.ScreenUpdating = True
Application.DisplayAlerts = wdAlertsAll
‘ オブジェクトの明示的解放
Set searchRange = Nothing
Set targetDoc = Nothing
MsgBox “置換が完了しました。総置換箇所数: ” & matchCount & “件”, vbInformation, “完了”
End Sub
—
3. コードの急所：シニアエンジニアが押さえるべき3つのポイント
① `wdFindStop` による無限ループの完全回避
`.Wrap = wdFindContinue` を指定すると、文書末尾に到達した際に先頭に戻って検索を継続するため、置換文字列の中にさらに検索対象が含まれている場合（自己参照バグ）、無限ループに陥る。
安全なエンジンでは必ず `wdFindStop` を指定し、検索範囲の終端に達したら確実にループを抜ける設計にすること。
② `searchRange.Collapse wdCollapseEnd` によるポインタの再同期
`searchRange.Text = replaceString` によって文字列を書き換えた瞬間、`searchRange` オブジェクトの指し示す範囲は「置換された文字列全体」に広がる。
次のループで正しく次の文字を探索するためには、`Collapse` メソッドを用いてレンジの終端にポインタを縮退（Collapse）させ、そこから検索を再開させなければならない。これを怠ると、同じ箇所を無限に置換し続けるか、エラー落ちする。
③ COMオブジェクトのライフサイクル管理とメモリ最適化
VBAの裏側では、WordのCOM（Component Object Model）インスタンスがメモリを占有している。特に変更履歴が絡むループ処理では、内部の参照カウンタが肥大化しやすい。
コードの最後で `Set searchRange = Nothing` を明示的に実行し、VBAのガベージコレクション頼みではなく、即座にメモリを解放する習慣を徹底すべきである。
—
4. システム間連携・レガシー環境における保守の知見
もしこのVBAコードを、外部のC#アプリケーションやVBScriptからCOM経由でリモート実行（`COM Interop`）する場合、さらに注意が必要となる。
- セキュリティダイアログのブロック: 自動化プロセスの背後でWordが変更履歴の競合やマクロセキュリティのダイアログを出すと、プロセスが無応答（ゾンビプロセス）になる。`DisplayAlerts = wdAlertsNone` やあらかじめ信頼された立地（Trusted Location）への配置が必須。
- Wordセッションの共有汚染: `ActiveDocument` ではなく、必ず明示的に開いた `Documents.Open` の戻り値として Document オブジェクトを変数に保持し、処理後は `Close SaveChanges:=True` で確実にクローズすること。
変更履歴を伴うWord自動化は、単なるテキスト置換ではなく、「ドキュメントの歴史的変遷を壊さないための手術」である。オブジェクトの挙動を完全に掌握し、予測可能な堅牢なシステムを構築してほしい。
