Word文書の「書式の迷宮」を解剖する：段落プロパティ監査エンジンの極意
Wordの文書管理において、最も忌むべき存在は「直接書式」である。スタイルという強固な規律があるにもかかわらず、現場のユーザーは無意識に太字やインデントを適用し、文書を肥大化させ、構造を破壊する。
私はこれまで数多のレガシーシステムと格闘してきたが、文書の「書式差異」を人の目で追うのは無駄な殺生に等しい。今回は、Wordのオブジェクトモデルを深層まで突き、スタイルからの逸脱をExcelへ抽出する「監査エンジン」の設計思想を伝授する。
1. オブジェクトモデルの限界と対峙する
Word VBAにおいて、`Paragraph`オブジェクトは単なるテキストの塊ではない。背後には膨大なプロパティが隠蔽されている。単純に `Paragraph.Format` をループするだけでは、再帰的な継承関係や、Characterレベルの直接書式（Direct Formatting）を完全には捕捉できない。
極限のパフォーマンスを求めるなら、以下の制約を理解せよ。
- Rangeオブジェクトの再生成コスト: `Paragraph.Range`を頻繁に呼び出すと、Wordの内部ヒープを断片化させる。一度変数に格納し、参照を使い回せ。
- イベントの抑制: `Application.ScreenUpdating = False` は基本だが、さらに `Application.DisplayAlerts = wdAlertsNone` を併用し、バックグラウンドでの描画更新を完全に殺せ。
- Excelとのブリッジ: `CreateObject(“Excel.Application”)` は、Late Binding（遅延バインディング）で行え。これにより、参照設定のバージョン差異による「コンパイルエラー地獄」から解放される。
2. 監査エンジンのコア・ロジック
以下に、標準スタイル（`Paragraph.Style`）と現在の書式を比較し、逸脱部分を特定するロジックを示す。
Option Explicit
‘ 伝説的な監査エンジン: Paragraph Style Auditor
‘ 目的: 標準スタイルからの直接書式適用箇所を特定し、ExcelへDumpする
Public Sub AuditParagraphFormats()
Dim wdApp As Object: Set wdApp = Application
Dim exApp As Object, exWb As Object, exWs As Object
Dim para As Paragraph, rowIdx As Long
‘ ExcelをLate Bindingで制御
Set exApp = CreateObject(“Excel.Application”)
Set exWb = exApp.Workbooks.Add
Set exWs = exWb.Sheets(1)
‘ ヘッダーの初期化
exWs.Range(“A1:D1”).Value = Array(“段落番号”, “スタイル名”, “差異の有無”, “直接書式詳細”)
rowIdx = 2
Application.ScreenUpdating = False
For Each para In ActiveDocument.Paragraphs
‘ 逸脱の検証: HasStyleで判定し、DirectFormattingを精査
‘ ここでは簡易的に「フォント名がスタイルと一致するか」を例示
If Not para.Range.Font.Name = para.Style.Font.Name Then
exWs.Cells(rowIdx, 1).Value = para.ParaID ‘ ParagraphのIDを取得
exWs.Cells(rowIdx, 2).Value = para.Style.NameLocal
exWs.Cells(rowIdx, 3).Value = “逸脱あり”
exWs.Cells(rowIdx, 4).Value = “フォント不一致: ” & para.Range.Font.Name
rowIdx = rowIdx + 1
End If
‘ 定期的なDoEventsでOSへの制御を戻す(高負荷時のフリーズ防止)
If rowIdx Mod 100 = 0 Then DoEvents
Next para
Application.ScreenUpdating = True
exApp.Visible = True
‘ メモリの解放：伝説のアーキテクトは参照を恐れない
Set exWs = Nothing
Set exWb = Nothing
Set exApp = Nothing
End Sub
3. なぜ「直接書式」を追うことが重要なのか
大規模なシステム連携や、XML/HTML変換を伴う文書生成において、直接書式は「ノイズ」となる。特に、複数のドキュメントを結合（Merge）する際、元文書の直接書式がスタイル定義を上書きし、レイアウト崩れを引き起こすケースを私は数えきれないほど見てきた。
このスクリプトは単なる調査ツールではない。文書の「純度」を保つための品質管理のゲートキーパーである。
4. チーフアーキテクトからの助言
1. Memory Management: 大規模文書の場合、`Paragraph`のループ中に作成される`Range`オブジェクトがメモリを圧迫する。ループの最後で必ず `Set para = Nothing` を明示的に行う習慣をつけよ。
2. Windows APIの活用: もしWordのプロセスが「応答なし」になるほどの巨大文書であれば、`GetTickCount` APIを用いてループごとの処理時間を計測し、タイムアウト制御を実装すべきだ。
3. レガシーの呪縛: `ParaID`はWord 2013以降の実装である。それ以前のレガシー環境で動かす場合は、`Paragraph.Range.Start` のオフセット値をキーにせよ。
コードは書くことよりも、「どう消すか」「どう解放するか」が重要である。このエンジンの出力結果は、あなたの文書管理における「技術的負債」のリストそのものであるはずだ。
さあ、今すぐコンソールを開き、文書の闇を可視化せよ。現場の混乱を収束させるのは、ツールではなく、あなたのその冷徹なまでの分析眼だ。
