Word VBAの「黒魔術」を解く：保守性を極限まで高めるエラーハンドリングの真髄
Word VBAで「動けばいい」というコードを書いているうちは、プロとは呼べない。
実務の現場で最も恐ろしいのは、エラーそのものではない。「エラーが起きたのに、どこで何が起きたのか誰も把握できない状態」だ。
Wordのオブジェクトモデル（Application > Document > Range）は非常に強力だが、その分、実行時の状態変化に極めて敏感だ。今日は、泥沼のデバッグ作業を終わらせ、「誰が使っても原因が即座に特定できる」、プロダクションレベルのエラーハンドリング設計を伝授する。
—
1. なぜ「On Error Resume Next」を多用してはいけないのか
初心者が陥る最大の罠が、`On Error Resume Next` の乱用だ。これはコードの「痛み止め」に過ぎない。予期せぬエラーを隠蔽し、後続の処理でさらなる不可解なエラーを引き起こす。
我々が求めるべきは、「エラーを握りつぶす」ことではなく、「エラーを記録し、安全にプロセスを終了させる」ことだ。
2. 堅牢な設計：中央集権型エラーハンドラ
各プロシージャに同じエラー処理をコピペするのは、保守性の観点から論外だ。エラーログ出力は一箇所に集約し、共通モジュール（例えば `modLogger`）として切り出すのが鉄則である。
実装：プロダクションコード例
以下のコードは、エラー発生時に「どのプロシージャの、どの行で、何が起きたか」をテキストファイルに書き出す汎用エンジンだ。
‘ — モジュール: modLogger —
Option Explicit
Public Sub WriteErrorLog(procName As String, errNum As Long, errDesc As String)
Dim logPath As String
Dim fileNum As Integer
‘ ログファイルの保存先（環境に合わせて変更してください）
logPath = ThisDocument.Path & “\error_log.txt”
fileNum = FreeFile
On Error Resume Next ‘ ログ書き込み自体が失敗する場合の無限ループ回避
Open logPath For Append As #fileNum
Print #fileNum, “————————————————–”
Print #fileNum, “発生日時: ” & Now
Print #fileNum, “プロシージャ名: ” & procName
Print #fileNum, “エラー番号: ” & errNum
Print #fileNum, “詳細: ” & errDesc
Close #fileNum
On Error GoTo 0
End Sub
3. 実践：エラーハンドリングの定石
呼び出し側のプロシージャでは、`Label` を使った構造化を行う。ここでのポイントは、「終了処理（CleanUp）」を必ず通る設計にすることだ。
‘ — 使用例 —
Public Sub ProcessDocument()
Const ProcName As String = “ProcessDocument”
On Error GoTo ErrorHandler
‘ ここにメインの業務ロジックを記述
‘ 例: ActiveDocument.Range.InsertAfter “Hello”
Exit Sub
ErrorHandler:
‘ ログを出力して、ユーザーに通知する
Call WriteErrorLog(ProcName, Err.Number, Err.Description)
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“詳細はログファイルを確認してください。”, vbCritical
End Sub
4. 現場で生き残るための「3つの極意」
① アプリケーションの「状態」を意識せよ
Word VBAでは、ユーザーが操作中に何かを選択したり、ウィンドウを切り替えたりすることでオブジェクトの状態が変化する。`Selection`オブジェクトに依存しすぎず、可能な限り `Range` オブジェクトを明示的に指定して操作せよ。それがバグを減らす最短距離だ。
② ファイルI/Oの競合を考慮せよ
ログを書き込む際、ネットワークドライブ上の共有ファイルや、別のプロセスが掴んでいるファイルに書き込もうとするとエラーになる。`FreeFile`を使い、ファイルハンドルを正しく管理することは、地味だが非常に重要なマナーである。
③ ユーザー体験（UX）を忘れるな
開発者にとっては「エラーログ」が全てだが、エンドユーザーには「何が起きたか」「次に何をすべきか」を提示しなければならない。単にエラーコードを表示するのではなく、業務が停止したことを丁重に謝罪し、ログを確認するよう誘導するメッセージを出すのがプロの仕事だ。
—
最後に：コードは「資産」か「負債」か
良いコードはメンテナンスを必要としない。なぜなら、エラーが起きた瞬間、誰がいつ見ても解決策が判明するからだ。
今日からあなたのWord VBAツールにこのログ機能を実装してほしい。コードを動かすことに満足するステージを卒業し、「運用し続けられるシステム」を作るステージへ上がろう。
何か不明点があれば、またいつでも聞いてくれ。現場からは以上だ。
