【極限の知見】結合セルの罠を突破せよ：Word VBAで「列幅」を自在に操る設計思想
こんにちは。現場の設計（アーキテクチャ）を司るチーフアーキテクトです。
Word VBAを触っていると、必ずと言っていいほど直面する「壁」があります。それは、「結合されたセル（Merged Cells）を含む表」です。
マクロの記録機能を使って表の幅を変えてみた。一見、うまくいった。しかし、運用していくうちに「あ、この行だけセルが結合されているからエラーが出る」「結合のせいで列のインデックスがズレて、全然違う列の幅が変わってしまった」……そんな経験はありませんか？
もしあなたが今、「`Table.Columns(i)` を使えば列幅は変えられるはずだ」と考えているなら、少し立ち止まってください。その考え方は、結合セルという「非線形な構造」の前では、あまりにも無防備です。
今日は、マクロの記録という「模倣」から脱却し、Wordのオブジェクトモデルの真理を理解することで、結合セルを完璧に制御する「プロフェッショナルな設計思想」を伝授しましょう。ここをクリアすれば、Word VBAの基本はバッチリですよ。
1. なぜ `Table.Columns(i)` は「破壊的」なのか？
まず、なぜエラーが起きるのか、その正体を解明しましょう。
一般的なプログラミングにおける「配列」や「行列」は、すべての行が同じ数の要素を持つ、整然としたグリッドです。しかし、Wordの表は違います。「セルは独立したオブジェクトの集合体」なのです。
結合セルが引き起こす「インデックスの崩壊」
例えば、以下のような3列の表を想像してください。
| 列1 | 列2 | 列3 |
|---|---|---|
| A1 | B1 | C1 |
| [ 結合セル (D1) ] | C2 |
1行目は3つのセルがありますが、2行目は「列1と列2が結合」されています。このとき、2行目の `Cells` コレクションには、実質的に2つしかセルが存在しません。
ここで、プログラムから「2列目の幅を変えろ」と `Table.Columns(2).Width = 50` と命令すると、Wordはこうパニックを起こします。
> 「2行目には、2番目のセルなんて存在しないよ！（あるいは、2番目のセルは実質3列目だよ！）」
これが、`The requested member of the collection does not exist`（コレクションの要求されたメンバーが存在しません）というエラーの正体です。
2. アーキテクトの思考：グリッドではなく「行」を歩け
結合セルが含まれる表を制御する際、我々エンジニアが取るべき戦略はただ一つ。
「列（Columns）という抽象的な概念を捨て、行（Rows）とセル（Cells）という具体的なオブジェクトを走査する」ことです。
「列の幅を変える」という操作を、以下のように再定義します。
> 「すべての行を順番に見ていき、その行の中に『目的の列番号に相当するセル』があれば、その幅を調整する」
この「行ごとに存在確認を行う」というステップこそが、堅牢なコードを生む鍵となります。
3. 実践：結合セルを回避する「安全な列幅変更」コード
それでは、実際に現場で使えるコードを見ていきましょう。このコードは、指定した列番号のセルを探し出し、結合セルによってインデックスが欠落していてもエラーで止まらないように設計されています。
''
' @description: 結合セルを含む表において、特定の列の幅を安全に変更する
' @param tbl: 対象となる Word.Table オブジェクト
' @param targetColIndex: 変更したい列のインデックス (1から始まる)
' @param newWidth: 設定したい幅 (ポイント単位)
''
Sub SetColumnWidthSafely(tbl As Word.Table, targetColIndex As Integer, newWidth As Single)
Dim i As Long
Dim targetCell As Word.Cell
' 1. 表の全行をループで走査する（列単位ではなく行単位が鉄則）
For i = 1 To tbl.Rows.Count
On Error Resume Next ' エラーハンドリングの極意：存在しないセルへのアクセスを許容する
' 2. その行の「targetColIndex」番目のセルを取得を試みる
' 結合セルがある行では、Cells(targetColIndex) が存在しない場合がある
Set targetCell = tbl.Rows(i).Cells(targetColIndex)
If Err.Number = 0 Then
' 3. セルが見つかった場合のみ、幅を変更する
' PreferredWidth を使うことで、レイアウトの崩れを最小限に抑える
targetCell.PreferredWidthType = wdPreferredWidthPoints
targetCell.PreferredWidth = newWidth
Else
' 4. エラーが発生した場合（セルが存在しない場合）
' ここでは「結合セルによってその列がスキップされた」と判断し、何もしない
Err.Clear
End If
On Error GoTo 0 ' エラーハンドリングを元に戻す（これ、超重要！）
Next i
Debug.Print "列 " & targetColIndex & " の幅を " & newWidth & "pt に調整完了。"
End Sub
' --- テスト用メインルーチン ---
Sub TestTableManipulation()
Dim doc As Document
Dim myTable As Word.Table
Set doc = ActiveDocument
' 文書内に表があるか確認
If doc.Tables.Count = 0 Then
MsgBox "表が見つかりません。先に表を作成してください。"
Exit Sub
End If
Set myTable = doc.Tables(1)
' 例: 2列目の幅を 80ポイント に変更する
' 結合セルが含まれていても、エラーにならずに実行される
Call SetColumnWidthSafely(myTable, 2, 80)
MsgBox "処理が完了しました。"
End Subコードの解説：ここが「プロ」の仕事
1. `On Error Resume Next` の戦略的利用:
通常、エラー回避のために `On Error Resume Next` を乱用するのは禁物です。しかし、今回のように「オブジェクトが存在しないことが構造上あり得る」場合には、これこそが最も効率的な防御策となります。ただし、処理が終わったら必ず `On Error GoTo 0` で解除する。これがプロの作法です。
2. `PreferredWidthType` の指定:
単に `.Width` を変えるのではなく、`PreferredWidthType = wdPreferredWidthPoints` を明示的に指定しています。これにより、Wordの自動レイアウト機能による「勝手な幅の再計算」を抑制し、意図した通りの数値を叩き込めます。
3. 行（Rows）を起点とした走査:
`tbl.Columns(i)` は「表全体の列」を指そうとして失敗しますが、`tbl.Rows(i).Cells(j)` は「その行の中でのセル」を指します。この視点の切り替えが、結合セルを攻略する最大の武器です。
4. 陥りやすい落とし穴：さらなる高みを目指すあなたへ
この手法をマスターしても、まだ注意すべき点があります。
- 「結合されたセルそのもの」の幅を変えたい場合:
もし、列1と列2が結合されたセルがあるとき、その「結合セル」の幅を変えたいなら、`targetColIndex` を `1` にする必要があります。その際、`Cells(2)` は存在しないため、コードは自然にスキップされます。
- パフォーマンスの重み:
行数が数千行に及ぶ巨大な表の場合、一行ずつ `On Error` を挟んで処理するのは少し重くなることがあります。その場合は、表全体のレイアウトを一度リセットしてから操作するなどの高度なアプローチが必要になりますが、通常の業務文書レベルであれば、今回の手法が最も安全でメンテナンス性が高いです。
まとめ：オブジェクトの「実体」を見つめよう
「マクロの記録」は、あくまで「人間が操作した結果の断片」を書き出したものです。そこに「なぜそのエラーが起きたのか」という論理的な背景は含まれていません。
結合セルに遭遇したとき、それはエラーではなく、「表の構造が、あなたが想定しているグリッド（行列）とは異なるオブジェクトモデルで動いているよ」という、Wordからのメッセージなのです。
1. 列（Columns）ではなく、行（Rows）を走査する。
2. セル（Cells）の存在を、エラーハンドリングで確認する。
3. 設定には PreferredWidth を活用する。
この3点を守れば、どんなに複雑な表構造が来ても、あなたは冷静に対処できるはずです。
さあ、これであなたも「結合セルの恐怖」から解放されました。次は、より複雑な動的生成の自動化へと歩みを進めましょう。応援していますよ！
