Word VBAの深淵を覗く：段落の「フォント崩壊」をバイナリレベルで検知する極限の手法
Wordという巨大なモンスターを相手にするとき、多くの開発者は`Range.Font`や`Paragraph.Style`という「表層のAPI」に甘んじています。しかし、複雑なドキュメントの改修や、レガシーなデータ変換を繰り返す現場では、それら上位のオブジェクトモデルが「嘘」をつく瞬間に出くわすはずです。
「画面上は正しく見えているのに、保存すると文字化けする」
「特定の環境でだけ、一部のフォント情報が欠落する」
これらは、Wordの内部XML（OpenXML）やバイナリの構造において、フォントテーブルの参照整合性が破綻している証拠です。今回は、Word VBAでこの「見えない欠陥」を検知し、堅牢なドキュメント運用を実現するためのアーキテクチャを伝授します。
—
1. なぜ上位APIでは「破損」を検知できないのか？
`Selection.Font`や`Paragraph.Range.Font`が返す値は、Wordエンジンが解釈した「現在の表示結果」に過ぎません。これらは、フォントの埋め込み情報や、Unicodeのサロゲートペアが正しく保持されているかの「整合性」までを保証しません。
真に堅牢なツールを組むためには、「表示上のプロパティ」ではなく「文字のバイナリ表現」と「スタイル参照のID」を突き合わせる必要があります。
2. 実践：文字コードとフォントの整合性チェック・ロジック
以下は、段落内の各文字を走査し、フォント情報が保持されているか、およびUnicodeの異常値を検知するためのプロトタイプコードです。
Option Explicit
‘ @description: 段落単位でフォント情報と文字コードの整合性を解析する関数
‘ @param targetPara: チェック対象のParagraphオブジェクト
Public Sub AnalyzeParagraphIntegrity(targetPara As Paragraph)
Dim rng As Range
Dim char As Range
Dim charCode As Long
Set rng = targetPara.Range
‘ 文字単位で走査（Rangeオブジェクトのオーバーヘッドを最小化するため、必要最小限の範囲でループ）
For Each char In rng.Characters
‘ 1. 文字コードの取得
charCode = AscW(char.Text)
‘ 2. 異常なコードポイントの検知（例: 制御文字や未定義のサロゲートペア）
‘ ※実務ではここで特定のXML名前空間が期待通りかを確認する
If IsInvalidCharacter(charCode) Then
Debug.Print “破損検知: 位置 ” & char.Start & ” – 文字コード: ” & charCode
End If
‘ 3. フォントの埋め込み判定（APIレベルでの検証）
‘ NameFarEastが空、もしくは特殊な記号で埋め尽くされている場合は破損の兆候
If Len(char.Font.NameFarEast) = 0 And charCode > 127 Then
Debug.Print “フォント不整合警告: 位置 ” & char.Start & ” – フォント情報が欠落”
End If
Next char
End Sub
‘ 簡易的な文字コード検証ロジック
Private Function IsInvalidCharacter(code As Long) As Boolean
‘ 0-31の制御文字のうち、改行(13)以外を「破損」と見なす等のルールをここに定義
If code < 32 And code <> 13 And code <> 9 Then
IsInvalidCharacter = True
End If
End Function
3. 大規模データ連携における「禁じ手」と「正攻法」
このスクリプトを数百ページのドキュメントで実行する場合、`For Each`の多用はパフォーマンスを著しく低下させます。以下の設計原則を遵守してください。
- Rangeオブジェクトのキャッシュ:
`Range`をループ内で生成し続けると、メモリリークに近い負荷がかかります。一度`Paragraph.Range`を特定したら、その範囲内で処理を完結させてください。
- データベース連携の罠:
WordのデータをSQL Server等へ保存する場合、単なる`Range.Text`の取得は避け、必ず`Range.XML`（Flat OPC形式）をバイナリデータとしてBLOBへ格納してください。テキストのみ抽出すると、フォントの埋め込み情報は永久に失われます。
- 「スタイル」の強制再適用:
破損が検知された場合、プログラム側で`Range.Style = wdStyleNormal`を強制的にあて直し、その後に本来のスタイルを適用する「リセット・プロセス」を実装するのが最も安全です。
4. チーフアーキテクトからの提言
多くのエンジニアが陥る過ちは、Wordを「文書作成ソフト」としてのみ捉えることです。Wordは「XML/バイナリのデータコンテナ」です。
今回提示したような低レイヤーの解析手法は、ドキュメントの自動生成ツールを構築する際の「検品」として極めて強力です。コードが単なる「自動化」から「品質保証（QA）」へと昇華したとき、あなたのツールは現場にとってかけがえのないインフラとなります。
次回の記事では、`OpenXML SDK`をVBAからラップし、Word内部の`document.xml`を直接操作してフォントの埋め込みを修復する「極限の手法」について深く掘り下げます。
—
エンジニアへのメッセージ:
コードを書くことは、道具を作ることです。しかし、真のエンジニアリングとは、道具が壊れないための「境界条件」を定義することにあります。このコードが、あなたの現場の「不可解なバグ」を解決する一助となれば幸いです。
