Word VBAの「Undoスタック」を掌握せよ：業務自動化における不可視の流儀
Word VBAでドキュメントを弄る際、多くのエンジニアが犯す致命的な過ちがある。「VBAによる操作は、ユーザーのUndo履歴を断片化させる」という事実を軽視していることだ。
100個の段落を修正した際、ユーザーがCtrl+Zを100回連打しなければ元の状態に戻せないシステムは、プロダクトとしては「未完成」である。プロフェッショナルな業務自動化とは、単に処理を速くすることではない。WordのUndoスタックを意のままに操り、VBAの操作をユーザーの「一連の思考」の一部として統合することにある。
本稿では、VBAによる大量の書式変更を単一のUndoスタックへ統合する、極限のアーキテクチャを解剖する。
—
1. Undoスタックの深淵：`UndoRecord` オブジェクトの真実
Word 2010以降、Microsoftは `UndoRecord` オブジェクトという隠し球を提供した。これを使わずに自動化を行うのは、地図を持たずに暗闇を歩くようなものだ。
`UndoRecord.StartCustomRecord` と `EndCustomRecord` で囲まれた範囲は、WordのUndoエンジンに対して「これらは一つの操作である」という原子性（Atomicity）を宣言する。
実装の極意：Undoレコードの統合コード
‘ 伝説的な自動装飾エンジンの核となるプロシージャ
Public Sub ApplyProfessionalFormatting(targetRange As Range)
Dim undoScope As UndoRecord
Set undoScope = Application.UndoRecord
‘ Undoスタックの境界を定義
undoScope.StartCustomRecord “一括書式適用エンジン”
On Error GoTo Cleanup
‘ 処理の高速化：画面描画とバックグラウンド再計算を停止
Application.ScreenUpdating = False
‘ ここに高度な書式適用ロジックを展開する
‘ パフォーマンスを極めるため、Rangeオブジェクトを個別に触らず
‘ Find/Replaceによる一括置換または特定のスタイル適用を推奨
With targetRange
.ParagraphFormat.Alignment = wdAlignParagraphJustify
.Style = ActiveDocument.Styles(“業務文書標準”)
End With
Cleanup:
‘ 常に状態を復旧させるのがアーキテクトの矜持
undoScope.EndCustomRecord
Application.ScreenUpdating = True
If Err.Number <> 0 Then
MsgBox “書式適用中に例外が発生: ” & Err.Description, vbCritical
End If
End Sub
—
2. パフォーマンスの境界：メモリ解放とWindows APIの静かなる協奏
大量の段落をループ処理する場合、VBAのガベージコレクション（GC）を待っていてはならない。メモリリークはレガシー環境における最大の敵だ。
オブジェクトの明示的解放とメモリ管理
Wordは、`Range` や `Paragraph` オブジェクトを生成するたびに内部ヒープを消費する。大規模文書では、ループ内でオブジェクトを生成し続けず、可能な限り `Find` オブジェクトの `Replacement.ParagraphFormat` を利用し、「Wordのカーネル側で処理させる」のが鉄則だ。
Windows APIによる「強制再描画」の抑制
複雑な書式設定を行うと、Wordは裏で何度も「再描画」と「レイアウト計算」を繰り返す。これを防ぐために `LockWindowUpdate` APIを駆使する手法があるが、現代のWord VBAでは `Application.ScreenUpdating = False` が十分に最適化されている。ただし、外部DLLやCOMコンポーネントと連携する場合、以下のようにWindows APIでウィンドウの更新を完全に沈黙させるのが、真のシニアの選択だ。
‘ API宣言（モジュールの先頭に配置）
If VBA7 Then
Private Declare PtrSafe Function LockWindowUpdate Lib “user32” (ByVal hWndLock As LongPtr) As Long
Else
Private Declare Function LockWindowUpdate Lib “user32” (ByVal hWndLock As Long) As Long
End If
‘ 使用時の知見：絶対にエラーハンドラ内でLockWindowUpdateを解放せよ。
‘ さもなくばWordのUIが凍結し、ユーザーは強制終了を余儀なくされる。
—
3. レガシー保守の極限：システム間連携の知見
APIやデータベースから取得したJSONデータをWordに流し込む際、スタイルの適用順序を誤ると、文書全体のXML構造（Flat OPC）が崩壊する。
- スタイルの再定義: 常にテンプレート（.dotm）をベースにし、VBA側でスタイルを上書き修正（`Styles.Add` または `Style.Update`）するのは避けよ。代わりに、文書プロパティやカスタムXMLパーツにメタデータを保持させ、スタイルはWordのスタイルセットに依存させる。
- Undoスタックの防波堤: 大規模なデータ投入を行う際は、Undoスタックを `Application.UndoRecord` で区切るだけでなく、一度 `Undo` を無効化（`Application.UndoClear`）する勇気も必要だ。トランザクションが肥大化しすぎてメモリを圧迫する場合、それが唯一の解となる。
—
結びに代えて：アーキテクトからの忠告
Word VBAは「枯れた技術」ではない。Wordという巨大なGUIを持つCOMインターフェースを、いかにエレガントに制御するかという、現代においても極めて難易度の高いアーキテクチャの現場である。
読者諸氏が記述するその一行が、ユーザーの作業時間を1秒短縮し、誤操作によるストレスを一つ排除する。その積み重ねこそが、伝説と呼ばれるシステムの礎となる。
コードを書け。ただし、それは常に「ユーザーの操作体験」の延長線上にあることを忘れるな。
