【実務・中級編】【中級者向け】段落の「スタイル」が手動で上書きされていないかチェックする監査ツール – Word VBA解析バイブル

スポンサーリンク

Word VBAを極める:段落の「直接書式」を駆逐せよ。品質管理のための監査ツール実装術

Wordドキュメントの運用において、最も頭を悩ませるのが「スタイルの崩壊」だ。
「見出し1」を適用しているはずなのに、なぜかフォントサイズが微妙に違う。強調表示が手動で太字にされている。この「直接書式(Direct Formatting)」の蓄積こそが、大規模ドキュメントをメンテナンス不能なゴミの山に変える元凶である。

今回は、プロフェッショナルな現場で品質を担保するための「直接書式監査ツール」の設計思想と実装を伝授する。

1. なぜ「手動修正」は悪なのか?

Wordのスタイル機能は、CSSのクラス設計に近い。スタイル定義を書き換えればドキュメント全体が一瞬で最適化される。しかし、ユーザーが段落の一部を選択し、リボンから個別に「太字」「フォントサイズ変更」「インデント調整」を行うと、それはスタイル定義に対する「上書き」として保存される。

この「直接書式」は、スタイルの変更を拒絶する
大規模なドキュメントで、後からフォントを一括変更しようとしても、手動でいじった箇所だけが取り残される。これを防ぐには、定期的に「スタイルと実態の乖離」を検出し、修正を迫る監査フローが不可欠だ。

2. 監査ツールの設計思想

Word VBAにおいて、直接書式を判定する鍵は `Paragraph.Range.Style` と `Paragraph.Range.Font`(あるいは `ParagraphFormat`)の比較にある。

しかし、愚直に全プロパティを比較してはいけない。Wordのオブジェクトモデルは、単なるプロパティの集まりではなく、複雑な継承関係を持っている。我々が監視すべきは、「スタイルから逸脱した情報が保持されているか」という一点に尽きる。

監査のポイント

  • Font.Bold / Italic: スタイルと一致しているか。
  • ParagraphFormat: インデントや行間がスタイルと異なっていないか。
  • パフォーマンス: `Selection` オブジェクトを操作するな。必ず `Range` オブジェクトでメモリ上を走査しろ。UIを更新するコストを極限まで排除する。

3. 直接書式監査ツール:プロダクションコード

以下のコードは、ドキュメント内の全段落を走査し、スタイル定義と異なる直接書式が適用されている箇所をイミディエイトウィンドウに出力する。これをベースに、Excelへのログ出力や、特定のスタイルへの強制リセット機能に拡張してほしい。

Option Explicit

‘ ———————————————————
‘ 監査ツール: 直接書式が適用された段落を特定する
‘ ———————————————————
Public Sub AuditDirectFormatting()
Dim para As Paragraph
Dim doc As Document
Set doc = ActiveDocument

Dim count As Long
count = 0

Application.ScreenUpdating = False

For Each para In doc.Paragraphs
‘ スタイルが標準的でない、かつ手動修正されている可能性がある場合
‘ ここではシンプルに「Font.Name」と「ParagraphFormat.LeftIndent」の乖離を例示
If IsDirectlyFormatted(para) Then
Debug.Print “【要チェック】ページ: ” & para.Range.Information(wdActiveEndAdjustedPageNumber) & _
” / 段落: ” & para.Range.Text
count = count + 1
End If
Next para

Application.ScreenUpdating = True
MsgBox “監査完了: ” & count & ” 箇所の直接書式を検出しました。”, vbInformation
End Sub

‘ ———————————————————
‘ 判定ロジック: スタイルとの乖離を判定する関数
‘ ———————————————————
Private Function IsDirectlyFormatted(para As Paragraph) As Boolean
Dim styleRef As Style
Set styleRef = para.Style

‘ 例: フォント名がスタイル定義と異なるか
If para.Range.Font.Name <> styleRef.Font.Name Then
IsDirectlyFormatted = True
Exit Function
End If

‘ 例: 左インデントがスタイル定義と異なるか
If para.Format.LeftIndent <> styleRef.ParagraphFormat.LeftIndent Then
IsDirectlyFormatted = True
Exit Function
End If

IsDirectlyFormatted = False
End Function

4. 運用上の注意点とさらなる高みへ

このツールを導入する際、以下の3点に留意せよ。

1. 「スタイル」の定義自体の正当性:
まず、基準となるテンプレート(.dotm)が完璧であることが大前提だ。テンプレートが汚れていれば、監査ツールは「正常な箇所」を「異常」と誤認する。
2. データベース連携:
大規模な案件では、この結果をCSVやJSONに出力し、SharePointリストやDBに蓄積せよ。どの担当者が頻繁に直接書式を発生させているかを分析することで、チームの教育コストを最適化できる。
3. 自動修正の危険性:
「直接書式をすべて消去する(`Range.Style = …`)」といった強制リセット機能は非常に強力だが、意図的な強調(赤字など)まで破壊する可能性がある。必ず「監査→手動確認→修正」のプロセスをフローに組み込め。

最後に

Word VBAは、現代のGUIツールが隠蔽してしまった「ドキュメントの構造」を操るための強力な権限だ。このコードをコピーして終わりにするのではなく、なぜこの実装が「速い」のか、なぜ `ScreenUpdating` を制御するのかを理解してほしい。

それができる者だけが、Wordという巨大な迷宮を支配できるエンジニアとなれる。健闘を祈る。

タイトルとURLをコピーしました