VBScriptを「使い捨て」から「資産」へ変える：WSFによるリソース分離と宣言的設計の極意
VBScriptを単なる「場当たり的な自動化ツール」で終わらせていないか？
多くの現場で散見されるのは、SQLクエリがハードコードされ、COMオブジェクトの生成が`CreateObject`の乱れ打ちでカオスと化したスクリプトだ。
「動けばいい」という甘えは、半年後の自分が仕様変更に直面した瞬間に「負債」となって跳ね返ってくる。本稿では、VBScriptをプロダクションレベルの品質へと昇華させるための唯一の回答、WSF（Windows Script File）によるリソース管理と宣言的コンポーネント設計を伝授する。
—
1. なぜ「.vbs」単体での開発は危険なのか
`CreateObject`をスクリプト内で直接呼び出すやり方は、以下の致命的な欠陥を抱えている。
- 依存関係の不可視化: どのライブラリ（Excel, ADODB, FSO等）に依存しているのかが、コードのあちこちを読まないと判明しない。
- ハードコードの汚染: SQLクエリや定数がロジックに埋没し、修正のたびにロジックを破壊するリスクを伴う。
- 型情報の欠如: `CreateObject`による遅延バインディングは、実行するまで型の不整合に気づけない。
WSF形式（`
—
2. 実践：WSFによるリソースとオブジェクトの分離
WSFは、スクリプトの「設定」と「ロジック」を分離するための強力なフレームワークだ。以下の構成を見てほしい。
SELECT ID, NAME, EMAIL FROM T_USER_MASTER WHERE STATUS = 1
この設計が優れている理由
1. `: スクリプト冒頭の`Dim`や`Set`による初期化コードが不要になる。これにより、メインロジックが「何をするか」という純粋な処理に集中できる。
2. `
3. カプセル化: ``など）をSQLクエリ内で自由に使える。これは保守性の観点から非常に大きい。
—
3. 現場で「死なない」コードを書くための注意点
WSFを活用しても、以下のポイントを守らなければ「堅牢」とは言えない。
① データベース連携は「接続文字列」で戦う
`ADODB.Connection`を使う際、接続先をハードコードしてはならない。環境変数や外部の`.ini`ファイルから読み込み、WSFのパラメータとして渡す設計にすべきだ。
② エラーハンドリングの徹底
VBScriptはエラー発生時の挙動が脆い。必ず `On Error Resume Next` を活用し、`Err.Number` をチェックする定型パターンを関数化しておくこと。
Function ExecuteQuery(sql)
On Error Resume Next
objConn.Open “Provider=SQLOLEDB;Data Source=ServerName;…”
If Err.Number <> 0 Then
WScript.Echo “DB接続エラー: ” & Err.Description
WScript.Quit 1
End If
‘ … 処理
End Function
—
4. 最後に：エンジニアとしての矜持
VBScriptは「古い言語」と揶揄されることもある。しかし、OS標準で動作し、追加インストールなしで企業内のインフラを制御できるこの言語のポテンシャルは、現代においても極めて高い。
WSFを用いたこの手法は、「コードを書くこと」と「コードを管理すること」を明確に切り分ける行為だ。
あなたが作成するツールが、誰か他のメンバーに引き継がれたとき、「何がどこにあるか一目瞭然である」こと。それがエンジニアとして、もっとも高潔な仕事のあり方だと私は信じている。
まずは、今の`.vbs`ファイルを`.wsf`にリネームし、定数を`
