Word VBAで「崩壊しない表」を生成せよ：実行時エラーを完全に封じ込める防衛的プログラミングの極意
Word VBAで表（Table）を操作する際、多くのエンジニアが「実行時エラー 5941（要求されたメンバーはコレクションに存在しません）」や「実行時エラー 4605」の泥沼に足を取られる。
Wordの表操作は、Word自体が持つ「文書の構造変化」に極めて脆い。セル結合、行の挿入、さらにはユーザーによる予期せぬ編集。これらが重なれば、安易な `Tables(1).Cell(1, 1).Range.Text = “…”` という記述は、時限爆弾に等しい。
真の業務自動化アーキテクトは、「操作対象が存在しないこと」を前提とした防衛的プログラミングを行う。本稿では、現場で二度とクラッシュを起こさないための、堅牢な表操作の設計思想を伝授する。
—
1. なぜ、あなたのコードは崩壊するのか
多くの初心者は、DocumentオブジェクトやTableオブジェクトを直接参照し続ける。だが、Wordの表は「行」を追加した瞬間に全範囲のインデックスが再計算される可能性がある。
特に以下の3点は、プロとして絶対に避けるべき設計だ。
- マジックナンバーの多用: `Tables(1)` のようなインデックス直書きは、文書の構成が変わった瞬間に死ぬ。
- 存在確認の欠如: セル結合されている場所に無理やりアクセスし、VBAを強制終了させる。
- 不透明な参照: `Selection` オブジェクトを多用する。これは描画負荷が高く、エラーの温床となる。
—
2. 堅牢な表操作のための「3つの防衛線」
実務で生き残るコードを書くためには、以下のアーキテクチャを適用せよ。
1. オブジェクトのキャッシュ化: 参照を何度も取得せず、オブジェクト変数に格納する。
2. 存在チェックの先行実行: 操作前に `Is Nothing` や `Count` プロパティで確実に存在を保証する。
3. 結合状態の検知: `MergeCells` プロパティをチェックし、結合セルへの不用意なアクセスを遮断する。
—
3. 実践：実行時エラーを封じ込めるプロダクションコード
以下は、安全に表にデータを流し込み、かつエラーを確実にキャッチする「テンプレート」である。
‘ ———————————————————
‘ 堅牢な表データ書き込みプロシージャ
‘ @param targetTable 操作対象の表オブジェクト
‘ @param rowIdx 書き込み対象行
‘ @param colIdx 書き込み対象列
‘ @param textToWrite 流し込む値
‘ ———————————————————
Public Sub SafeWriteToCell(ByRef targetTable As Table, ByVal rowIdx As Long, ByVal colIdx As Long, ByVal textToWrite As String)
On Error GoTo ErrorHandler
‘ 1. 表の存在確認
If targetTable Is Nothing Then Err.Raise 1001, , “表オブジェクトが割り当てられていません。”
‘ 2. 行・列範囲の論理的検証
If rowIdx > targetTable.Rows.Count Or colIdx > targetTable.Columns.Count Then
Debug.Print “範囲外のアクセスです: (” & rowIdx & “,” & colIdx & “)”
Exit Sub
End If
‘ 3. セル結合の判定と防衛
‘ 結合されている場合、対象のセルがオブジェクトとして存在しない可能性がある
Dim targetCell As Cell
Set targetCell = targetTable.Cell(rowIdx, colIdx)
If targetCell.Range.Information(wdWithInTable) Then
‘ 正常にアクセス可能な場合のみ書き込み
targetCell.Range.Text = textToWrite
End If
Exit Sub
ErrorHandler:
‘ ログ出力して沈黙させるか、重要な場合はユーザーに通知
Debug.Print “Error ” & Err.Number & “: ” & Err.Description
Resume Next
End Sub
—
4. データベース連携時の落とし穴：パフォーマンスの真実
外部データベース（SQL ServerやAccess）からデータを取得し、Wordへ流し込む際、もっとも重い処理は「描画更新」である。
- 画面更新の停止: `Application.ScreenUpdating = False` は必須。これを忘れるだけで処理速度は10倍変わる。
- 行追加の最適化: `Table.Rows.Add` をループ内で何度も実行するのは最悪の設計だ。必要数を計算し、一度にテーブル構造を生成するか、最終行に追記する際は `Range` オブジェクトを適切に使い回すこと。
設計の鉄則：Rangeオブジェクトを使い倒せ
`Cell.Range.Text` を多用すると、セルの末尾に存在する「段落記号」の扱いが面倒になる。データ末尾の余計な改行を消すために `Len – 1` を繰り返すような泥臭いコードは避け、`Range.Text = textToWrite` ではなく、`Range.InsertAfter` や `Range.Delete` を組み合わせることで、文書構造を破壊せずにデータを流し込むことが可能だ。
—
5. 結論：コードは「生き物」である
Word VBAで書く自動化ツールは、一度作って終わりではない。ユーザーがテンプレートを改変すれば、即座に破壊される。
- 「失敗しないこと」を目指すのではなく、「失敗した時に何が起きたか特定できること」を目指せ。
- エラーハンドリングの中に `Err.Source` や `Err.Description` を含めたログ出力処理を実装するだけで、保守コストは劇的に下がる。
このアーキテクチャを理解したあなたなら、もう「突然死するWordファイル」に怯える必要はない。さあ、堅牢で美しい自動化の道を歩んでほしい。
