VBScriptを極める：ファイル排他ロックを「美しく」検知する鉄則
業務自動化の現場において、VBScriptは今なお強力な武器だ。しかし、多くのエンジニアが「ファイル操作」の段階で躓く。特に、Excelや他システムが掴んでいるファイルを無理やり操作しようとして、スクリプトが非情にも「実行時エラー」で停止する事態は、自動化の信頼性を根底から覆す。
今回は、VBScriptにおける「ファイル排他ロック判定」の極致を伝授する。安易なエラー回避ではなく、OSの挙動とオブジェクトのライフサイクルを深く理解した堅牢な設計手法だ。
—
なぜ「OpenTextFile」での判定が必要なのか
VBScriptで最も手軽、かつ強力なファイル操作オブジェクトは `Scripting.FileSystemObject` (FSO) だ。しかし、FSO自体には「今、誰かがこのファイルを開いているか？」を直接問い合わせるメソッドは存在しない。
そこで我々がとるべき戦略は、「排他的アクセスを試行し、拒絶されるかどうかで判定する」というアプローチだ。
陥りがちなアンチパターン
多くの初心者は、単に `Err.Number <> 0` をチェックして「ダメなら終了」と記述する。だが、これでは不十分だ。
- リソースの解放漏れ: エラー発生時にオブジェクトを正しく破棄しないと、メモリリークやプロセス残留を招く。
- 例外の不透明さ: 権限不足なのか、ロック中なのか、ファイルが存在しないのかを区別しない設計は、運用保守を地獄に変える。
—
【実装】プロダクションレベルの排他判定関数
以下のコードは、単なる判定関数ではない。OSのファイルロックに対する「攻撃」を最小限の負荷で行い、結果を論理値で確実に返すプロフェッショナル仕様だ。
‘ ———————————————————
‘ 関数名: IsFileLocked
‘ 概要: 指定したファイルが他プロセスによってロックされているか判定する
‘ 戻り値: True(ロック中/操作不可), False(操作可能)
‘ ———————————————————
Function IsFileLocked(ByVal filePath)
Dim fso, ts
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ ファイルが存在しなければ、ロック判定以前の問題である
If Not fso.FileExists(filePath) Then
IsFileLocked = False
Exit Function
End If
On Error Resume Next ‘ エラーをトラップし、制御をコードに戻す
‘ 書き込みモード(ForAppending)で開こうとする
‘ ロックされている場合、ここで実行時エラーが発生する
Set ts = fso.OpenTextFile(filePath, 8, False)
If Err.Number <> 0 Then
‘ エラーが発生した＝ロックされている可能性が高い
IsFileLocked = True
Err.Clear
Else
‘ 正常に開けた場合は即座に閉じる（これが重要）
ts.Close
IsFileLocked = False
End If
On Error Goto 0 ‘ エラーハンドリングを解除
Set ts = Nothing
Set fso = Nothing
End Function
‘ — 利用例 —
Dim targetFile
targetFile = “C:\Temp\Report.xlsx”
If IsFileLocked(targetFile) Then
WScript.Echo “警告: ファイルが使用中です。処理をスキップします。”
Else
‘ ここに本来の業務ロジックを記述
WScript.Echo “成功: ファイルを操作可能です。”
End If
—
現場で差がつく3つの知見
このコードをただコピペするだけでなく、以下の「設計思想」を理解してほしい。
1. 「ForAppending」を使用する理由
読み取りモード(`ForReading`)で開くと、Excelなどは「読み取り専用」として開かせてしまうことがある。これではロックを検知できない。排他ロックを確実に検知するには、書き込み権限を要求するモードで開くのが鉄則である。
2. 「オブジェクトの解放」は義務
`Set ts = Nothing` を忘れるエンジニアが多い。VBScriptのガベージコレクションは頼りない。特にループ処理の中でこの関数を多用する場合、オブジェクトを解放しないと、スクリプト実行中にメモリを食いつぶし、OS全体が不安定になるリスクがある。
3. 「冪等性（べきとうせい）」の確保
この関数は、何度実行してもファイルの状態を破壊しないよう設計されている。自動化ツールにおいて「何度実行しても安全である」ことは、異常終了時のリカバリやリトライ処理を構築する上で最も重要な要件だ。
—
最後に：自動化エンジニアの誇りとして
ファイルロック判定は、自動化の「門番」だ。ここを雑に作ると、後続のメイン処理でエラーが連鎖し、デバッグが極めて困難になる。
「動けばいい」というコードは、一ヶ月後の自分を苦しめる。今回提示したロジックのように、エラーを能動的に飼いならし、OSの挙動を予測する設計こそが、伝説的な自動化エンジニアへの第一歩だ。
さあ、この関数をあなたのツールキットに加え、堅牢な自動化フローを構築してほしい。君の書くコードが、組織の業務を止めるのではなく、支えるものになることを期待している。
