【上級者向け】Word文書を「XML形式」で読み込み、DOM操作で高速置換を行う実験的アプローチ
Word VBAによる大規模文書の処理において、最大のボトルネックは常に「画面描画とオブジェクトモデルの往復コスト」にある。
数千ページ、あるいは数十万語に及ぶ文書に対し、標準の `Selection.Find` や `Range.Find` をループさせれば、進捗バーはみるみるうちにフリーズし、実用的な時間内での処理は絶望的となる。オブジェクトを1つ操作するたびにCOMの境界を跨ぐオーバーヘッドが発生するためだ。
この物理的な限界を突破するため、シニアエンジニアが最終的に行き着くアプローチが 「OpenXML (OOXML) アーキテクチャの直接DOM操作」 である。
Wordファイル（.docx）の本質は、実態としてZIP圧縮されたXML群に他ならない。アプリケーションとしてのWordを起動せず、VBA（あるいはVBAから呼び出す外部コンポーネント）でXMLをメモリ上に展開し、MSXML2や正規表現エンジンで一括置換を完結させる。このアプローチにより、処理速度を従来の数十倍〜数百倍へと劇的に跳ね上げることが可能になる。
本稿では、Word VBAの常識を覆すこの実験的かつ実用的な高速置換アーキテクチャの全貌を解説する。
—
1. なぜWordオブジェクトモデルは遅いのか？
実務でよく見かける以下のコードを考えてほしい。
‘ 【アンチパターン】典型的なRange.Findによる置換ループ
Sub SlowReplace()
Dim rng As Range
Set rng = ActiveDocument.Content
rng.Find.ClearFormatting
rng.Find.Replacement.ClearFormatting
rng.Find.Text = “旧キーワード”
rng.Find.Replacement.Text = “新キーワード”
‘ 文書全体を一括置換ならまだマシだが、条件分岐を伴うループになると激遅になる
rng.Find.Execute Replace:=wdReplaceAll
End Sub
単一の置換であれば `wdReplaceAll` が高速に動作するように見えるが、「特定のスタイルが適用されている箇所だけ置換する」「前後の文脈を判定して置換を動的に変える」といった複雑な要件が加わった途端、`Range`オブジェクトの走査ループが必要となり、処理時間は幾何級数的に悪化する。
オブジェクトモデルの構造的欠陥
- COM境界の跨ぎすぎ: VBAのランタイムとWordのC++コアの間で発生するマーシャリングコスト。
- 再描画とレイアウトエンジンの介入: 文字列を変更するたびに、Wordはページレイアウトの再計算（Pagination）を試みる。
- メモリリークの温床: `Range` や `Selection` をループ内で不適切に生成・破棄すると、VBA側のメモリ管理が追いつかなくなる。
これを解決唯一の解が、「WordをただのZIPアーカイバとして扱い、実体のXMLを直接書き換える」手法である。
—
2. OOXML構造の理解とターゲットの特定
`.docx` ファイルを拡張子変更して `.zip` として解凍すると、内部にはいくつかのXMLファイルが存在する。テキスト置換のターゲットとなるのは、主に以下のファイルだ。
- `word/document.xml`: メインの本文データ
- `word/header.xml`: ヘッダーデータ
- `word/footer.xml`: フッターデータ
これらのファイル内では、テキストは `
例えば、「本日は晴天なり」という文字列は、次のように分断されてXML上に存在することがある。
単純な文字列置換では、このタグの分断（Wordの編集履歴や書式変更の境界で発生する）を考慮漏れしがちだが、DOM（Document Object Model）あるいは高度なXMLパーサを用いることで、ノード単位での安全な走査と置換が可能になる。
—
3. 実装コード：VBAからDOMでXMLを直接書き換える
以下のコードは、Word文書を裏側でZIP展開し、`word/document.xml` を MSXML2.DOMDocument で読み込んで高速置換を行い、再びZIPに戻すプロトタイプである。
> 前提条件: 実行にはシェルオブジェクト（FileSystemObject および Shell.Application）を使用するため、外部ライブラリの参照設定は不要である。
Option Explicit
‘ 【極限の高速化】DOM操作によるWord XML一括置換エンジンのコアプロシージャ
Sub HighSpeedXMLReplace(ByVal targetFilePath As String, ByVal targetStr As String, ByVal replacementStr As String)
Dim fso As Object
Dim shellApp As Object
Dim tempDir As String
Dim xmlPath As String
Dim xmlDoc As Object
Dim nodeList As Object
Dim node As Object
‘ 1. オブジェクトの初期化
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set shellApp = CreateObject(“Shell.Application”)
‘ 一意のテンポラリディレクトリを作成
tempDir = fso.GetSpecialFolder(2) & “\” & fso.GetTempName()
fso.CreateFolder tempDir
On Error GoTo ErrorHandler
‘ 2. .docx を .zip として解凍 (Shell.Applicationを使用)
Dim srcFile As Object, destFolder As Object
Set srcFile = shellApp.Namespace(targetFilePath)
Set destFolder = shellApp.Namespace(tempDir)
‘ 非同期処理を避けるためコピー完了を待つ
destFolder.CopyHere srcFile.Items, 4 ‘ 4 = 進行状況ダイアログ非表示
‘ 少し待機（環境依存のI/O遅延対策）
DoEvents
‘ 3. word/document.xml のDOM読み込み
xmlPath = tempDir & “\word\document.xml”
If Not fso.FileExists(xmlPath) Then
Err.Raise 9999, “XMLReplace”, “有効なWord XML構造が見つかりません。”
End If
Set xmlDoc = CreateObject(“MSXML2.DOMDocument.6.0”)
xmlDoc.Async = False
xmlDoc.ResolveExternals = False
If Not xmlDoc.Load(xmlPath) Then
Err.Raise 9998, “XMLReplace”, “XMLのパースに失敗しました: ” & xmlDoc.parseError.reason
End If
‘ 名前空間の解決（必要に応じてプレフィックスを設定）
‘ ※単純なタグ名検索の場合は XPath を利用するか、getElementsByTagName を使用
Set nodeList = xmlDoc.getElementsByTagName(“w:t”)
‘ 4. 高速メモリ上置換ループ
Dim i As Long
For i = 0 To nodeList.Length – 1
Set node = nodeList.Item(i)
If InStr(node.Text, targetStr) > 0.0 Then
‘ 文字列置換の実行
node.Text = Replace(node.Text, targetStr, replacementStr)
End If
Next i
‘ 5. 変更されたXMLの保存
xmlDoc.Save xmlPath
‘ 6. 既存のzip（.docx）内の document.xml を差し替えて再圧縮
‘ ※実運用では既存ZIP内の該当ファイルを更新、またはフォルダ全体を再ZIP化する
Call RecompressToDocx(fso, shellApp, tempDir, targetFilePath)
CleanUp:
‘ 7. メモリと一時ファイルの確実な解放（リソースリークの防止）
On Error Resume Next
If fso.FolderExists(tempDir) Then fso.DeleteFolder tempDir, True
Set node = Nothing
Set nodeList = Nothing
Set xmlDoc = Nothing
Set destFolder = Nothing
Set srcFile = Nothing
Set shellApp = Nothing
Set fso = Nothing
Exit Sub
ErrorHandler:
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical, “XML高速置換エンジン”
Resume CleanUp
End Sub
‘ 再圧縮処理のヘルパー（フォルダをZIPに戻す）
Private Sub RecompressToDocx(fso As Object, shellApp As Object, sourceDir As String, destZipPath As String)
Dim zipFile As String
zipFile = destZipPath
‘ 既存のファイルを削除して上書き準備
If fso.FileExists(zipFile) Then fso.DeleteFile zipFile, True
‘ 空のZIPファイルを作成 (ヘッダ書き込み)
fso.CreateTextFile(zipFile, True).Write Chr$(80) & Chr$(75) & Chr$(5) & Chr$(6) & String(18, Chr$(0))
Dim destZip As Object
Set destZip = shellApp.Namespace(zipFile)
‘ フォルダ内の全アイテムをZIPに圧縮格納
Dim srcFolder As Object
Set srcFolder = shellApp.Namespace(sourceDir)
destZip.CopyHere srcFolder.Items, 4
‘ 圧縮処理の完了を待つループ
Dim startTime As Single
startTime = Timer
Do While destZip.Items.Count < srcFolder.Items.Count
DoEvents
If Timer - startTime > 10 Then Exit Do ‘ タイムアウト防衛策
Loop
End Sub
—
4. チーフアーキテクトが指摘する「実運用上のリスクと限界」
このXML直接操作アプローチは、パフォーマンス面において圧倒的なアドバンテージを誇る一方で、シニアエンジニアとして看過できないトレードオフとリスクが存在する。実システムへ導入する際には、以下の設計判断が求められる。
① スキーマ破壊のリスク
Word文書は非常に複雑なスキーマ（OpenXML標準）を持っている。例えば、「検索キーワード」が単一の `
この場合、単なる `getElementsByTagName(“w:t”)` ではヒットせず、テキストが断片化したまま残ることになる。この問題を完全にクリアするには、DOMツリー全体を再帰的に走査し、隣接するテキストノードを結合（Normalization）してから置換する高度なアルゴリズムが必要となる。
② Wordアプリケーション側の整合性チェック
バックグラウンドでXMLを無理やり書き換えたファイルを、将来的にWordで開いた際、Wordの修復機能（XML Validation Engine）が働いて「ファイルが破損しています」と警告されるリスクがある。特に、XML名前空間の宣言漏れや、不正なエスケープ文字（`&`, `<`, `>` など）が混入した場合には一発でファイルがクラッシュする。
`MSXML2.DOMDocument` を用いることで、エンコードやXMLのエスケープ処理は自動的に安全に行われるが、手動で文字列を連結するような実装を行うと即座に破損原因となるため注意が必要だ。
③ 排他制御とファイルロック
システム間連携やバッチ処理において、対象の `.docx` ファイルが他のプロセス（またはユーザー自身）によって開かれている場合、ZIPの再圧縮・上書き保存時に「権限エラー（エラー 70: 書き込み権限がありません）」が発生する。ファイルストリームの安全なキャプチャと、リトライ機構（Polly的なリトライパターン）の組み込みが不可欠である。
—
5. 結論：いつこの手法を採用すべきか？
- 採用すべきケース:
- 数千ページに及ぶマスターデータからの定型文言の一括置換。
- サーバーサイドや常駐バッチにおいて、ユーザーインターフェース（Word画面）を一切立ち上げずに高速処理を行いたい場合。
- 既存のVBAコードではタイムアウトしてしまうほどの巨大なファイルを扱う場合。
- 避けるべきケース:
- ユーザーがリアルタイムで画面を確認しながらインタラクティブに置換を行いたい場合。
- 書式（スタイル、段落番号、フィールドコード）が入り組んでおり、テキストの分断リスクが高い文書。
オブジェクトモデルの限界を知り、XMLという「文書の真の姿」を直接手懐けること。これこそが、レガシーとモダン技術の境界線に立つエンジニアに求められる真のスキルセットである。保守性とパフォーマンスのバランスを見極め、あなたのアーキテクチャの武器庫にこのアプローチを加えてほしい。
