【Word VBA極限講座】数百ページの巨獣を手懐ける：大規模文書の分割・結合におけるメモリ管理と最適化の哲学
Word VBAにおける真の地獄を見たことがあるだろうか。
数百ページに及び、数千個の図表や複雑なネストを持つテーブル、そして膨大な変更履歴が絡み合った「巨獣」のようなドキュメント。これを無造作なループと甘いオブジェクト参照で処理しようとすれば、VBAのホストプロセス（WINWORD.EXE）は瞬く間にメモリを喰らい尽くし、冷酷な「メモリ不足です（Out of memory）」のエラー、あるいは原因不明の強制終了（ハングアップ）をもって答える。
一般の入門書やネットのサンプルコードは、玩具のような数ページの文書を前提に書かれている。
しかし、我々が対峙する現場のシステムは違う。数メガバイトから時には数百メガバイトに達するファイル群を、安定して、かつ高速に分割・結合しなければならない。
今回は、Word VBAのオブジェクトモデルの深層、ガベージコレクションの裏側、そしてOSのメモリ管理までを見据えた、極限の自動化アーキテクチャを授けよう。
—
1. Word VBAのメモリリークの根源とオブジェクトライフサイクルの真実
なぜWord VBAはメモリリークを起こすのか。その理由は、COM（Component Object Model）の参照カウンティングと、VBAランタイムの遅延バインディング・暗黙的参照の悪習にある。
特に、ドキュメントの分割・結合処理では、以下のアンチパターンが致命的なメモリ肥大化を引き起こす。
- 不適切なRangeオブジェクトの乱用：ループ内で `Selection` や不必要な `Range` を生成し続け、参照を切断しない。
- ドキュメント間の暗黙的な参照の蓄積：`Documents.Add` や `Documents.Open` で開いた文書のポインタを適切に解放せず、プロセス内にゾンビオブジェクトを残す。
- 画面描画とイベントの放置：DOM（Document Object Model）が更新されるたびにWordが再描画と再計算を行い、メモリとCPUのキャッシュを焼き尽くす。
これを防ぐための鉄則はただ一つ。「生成したオブジェクトは、責任を持って明示的に `Nothing` を代入し、VBAの裏で動くCOM参照カウンタを即座にデクリメントする」ことだ。
—
2. 実装：メモリ破綻を防ぐ「大規模文書分割・結合」エンジン
以下に、数百ページの文書を安全に分割・結合するためのプロダクションコードを提示する。
無駄なオブジェクト生成を極限まで排除し、イテレーションごとにメモリを強制解放する設計思想を読み取ってほしい。
Option Explicit
‘ ==============================================================================
‘ 処理名: 巨大Word文書 安定分割・結合エンジン
‘ アーキテクチャノート:
‘ – 画面描画、バックグラウンド保存、スペルチェックを完全に抑制しCPU/MEM負荷を激減。
‘ – すべてのRange/Document変数をループのスコープごとにNothing化し、COMリークを根絶。
‘ ==============================================================================
Public Sub MasterProcess_Execute()
Dim targetPath As String
targetPath = “C:\LargeData\MassiveDocument.docx”
‘ 環境のハードニング（爆速化と安定化の定石）
Call OptimizeEnvironment(True)
On Error GoTo ErrorHandler
‘ 1. 分割処理の実行（例：セクション単位または指定ページ数単位）
Debug.Print “— 分割処理を開始 —”
ExecuteSplitDocument targetPath, “C:\LargeData\SplitOutput\”, 50 ‘ 50ページごとに分割
‘ 2. 結合処理の実行
Debug.Print “— 結合処理を開始 —”
ExecuteMergeDocuments “C:\LargeData\SplitOutput\”, “C:\LargeData\RebuiltDocument.docx”
Debug.Print “— すべてのプロセスが正常に完了しました —”
ErrorHandler:
If Err.Number <> 0 Then
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “チーフアーキテクトからの警告”
End If
‘ 環境の復元（例外時も必ず実行）
Call OptimizeEnvironment(False)
End Sub
‘ ——————————————————————————
‘ 環境最適化プロシージャ
‘ ——————————————————————————
Private Sub OptimizeEnvironment(ByVal pEnable As Boolean)
With Application
If pEnable Then
.ScreenUpdating = False
.DisplayAlerts = wdAlertsNone
.Calculation = wdCalculationManual
.EnableEvents = False
Else
.ScreenUpdating = True
.DisplayAlerts = wdAlertsAll
.Calculation = wdCalculationAutomatic
.EnableEvents = True
.ScreenRefresh
End If
End With
End Sub
‘ ——————————————————————————
‘ 高速・安全な文書分割
‘ ——————————————————————————
Private Sub ExecuteSplitDocument(ByVal pSourcePath As String, ByVal pOutputDir As String, ByVal pPagesPerFile As Long)
Dim srcDoc As Document
Dim targetDoc As Document
Dim rngSource As Range
Dim totalPages As Long
Dim startPage As Long, endPage As Long
Dim fileIndex As Long
Dim savePath As String
Set srcDoc = Documents.Open(FileName:=pSourcePath, ReadOnly:=True, Visible:=False)
totalPages = srcDoc.ComputeStatistics(wdStatisticPages)
fileIndex = 1
startPage = 1
Do While startPage <= totalPages endPage = startPage + pPagesPerFile - 1 If endPage > totalPages Then endPage = totalPages
‘ 該当ページの範囲を取得
Set rngSource = srcDoc.Range
‘ 注: 厳密なページ単位の切り出しには Goto や Range.GoToを用いる
Dim startPos As Long, endPos As Long
startPos = srcDoc.GoTo(What:=wdGoToPage, Which:=wdGoToAbsolute, Count:=startPage).Start
If endPage >= totalPages Then
endPos = srcDoc.Content.End
Else
endPos = srcDoc.GoTo(What:=wdGoToPage, Which:=wdGoToAbsolute, Count:=endPage + 1).Start
End If
‘ 新規ドキュメントにレンジをコピー
Set targetDoc = Documents.Add(Visible:=False)
srcDoc.Range(startPos, endPos).Copy
targetDoc.Content.Paste
‘ 物理保存（余計なメタデータを削ぎ落とす）
savePath = pOutputDir & “Split_” & Format(fileIndex, “000”) & “.docx”
targetDoc.SaveAs2 FileName:=savePath, FileFormat:=wdFormatXMLDocument
targetDoc.Close SaveChanges:=wdDoNotSaveChanges
‘ —【極めて重要】オブジェクトの即座な明示的解放 —
Set targetDoc = Nothing
Set rngSource = Nothing
fileIndex = fileIndex + 1
startPage = endPage + 1
Loop
srcDoc.Close SaveChanges:=wdDoNotSaveChanges
Set srcDoc = Nothing
DoEvents ‘ OSに制御を返し、メモリのガーベージコレクションを促す
End Sub
‘ ——————————————————————————
‘ 高速・安全な文書結合
‘ ——————————————————————————
Private Sub ExecuteMergeDocuments(ByVal pInputDir As String, ByVal pOutputPath As String)
Dim masterDoc As Document
Dim targetDoc As Document
Dim fileName As String
Dim filePath As String
‘ マスターとなる新規文書を作成
Set masterDoc = Documents.Add(Visible:=False)
fileName = Dir(pInputDir & “Split_.docx”)
Do While fileName <> “”
filePath = pInputDir & fileName
‘ 結合先文書の末尾にファイルを挿入
masterDoc.Content.InsertAfter vbCr
masterDoc.Content.Collapse wdCollapseEnd
masterDoc.Content.InsertFile FileName:=filePath
fileName = Dir() ‘ 次のファイル
Loop
masterDoc.SaveAs2 FileName:=pOutputPath, FileFormat:=wdFormatXMLDocument
masterDoc.Close SaveChanges:=wdDoNotSaveChanges
Set masterDoc = Nothing
DoEvents
End Sub
—
3. チーフアーキテクトが教える：システム間連携とさらなる極限チューニング
このコードをベースにしつつ、さらに巨大な数ギガバイト規模のエンタープライズ文書を扱う場合や、外部システム（C# / .NETのバックエンドサービスなど）からCOM経由でWordを制御する場合の知見を授けよう。
① `DoEvents` の戦略的配置
ループ処理の内部で毎回 `DoEvents` を呼ぶのは速度低下を招くが、数百MBのファイルを扱う場合は 「一定のイテレーション、またはファイル処理ごと」 に `DoEvents` を挟むべきだ。これにより、Windowsメッセージキューが処理され、メモリの断片化やWINWORD.EXEの肥大化をOSレベルでいなすことができる。
② 変更履歴（Track Changes）とコメントの爆弾
大規模文書が重くなる最大の原因は、テキストそのものではなく「見えない変更履歴とコメントの履歴ツリー」である。
もし分割・結合のプロセスにおいて変更履歴の保持が不要なのであれば、処理の冒頭で以下のように一刀両断すべきだ。
‘ 変更履歴を強制的に受け入れ、履歴ツリーを根絶やしにする
srcDoc.AcceptAllRevisionsShown
srcDoc.DeleteAllComments
これを行うだけで、文書サイズが数分の一になり、メモリ消費量も劇的に改善される。
③ COMの墓場：「ゾンビプロセス」を絶対に生み出さないための防衛策
VBAからWordを操作する際、エラーが発生して途中でコードが止まると、見えない裏画面で `WINWORD.EXE` がゾンビと化してメモリ居座り続ける現象に直面した読者も多いはずだ。
プロダクション環境では、エラーハンドラで確実にインスタンスを破棄し、必要に応じてWindows API（あるいはシェルコマンド）でプロセスを強制刈り取りする強靭さが求められる。
‘ 万が一のゾンビプロセス駆逐（TaskkillのVBAからの実行例）
Private Sub ForceKillWordZombies()
Dim wmi As Object, processes As Object, proc As Object
Set wmi = GetObject(“winmgmts:\\.\root\cimv2”)
Set processes = wmi.ExecQuery(“Select from Win32_Process where Name = ‘WINWORD.EXE'”)
For Each proc In processes
‘ 必要に応じ、親を持たない孤児プロセスなどを判定してTerminate
‘ proc.Terminate
Next
End Sub
（※実運用では、プロセスごとの起動時刻やセッションIDを精査して誤爆を防ぐこと）
—
結びにかえて
VBAは、しばしば「おもちゃの言語」と揶揄される。しかし、それは書き手側のオブジェクトモデルに対する理解が浅い言い訳に過ぎない。
メモリのライフサイクルを支配し、OSとCOMの対話を完全にコントロール下置いたとき、Word VBAは数百ページの巨獣をも軽々と踊らせる、極めて強靭なエンタープライズ・オートメーション・ツールへと変貌する。
コードを書き飛ばすな。オブジェクトの生死に責任を持て。
それこそが、真のエンジニアリングである。
