【実務・中級編】【中級者向け】表の列幅をミリ単位で厳密に制御し、印刷時のレイアウト崩れを防ぐ – Word VBA解析バイブル

「AutoFit」という名の罠を越えろ：Word VBAにおけるミリ単位の厳密な表レイアウト制御術

業務自動化の現場で、クライアントや上司から最も恐ろしいフィードバックは何だろうか？

「ツールは動くけれど、印刷すると表の端が切れている」「Excelから流し込んだデータによって、列の幅が勝手に変わってしまう」――。

これだ。ロジックが正しいことは、業務ツールとして最低条件に過ぎない。プロフェッショナルが追求すべきは、「どの環境で、何度印刷しても、設計通りの見た目を維持する」という再現性と堅牢性である。

多くの開発者が、Word VBAで表を扱う際に「なんとなく」でコードを書いている。`Table.AutoFitBehavior` を適当に設定し、列幅を数値で指定する。しかし、Wordの内部単位である「ポイント(Point)」と、我々が日常的に使う「ミリメートル(mm)」の乖離、そしてWordの「気を利かせすぎた」自動調整機能（AutoFit）を理解していなければ、レイアウト崩れという名のバグから逃れることはできない。

本稿では、中級者への階段を登るエンジニアに向けて、ミリ単位でレイアウトを支配するための設計思想と、プロダクションレベルのコードを伝授する。

1. なぜあなたの表は崩れるのか：設計上の致命的な欠陥

まず、なぜ一般的な書き方ではレイアウトが崩れるのか、そのメカニズムを解明しておこう。原因は大きく分けて3つある。

① 単位系の混同（Points vs Millimeters）

Word VBAの `Width` プロパティが受け取る値は、ミリメートルではなくポイントだ。
1mm は正確には `28.3465…` ポイントである。これを理解せず、`Column.Width = 50` と書いた者は、「50mmの列を作ったつもり」で、実際には「約17.6mmの極細な列」を作り出している。

② Wordの「親切心」：AutoFitの暴走

Wordには `AllowAutoFit` というプロパティがある。これが `True`（デフォルトに近い状態）だと、セル内のテキスト量に応じてWordが勝手に列幅を伸縮させる。データベースから長い文字列を流し込んだ瞬間、設計したレイアウトは音を立てて崩壊する。

③ レイアウトエンジンの優先順位

Wordの表は、コンテンツ（文字数）とコンテナ（列幅）の間の「妥協点」を探そうとする。これを防ぐには、「列幅を固定値(Points)で指定し、かつ自動調整機能を明示的に殺す」という強い意志を持ったコードが必要だ。

2. 堅牢な設計思想：TableBuilderパターンの採用

単に「幅を変えるコード」を書くのではない。我々が作るべきは、「仕様（ミリメートル）を入力すれば、確実にその通りの表を構築するエンジン」だ。

設計のポイントは以下の3点に集約される。

1. 単一責任の原則: 「単位変換」「表の生成」「幅の適用」を分離する。
2. 明示的なプロパティ制御: `PreferredWidthType` を `wdPreferredWidthPoints` に固定し、パーセント指定による揺らぎを排除する。
3. 例外への備え: ページの有効幅を超える列幅が指定された場合、エラーを出すか、あるいは適切にガードレールを敷く。

3. プロダクションコード：厳密な列幅制御エンジン

以下に、そのままプロジェクトに組み込めるレベルの、保守性と堅牢性を備えたモジュール例を示す。

Option Explicit

' ==============================================================================
' Module: TableLayoutEngine
' Description: ミリメートル単位での厳密な表レイアウト制御を行うためのエンジン
' Author: Chief Architect
' ==============================================================================

''' <summary>
''' 指定したミリメートル幅に基づき、表の列幅を厳密に設定する
''' </summary>
''' <param name="targetTable">操作対象のWord Tableオブジェクト</param>
''' <param name="columnWidthsMm">各列の幅を格納したDouble型の配列 (単位: mm)</param>
Public Sub SetTableWidthsStrictly(ByRef targetTable As Word.Table, ByRef columnWidthsMm() As Double)
    Dim i As Long
    Dim targetWidthPoints As Double
    
    ' 1. 表の自動調整機能を完全に無効化する (これが最重要)
    ' これを行わない限り、Wordはコンテンツに合わせて勝手に幅を変えてしまう
    targetTable.AllowAutoFit = False
    
    ' 2. 列の数を確認
    If UBound(columnWidthsMm) + 1 <> targetTable.Columns.Count Then
        Err.Raise vbObjectError + 513, "TableLayoutEngine", _
            "指定された列幅の配列サイズと、実際の表の列数が一致しません。"
    End If

    ' 3. 各列に対して厳密な幅を適用
    On Error GoTo ErrorHandler
    For i = 1 To targetTable.Columns.Count
        ' mm を Points に変換 (1mm = 28.3465 points)
        ' PointsToMillimetersの逆算を行う
        targetWidthPoints = MillimetersToPoints(columnWidthsMm(i - 1))
        
        With targetTable.Columns(i)
            ' 優先幅のタイプを「ポイント指定」に固定
            ' これにより、%指定によるレイアウト崩れを防止する
            .PreferredWidthType = wdPreferredWidthPoints
            .PreferredWidth = targetWidthPoints
            ' 直接Widthプロパティも叩いておく（念のための二重ロック）
            .Width = targetWidthPoints
        End With
    Next i
    
    Exit Sub

ErrorHandler:
    Err.Raise Err.Number, "TableLayoutEngine", _
        "列幅の設定中にエラーが発生しました: " & Err.Description
End Sub

''' <summary>
''' ミリメートルをポイントに変換する内部関数
''' </summary>
''' <param name="mm">ミリメートル単位の数値</param>
''' <returns>ポイント単位の数値</returns>
Private Function MillimetersToPoints(ByVal mm As Double) As Double
    ' WordのPointsToMillimetersは「ポイント→mm」の変換。
    ' 「mm→ポイント」は、係数 28.3465 を乗じるのが最も確実。
    Const POINTS_PER_MM As Double = 28.3465454545
    MillimetersToPoints = mm * POINTS_PER_MM
End Function

' ==============================================================================
' 実装テスト用メインルーチン
' ==============================================================================
Sub TestStrictTableLayout()
    Dim doc As Word.Document
    Dim tbl As Word.Table
    Dim colWidths(0 To 2) As Double ' 3列分
    
    Set doc = ActiveDocument
    
    ' テストデータの準備 (単位: mm)
    colWidths(0) = 20.0  ' 1列目: 20mm
    colWidths(1) = 100.0 ' 2列目: 100mm
    colWidths(2) = 40.0  ' 3列目: 40mm
    
    ' テスト用の表を作成
    Set tbl = doc.Tables.Add(Range:=doc.Range(doc.Content.End - 1), _
                             NumRows:=3, NumColumns:=3)
    
    ' 表のスタイル設定（実務ではここも共通化すべき）
    tbl.Borders.Enable = True
    
    ' --- エンジン呼び出し ---
    ' ここでミリ単位の制御を注入する
    Call SetTableWidthsStrictly(tbl, colWidths)
    
    MsgBox "レイアウト制御が完了しました。印刷プレビューを確認してください。", vbInformation
End Sub

4. 実務における「落とし穴」と回避策

コードを書いただけで満足してはいけない。プロフェッショナルは、データ連携の局面で起こりうるリスクを予見しておく。

データベース・Excel連携時の注意点

ExcelやSQL Serverからデータを流し込む際、セル内に「改行」や「非常に長い英単語（ハイフンなし）」が含まれていることがよくある。

• リスク: `AllowAutoFit = False` にしていても、セルの高さ（Row Height）が爆発的に増えることがある。
• 対策: 必要に応じて `targetTable.Rows(i).HeightRule = wdRowHeightAtLeast` を設定し、高さの制御も設計に組み込むこと。

パフォーマンスの最適化

大量の表（例えば数百ページのレポート）を生成する場合、`targetTable.Columns(i)` へのアクセスは、実はそれなりにコスト（COMオーバーヘッド）がかかる。

• 高度な設計: 非常に巨大な表を扱う場合は、列ごとにアクセスするのではなく、表全体の `PreferredWidth` を計算してから、セルの結合（Merge）等を最小限に抑える設計を検討せよ。

印刷設定との整合性

「ミリ単位で指定したのに、印刷するとズレる」という不満が届いた場合、疑うべきはコードではなく「プリンタドライバ」と「用紙サイズ設定」だ。

• 設計指針: プログラム側で「用紙サイズ（A4など）」を明示的に指定する処理を、表生成の前に必ず実行すること。用紙サイズが `Letter` になっていたら、どんなに精密なミリメートル計算も無意味だ。

結論

Word VBAにおける表の制御は、単なる「値の代入」ではない。それは、「Wordという柔軟すぎるアプリケーションに対し、いかにして厳格な制約を課すか」という、エンジニアリングの戦いである。

1. `AllowAutoFit = False` で自由を奪え。
2. `PreferredWidthType = wdPreferredWidthPoints` で基準を固定せよ。
3. 単位変換を抽象化し、設計の意図（mm）をコードに刻め。

この原則を守るだけで、あなたの作るツールは「動くスクリプト」から「信頼される業務システム」へと昇華する。