【テクニカル・上級編】【中級者向け】置換処理の「Undo（元に戻す）」を1回で済ませるためのUndoRecord活用法 – Word VBA解析バイブル

Word VBA

2026.10.01

Word VBAの深淵：UndoRecordによる「置換の原子性」とメモリ管理の極意

Word VBAでドキュメントを弄る際、最も無防備な瞬間は「ループの中でFind/Replaceを繰り返す」時だ。
なぜなら、VBAの標準的な置換処理は、一つひとつの置換がUndoスタックに個別の操作として積まれるからだ。1,000箇所の置換を行えば、ユーザーはCtrl+Zを1,000回叩かなければならない。これは業務用システムとしては「未完成」以外の何物でもない。

今回は、UndoRecordオブジェクトを駆使し、Wordの内部スタックをハックして、数千の変更を「単一のトランザクション」として封じ込める技術を伝授する。

—

1. なぜ「UndoRecord」が必要なのか？

Wordの`Find.Execute`メソッドは強力だが、マクロで実行すると履歴が断片化する。巨大なドキュメントに対する置換処理において、この履歴の断片化は単なる操作性の低下にとどまらず、Wordのメモリ管理に無用な負荷をかけ、最悪の場合、メモリリークやスタックオーバーフローを誘発する。

`UndoRecord`オブジェクトは、この「操作の不可分性（Atomicity）」を保証するための強力な武器だ。

2. 実装の設計思想：原子的な置換処理

以下のコードは、単なる検索置換ではない。開始から終了までを一つの「論理的単位」としてWordのUNDOバッファに認識させる実装である。

‘ 伝説的なアーキテクトによる、UndoRecordを活用した置換ラッパー
Public Sub ExecuteBulkReplacement()
Dim wrdApp As Word.Application
Set wrdApp = Application

‘ UndoRecordオブジェクトのインスタンス化
Dim undo As UndoRecord
Set undo = wrdApp.UndoRecord

‘ トランザクションの開始（ここからCtrl+Z一回で戻せる）
undo.StartCustomRecord “一括置換処理_20231027”

On Error GoTo Cleanup ‘ 万が一のクラッシュに備えた安全装置

Dim rng As Range
Set rng = ActiveDocument.Content

With rng.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = “置換前文字列”
.Replacement.Text = “置換後文字列”
.Forward = True
.Wrap = wdFindContinue
.Format = False
.MatchCase = False
‘ 一括実行の高速化：ループを回すよりReplaceAllの方がエンジン効率が良い
.Execute Replace:=wdReplaceAll
End With

Cleanup:
‘ 異常終了時でもスタックを閉じないとWordが不安定になる
undo.EndCustomRecord

‘ オブジェクトの明示的解放（VBAのGCに頼らない意志）
Set rng = Nothing
Set undo = Nothing

If Err.Number <> 0 Then
MsgBox “システムエラーが発生しました: ” & Err.Description, vbCritical
End If
End Sub

—

3. シニアエンジニアが意識すべき「メモリの重み」

VBAは、一見すると高レベルな言語だが、その実態はWordのCOMオブジェクトを操るクライアントに過ぎない。

Undoスタックの肥大化抑制: `StartCustomRecord`を使用することで、個別の置換履歴がスタックに積まれるのを防ぐ。これにより、RAMの消費を劇的に抑え、長時間稼働するマクロでも「Wordが重くなる」現象を回避できる。
APIとCOMの境界線: `ActiveDocument.Content`をむやみに変数へ代入し続けると、COMの参照カウントが食い合って解放されなくなることがある。必ず`Set rng = Nothing`で参照を切り、スタックを閉じる直前でクリーンな状態を作るべきだ。
レガシー環境への配慮: 古いWord（2010以前など）でUndoRecordが予期せぬ挙動を示す場合は、`Application.ScreenUpdating = False`を併用し、描画負荷を物理的に遮断するのが定石だ。

4. 極限の知見：システム連携時の注意点

外部API（例えばREST APIから取得したJSONをドキュメントに流し込む処理）とこの置換を組み合わせる場合、「UndoRecordの中にネットワーク通信を入れない」ことが鉄則である。

ネットワーク遅延やタイムアウトが起きた際、`EndCustomRecord`が呼ばれずに中途半端なUNDOスタックが残ると、Word自体が「ハング状態」に近い不安定なメモリ領域へ突入する。
必ず、データ取得（API通信）を完了させ、メモリ上にデータが揃ってから「一瞬で置換処理を完遂する」設計にしてほしい。

—

結びに代えて

ツールを使いこなす技術者は多いが、Wordの内部スタックのライフサイクルを制御できる技術者は極めて少ない。
`UndoRecord`は、あなたの書いたコードが「プロフェッショナルなツール」であるか、「素人のおもちゃ」であるかを分かつ分岐点だ。

コードを記述する際は、常に「この処理が失敗したとき、ユーザーのドキュメントを汚さないか？」という問いを自分に投げかけよ。それこそが、伝説を築くアーキテクトの矜持である。