現場のコードを「事故」から守る：VBScriptにおける排他制御と安全な一時ファイル管理の極意
業務自動化の現場で、なぜ「ファイルアクセス拒否（エラー70）」や「予期せぬデータ混入」が発生するのか。その原因のほとんどは、安易なファイル名命名規則と、プロセス間の生存期間を考慮しない一時ファイル管理にあります。
VBScript（WSH）はレガシーな技術と揶揄されがちですが、適切に設計すれば、Windows環境において極めて軽量かつ堅牢な自動化兵器となります。今回は、大規模なバッチ処理が並行稼働する環境でも「絶対に競合しない」一時ファイル管理のアーキテクチャを伝授しましょう。
—
1. なぜ「現在時刻」ベースの命名では破綻するのか
多くのエンジニアがやりがちな間違いが、`FormatDateTime(Now, vbGeneralDate)` を使ったファイル生成です。
- 競合の温床: CPUの処理速度が向上した現代では、同一ミリ秒内に複数のプロセスが立ち上がることは日常茶飯事です。
- ソート順の欠如: 時間ベースの命名は、ファイルシステム上での管理が煩雑になり、後続のログ解析やクリーンアップ処理の難易度を上げます。
真にプロフェッショナルな設計とは、「そのファイルがいつ、どのプロセスから生成されたか」を特定しつつ、確率論的に衝突をゼロにすることです。
—
2. GUID風アルゴリズムによる「衝突回避」の設計
Windowsには `TypeLib` 経由でGUIDを生成する機能がありますが、VBScriptで最も高速かつ安全なのは、`Scripting.FileSystemObject` と `TypeLib.Guid` の特性を組み合わせることです。ここでは、外部依存を最小限にしつつ、実行のたびにユニークな文字列を生成する堅牢な関数を提示します。
安全な一時ファイル管理モジュール
‘ — TempManager.vbs —
Option Explicit
‘ 実行環境での競合を完全に排除する一時ファイル管理クラス
Class TempFileManager
Private fso
Private tempFolder
Private Sub Class_Initialize()
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ Windowsの標準Tempフォルダを取得
tempFolder = fso.GetSpecialFolder(2).Path
End Sub
‘ ランダムな一時ファイルパスを生成する
Public Function GetUniqueTempPath(extension)
Dim guid, filePath
‘ TypeLibを借りてGUIDを生成 (乱数より圧倒的に安全)
guid = Left(CreateObject(“Scriptlet.TypeLib”).Guid, 38)
guid = Replace(Replace(guid, “{“, “”), “}”, “”)
filePath = fso.BuildPath(tempFolder, “tmp_” & guid & “.” & extension)
GetUniqueTempPath = filePath
End Function
‘ ファイルを安全に破棄する（後処理の自動化）
Public Sub SafeDelete(filePath)
If fso.FileExists(filePath) Then
‘ 読み取り専用属性を強制解除してから削除
fso.GetFile(filePath).Attributes = 0
fso.DeleteFile filePath, True
End If
End Sub
End Class
‘ — 使用例 —
Dim manager, myTempFile
Set manager = New TempFileManager
‘ 一時ファイルの生成
myTempFile = manager.GetUniqueTempPath(“txt”)
WScript.Echo “生成された一時ファイル: ” & myTempFile
‘ 処理終了後に必ず削除 (Try…Finallyの概念を実装する)
On Error Resume Next
‘ ここにメイン処理を記述
‘ …
On Error GoTo 0
‘ 終了処理
manager.SafeDelete(myTempFile)
—
3. 実務で勝つための「3つの鉄則」
コードを動かすだけでなく、運用で死なないための設計指針です。
① 「読み取り専用」という罠を想定する
たまに発生する「なぜか削除できない」というエラーは、前回の異常終了時にファイルが読み取り専用属性になったまま残っていることが原因です。`fso.GetFile(filePath).Attributes = 0` を明示的に呼び出し、属性をクリアしてから削除するルーチンは必須です。
② エラーハンドリングは「例外」ではなく「戻り値」で管理する
VBScriptには強力なtry-catchがありません。だからこそ、ファイル操作を行う関数は、操作が成功したかどうかのBooleanを返す設計にすべきです。「動けばいい」コードは、半年後の自分がメンテナンスするときに地獄を見ます。
③ クリーンアップの自動化
バッチ処理が異常終了した際に、一時ファイルがゴミとして残るのを防ぐ手段として、終了時にTempフォルダを定期的に掃き出す「ガーベジコレクション・スクリプト」を別途作成し、タスクスケジューラで回す運用を推奨します。
—
結論：コードは「防御」のために書く
今回提示したGUID活用によるファイル名生成は、単なる小手先のテクニックではありません。「同時並行処理において、リソースの衝突は必ず発生する」という前提に立ち、それをコードレベルで封殺するエンジニアリングの基本姿勢です。
自動化ツールの品質は、正常系ではなく「異常系や並行実行環境」で決まります。ぜひ、あなたの現場のコードにもこの設計を取り入れ、無用なトラブルを根絶してください。
