【Word VBA極意】配布文書の「フォント崩れ」を物理的に封殺する――埋め込み設定の自動診断と強制修復
業務文書がクライアントのPCで開かれた途端、レイアウトが崩壊し、フォントがMS明朝に置換される……。この「再現性の呪い」は、Word文書を扱うエンジニアにとって避けて通れない最大の敵です。
「フォントの埋め込み」は、設定メニューの深層に隠されており、属人化した運用では必ず漏れます。今回は、Word VBAのオブジェクトモデルを掌握し、この設定を強制的に制御する「堅牢な防衛機構」を実装します。
—
なぜ「設定確認」を自動化しなければならないのか
Wordの `SaveProperties` に含まれる `EmbedTrueTypeFonts` は、アプリケーション全体の設定ではなく、個別のDocumentオブジェクトに帰属するプロパティです。
多くのエンジニアが犯す過ちは、これを「Wordのオプション」と混同することです。ドキュメントごとに制御しなければならないこの設定を、手作業のチェックリストに頼ることは、エンジニアの怠慢と言わざるを得ません。我々は、コードでこれを「物理的に」制御します。
—
実装の核心：Documentオブジェクトを制する
今回の実装では、`ActiveDocument` に対して埋め込み設定を確認し、未設定であれば即座に書き換えるアーキテクチャを採用します。
堅牢なプロダクションコード
このコードは、単に設定をオンにするだけでなく、「その文書が本当に埋め込みを必要としているか」を判断するフローを組み込んでいます。
Option Explicit
”’
”’
Public Sub EnsureFontEmbedding()
Dim doc As Document
Set doc = ActiveDocument
‘ 1. オブジェクトの有効性チェック
If doc Is Nothing Then Exit Sub
‘ 2. 埋め込み設定の診断
‘ EmbedTrueTypeFonts = True であれば埋め込み有効
If Not doc.EmbedTrueTypeFonts Then
Debug.Print “警告: フォント埋め込みが無効です。修復を開始します。”
‘ 3. 設定の強制適用
‘ SaveSubsetFonts: 使用している文字だけ埋め込む（ファイル軽量化のため推奨）
‘ EmbedTrueTypeFonts: 埋め込み自体を有効化
With doc
.EmbedTrueTypeFonts = True
.SaveSubsetFonts = True
End With
‘ 4. 変更後のステータス確認
If doc.EmbedTrueTypeFonts Then
MsgBox “フォントの埋め込み設定を正常に適用しました。”, vbInformation
Else
Err.Raise vbObjectError + 1001, “FontFixer”, “設定の適用に失敗しました。読み取り専用属性を確認してください。”
End If
Else
Debug.Print “正常: フォント埋め込みは既に有効です。”
End If
End Sub
—
アーキテクトの視点：設計上の注意点
このツールを業務フローに組み込む際、以下の3点に注意を払う必要があります。
1. 読み取り専用属性と「保存」のジレンマ
VBAでプロパティを変更しても、物理的なファイルに永続化されるのは「保存時」です。もしこのロジックを読み取り専用のテンプレートファイルで実行しても、結果は保存されません。運用フローに `doc.Save` を含めるか、あるいは「保存を促すダイアログ」を出す設計が必須です。
2. ファイルサイズの肥大化
`SaveSubsetFonts = True` を指定することで、文書内で使用されていない文字の埋め込みを回避できます。これを `False` にすると、Windowsのシステムフォント全体が埋め込まれ、ファイルサイズが数メガバイト単位で跳ね上がります。「必要最小限」の埋め込みが、プロの流儀です。
3. テンプレート（dotm）への埋め込み
配布用文書の基となるテンプレート（Normal.dotmやカスタムテンプレート）に対してこのVBAを走らせてください。一度テンプレート側でフラグが立てば、そこから作成される新規ドキュメントは、デフォルトで埋め込み設定が継承されます。
—
まとめ：自動化は「防波堤」である
配布される文書がどの環境で開かれようとも、意図したデザインを維持する。それはドキュメントエンジニアとしての誠実さそのものです。
今回提示したコードは、単なるプロパティの書き換えではありません。「配布物の品質保証」を自動化するためのインフラストラクチャです。これを `Document_Open` イベントと組み合わせれば、ユーザーが意識せずとも常に最新の設定が適用される「自己修復型文書」を作成することも可能です。
次は、これをデータベース（SQL Server等）と連携させ、「どのバージョンの文書が、どの設定で作成されたか」をログとして残す実装へ踏み込むべきです。技術の深淵は常に足元にあります。さあ、実装を始めましょう。
