VBScriptにおけるリソース管理の極致：TextStreamの確実な解放とファイルロック回避の設計思想
レガシーシステムの保守、あるいはWindows環境における高度な自動化タスクに従事するエンジニアにとって、VBScriptは避けては通れない、しかし極めて「危うい」道具だ。
特に`FileSystemObject`（FSO）を用いたテキストファイル操作において、多くの開発者が陥る致命的な罠がある。それは、「処理の途中で条件分岐やエラーが発生した際、TextStreamオブジェクトが適切にClose（閉鎖）されず、ファイルハンドルがOSレベルで残留してしまう」という問題だ。
これが引き起こすのは、単なるメモリリークではない。「ファイルは別のプロセスによって使用されているため、プロセスはアクセスできません」という、システム連携を根底から破壊するファイルロックエラーである。
本稿では、プロフェッショナルとして、`Exit Sub`や`Exit Function`を乱用せず、いかにしてリソースのライフサイクルを完璧に制御するか。その極限の設計パターンを伝授する。
1. なぜ「ただのClose」では足りないのか
通常のプログラミングにおいて、関数の末尾に`objTextStream.Close`を記述するのは当然の作法に見える。しかし、実務におけるロジックは常に直線的ではない。
' --- 典型的な「失敗する」パターン ---
Sub BadExample(filePath)
Dim fso, ts
Set fso = CreateObject("Scripting.FileSystemObject")
Set ts = fso.OpenTextFile(filePath, 1)
' 何らかの複雑な検証ロジック
If Not ValidateData(ts) Then
Exit Sub ' <--- 【致命的】ここで終了するとCloseが呼ばれない
End If
' ... メイン処理 ...
ts.Close
Set ts = Nothing
Set fso = Nothing
End Sub上記のコードでは、`ValidateData`が`False`を返した瞬間、`ts.Close`がスキップされる。このとき、`ts`（TextStreamオブジェクト）が保持しているファイルハンドルは、VBScriptのプロセスが完全に終了するか、あるいはCOMの参照カウンタがゼロになるまでOSに握られたままとなる。
これが、バッチ処理をループで回す際や、長時間稼働する常駐スクリプトにおいて、後続のプロセスを次々と「死に体」にする原因となるのだ。
2. 鉄則：`Cleanup`ラベルによる構造化された脱出
VBScriptには、現代的な言語にある`try…finally`構文が存在しない。我々アーキテクトが取るべき戦略は、「いかなる脱出経路においても、必ず共通の解放処理（Cleanup）を経由させる」という構造化設計である。
これこそが、レガシー環境におけるリソース管理の黄金律である。
実践的ベストプラクティス：構造化リソース解放パターン
' =================================================================
' 堅牢なファイル読み込みプロシージャ
' =================================================================
Sub RobustFileProcess(strFilePath)
' オブジェクト変数の宣言（スコープを限定）
Dim fso, ts, strLine
Dim bSuccess
' エラーハンドリングの初期化
On Error Resume Next
bSuccess = False
' 1. オブジェクトの生成
Set fso = CreateObject("Scripting.FileSystemObject")
' 2. ファイルのオープン
' OpenTextFileが失敗する可能性を考慮
Set ts = fso.OpenTextFile(strFilePath, 1)
If Err.Number <> 0 Then
' エラーログ出力などの処理（ここでは簡略化）
Err.Clear
GoTo Cleanup ' エラーが発生した場合は即座に解放処理へ
End If
' 3. メインロジック
Do Until ts.AtEndOfStream
strLine = ts.ReadLine
' 条件による早期脱出が必要な場合も、Exit SubではなくGoTo Cleanupを使う
If IsInvalid(strLine) Then
' 無効なデータを発見した際の処理
GoTo Cleanup
End If
' --- ここに実務的な処理を記述 ---
Loop
' 全ての処理が正常に終了した場合のみ成功フラグを立てる
bSuccess = True
' =================================================================
' Cleanupセクション：全ての脱出経路が集約される唯一の場所
' =================================================================
Cleanup:
' エラーハンドリングを元の状態（あるいは停止状態）に戻す
On Error GoTo 0
' TextStreamの解放（存在確認を行ってからClose）
If Not ts Is Nothing Then
On Error Resume Next ' Close自体の失敗による二次エラーを防ぐ
ts.Close
Set ts = Nothing
On Error GoTo 0
End If
' FSOの解放
If Not fso Is Nothing Then
Set fso = Nothing
End If
' 結果に応じた後続処理の制御
If Not bSuccess Then
' 失敗時のログ出力や通知ロジックをここに集約
End If
End Sub
' 補助関数（例）
Function IsInvalid(str)
IsInvalid = (str = "")
End Function3. アーキテクトの視点：メモリ最適化とCOMオブジェクトの真実
ここで、シニアエンジニアが知っておくべき「オブジェクトのライフサイクル」についての深淵な知見を共有しておこう。
`Close` と `Set Nothing` の決定的な違い
多くの者が混同しているが、これらは全く別次元の操作である。
1. `ts.Close`: これはOSレベルのファイルハンドルを解放する命令である。ファイルロックを解除するために必須の操作だ。
2. `Set ts = Nothing`: これはCOM（Component Object Model）の参照カウンタをデクリメントする操作である。メモリ上のオブジェクトの生存期間を管理するためのものである。
もし`Close`を忘れて`Set Nothing`だけを行った場合、VBScriptのガベージコレクション（正確にはCOMの参照カウント方式）が動作するまで、ファイルはロックされたままである。メモリは解放されても、ファイルハンドルは「開いたまま」という、最悪の矛盾状態が生じるのだ。
Windows APIとの境界線
VBScriptのFSOは、内部的にWindowsのWin32 API（`CreateFile`, `ReadFile`, `CloseHandle`等）を呼び出している。我々が`Close`を呼ぶということは、直接的にカーネルモードへの命令を送り、システムリソースを返還することを意味する。
大規模なシステム間連携（例：VBScriptで生成したログを、即座に別のC#アプリケーションが解析する等）において、この「リソースの返還タイミング」の不確実性は、システムの信頼性を損なう最大の要因となる。
4. 結論：守るべき設計思想
VBScriptを扱う際、我々は常に「最悪の事態」を想定しなければならない。
- `Exit Sub` / `Exit Function` を、ロジックの途中で安易に使わない。
- 全ての脱出経路は `Cleanup:` ラベルへ集約させる。
- `Close`（OSリソース解放）と `Set Nothing`（メモリリソース解放）をセットで行う。
- `On Error Resume Next` を使う場合は、必ず `Cleanup` 内で適切にエラーハンドリングを制御する。
この規律を守るか否かが、単なる「スクリプト作成者」と、堅牢なシステムを構築できる「エンジニア」を分かつ境界線である。レガシーな技術であっても、その扱い方には常に最新のアーキテクチャ思想を注入すべきなのだ。
