【Word VBA】描画の呪縛を断て：Range直接操作による検索・置換の極限高速化
Word VBAの開発において、多くのエンジニアが最初に直面し、そして知らず知らずのうちにパフォーマンスのボトルネックを作り出す元凶がある。それが `Selection` オブジェクトの乱用だ。
「画面上でカーソルが動き、文字がハイライトされながら置換されていく」
このビジュアル的なフィードバックは、デバッグ時には安心感を与えるかもしれない。しかし、数百ページに及ぶ社内仕様書や、数万行の契約書データを相手にするエンタープライズ環境において、その挙動は「致命的な遅延」を意味する。
今回は、UIスレッドと完全に切り離された領域でドキュメントを高速かつ安全に処理するための、`Range` オブジェクトを軸にした直接操作の極限知見を公開する。
—
1. なぜ `Select` / `Activate` は「悪」なのか？
WordのVBAランタイムにおいて、`Selection` と `Range` は似て非なるものだ。
- `Selection` (選択範囲): 現在ユーザーインターフェース（GUI）上で選択されている領域を指す。これは常にWordアプリケーションのGUIスレッド、および画面描画（UIレンダリング）と同期している。
- `Range` (範囲): ドキュメント内の文字位置（開始・終了ポインタ）を示す抽象的なデータ構造であり、GUIの描画ツリーから完全に独立しているバックグラウンドメモリ上に存在する。
`Selection.Find` を実行すると、Wordはわざわざ画面上のビューポートをスクロールさせ、ハイライトを描画し、イベントキューを処理する。この「人間が見るための描画コスト」が、バッチ処理において数倍から数十倍のオーバーヘッドを生み出すのだ。
シニアエンジニアであれば、プログラムは「画面の裏側で、無音かつ高速に完結するべき」という原則を忘れてはならない。
—
2. 画面描画とイベントの完全な掌握（スクリーンの凍結）
`Range` オブジェクトを使う基本大前提として、Word自体の描画エンジンとイベントハンドラをコードの実行前に完全に沈黙させる必要がある。これを行わないと、どれほど美しい `Range` 操作を書いても、OSのウィンドウメッセージループが干渉して速度が落ちる。
以下の定石コードを、すべての重いマクロの起点に配置せよ。
‘ —————————————————————–
‘ プロシージャ名: ExecuteWithHighPerformance
‘ 概要: 画面描画と警告を抑制し、極限のパフォーマンスで処理を実行するラッパー
‘ —————————————————————–
Public Sub ExecuteWithHighPerformance()
Dim startTime As Double
startTime = Timer
‘ 【極限最適化ステップ1】画面描画の完全停止
Application.ScreenUpdating = False
‘ 【極限最適化ステップ2】バックグラウンド再計算の停止
Application.DisplayAlerts = wdAlertsNone
‘ 【極限最適化ステップ3】ステータスバーの更新停止（I/O削減）
Application.ScreenRefresh
On Error GoTo ErrorHandler
‘ — ここにメイン処理を記述 —
Call ProcessDocumentWithRange(ActiveDocument)
ErrorHandler:
If Err.Number <> 0 Then
MsgBox “エラー発生: ” & Err.Description, vbCritical
End If
‘ 【極限最適化ステップ4】環境のクリーンアップ（必ず復元すること）
Application.ScreenUpdating = True
Application.DisplayAlerts = wdAlertsAll
Debug.Print “処理完了時間: ” & (Timer – startTime) & ” 秒”
End Sub
—
3. `Range.Find` を用いた高速置換の実装パターン
`Selection.Find` を使ったコードを `Range.Find` に書き換えるのは難しくない。しかし、メモリ管理とオブジェクトのライフサイクルを意識しなければ、Word特有のメモリリークや無限ループの罠に嵌まる。
以下のコードは、指定したキーワードを `Range` 経由で検索し、選択（Select）を一切行わずに太字化と置換を同時に行う実例だ。
‘ —————————————————————–
‘ 関数名: ProcessDocumentWithRange
‘ 引数: targetDoc (Document)
‘ 概要: Rangeオブジェクトを用いたノンブロッキング高速置換エンジン
‘ —————————————————————–
Private Sub ProcessDocumentWithRange(ByRef targetDoc As Document)
Dim rngTarget As Range
‘ ドキュメント全体を内包するRangeを取得
Set rngTarget = targetDoc.Content
‘ Findオブジェクトの設定
With rngTarget.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = “旧システム名”
.Replacement.Text = “新クラウド基盤”
.Forward = True
.Wrap = wdFindStop ‘ 検索が文書末尾に達したら停止（重要）
.Format = False
.MatchCase = True
.MatchWholeWord = True
.MatchByte = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
‘ 実行と一括置換 (wdReplaceAll は Range でも有効かつ高速)
‘ ※ただし、ヒットした位置に対して個別の複雑な条件分岐を入れる場合は
‘ Do While ループで `.Execute` を回す必要がある。
.Execute Replace:=wdReplaceAll
End With
‘ オブジェクトの明示的解放（VBAガベージコレクタへのヒント）
Set rngTarget = Nothing
End Sub
なぜ `wdFindStop` なのか？
レガシーなマクロでは `.Wrap = wdFindContinue` が多用されるが、これを行うと検索がドキュメントの末尾から先頭に戻り、ループの制御を誤ると無限ループを引き起こす。`Range` を使う場合は `wdFindStop` を指定し、必要であれば明細をコントロールする方がアーキテクチャとして堅牢である。
—
4. ヒットした個別に高度な処理を加える場合のループパターン
単純な文字列置換であれば上記の `wdReplaceAll` で十分だが、「検索にヒットした特定の文字列のフォントサイズを変更しつつ、直後の段落書式を書き換える」といった複雑な要件では、`Range.Execute` をループさせる必要がある。
このとき、`Range` の性質（検索が成功すると、その `Range` 自体が「ヒットした文字列の範囲」に縮小・移動する）を利用するのが鍵となる。
‘ —————————————————————–
‘ 概要: 検索ヒット位置ごとに動的にRangeを制御する高度なパターン
‘ —————————————————————–
Public Sub AdvancedRangeProcessing(ByRef targetDoc As Document)
Dim rngSearch As Range
Set rngSearch = targetDoc.Content
With rngSearch.Find
.ClearFormatting
.Text = “【要確認】”
.Forward = True
.Wrap = wdFindStop
.MatchWildcards = False
‘ ループによる個別制御
Do While .Execute
‘ rngSearchは、この瞬間「【要確認】」という文字列の正確な位置を指している
‘ 例: ヒットした箇所の文字色を赤にし、太字にする
rngSearch.Font.Color = wdColorRed
rngSearch.Font.Bold = True
‘ 例: さらに、その範囲を含む「段落（Paragraph）」全体へアクセスする
Dim targetPara As Paragraph
Set targetPara = rngSearch.Paragraphs(1)
targetPara.Format.SpaceBefore = 6 ‘ 段落前余白を追加
‘ 【重要】無限ループを防ぐため、Rangeのポインタを「ヒットした文字列の末尾」に移動して検索を続行する
rngSearch.Collapse wdCollapseEnd
‘ オブジェクトの解放（ループ内でのメモリ肥大化を防ぐ）
Set targetPara = Nothing
Loop
End With
Set rngSearch = Nothing
End Sub
このコードの肝は、`rngSearch.Collapse wdCollapseEnd` である。これを行わないと、次の `.Execute` は「先ほど見つけた文字の先頭」を再度ヒットさせてしまい、永遠に同じ場所でループし続けることになる。`Range` を手動で前方に進めるこの感覚こそ、APIを直接叩くエンジニアに求められる作法だ。
—
5. チーフアーキテクトからの最終提言
VBAは「おもちゃの言語」と揶揄されることがある。しかしそれは、書く人間がUIの都合（`Select` や `Activate`）に引きずられたコードを書いている場合に限る。
WordのCOMオブジェクトモデルの深層を理解し、`Range` という名の「ポインタと長さを持つ純粋なデータ構造」を意のままに操る時、VBAはネイティブアプリケーションに匹敵する爆発的なパフォーマンスを発揮する。
画面の描画を断ち、不要なオブジェクトの生成と破棄をコントロールし、メモリを支配せよ。君たちの書くマクロは、もっと速くなる。
