現場のエンジニアへ：VBScriptの「野蛮なエラー」を静かに制圧する極意
VBScriptで業務自動化ツールを組む際、多くの開発者が陥る罠がある。それは「`On Error Resume Next` を書いただけで、エラーハンドリングをした気になっている」という慢心だ。
FSO（FileSystemObject）は強力だが、ネットワークの瞬断、ファイルロック、権限の不一致など、外部要因による失敗が付きまとう。何も対策せずにツールを放置すれば、ある日突然、無言で処理が停止し、誰にも気づかれずにデータが欠落する。
今日は、プロフェッショナルとして現場で戦うための、「沈黙させないエラーハンドリング」の極意を伝授する。
—
1. なぜ「雑なエラー回避」が死を招くのか
`On Error Resume Next` は強力な「鎮痛剤」だ。しかし、痛みの原因を特定せずに麻痺させるのは、致命的なバグの温床となる。
- 何が起きたか不明: ログがないため、後から「なぜ一部のファイルだけ処理されていないのか」を追うことが不可能。
- 状態の不整合: エラーが発生したのに処理を続行することで、ゴミファイルが生成されたり、データベースとファイルシステム間で不整合が生じる。
真のエンジニアは、「エラーを消す」のではなく「エラーを詳細な記録として残し、システムを安全に停止（またはスキップ）させる」設計を行う。
—
2. 堅牢なFSO操作のためのログ設計テンプレート
以下は、私が長年の開発現場で磨き上げた、汎用的な「ログ出力付きFSO操作クラス的コード」だ。この構造をコピーし、自分のツールに組み込んでほしい。
‘ — 設定エリア —
Const LOG_FILE_PATH = “C:\Logs\operation_log.txt”
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ — メイン処理ループ —
Sub ProcessFiles(targetPath)
Dim file, folder
Set folder = fso.GetFolder(targetPath)
For Each file In folder.Files
On Error Resume Next ‘ 局所的なエラー制御
‘ ここでFSO操作を実行
fso.DeleteFile file.Path, True
‘ エラー判定
If Err.Number <> 0 Then
‘ 異常発生時、詳細をログに出力して即座にクリア
WriteErrorLog file.Path, Err.Number, Err.Description
Err.Clear
Else
‘ 正常時もログを残すのがプロの流儀
WriteInfoLog “SUCCESS: ” & file.Path
End If
On Error Goto 0 ‘ エラー制御を戻す（忘れるとデバッグ不可になる）
Next
End Sub
‘ — ログ出力用共通関数 —
Sub WriteErrorLog(filePath, errNum, errDesc)
Dim ts
Set ts = fso.OpenTextFile(LOG_FILE_PATH, 8, True) ‘ 8: ForAppending
ts.WriteLine Now & ” [ERROR] Path: ” & filePath & ” | Code: ” & errNum & ” | Msg: ” & errDesc
ts.Close
End Sub
Sub WriteInfoLog(msg)
Dim ts
Set ts = fso.OpenTextFile(LOG_FILE_PATH, 8, True)
ts.WriteLine Now & ” [INFO] ” & msg
ts.Close
End Sub
—
3. 現場で生き残るための「3つの鉄則」
コードを動かすこと以上に、「運用に耐えうるか」という視点が重要だ。以下の鉄則を忘れないでほしい。
① ログファイルは「追記（Appending）」一択
毎回ログファイルを書き換えてはいけない。`OpenTextFile` の第3引数を `8` に設定し、古い記録を資産として残すこと。ログの肥大化が気になるなら、週次でアーカイブするバッチを別途組めばいい。
② `Err.Clear` を忘れない
`On Error Resume Next` のあとに `Err.Clear` を叩かなければ、直前のエラー情報がメモリに残り続け、次回の正常な処理まで「前のエラー」として誤判定される。これはバグの元凶だ。
③ ファイルロックへの防衛策
FSO操作が最も失敗するのは「ファイルが編集中（ロック中）」の時だ。
エラーログに `800A0046`（書き込み禁止）や `800A004C`（パスが見つからない）が出たら、それはコードのバグではなく「運用上の制約」だ。ログに「ファイルがロックされているためスキップ」と明記することで、ユーザー（現場担当者）に対して「ツールが壊れているのではなく、ファイルを開きっぱなしにしている運用を見直すべき」という事実を突きつけられる。
—
最後に：ツールは「沈黙」を許してはならない
自動化とは、人間の代わりに目を光らせることだ。
エラーを無視して走り続けるツールは、ただの「暴走する無責任なプログラム」に過ぎない。
今日紹介したコードはシンプルだが、この「エラーを可視化する」という一歩があるだけで、保守コストは劇的に下がる。次に誰かがコードを見たとき、「このエンジニアはここが失敗することを予見していたんだな」と伝わるような、気配りのあるコードを書いてほしい。
それが、世界最高峰のエンジニアになるための第一歩だ。現場からは以上だ。
