泥沼の「直接書式」を制する：Word文書の品質を担保する監査エンジニアリング
Word文書における最大の技術的負債は、XML構造を破壊する「直接書式（Direct Formatting）」である。スタイルベースの運用が崩壊し、書式がスパゲッティ化する原因の9割はここにある。
本稿では、Wordのオブジェクトモデルを深く理解し、文書の整合性をプログラム的に担保するための監査ツールについて、チーフアーキテクトの視点から解説する。
—
なぜ「直接書式」の監視が必要か
Wordの段落（`Paragraph`）オブジェクトには、スタイル（`Style`）という論理構造の上に、個別のフォントやインデントといった直接書式がレイヤー状に重なる。
手動でフォントサイズを1ポイントでも変更すれば、その段落は「スタイル定義」との乖離を起こす。大規模な文書でこれが頻発すると、後からのスタイル一括更新が機能せず、保守性が絶望的に低下する。我々は、この「意図せぬオーバーライド」を自動検出し、排除しなければならない。
技術的要諦：`Paragraph.Range.Font.Duplicate` の罠
多くの初学者は `Paragraph.Range.Font` を直接比較しようとするが、これは罠だ。Wordのオブジェクトモデルでは、一部でも未定義（`wdUndefined`）な属性が含まれている場合、比較結果が不正確になる。
ここで真価を発揮するのが、プロパティの完全なコピーをメモリ上に生成する `Duplicate` プロパティである。
実装：Direct Formatting 監査エンジン
以下は、文書内の全段落を走査し、スタイル定義と実際の書式が異なっている箇所をリストアップする実用コードである。
Option Explicit
‘ メモリ管理を意識した監査用プロシージャ
Public Sub AuditDirectFormatting()
Dim doc As Document
Dim para As Paragraph
Dim report As String
Set doc = ActiveDocument
‘ 画面描画の停止によるパフォーマンス最適化
Application.ScreenUpdating = False
Debug.Print “— 監査開始: ” & Now & ” —”
For Each para In doc.Paragraphs
‘ スタイルの属性と現在の範囲の属性を比較
If IsDirectFormattingApplied(para) Then
Debug.Print “監査警告: 段落 ” & para.ParaID & ” に直接書式が検出されました。”
‘ 必要に応じてここにログ収集や自動補正のロジックを挿入
End If
Next para
Application.ScreenUpdating = True
MsgBox “監査完了”, vbInformation
End Sub
‘ 直接書式が適用されているかを判定するロジック
Private Function IsDirectFormattingApplied(para As Paragraph) As Boolean
Dim styleFont As Font
Dim paraFont As Font
‘ スタイル定義のフォント設定を取得
Set styleFont = para.Style.Font.Duplicate
‘ 現在の段落のフォント設定を取得
Set paraFont = para.Range.Font.Duplicate
‘ 比較ロジック: ここでは簡略化のためNameとSizeを例示
‘ 厳密な監査には、ColorやBoldなどの属性を個別に比較する拡張が必要
If paraFont.Name <> styleFont.Name Or _
paraFont.Size <> styleFont.Size Then
IsDirectFormattingApplied = True
End If
‘ 明示的なオブジェクト解放（VBAの参照カウンタ管理の基本）
Set styleFont = Nothing
Set paraFont = Nothing
End Function
—
アーキテクトの視点：パフォーマンスと安定性の最適化
1. オブジェクトの明示的解放
VBAはガベージコレクションを備えていない。`Duplicate` で作成したオブジェクトは、スコープを抜ける前に必ず `Set = Nothing` で解放する。特に数千ページの文書をループ処理する場合、メモリリークはアプリケーションのクラッシュを招く致命的なバグとなる。
2. Windows APIによる高速化の検討
もし数百ファイル規模のバッチ処理を行う場合、`Word.Application` のオーバーヘッドが無視できなくなる。その際は、`Open XML SDK` を使用してバイナリレベル（`.docx` は実質的なZIP構造）で解析するアプローチへ切り替えるべきだ。VBAはあくまで「UI内での即時監査」に留め、システム連携レベルではC#/.NETによる解析を推奨する。
3. 運用への組み込み
このツールを単独で走らせるのではなく、文書保存時の `DocumentBeforeSave` イベントにフックさせ、品質基準を満たさない場合に警告を出す「ゲートキーパー」として実装するのが、エンタープライズレベルでの正しい活用法である。
結びに代えて
「設定すれば動く」というフェーズはとうに過ぎた。我々エンジニアが追求すべきは、ツールそのものの堅牢さと、それが生み出す文書の構造的品質である。
直接書式の排除は、単なるクリーンアップではない。それは、Wordというドキュメントプラットフォームを正しく理解し、制御下に置くための、技術者としての矜持そのものなのだ。
