聖域なきレイアウト統制：Word VBAによる行間「固定値」強制の実務知見
Wordの「1行」という単位は、グリッド線やフォントサイズに依存する極めて曖昧な基準だ。この「仕様」を放置することは、ドキュメントのレイアウト崩壊を運命づけるに等しい。システム間の帳票出力や、複数名で編集するドキュメントにおいて、レイアウトの完全再現を求めるなら、行間は必ず「固定値（pt）」で制御せよ。
今日は、Word VBAを用いて段落の行間を物理量として掌握するための、アーキテクト視点の実装を伝授する。
—
1. なぜ「固定値」でなければならないのか
Wordの行間設定には「最小値」「1行」「倍数」などが存在するが、これらはフォント設定や「グリッド線に合わせる」オプションの影響を直接受ける。特に日本語環境では、文字サイズが混在した瞬間にレイアウトは崩壊する。
シニアエンジニアとして肝に銘じてほしいのは、「Wordのデフォルト設定は、意図しない自動調整を許容する設計である」という点だ。我々が求めるのは、設計図通りのミリ単位の再現性である。そのためには `LineSpacingRule` を `wdLineSpaceExactly` に固定し、`LineSpacing` をポイント単位で指定する他ない。
—
2. 実装：メモリの最適化とオブジェクト制御の鉄則
単にプロパティを代入するだけのコードは素人でも書ける。ここでは、大規模文書を処理する際にもメモリリークを許さない、堅牢なモジュール設計を提示する。
実装コード
Option Explicit
‘ —————————————————————————–
‘ 目的：指定ドキュメントの全段落を固定行間に設定し、レイアウトを統一する
‘ 備考：大量の段落操作を伴うため、画面更新を抑制してパフォーマンスを最適化
‘ —————————————————————————–
Public Sub SetFixedLineSpacing(ByVal targetDoc As Document, ByVal ptValue As Single)
Dim para As Paragraph
‘ プロセス速度向上のための最適化：画面描画と再計算を停止
Application.ScreenUpdating = False
‘ 大規模文書でのパフォーマンス低下を避けるため、範囲指定ではなく
‘ 段落オブジェクトを直接イテレーションする
For Each para In targetDoc.Paragraphs
With para.Format
‘ 行間を「固定値」に設定
.LineSpacingRule = wdLineSpaceExactly
‘ ポイント単位で値を指定（1pt = 20 twips）
.LineSpacing = ptValue
‘ 【重要】「グリッド線に合わせる」を無効化
‘ これを行わないと固定値指定が無視される場合がある
.AutoSpaceBetweenDE = False
.AutoSpaceBetweenEAsian = False
End With
Next para
‘ 描画を再開して状態をリセット
Application.ScreenUpdating = True
‘ オブジェクトの明示的解放（VBAにおいては参照カウンタの減少を意識）
Set para = Nothing
End Sub
—
3. シニアエンジニアが押さえるべき「罠」
この実装を行う上で、必ず直面する「罠」が2つある。
A. 「グリッド線に合わせる」という亡霊
Wordには「行グリッド線に合わせる」という強烈な補正機能がある。たとえ行間を固定値にしても、段落設定でグリッド線に吸着する設定がONのままだと、固定値設定は無力化される。上記のコードで `Format` オブジェクトをいかに叩こうとも、この設定が生きている限りレイアウトは揺らぐ。`ParagraphFormat.DisableLineHeightGrid` プロパティを明示的に `True` に設定する制御を加えるのが、極限の自動化においては必須となる。
B. COM参照とメモリ管理
VBAはガベージコレクションが強力ではない。特に大規模なドキュメントで `Paragraph` をループする際、オブジェクトの参照を保持しすぎるとヒープメモリを圧迫する。ループ内でのオブジェクト生成は最小限にし、処理が終わった瞬間に参照をクリアする。これが、Wordが数千ページのドキュメントでクラッシュしないための「技術者の嗜み」だ。
—
4. 拡張：Windows APIを用いた環境強制
もし、この設定をドキュメントを開くたびに強制したいのであれば、`Document_Open` イベントをフックするのではなく、Wordアドイン（COMアドイン）を作成し、`WindowSelectionChange` 等で監視する手法も検討すべきだ。
さらには、レガシー環境で外部システムからWordを操作する場合、`CreateObject(“Word.Application”)` は必ず「非表示（Visible = False）」で開始し、`Application.Quit` を確実に実行するハンドラを組むこと。これを怠ることは、サーバー上にゾンビプロセスをばら撒く行為と同義である。
結びに：技術の深淵へ
「行間を揃える」という単純なタスク一つとっても、Wordの内部モデルを理解していれば、これほどの深掘りが可能だ。VBAは決して「古臭い言語」ではない。オブジェクトのライフサイクルと、Wordという巨大なCOMサーバーの挙動を完全に支配できたとき、それは最強の自動化ツールへと変貌する。
次回のブログでは、スタイル定義によるレイアウトの動的注入と、その構成管理手法について論じるとしよう。君たちの自動化が、より堅牢なものになることを期待している。
