【上級者向け】数千行規模の表を扱う際のメモリ消費を抑える逐次処理テクニック
Word VBAにおいて、数千行規模の巨大な表（Table）を動的に生成・操作する際、多くの開発者が直面する壁が「フリーズ」と「メモリリーク」だ。
単に `For` ループを回して `Add` や `Cells.Merge` を繰り返すだけのコードは、数百度のループを超えたあたりから劇的に速度が落ち、最終的に `Out of memory (エラー 7)` または、最悪の場合はWordのプロセスそのものが沈黙する。
本稿では、レガシーなVBAランタイムのメモリ管理の闇を暴き、オブジェクトのライフサイクルを完全に制御することで、数万行のデータであっても軽快に処理しきる「逐次処理（Chunk Processing）」の極限知見を共有する。
—
1. なぜWord VBAの表操作は「重い」のか？
原因は、VBAとCOMコンポーネント（Word Application）の間で行われるマーシャリングのオーバーヘッドと、Undoスタックの肥大化にある。
1. Range/Cellオブジェクトの暗黙の生成:
VBAから `Table.Cell(r, c).Range` にアクセスするたびに、COMラッパーオブジェクトがヒープ上に生成される。これが数千行×数十列の規模になると、VBAのガベージコレクタ（厳密にはRCWの参照カウント管理）が追いつかなくなり、メモリが圧迫される。
2. Undo（元に戻す）バッファの暴走:
Wordはデフォルトで、すべての操作をUndoスタックに記録する。数千行の表の動的生成を1つのトランザクションとして処理すると、Undoバッファが数GBのメモリを喰いつぶし、スワップアウトを引き起こす。
3. 画面描画（ScreenUpdating）とレイアウト計算:
行が追加されるたびに、Wordは全体のページレイアウトとセルの再計算（Pagination & Layout Engine）を実行する。これが最大のボトルネックだ。
—
2. 極限最適化のアーキテクチャ
数千行規模の表を安全に処理するためには、以下の4原則を厳守しなければならない。
- 原則1：描画とイベントの完全な遮断 (`ScreenUpdating = False`, `EnableEvents = False`)
- 原則2：Undoバッファの無効化 (`CustomUndo` のクリア、あるいはバッチ分割によるメモリフラッシュ)
- 原則3：オブジェクトの即時解放とスコープの分離 (変数への参照保持を最小限にし、ループごとにスコープを落とす)
- 原則4：チャンク（分割）処理とDoEventsによるUIスレッドの解放
—
3. 実装コード：数千行データを安全に流し込む逐次処理エンジン
以下に、実業務のシステム間連携（例：数万件のCSV/外部DBから取得したデータをWord帳票へ流し込むシーン）を想定した、プロダクション品質のコードを示す。
Option Explicit
‘ Windows API: 処理の合間にCPUとUIスレッドに制御を戻すためのスリープ（必要に応じて使用）
If VBA7 Then
Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
Else
Declare Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
End If
Public Sub ExecuteHighPerformanceTableGeneration()
Dim startTime As Double
startTime = Timer
‘ —————————————————-
‘ 1. 環境の最適化（パフォーマンスの最大化）
‘ —————————————————-
With Application
.ScreenUpdating = False
.DisplayAlerts = wdAlertsNone
.Calculation = wdCalculationManual
.EnableEvents = False
End With
‘ Undoバッファをクリアするため、一度空のドキュメントアクションを挟むか、
‘ 大規模処理時はUndoを期待しない設計にする（WordにはExplicitなUndoクリアAPIがないため、
‘ 巨大すぎる場合はドキュメントを分けて結合するアプローチも視野に入れる）
On Error GoTo ErrorHandler
‘ —————————————————-
‘ 2. データの準備（ここではモックとして配列を使用）
‘ —————————————————-
Const TOTAL_ROWS As Long = 5000
Const COLS As Long = 5
Dim dataSource() As String
ReDim dataSource(1 To TOTAL_ROWS, 1 To COLS)
Dim r As Long, c As Long
For r = 1 To TOTAL_ROWS
For c = 1 To COLS
dataSource(r, c) = “Data_” & r & “_” & c
Next c
Next r
‘ —————————————————-
‘ 3. ターゲット文書と表の初期化
‘ —————————————————-
Dim targetDoc As Document
Set targetDoc = ActiveDocument
Dim targetRange As Range
Set targetRange = targetDoc.Content
targetRange.Collapse wdCollapseEnd
‘ 最初に表の骨組みを生成（行数は一気に作らず、チャンク単位で拡張するか、
‘ まとめて作成してRange経由で一括流し込みする）
‘ ※数千行の場合、Addメソッドで一気に作ると重いため、分割アプローチをとる
Dim mainTable As Table
‘ ヘッダー行を含めて1度に作成するのは重いので、まずは最小限で作成
Set mainTable = targetDoc.Tables.Add(Range:=targetRange, NumRows:=1, NumColumns:=COLS)
With mainTable
.Borders.Enable = True
‘ ヘッダーの設定
For c = 1 To COLS
.Cell(1, c).Range.Text = “Header_” & c
.Cell(1, c).Shading.BackgroundPatternColor = wdColorGray25
.Next c
End With
‘ —————————————————-
‘ 4. チャンク（分割）逐次処理の実行
‘ —————————————————-
Const CHUNK_SIZE As Long = 200 ‘ 1回あたりの処理行数
Dim currentChunk As Long
Dim startRow As Long, endRow As Long
Dim i As Long, j As Long
Dim workingCell As Cell ‘ ループ内のオブジェクト使い回しを避けるための宣言
For startRow = 1 To TOTAL_ROWS Step CHUNK_SIZE
endRow = startRow + CHUNK_SIZE – 1
If endRow > TOTAL_ROWS Then endRow = TOTAL_ROWS
‘ チャンク単位で行を追加
For i = startRow To endRow
Dim newRow As Row
Set newRow = mainTable.Rows.Add
For j = 1 To COLS
‘ Cell.Range.Textへの直接代入は重いが、テキストのみなら高速
newRow.Cells(j).Range.Text = dataSource(i, j)
Next j
‘ オブジェクト参照の破棄（メモリリーク防止）
Set newRow = Nothing
Next i
‘ 【重要】OSに制御を返し、メモリのコンパクションとUIのフリーズを防ぐ
DoEvents
‘ 必要であれば微小なウェイトを入れてCPU負荷を平準化
‘ Sleep 10
Next startRow
‘ —————————————————-
‘ 5. 終了処理とクリーンアップ
‘ —————————————————-
MsgBox “処理完了: ” & TOTAL_ROWS & “行の生成に成功しました。” & vbCrLf & _
“処理時間: ” & Format(Timer – startTime, “0.00”) & “秒”, vbInformation
CleanUp:
‘ 環境の復元
With Application
.ScreenUpdating = True
.DisplayAlerts = wdAlertsAll
.Calculation = wdCalculationAutomatic
.EnableEvents = True
End With
‘ オブジェクト変数の明示的解放
Set targetRange = Nothing
Set targetDoc = Nothing
Set mainTable = Nothing
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
—
4. チーフアーキテクトが指摘する「見落とされがちな罠」
上記のコードを実装するにあたり、シニアエンジニアが知るべきインサイドハックをいくつか挙げておく。
① `Cell.Range.Text` への代入コスト
セルに値を流し込む際、`Cell.Range.Text = “value”` を実行すると、Wordは内部で段落マーク（ParagraphMark）の書き換えと書式再適用を行う。
もし数万行に及ぶ場合、セル単位ではなく、タブ区切りまたはCSV形式の文字列を一気に構築し、それを `Range.Text` に流し込んだ後に `ConvertToTable` メソッドを使う方が、圧倒的に高速であるケースが多い。
（※ただし、複雑なセルの結合や個別のセル装飾が絡む場合は、前述のチャンク行追加方式に軍配が上がる）
② オブジェクト変数のスコープと「隠れ参照」
VBAには明示的な `GarbageCollector` コマンド（`Set obj = Nothing` を除く）が存在しない。
ループ内で `Set newRow = mainTable.Rows.Add` のようにオブジェクトを生成し続けると、VBAの内部参照カウンタが即座にデクリメントされない場合がある。
ループ変数や一時オブジェクトは、必ずループのスコープ内で使い捨て、かつループの最後で確実に `Nothing` を代入する癖をつけよ。
③ 描画エンジンの手動制御 (`wdCalculationManual`)
表のセル内に数式（`=SUM(ABOVE)` など）が含まれている場合、行が追加されるたびに全セルの数式フィールドが再計算され、O(N^2) の計算量に陥る。
大規模データを扱う際は、必ず計算モードを手動（`wdCalculationManual`）にし、処理の最後に一度だけ `Fields.Update` を叩くこと。
—
5. 総括
Wordは元来、DTP（デスクトップパブリッシング）のためのドキュメントエディタであり、RDB（リレーショナルデータベース）やExcelのような「数万行のデータグリッド」を高速に処理するようには設計されていない。
それをVBAでねじ伏せてシステム間連携の帳票出力基盤として成立させるためには、Wordの内部ライフサイクル（UIスレッド、レイアウトエンジン、Undoスタック）をエンジニア側が完全に掌握し、リソースを適切に調停・解放してやる必要がある。
「動けばいい」というアマチュアのコードを捨て、ハードウェアの限界ギリギリまで最適化された堅牢なアーキテクチャを構築してほしい。それこそが、プロフェッショナルな業務自動化エンジニアの仕事である。
