VBScriptを掌握する極限の知見：環境変数を起点としたマルチ環境自動切替アーキテクチャ
レガシーシステムの深部、あるいは厳格なエンタープライズの自動化レイヤーにおいて、VBScript（Visual Basic Scripting Edition）は今なお不可欠なインフラストラクチャの一部として稼働し続けている。
だが、多くの現場で見過ごされているアンチパターンがある。それは、環境（開発・検証・本番）ごとにスクリプトのソースコードそのものを書き換えたり、ハードコーディングされた設定ファイルを都度手動で配置したりするという、極めてプリミティブで脆弱な運用手法だ。
真に堅牢なシステム運用において、コードの変更はリスクでしかない。スクリプトは不変（Immutable）であり、動作する環境の差異は実行基盤の環境変数から動的に検知・解決されるべきである。
今回は、WSH（Windows Script Host）の`WScript.Shell.Environment`を極限まで活用し、OSの環境変数から動的に実行環境を判定。接続先データベース、APIエンドポイント、ログ出力先を一瞬で切り替える、プロダクション品質のマルチ環境対応アーキテクチャを解説する。
—
1. WSH環境変数オブジェクトの深層とメモリ管理の鉄則
VBScriptから環境変数を取得する場合、多くの開発者は無意識にプロセス空間の変数のみを参照しがちである。しかし、WSHの`WScript.Shell`が提供する`Environment`コレクションは、スコープを明示的に指定することで、システム全体の構成管理を極めて優位に進めることができる。
コレクションのスコープ
- `Process`: 現在のプロセスおよび継承された環境変数。
- `User`: 現在ログオンしているユーザーの環境変数（レジストリ `HKCU\Environment`）。
- `System`: マシン全体の環境変数（レジストリ `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment`）。
- `Volatile`: セッション固有の揮発性変数（主にターミナルサービス環境で使用）。
マルチ環境切替においては、セキュリティと権限分離の観点から、OSのSystemまたはUserレイヤーに設定された `APP_ENV`（または `RUN_MODE`）キーを読み取る設計が最も堅牢となる。
さらに、VBScriptのメモリ管理において、COMコンポーネント（`WScript.Shell` など）のライフサイクル制御を怠ることは、ハングアップやメモリリークの温床となる。ガベージコレクションに依存せず、使用後は必ず `Nothing` を代入して明示的に解放するのが、シニアアーキテクトの最低限の作法である。
—
2. 実装コード：マルチ環境対応オーケストレーション・スクリプト
以下のコードは、開発（DEV）、検証（STG）、本番（PROD）の各環境を環境変数から自動判定し、それに紐づく設定をカプセル化して安全に処理を実行するプロダクションクオリティのVBScriptテンプレートである。
‘ ==============================================================================
‘ Script Name : MultiEnvDispatcher.vbs
‘ Description : OS環境変数に基づく動的環境切替と堅牢なリソース管理
‘ Architecture: Chief Architect Verified
‘ ==============================================================================
Option Explicit
‘ メイン処理の実行
Main
Sub Main()
Dim wshShell, envType, config
Set wshShell = CreateObject(“WScript.Shell”)
On Error Resume Next
‘ 1. 環境変数の取得 (System環境変数から “APP_ENV” を取得。フォールバックとしてProcessも走査)
envType = UCase(Trim(wshShell.Environment(“System”)(“APP_ENV”)))
If envType = “” Then
envType = UCase(Trim(wshShell.Environment(“Process”)(“APP_ENV”)))
End If
‘ デフォルトフォールバック（未定義時は安全のためDEVとみなす）
If envType = “” Then
envType = “DEV”
End If
‘ 2. 環境に応じた設定オブジェクト（Dictionary）の構築
Set config = LoadConfiguration(wshShell, envType)
If Err.Number <> 0 Then
WScript.Echo “[FATAL ERROR] 設定のロードに失敗しました: ” & Err.Description
Call Cleanup(wshShell, config)
WScript.Quit(1)
End If
On Error GoTo 0
‘ 3. 実行ログの出力（環境の整合性確認）
WScript.Echo “========================================”
WScript.Echo ” 実行環境検知: ” & config.Item(“ENV_NAME”)
WScript.Echo ” 接続先DB : ” & config.Item(“DB_SERVER”)
WScript.Echo ” 出力先パス: ” & config.Item(“LOG_PATH”)
WScript.Echo “========================================”
‘ 4. ビジネスロジックの呼び出し（環境設定を引数として渡す）
ExecuteBusinessLogic config
‘ 5. 厳格なメモリ解放
Call Cleanup(wshShell, config)
WScript.Quit(0)
End Sub
‘ ——————————————————————————
‘ 設定プロバイダ（環境変数ごとにパラメータをマッピング）
‘ ——————————————————————————
Function LoadConfiguration(ByRef shell, ByVal envName)
Dim dict
Set dict = CreateObject(“Scripting.Dictionary”)
‘ 共通設定
dict.Add “APP_NAME”, “EnterpriseBatchProcessor”
dict.Add “ENV_NAME”, envName
Select Case envName
Case “PROD”
‘ 本番環境パラメータ
dict.Add “DB_SERVER”, “prod-db.internal.net”
dict.Add “DB_NAME”, “ProdCoreDB”
dict.Add “LOG_PATH”, “\\fs-prod\logs\batch\”
dict.Add “DEBUG_MODE”, False
Case “STG”
‘ 検証（ステージング）環境パラメータ
dict.Add “DB_SERVER”, “stg-db.internal.net”
dict.Add “DB_NAME”, “StgCoreDB”
dict.Add “LOG_PATH”, “\\fs-stg\logs\batch\”
dict.Add “DEBUG_MODE”, True
Case “DEV”
‘ 開発環境パラメータ
dict.Add “DB_SERVER”, “localhost\SQLEXPRESS”
dict.Add “DB_NAME”, “DevCoreDB”
dict.Add “LOG_PATH”, “C:\Work\Logs\”
dict.Add “DEBUG_MODE”, True
Case Else
‘ 未知の環境が指定された場合の例外スロー
Err.Raise 9999, “LoadConfiguration”, “無効な環境変数が指定されています: ” & envName
End Select
Set LoadConfiguration = dict
End Function
‘ ——————————————————————————
‘ メインのビジネスロジック（環境依存のない抽象化された処理）
‘ ——————————————————————————
Sub ExecuteBusinessLogic(ByRef config)
‘ ここに実際のデータベース接続やファイル処理を記述
WScript.Echo “[” & config.Item(“APP_NAME”) & “] 処理を開始します…”
If config.Item(“DEBUG_MODE”) = True Then
WScript.Echo “[DEBUG] デバッグモードが有効です。詳細ログを出力します。”
End If
‘ 擬似的な処理
WScript.Echo “Target DB: ” & config.Item(“DB_SERVER”) & “.” & config.Item(“DB_NAME”)
WScript.Echo “[” & config.Item(“APP_NAME”) & “] 処理が正常に完了しました。”
End Sub
‘ ——————————————————————————
‘ リソースのクリーンアップ（メモリリーク防止の極意）
‘ ——————————————————————————
Sub Cleanup(ByRef shell, ByRef config)
If Not IsEmpty(config) Then
config.RemoveAll
Set config = Nothing
End If
If Not IsNull(shell) Then
Set shell = Nothing
End If
End Sub
—
3. チーフアーキテクトが指摘する「実運用における罠とベストプラクティス」
このアーキテクチャを現場に投入する際、以下の3点を遵守しなければならない。
① 権限昇格と環境変数のスコープ不一致
Windowsにおいて、タスクスケジューラやサービス経由でVBScriptを実行する場合、「最高特権で実行する」にチェックが入っていると、ローカルユーザー（User）の環境変数が引き継がれない現象が発生する。
必ずOSのシステム環境変数（System）側に `APP_ENV` を定義するか、バッチファイル（`.bat` / `.cmd`）のラッパー層で明示的に環境変数をインジェクトする設計にすること。
② ラッパーバッチによる二重担保
純粋な `.vbs` を直接叩かせるのではなく、以下のような環境変数インジェクト用のラッパーバッチを用意するのが、現場の運用保守性を劇的に向上させる。
@echo off
setlocal
REM — ラッパー層で明示的に環境変数を強制する場合 —
REM set APP_ENV=PROD
cscript //nologo “%~dp0MultiEnvDispatcher.vbs”
endlocal
exit /b %errorlevel%
③ エラーハンドリングの隠蔽化を防ぐ
`On Error Resume Next` はVBScriptの構造上、例外制御に不可欠だが、これを乱用するとバグの特定が困難になる。上記コードのように、環境変数の取得や設定構築といった「障害ポイント」の直近でのみスコープを絞って適用し、異常時は速やかに `Err.Raise` でプロセスを非正常終了（Exit Code > 0）させること。これにより、上位のジョブ管理システム（JP1やWindowsタスクスケジューラ）が異常を正確に検知できるようになる。
—
結び
VBScriptはレガシーな技術と揶揄されることがある。だが、その背後にあるCOMの挙動、メモリモデル、そしてOSアーキテクチャの本質を理解していれば、モダンなスクリプト言語に劣らぬ堅牢でエレガントなシステムを構築可能である。
環境変数を制する者は、デプロイの恐怖を制する。本稿の知見が、あなたの管理するシステム基盤の自動化を次のステージへと引き上げる契機となることを期待する。
