序文：ハードコーディングという名の負債を断つ
長年、エンタープライズ領域でVBAアーキテクチャを設計してきた私から言わせれば、コード内に置換ルールをベタ書き（ハードコーディング）する行為は、将来の自分に対する「技術的負債」の予約に他ならない。
要件は常に変わる。用語の統一基準は更新され、コンプライアンス対応で特定のワードが禁止される。そのたびにVBAプロジェクトのパスワードを解除し、ソースコードを修正してコンパイルし直すのか？ そんな運用は、プロフェッショナルの仕事ではない。
真に堅牢なシステムとは、「ロジック」と「データ」が峻烈に分離されているものだ。本稿では、FileSystemObject（FSO）を用いた外部CSVによる一括置換エンジンの構築を軸に、Word VBAにおける検索・置換の深淵な最適化手法を解説する。
—
1. 外部ファイル連携の設計思想：なぜFSOなのか
Word VBAで外部ファイルを扱う際、古い`Open`ステートメントを用いる手法もあるが、私は`Scripting.FileSystemObject`（FSO）を推奨する。理由は単純だ。オブジェクト指向的な記述が可能であり、ファイルの存在チェック、ストリームの読み込み、パスの操作において、エラーハンドリングの堅牢性が一段高いからである。
アーキテクチャの要点
1. 疎結合の実現: 置換ルールをCSV（UTF-8またはShift-JIS）に分離。
2. ステートフルな検索オブジェクトの制御: Wordの`Find`オブジェクトはプロパティの設定を保持し続ける。各ループでの初期化が成否を分ける。
3. Rangeオブジェクトの局所化: `Selection`ではなく`Range`を操作することで、画面描画のオーバーヘッドを劇的に削減する。
—
2. 極限の置換エンジン：実装コード
以下のコードは、単なる置換の繰り返しではない。WordのDOM構造を考慮し、メモリ効率と実行速度を最大化したプロトタイプである。
Option Explicit
”’
”’
Public Sub ExecuteMassReplacement()
On Error GoTo ErrorHandler
‘ パフォーマンス最適化：画面更新の停止
Application.ScreenUpdating = False
Dim fso As Object ‘ Scripting.FileSystemObject
Dim ts As Object ‘ Scripting.TextStream
Dim csvPath As String
Dim line As String
Dim parts() As String
Dim targetDoc As Document
Dim rng As Range
‘ 置換リストのパス（実行マクロと同一フォルダを想定）
csvPath = ThisDocument.Path & “\replacement_list.csv”
Set fso = CreateObject(“Scripting.FileSystemObject”)
If Not fso.FileExists(csvPath) Then
Err.Raise 53, , “置換リスト（CSV）が見つかりません: ” & csvPath
End If
‘ CSVの読み込み（読み取り専用、ASCII/Shift-JIS想定）
‘ ※UTF-8（BOMなし）を扱う場合はADODB.Streamへの切り替えを検討せよ
Set ts = fso.OpenTextFile(csvPath, 1, False)
Set targetDoc = ActiveDocument
‘ CSVの各行をループ処理
Do While Not ts.AtEndOfStream
line = ts.ReadLine
If Trim(line) <> “” Then
parts = Split(line, “,”)
‘ カンマ区切りの妥当性チェック
If UBound(parts) >= 1 Then
Dim findText As String: findText = parts(0)
Dim replaceText As String: replaceText = parts(1)
‘ ドキュメント全体をRangeとして取得
Set rng = targetDoc.Content
‘ Word.Findオブジェクトの制御
‘ 以前の検索条件が残存するため、都度ClearFormattingを行う
With rng.Find
.ClearFormatting
.Replacement.ClearFormatting
.Text = findText
.Replacement.Text = replaceText
‘ 検索オプションの設定
.Forward = True
.Wrap = wdFindContinue
.Format = False
.MatchCase = True ‘ 大文字小文字の区別
.MatchWholeWord = False ‘ 単語単位（日本語の場合はFalse推奨）
.MatchByte = False ‘ 全角半角の区別
.MatchAllWordForms = False
.MatchSoundsLike = False
.MatchWildcards = False ‘ 正規表現(ワイルドカード)使用時はTrue
‘ 実行：wdReplaceAll（一括置換）
.Execute Replace:=wdReplaceAll
End With
End If
End If
Loop
ts.Close
MsgBox “一括置換が完了しました。”, vbInformation
CleanUp:
‘ オブジェクトの明示的解放（VBAのメモリ管理における鉄則）
Set ts = Nothing
Set fso = Nothing
Set rng = Nothing
Application.ScreenUpdating = True
Exit Sub
ErrorHandler:
MsgBox “エラー発生: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
—
3. シニアエンジニアが注目すべき「三つの急所」
① Findオブジェクトの「負の遺産」を断つ
Wordの`Find`オブジェクトは、GUI上の「検索と置換」ダイアログの設定と共有されている。つまり、手動操作で「あいまい検索」をオンにしていれば、VBA側でもそれが引き継がれる。
`ClearFormatting`の実行はもちろんのこと、`.Text`や`.Replacement.Text`以外の全プロパティ（`.MatchCase`, `.MatchWildcards`等）を明示的に指定することが、予期せぬ挙動を防ぐ唯一の道である。
② メモリ最適化とRangeのライフサイクル
`Selection`オブジェクトを使って置換を行うのは、アマチュアのやり方だ。`Selection`は常に画面表示（View）とリンクしており、実行速度を著しく低下させる。
`Document.Content`から`Range`を取得し、メモリ上で操作を完結させるのが定石だ。また、大規模な置換（数千箇所など）を行う場合、WordのUndoスタックがメモリを圧迫することがある。非常に長大な文書を扱う場合は、一定間隔で`ActiveDocument.Save`を挟み、バッファをフラッシュする設計も検討に値する。
③ 文字コードの壁：FSO vs ADODB.Stream
上記コードでは標準的なFSOを用いているが、現代のシステム連携においてCSVがUTF-8（BOMなし）で出力されるケースは多い。残念ながらFSOはUTF-8を正しく解釈できない。その場合は、`ADODB.Stream`オブジェクトをインスタンス化し、Charsetに`UTF-8`を指定して読み込む必要がある。
—
4. 高度な応用：ワイルドカード（正規表現的アプローチ）の活用
単なる文字列置換を超え、パターンの置換が必要な場合は、`.MatchWildcards = True`を設定する。Word独自のワイルドカード構文は、標準的な正規表現（RegExp）とは異なるが、非常に強力だ。
- 例：`[0-9]{3}-[0-9]{4}` （日本の郵便番号形式を置換）
- 例：`([A-Z]{1,})` （英大文字の連続をグループ化してキャプチャ）
CSVの第3列に「ワイルドカードフラグ」を持たせ、行ごとに`.MatchWildcards`を切り替える実装に進化させれば、もはやそのシステムは「置換ツール」ではなく、高度な「ドキュメント・サニタイズ・エンジン」へと昇華する。
—
結論：保守性こそがエンジニアの誠実さである
コードを書く時間は一瞬だが、そのコードが保守される時間は数年に及ぶ。
置換ルールを外部CSVに追い出すという一見シンプルな工夫が、将来の仕様変更コストをゼロにする。
Windows APIを駆使したパフォーマンス計測（`QueryPerformanceCounter`等）を行うのも良いが、まずはこのような「変化に強いアーキテクチャ」を構築すること。それこそが、Word VBAを掌握するチーフアーキテクトに求められる真の資質である。
