【静的チェック】Option Explicit の徹底活用で変数宣言漏れとスペルミスによるバグを根絶する
業務自動化の現場において、VBScriptは今なおWindows環境におけるキラーツールとしての役割を担っている。インストールの手間なく、OSの標準機能だけで動作する手軽さは、日々の定型作業を効率化する上で絶大な威力を発揮する。
しかし、その「手軽さ」の裏側には、多くの開発者を地獄に突き落とす魔物が潜んでいる。それが、動的型付けとデフォルトの変数自動生成（暗黙の宣言）だ。
今回は、VBScriptで堅牢なスクリプトを組み上げるための絶対命題、`Option Explicit` について、そのアーキテクチャの裏側と実務での活用法を叩き込む。
—
なぜ、デフォルトのVBScriptは危険なのか？
次のコードを見てほしい。一見すると、何の問題もないように見えるかもしれない。
‘ 【アンチパターン】Option Explicitのないコード
Dim totalCount
totalCount = 100
‘ 処理の途中で変数のスペルミスが発生
totlaCount = totalCount + 50
WScript.Echo “合計: ” & totalCount
このスクリプトを実行するとどうなるか？ エラーは起きず、画面には `100` と表示される。
「合計: 150」ではなく、だ。
原因は明白である。`totlaCount`（LとTの順番が逆）という存在しない変数を勝手に新規作成し、そこに `150` を代入してしまったからだ。元の `totalCount` は書き換わっていない。
VBScriptはデフォルトでは、変数宣言（`Dim`）なしで値代入が行われると、自動的にバリアント型（Variant）の変数をその場で生成する仕様になっている。この仕様が、大規模なスクリプトや複雑なファイル・データベース連携処理において、原因の特定が極めて困難な「サイレント・バグ」を生み出す元凶となる。
—
救世主：`Option Explicit` による静的チェックの強制
この悪夢のような仕様を根絶するのが、スクリプトの先頭に記述するたった1行の宣言だ。
Option Explicit
これをファイルの最上行（コメントを除く）に記述すると、VBScriptの実行エンジンは「すべての変数を事前に `Dim` で明示的に宣言することを強制する」モードに切り替わる。
もし宣言していない変数（あるいはスペルミスした変数）がコード内に存在した場合、スクリプトは実行すらされず、即座にコンパイルエラー（実行時エラー）として検知される。
エラー: 変数が定義されています: ‘totlaCount’
コード: 6
行: 5
「実行する前にバグに気づける」――これこそが、プロのエンジニアが絶対に妥協してはならない防衛ラインである。
—
【実務プロダクションコード】堅牢な設計のテンプレート
ファイル操作やログ出力、エラーハンドリングを組み込んだ、実務でそのまま流用できる堅牢なVBScriptのテンプレートを提示する。
すべての基本は、`Option Explicit` の宣言から始まる。
Option Explicit
‘ —————————————————————–
‘ スクリプト名: SecureFileProcessor.vbs
‘ 概要: Option Explicitを徹底し、安全にファイル処理を行うプロダクションコード
‘ —————————————————————–
‘ メイン処理の実行
Main
Sub Main()
‘ 変数は必ずプロシージャの先頭でDim宣言する
Dim objFSO, targetPath, logMessage
‘ オブジェクト変数の初期化
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
targetPath = “C:\Automation\data\target.txt”
‘ エラーハンドリングの有効化
On Error Resume Next
‘ ファイルが存在するかチェック
If objFSO.FileExists(targetPath) Then
logMessage = “対象ファイルを確認しました: ” & targetPath
Call WriteLog(logMessage)
Else
logMessage = “警告: 対象ファイルが存在しません -> ” & targetPath
Call WriteLog(logMessage)
End Sub ‘ Syntax Errorの罠を防ぐための正しいEnd If (※下記解説参照)
‘ エラーハンドリングの終了
If Err.Number <> 0 Then
WScript.Echo “予期せぬエラーが発生しました: ” & Err.Description
Err.Clear
End If
On Error GoTo 0
‘ オブジェクトの解放（メモリリーク防止の作法）
Set objFSO = Nothing
WScript.Echo “処理が正常に完了しました。”
End Sub
‘ —————————————————————–
‘ ログ出力用サブルーチン
‘ @param {String} message 出力するメッセージ
‘ —————————————————————–
Sub WriteLog(ByVal message)
‘ ここでもOption Explicitの効力を受けるため、変数使用時は必ずDimする
Dim fsoLog, logFile, logPath
logPath = “C:\Automation\logs\operation.log”
Set fsoLog = CreateObject(“Scripting.FileSystemObject”)
‘ ログファイルの追記オープン (ForAppending = 8, Create = True = -1)
Set logFile = fsoLog.OpenTextFile(logPath, 8, True)
logFile.WriteLine “[” & Now & “] ” & message
logFile.Close
‘ クリーンアップ
Set logFile = Nothing
Set fsoLog = Nothing
End Sub
—
プロが実践するコードレビューの視点と設計の極意
上記のコードには、現場で生き残るための「こだわり」がいくつも詰まっている。
1. 変数スコープとライフサイクルの管理
VBScriptでは、グローバルスコープでの変数の乱用はバグの温床となる。可能な限り `Sub` や `Function` のスコープ内に閉じ込め、それぞれのプロシージャの先頭で `Dim` を行うこと。これにより、変数のライフサイクルが明確になり、メモリ管理や予期せぬ値の書き換えを防ぐことができる。
2. オブジェクトの明示的な破棄 (`Set … = Nothing`)
VBScriptはスクリプト終了時にガベージコレクションが走るが、COMオブジェクト（`Scripting.FileSystemObject` や `ADODB.Connection` など）を多用する長時間の自動化処理では、明示的に `Set obj = Nothing` で解放する癖をつけなければならない。これを怠ると、ファイルロックが解除されない、メモリリークを引き起こすなどの致命的なトラブルに直結する。
3. `On Error Resume Next` との付き合い方
データベース連携やファイルI/Oでは例外処理が不可欠だが、VBScriptのエラーハンドリングは非常にプリミティブである。`On Error Resume Next` を使用する場合は、必ず直後に `If Err.Number <> 0 Then` でトラップし、処理が終わったら速やかに `On Error GoTo 0` に戻すこと。`Option Explicit` と組み合わせることで、エラーの検知漏れを最小限に抑え込める。
—
まとめ：プロと素人を分ける境界線
「動けばいい」という妥協のもとに書かれたVBScriptは、数ヶ月後に改修が必要になった際、開発者を絶望させる負債へと変わる。変数名のタイポ一つで挙動が変わるような脆弱なコードを野放しにしてはならない。
すべてのVBScriptファイルの先頭に `Option Explicit` を書く。
この極めてシンプルで強力なルールをチーム全体で徹底することこそが、保守性が高く、トラブルフリーな業務自動化環境を実現するための最短にして唯一の道である。今日からあなたのスクリプトにも、この「盾」を必ず装着してほしい。
