Word VBAを掌握する極限の知見：`InlineShape`と`Shape`の境界線、そして座標支配のロジック
Word VBAの自動化において、多くの開発者が最初に直面し、そして最後まで頭を悩ませるのが「画像と図形の配置制御」である。
「文字と一緒に流れてしまう」「意図した座標に配置できない」「ページを跨ぐとレイアウトが崩壊する」。これらは、Wordのオブジェクトモデルにおける`InlineShape`（インライン図形）と`Shape`（フローティング図形）の本質的な違いを理解していないことから生じる必然の悲劇に他ならない。
本稿では、レガシーなWord文書構造の深層から、APIレベルの振る舞い、そして実務で即座に使える堅牢な自動化コードまで、シニアエンジニアが知るべきすべての知見を体系化する。
—
1. オブジェクトモデルの根本思想：`InlineShape` vs `Shape`
Wordのキャンバスは、Excelのシートのような絶対座標の世界ではない。テキストの流動性とページネーション（改ページ計算）が支配する特殊な空間である。この空間における2つの描画オブジェクトの差異を、アーキテクチャの観点から正確に把握せよ。
`InlineShape` （文字列と共に配置する）
- 正体: 本文中の「1文字」として扱われるオブジェクト。
- メモリ・ライフサイクル: `Paragraph.Range` 内に存在し、段落のフロー（段落の先頭、中央、末尾）に厳密に従属する。
- 座標制御: 不可能。`Top`や`Left`といったプロパティを持たず、配置は段落の「揃え（Alignment）」や前後のスペースに依存する。
- 用途: 書籍の挿絵や、レイアウトが厳密に固定されなくてもよい単純なインライン画像。
`Shape` （キャンバスに描画する / 浮動オブジェクト）
- 正体: テキスト層とは別の「描画レイヤー（Drawing Layer）」に存在するオブジェクト。
- メモリ・ライフサイクル: `Document.Shapes` コレクションに属し、必ずアンカー（Anchor：基準となる段落や文字範囲）を伴う。
- 座標制御: 完全可能。アンカーからの相対位置、あるいはページ上の絶対座標（`Left` / `Top`）をミリ単位（ポイント単位）で指定可能。
- 用途: 帳票の指定位置への印影配置、フォーマットが決まった公文書のロゴ挿入、複雑なレイアウト制御。
—
2. 座標指定の罠と「アンカー」の支配
`Shape` オブジェクトを操作する際、シニアエンジニアが最も警戒すべきは「アンカーの移動による座標の狂い」である。
`Shape.Left` や `Shape.Top` は、多くの場合「アンカー（基準段落）の上端・左端からの相対距離」または「ページ基準」として評価される。文書の編集によってアンカーが前のページに押し出されたり、改行が追加されたりすると、`Shape` 自体も連動して移動し、予期せぬレイアウト崩壊を引き起こす。
これを完全に制御するためには、以下の3ステップをコードで担保しなければならない。
1. `InlineShape` として安全にインポートする。
2. ドキュメント構造を破壊しないよう、適切なタイミングで `ConvertToShape` を実行する。
3. ラップ（文字の回り込み）とアンカーロックを明示的に設定する。
—
3. 実践：高精度画像配置エンジン（VBA実装）
以下のコードは、指定された画像を文書内の特定のキーワード（アンカー文字列）の直近に配置し、サイズと座標（余白からの絶対距離）をミリ単位で完全に制御する実用的なプロシージャである。
Option Explicit
‘ ==============================================================================
‘ 処理名: プレースホルダー置換型・高精度画像配置エンジン
‘ 概要: 指定キーワードを検索し、その位置をアンカーとして画像を絶対座標配置する
‘ ==============================================================================
Public Sub InsertImageAtAnchorPoint(ByVal targetDoc As Document, _
ByVal placeholderText As String, _
ByVal imagePath As String, _
ByVal widthMm As Single, _
ByVal heightMm As Single, _
ByVal leftMm As Single, _
ByVal topMm As Single)
Dim rngTarget As Range
Set rngTarget = targetDoc.Content
‘ 1. プレースホルダーの検索
With rngTarget.Find
.Text = placeholderText
.Forward = True
.Wrap = wdFindStop
.MatchWholeWord = True
If Not .Execute Then
MsgBox “指定されたアンカーが見つかりません: ” & placeholderText, vbCritical, “配置エラー”
Exit Sub
End If
End With
‘ 2. ミリメートルからポイントへの変換係数 (1 inch = 25.4 mm = 72 points)
Const MM_TO_PT As Single = 72.0 / 25.4
Dim targetWidth As Single
Dim targetHeight As Single
targetWidth = widthMm MM_TO_PT
targetHeight = heightMm MM_TO_PT
Dim targetLeft As Single
Dim targetTop As Single
targetLeft = leftMm MM_TO_PT
targetTop = topMm MM_TO_PT
‘ 3. InlineShapeとして安全に挿入 (メモリリークを防ぐためRangeオブジェクトを限定)
Dim inLinePic As InlineShape
Set inLinePic = targetDoc.InlineShapes.AddPicture(FileName:=imagePath, _
LinkToFile:=False, _
SaveWithDocument:=True, _
Range:=rngTarget)
‘ 4. インラインからフローティング(Shape)へ昇格
Dim targetShape As Shape
Set targetShape = inLinePic.ConvertToShape
‘ 5. オブジェクトのレイアウト・ラップ設定の厳密化
With targetShape
‘ 文字の回り込みを「外枠(Tight)」または「なし(None)」に設定
.WrapFormat.Type = wdWrapNone
‘ 祖先段落に対する相対位置ではなく、ページまたは余白からの絶対位置に固定
.LeftPositioning = wdShapePositionRelativeNone
.TopPositioning = wdShapePositionRelativeNone
‘ 座標の適用（ポイント単位）
.Left = targetLeft
.Top = targetTop
‘ サイズの適用（アスペクト比固定を解除して強制指定する場合）
.LockAspectRatio = msoFalse
.Width = targetWidth
.Height = targetHeight
‘ アンカーの移動ロック（文書編集による勝手な移動を防ぐ）
.LockAnchor = True
End With
‘ 6. 明示的なオブジェクト解放 (VBAのCOM互換レイヤー対策)
Set targetShape = Nothing
Set inLinePic = Nothing
Set rngTarget = Nothing
Debug.Print “画像配置完了: ” & imagePath
End Sub
—
4. チーフアーキテクトが教える極限の知見：メモリ最適化とレガシー環境の罠
大規模な帳票自動生成システムや、数千枚のPDF・Wordドキュメントをバッチ処理する基盤において、Word VBA（あるいはCOM Interopを通じたC#/VB.NET連携）は、しばしばメモリリークの悪夢を引き起こす。
COMオブジェクトの明示的解放
VBAのガベージコレクションは遅延評価であり、ループ内で `AddPicture` や `ConvertToShape` を大量に呼び出すと、Wordのバックグラウンドプロセスが肥大化し、最終的に `RPC_E_SERVERCALL_RETRYLATER` やメモリ不足エラーでクラッシュする。
- ループ処理内では必ず `Set obj = Nothing` を実行し、参照カウントを即座にデクリメントすること。
- 定期的に `DoEvents` を挟み、Windowsメッセージキューを処理させると同時に、COMプロセスの息継ぎ時間を確保せよ。
Word 2003レガシー形式 (`.doc`) とモダン形式 (`.docx`) の挙動差
`.doc` (Word 97-2003 Binary File Format) と `.docx` (OpenXML) では、描画レイヤーの構造が根本的に異なる。
- .doc: `Shape` の絶対座標計算が古いエンジンに依存しており、プリンタードライバーの変更によってレイアウトがズレるという致命的な仕様がある。
- .docx: XMLベースで完全に構造化されているため、今回紹介した `ConvertToShape` と絶対座標指定の組み合わせが非常に安定する。
レガシー環境の保守であっても、自動生成の出力フォーマットは可能な限り `.docx`（または `.docm`）に強制変換してから座標処理を行うべきである。
システム間連携（外部アプリケーションからの制御）時の注意
外部（C#の `Microsoft.Office.Interop.Word` など）からこのロジックを移植する場合、`Missing.Value` の扱いや、`Application.ScreenUpdating = False` による描画抑制がパフォーマンスの生死を分ける。特に座標計算を行う前には、必ず一度ドキュメントの再計算（`Document.Fields.Update` やページネーションの確定）を強制させるコードを挟むことが、環境依存のバグを防ぐ唯一にして最大の防御策となる。
—
結び
Wordは「ワープロソフト」ではなく、「ページネーションを持つ複雑なレイアウトエンジン」である。その中で座標を支配するには、GUIの常識を捨て、オブジェクトモデルの階層構造（Paragraph -> Range -> InlineShape -> Shape -> Canvas）を完全に手中に収める必要がある。
本稿で示したコードと知見が、あなたの自動化システムを「動くだけの脆弱なスクリプト」から「ミッションクリティカルな堅牢システム」へと昇華させるための確かな礎となることを確信している。
