Word VBAの深淵：画像挿入に伴う「行間レイアウト崩壊」を制するアーキテクチャ
Wordという文書エンジンは、一見するとWYSIWYGなワープロソフトだが、その内部構造は複雑怪奇なオブジェクトモデルの塊だ。特に「段落（Paragraph）」と「行間（LineSpacing）」の関係は、初心者が最も躓く罠であり、またシニアエンジニアがその挙動の不安定さに頭を抱える領域でもある。
画像（InlineShape）を挿入した途端、周囲のテキストが押し出され、行間設定が「1行」のままだとレイアウトが壊滅する。これを力技のマクロで解決するのではなく、Wordの描画パイプラインを理解し、メモリ効率を考慮した「プロフェッショナルな制御手法」を解説する。
—
1. なぜ「1行」設定は悪なのか
Wordの「行間：1行」は、フォントサイズに合わせて動的に計算される相対値だ。しかし、画像が挿入されると、Wordはその画像を「巨大な文字」として扱い、行高を無理やり引き伸ばす。この際、行間設定が動的であると、レンダリングエンジンは再計算の連鎖を引き起こし、パフォーマンスの低下とレイアウトの跳ね（Jumping）を誘発する。
我々が取るべき戦略は、「画像を含む段落のみ、行間を『固定値』へ強制遷移させ、高さを画像サイズ＋αに固定する」ことだ。
—
2. 極限の最適化を施した実装コード
以下のコードは、単にプロパティを書き換えるだけではない。オブジェクトの参照を最小化し、不要なレンダリング更新を抑制する設計にしている。
Option Explicit
‘ メモリリークを抑止し、レンダリングの再計算を最小化する設計
Public Sub AutoFixParagraphLineSpacing()
Dim doc As Document
Dim para As Paragraph
Dim ils As InlineShape
Dim targetHeight As Single
Set doc = ActiveDocument
‘ 画面更新停止：描画コストを極限まで削減
Application.ScreenUpdating = False
For Each para In doc.Paragraphs
‘ 段落内にInlineShapeが存在するか判定
If para.Range.InlineShapes.Count > 0 Then
For Each ils In para.Range.InlineShapes
‘ 画像の高さに余裕を持たせた値を算出（pt単位）
targetHeight = ils.Height + 6 ‘ +6ptは余白用
With para.Format
‘ 行間を固定値に変更
.LineSpacingRule = wdLineSpaceExactly
‘ 画像サイズに応じて固定値をセット
.LineSpacing = targetHeight
End With
Next ils
Else
‘ 画像がない場合は標準の1行に戻す（必要に応じて）
para.Format.LineSpacingRule = wdLineSpaceSingle
End If
Next para
‘ オブジェクトの明示的解放
Set ils = Nothing
Set para = Nothing
Set doc = Nothing
Application.ScreenUpdating = True
MsgBox “レイアウトの再構成を完了しました。”, vbInformation
End Sub
—
3. シニアエンジニアが留意すべき「見えざる制約」
このコードを実務環境へ導入する際、以下の3点に注意を払わなければならない。これができるか否かで、システムの「耐久性」が決まる。
A. レンダリングのキャッシュと再計算
`Application.ScreenUpdating = False` は必須だが、それでも複雑な文書ではWordはバックグラウンドで再描画を試みる。もし文書が数千ページ規模であれば、`ActiveDocument.UndoClear` を併用し、メモリ上のUndoスタックをクリアすることで、メモリ肥大化を回避すべきだ。
B. Floating Shapes（浮動オブジェクト）の罠
上記のコードは `InlineShapes`（文字列と共に流れる画像）のみを対象としている。`Shapes` コレクション（テキストボックス等で囲まれた画像）は別次元の座標空間に存在するため、これらも考慮するならば、`Shape.RelativeHorizontalPosition` 等のプロパティを解析する再帰的なスキャン処理が必要となる。
C. Windows APIによる「微調整」の誘惑
もし、OSレベルで描画エンジンを強制的に制御したいという衝動に駆られたとしても、VBAから直接 `GDI+` を叩くのは推奨しない。Wordの内部的な `TextLayoutEngine` は、APIによる介入を想定しておらず、これを強行すれば、保存時に文書破損（Corrupted Document）を招くリスクが極めて高い。「Wordのオブジェクトモデルの枠内で、最も効率的な属性変更を行う」ことこそ、伝説的なアーキテクトが辿り着いた結論だ。
—
結論
Word VBAの自動化において、最も重要なのは「コードの短さ」ではない。「Wordというブラックボックスに対して、いかに計算負荷をかけず、かつ意図した状態へ遷移させるか」という状態遷移の作法である。
今回提示した「固定値への切り替え」は、一見単純だが、Wordの再計算ロジックを静止させるための強力な防御策となる。大規模文書の自動生成や、システム間連携による帳票出力を行う際は、ぜひこの「行間固定」のアーキテクチャを標準装備として組み込んでほしい。
技術の深淵へ触れたいのであれば、まずは「なぜその行間が動くのか」を、Wordの内部ログではなく、自身のロジックで制御する感覚を養うことだ。健闘を祈る。
