Word VBAを掌握する極限の知見：変更履歴ONの地雷原で「置換（Find/Replace）」を安全に完遂する技術
Word VBAにおける`Find`および`Replacement`オブジェクトは、一見するとシンプルで強力なツールだ。しかし、「変更履歴（Track Revisions）」が有効な文書という極限環境に足を踏み入れた途端、このオブジェクトはサイレントバグを量産する「地雷原」へと変貌する。
開発プロジェクトで「変更履歴を残したまま、特定の用語を全置換してほしい」という要件を突きつけられたことはないだろうか？
何も考えずに `.Execute Replace:=wdReplaceAll` を叩けば、履歴の破損、不正な削除・挿入の混入、果てはWordプロセスのフリーズや文書の破損という悪夢を引き起こす。
今回は、Wordの内部構造と変更履歴のライフサイクルを知り尽くしたアーキテクトの視点から、この難問を華麗にクリアし、プロダクション環境で耐えうる堅牢な置換ロジックを伝授する。
—
なぜ、素朴な `.Execute Replace:=wdReplaceAll` は破綻するのか？
多くの初中級プログラマーが陥る罠は、以下のコードをそのまま実行することだ。
‘ 【アンチパターン】絶対にやってはいけない実装
Sub BadReplaceWithTrackRevisions()
ActiveDocument.TrackRevisions = True
With Selection.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = “旧用語”
.Replacement.Text = “新用語”
.Execute Replace:=wdReplaceAll ‘ ← これが文書を破壊する
End With
End Sub
1. 一括置換（`wdReplaceAll`）の暴走
変更履歴がONの状態で一括置換を行うと、Wordの内部エンジンは「検索範囲内の該当箇所」を一瞬ですべて書き換えようとする。この時、履歴のメタデータ（誰が、いつ変更したか）のインデックス同期が追いつかず、複数の変更履歴がグロテスクに絡み合った「削除されたはずの文字列が残る幽霊テキスト」や、XML構造の破損を引き起こす。
2. 「見えている文字列」と「履歴オブジェクト」の乖離
変更履歴が有効なとき、文書は単なる文字列の集合ではない。削除されたテキスト（取り消し線）も、追加されたテキストも、すべて「Revisionオブジェクト」として文書のDOM（Document Object Model）に存在し続ける。
一括置換は、この履歴のレイヤーを無視して突撃するため、意図しない範囲まで巻き込んで置換を行ってしまうのだ。
—
堅牢な設計：安全に変更履歴を残しながら置換するアルゴリズム
プロフェッショナルな現場に求められるのは、「一括置換のロマンを捨て、ループ処理による確実な個別置換」へのシフトである。
安全性を担保するための設計方針は以下の3点だ。
1. 一括置換（`wdReplaceAll`）を封印する
`.Execute` を1回ずつループさせ、ヒットした箇所を個別に制御する。
2. 検索方向の固定（`wdCollapseEnd`）
置換を行った後、カーソルを「置換後の文字列の末尾」に明示的に移動させ、無限ループや重複置換を防ぐ。
3. エラーハンドリングと画面描画の抑制
大量のループ処理が発生するため、`ScreenUpdating` を切り、パフォーマンスを極限まで高める。
—
【コピペOK】プロダクションコード例
以下に、実務の現場でそのまま組み込める、堅牢性を極めた置換プロシージャを示す。コメントを熟読し、設計の意図を汲み取ってほしい。
Option Explicit
/
- 変更履歴が有効な文書に対して、履歴を残しながら安全に文字列を置換する
- @Param targetDoc 対象のDocumentオブジェクト
- @Param findText 検索する文字列
- @Param replaceText 置換後の文字列
/
Sub SafeReplaceWithTrackRevisions(targetDoc As Document, findText As String, replaceText As String)
‘ パフォーマンス向上と画面ちらつき防止のため、描画と警告を停止
With Application
.ScreenUpdating = False
.DisplayAlerts = wdAlertsNone
End With
‘ 変更履歴が有効であることを強制確認
If Not targetDoc.TrackRevisions Then
targetDoc.TrackRevisions = True
End If
Dim rngSearch As Range
Set rngSearch = targetDoc.Content ‘ 文書全体を検索範囲とする
With rngSearch.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = findText
.Replacement.Text = replaceText
.Forward = True
.Wrap = wdFindStop ‘ 文書の最後まで来たら終了する（重要）
.Format = False
.MatchCase = True
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
‘ 一括置換(wdReplaceAll)は使わず、ループで1つずつ安全に処理する
Do While .Execute
‘ 検索範囲がヒットしたら、その場所で置換を実行
‘ 変更履歴がONのため、この置換操作自体が適切に履歴として記録される
rngSearch.Text = replaceText
‘ 【重要】置換後の文字列の末尾にレンジを折り畳み、次の検索開始位置とする
‘ これを行わないと、無限ループに陥るか、置換直後の文字列を再度検索してしまう
rngSearch.Collapse wdCollapseEnd
‘ 次の検索のために、文書の終端までの範囲を再設定
rngSearch.End = targetDoc.Content.End
Loop
End With
‘ 終了処理（必ず描画を戻すこと）
With Application
.ScreenUpdating = True
.DisplayAlerts = wdAlertsAll
End With
MsgBox “置換処理が正常に完了しました。”, vbInformation, “完了”
End Sub
‘ 実行用ラッパープロシージャ
Sub RunSafeReplace()
Dim target As Document
Set target = ActiveDocument
‘ 例：社内用語の統一
Call SafeReplaceWithTrackRevisions(target, “旧システム名”, “新次世代システム名”)
End Sub
—
ファイル連携・データベース連携における注意点
このVBAスクリプトを、Excelからのマクロ制御や、外部データベース（AccessやSQL Server）から取得した置換リストと連携させる場合、以下のアーキテクチャ上の注意が必要だ。
1. 置換リストの順序性（依存関係の排除）
データベースから「A」を「B」へ、「B」を「C」へ置換するようなリストを取得した場合、順序を誤ると「A」→「B」と置換された直後のテキストが、次の処理で「C」に書き換わるという連鎖置換（Cascade Replacement）の事故が起きる。
複数ワードの置換を行う場合は、文字列の長い順（あるいは競合しない独立したワード）にソートしてループを回す設計が必須となる。
2. メモリリークとオブジェクトの解放
大規模な文書や、複数のファイルを連続処理（バッチ処理）する場合、`Range`オブジェクトをループ内で生成・破棄する際にメモリリークが発生することがある。上記コードのように `rngSearch` を適切に使い回す（再定義する）か、処理の節目で明示的に `Set rngSearch = Nothing` を行う習慣をつけよ。
—
チーフアーキテクトからの総括
Word VBAにおける`Find`は、DOMの操作と密接に結びついている。特に「変更履歴」というメタデータが絡む領域では、甘いコードは確実に破綻する。
「動けばいい」という妥協を捨て、背後にあるオブジェクトのライフサイクルとWordエンジンの挙動をコントロールすること。それこそが、現場を救う真の自動化エンジニアの仕事である。この知見をあなたの武器とし、堅牢なソリューションを構築してほしい。
