Word VBAを掌握する極限の知見：スタイルとローカル書式の共存——Findオブジェクトによる「段落を破壊しない」文字列装飾の極意
Word VBAにおけるテキスト装飾において、多くの開発者が陥る致命的な罠がある。それが「`.Range.Font.Color`を用いた力技の着色」だ。
特定のキーワードを赤字にするために、ドキュメント全体を走査し、ヒットした文字列に対して直接フォントプロパティを書き換える——。このアプローチは一見して動くように見えるが、実務の現場においては「段落スタイルの崩壊」「保守性の消滅」「巨大ドキュメントでの致命的なパフォーマンス低下」という三重大罪を引き起こす。
Wordの本質は「スタイルの継承階層」にある。段落スタイル（Paragraph Style）が持つフォント定義に対し、文字単位の直接書式（Direct Formatting / ローカル書式）がどのようにオーバーライドされるか。このオブジェクトモデルのライフサイクルを理解していない者が書いたVBAコードは、ドキュメントの構造を静かに破壊していく。
今回は、段落の「スタイル」を微塵も傷つけず、`Find`オブジェクトの書式指定機能（`Replacement.Font`）を極限までチューニングして「特定のキーワードだけを安全に装飾する」ための実践的アーキテクチャを提示する。
—
1. なぜ「直接書式（Direct Formatting）」の乱用はシステムを破壊するのか
WordVBAにおいて、`Selection`オブジェクトや、安易に取得した`Range.Font`を操作することは、GUI上で「選択してフォントの色ボタンを押す」行為と同義である。
これを行収すると何が起きるか。
Wordの内部XML（`document.xml`）において、該当テキスト要素に `
さらに、数万行に及ぶエンタープライズ文書において、ループ内で毎回`Range`オブジェクトを生成・破棄するコードは、COMのMarshalling（境界跨ぎ）オーバーヘッドを増大させ、Wordをフリーズへと追いやる。
解決の鍵：`Find & Replace` エンジンの内部書式バッファの利用
Wordの`Find`オブジェクトは、UIの「検索と置換」ダイアログと完全に同一のC++ベースの高速エンジンをラップしている。
このエンジンに対し、「検索文字列」と「置換先の書式（Font Color）」のみをアタッチし、テキストの内容そのものは書き換えずに書式だけを上書き（Replace:=wdReplaceAll）させる。これが、スタイルを維持したまま高速に装飾を行う唯一にして最良の解である。
—
2. 実装コード：スタイルを死守する「セマンティック・ハイライター」
以下のコードは、シニアエンジニアの現場に耐えうる堅牢性を持たせたプロシージャだ。
無駄なオブジェクト生成を排除し、画面描画を停止（`ScreenUpdating = False`）することで、メモリとCPUの負荷を極限まで抑制している。
Option Explicit
‘ ==============================================================================
‘ 処理名 : HighlightKeywordPreservingStyle
‘ 概要 : 段落スタイルを破壊せず、指定キーワードのフォント色のみを安全に変更する
‘ 依存関係 : Microsoft Word 16.0 Object Library
‘ ==============================================================================
Public Sub ExecuteKeywordHighlight()
Dim targetDoc As Document
Set targetDoc = ActiveDocument ‘ 実際の運用では必要に応じてパス指定や呼び出し元から受渡す
‘ 監視対象のキーワードと、適用する色（RGB値）の定義
Const TARGET_KEYWORD As String = “機密情報”
Const TARGET_COLOR As Long = 192 ‘ RGB(0, 0, 192) など、wdColor定数またはRGB値
‘ パフォーマンスの極限最適化：UI描画とイベントの完全遮断
With Application
.ScreenUpdating = False
.DisplayAlerts = wdAlertsNone
.Calculation = wdCalculationManual
End With
Dim startTime As Double
startTime = Timer
On Error GoTo ErrorHandler
‘ Findオブジェクトの初期化とクリア
Dim rngTarget As Range
Set rngTarget = targetDoc.Content
With rngTarget.Find
.ClearFormatting
.Replacement.ClearFormatting
‘ 検索条件の設定
.Text = TARGET_KEYWORD
.MatchCase = True
.MatchWholeWord = True
.MatchWildcards = False
‘ 置換条件の設定（スタイルは触らず、フォントカラーのみを指定）
.Replacement.Font.Color = TARGET_COLOR
‘ 実行：テキスト自体は置換せず（置換前文字列を指定）、書式のみを適用
.Execute FindText:=TARGET_KEYWORD, _
MatchCase:=True, _
MatchWholeWord:=True, _
Forward:=True, _
Wrap:=wdFindStop, _
Replace:=wdReplaceAll
End With
Debug.Print “Highlight process completed successfully in ” & Format(Timer – startTime, “0.00”) & ” seconds.”
CleanUp:
‘ 描画プロパティの安全な復元（例外発生時も必ず実行）
With Application
.ScreenUpdating = True
.DisplayAlerts = wdAlertsAll
.Calculation = wdCalculationAutomatic
End With
‘ オブジェクト変数の明示的解放
Set rngTarget = Nothing
Set targetDoc = DataNull_Or_Nothing_Handling(targetDoc) ‘ ※ダミー。実際は Set targetDoc = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “VBA Architecture Error”
Resume CleanUp
End Sub
‘ 冗長な記述を避けるためのプレースホルダー関数（実際のコードでは単に Set obj = Nothing で十分）
Private Function DataNull_Or_Nothing_Handling(ByRef target As Document) As Document
Set target = Nothing
Set DataNull_Or_Nothing_Handling = Nothing
End Function
—
3. チーフアーキテクトが解説するコードの急所
① `.ClearFormatting` の不可欠性
`Find`および`Replacement`オブジェクトは、Wordセッション内で前回の検索条件（ボールドが有効だった、特定のスタイルが指定されていた等）をキャッシュし続ける。
これを明示的に `.ClearFormatting` でクリアしない場合、前回実行時のゴミ書式が今回の置換に混入し、意図しないスタイル崩壊を引き起こす。この初期化処理は、レガシーマクロの保守において最も見落とされがちな「地雷」である。
② `Wrap:=wdFindStop` の選択
ドキュメントの末尾まで検索した際に、ユーザーに対して「文書の残りの部分を検索しますか？」というダイアログを出させないために、`wdFindStop` を指定する。無人実行（バッチ処理・システム間連携）を前提とするアーキテクチャにおいて、ダイアログによる処理の停止はシステムクラッシュと同義である。
③ 計算モードの手動化（`wdCalculationManual`）
文書内に多数のフィールドコードや相互参照が存在する場合、文字単位の書式変更に伴ってWordがバックグラウンドで再計算（Field Update）を走らせ、激しいパフォーマンス低下を引き起こす。処理の冒頭で計算をマニュアル化し、最後に復元する一手間が、プロフェッショナルとアマチュアを分ける境界線となる。
—
4. レガシー環境・システム間連携における実務的知見
この手法をサーバーサイド（Windows Server上のCOMコンポーネントとしてのWord起動、あるいはPowerShellからのVBA呼び出し）で運用する場合、以下の制約事項に直面する。
1. セッション0の壁とUIの不在
サーバー環境では画面描画（`ScreenUpdating`）やアラート表示（`DisplayAlerts`）は完全に無効化されているが、WordのCOMインスタンスは内部的にウィンドウプロシージャを要求することがある。上記コードのように明示的にステータスを制御・固定することが、サーバーサイドでの「ゾンビプロセス化」を防ぐ防壁となる。
2. メモリリークの完全排除
VBAのガベージコレクションは参照カウント方式である。`Range` や `Document` オブジェクトをループ内で生成する場合、スコープを適切に切り、処理が終わるごとに `Set xxx = Nothing` を徹底すること。特にWord VBAでは、COMラッパーの解放漏れがメモリリークに直結し、IISや外部タスクランナーの枯渇を招く。
総括
段落スタイルを保持したままのスマートな文字列修飾は、単なる「見た目の美しさ」の追求ではない。それはドキュメントという構造化データの整合性を守り、システムの信頼性を担保するためのエンジニアリングである。
小手先のプロパティ操作に頼るのではなく、Wordのエンジンが持つプリミティブな仕様をハックすること。それこそが、現場を生き抜くシニアエンジニアの正しい姿である。
