【極限のVBA】Wordオブジェクトモデルを捨てろ。Flat OPC直接操作による「数万箇所の段落書式」高速書き換え術
Word VBAで数万行のドキュメントを処理しようとして、`Paragraphs.Count` を回し、`Range.Font` や `Range.ParagraphFormat` を叩いていないか？ もしそうなら、君はCPUを無駄に浪費し、メモリリークの温床となるオブジェクトの森を彷徨っているに過ぎない。
Wordのオブジェクトモデルは非常に「重い」。COM経由でのプロパティアクセスは、その都度マーシャリングが発生し、Wordの再描画プロセスと同期を取るため、極めて低速だ。
真の自動化エンジニアが到達すべき境地は、Wordを「文書作成ソフト」としてではなく「XMLコンテナ」として扱うことである。
1. なぜFlat OPC（.xml）なのか
Word 2007以降、`.docx` はOpenXML形式の圧縮パッケージである。これを解凍して操作するのも一つの手だが、さらにスマートな手法がある。それが Flat OPC（XML形式） だ。
Flat OPCは、バイナリ化されていない単一のXMLファイルとしてWord文書を表現する。これであれば、DOM（Document Object Model）を構築せずとも、ストリームとして読み込み、正規表現あるいは文字列置換でXMLタグを直接操作できる。この手法における処理速度は、オブジェクトモデル経由と比較して数百倍から数千倍に達する。
2. 実装の要諦：オブジェクト解放とメモリ最適化
VBAでこれを扱う際、`MSXML2.DOMDocument` を使うのは悪手ではないが、メモリ効率を極限まで高めるなら、`ADODB.Stream` を使用してバイナリとして読み込み、メモリ上で高速な文字列処理を行うのがベストだ。
以下のコードは、Flat OPC形式の文書に対し、特定のスタイル定義を強引に書き換えるアーキテクチャのプロトタイプである。
‘ 伝説的なチーフアーキテクトが教える、高速XML置換の定石
Public Sub HighSpeedFormatPatch(ByVal filePath As String)
Dim stream As Object
Dim xmlContent As String
‘ メモリの断片化を避けるため、ADODB.Streamで一括読み込み
Set stream = CreateObject(“ADODB.Stream”)
stream.Type = 2 ‘ adTypeText
stream.Charset = “utf-8”
stream.Open
stream.LoadFromFile filePath
xmlContent = stream.ReadText
stream.Close
‘ ここでXMLの構造を直接書き換える
‘ 例: 特定の段落プロパティ
‘ 巨大な文字列操作はVBAのMid$やReplace関数が意外にも高速
‘ 正規表現(VBScript.RegExp)を使う場合はインスタンスを使い回すこと
xmlContent = Replace(xmlContent, “
‘ 書き戻し
stream.Open
stream.WriteText xmlContent
stream.SaveToFile filePath, 2 ‘ adSaveCreateOverWrite
stream.Close
‘ 明示的なオブジェクト解放
Set stream = Nothing
End Sub
3. シニアエンジニアが押さえるべき「罠」
この手法には、Wordの内部仕様を知り尽くした者だけが知る「地雷」が存在する。
- 名前空間（Namespaces）の整合性: XMLの一部を書き換える際、`w:`, `wp:`, `w14:` といった名前空間の宣言が文書全体で崩れると、Wordは即座に「ファイル破損」とみなす。置換後のXMLが、元のスキーマ定義（`word/document.xml`）と合致しているか、検証プロセスを挟むのがプロの仕事だ。
- 圧縮の有無: Flat OPCではない通常の `.docx` を操作する場合は、`Shell.Application` 等で解凍してから操作する必要があるが、一時ファイルが作成されるためI/Oボトルネックが生じる。大規模運用では、メモリ上に展開するRAMディスクを利用するなどの工夫が求められる。
- Windows APIの活用: `Replace` 関数だけでは限界がある場合、`kernel32` の `lstrcpyn` や `MoveMemory` を駆使し、メモリバッファを直接操作する領域へ足を踏み入れるべきだ。
4. 総括：自動化の真髄
Word VBAを極めるということは、Wordというアプリケーションの「作法」から脱却することと同義である。
数万行の書式変更が必要になったとき、君がすべきことは「ループを回すコードを書くこと」ではない。「文書の内部構造をいかに効率よくハックするか」という設計思想を持つことだ。
自動化とは、単なる作業の代行ではない。システムのボトルネックを物理法則レベルで理解し、それを超越する実装を選択することである。コードをコピペして満足するな。XMLの構造（`word/document.xml`）を読み込み、その深淵を覗き込め。そこにしか、真の効率化は存在しない。
次は、メモリマップドファイルを用いた、さらに低レイヤーな操作について語るとしよう。諸君の健闘を祈る。
