【WSH実行制限ポリシー検証】レジストリ監視によるVBScriptブロック状態の事前自動診断
レガシーシステムの維持において、VBScriptとWSH（Windows Script Host）の挙動制御は、インフラストラクチャ管理者にとって永続的な関心事である。近年のセキュリティ強化トレンド、特にマルウェアの侵入経路としてのスクリプト言語悪用を防ぐため、グループポリシー（GPO）やレジストリ直叩きによるWSHの無効化（`Enabled = 0` または `DisallowRun` の設定）は、エンドポイントセキュリティの標準プラクティスとなっている。
だが、現場のエンジニアリングにおいて発生する致命的な課題は別にある。
「WSHがブロックされている環境でVBScriptを実行した際、不親切なOS標準エラー（または完全な無音の無視）が発生し、エンドユーザーが混乱する」という点だ。
本稿では、VBScriptランタイムが完全に停止させられる前に、自らが置かれた実行環境のレジストリポリシーを精査し、ブロック状態を検知した時点で「優雅に（Graceful）かつ安全に」自プロセスを終了させる、極限まで最適化された事前自動診断アーキテクチャを解説する。
—
1. WSH実行制限のメカニズムとレジストリ構造
Windows環境において、WSHの実行可否は主に以下のレジストリハイブによって制御される。
1. ユーザーごとの設定 (HKEY_CURRENT_USER)
`Software\Microsoft\Windows Script Host\Settings\Enabled`
2. マシン全体の設定 (HKEY_LOCAL_MACHINE)
`Software\Policies\Microsoft\Windows Script Host\Settings\Enabled`
この `Enabled` 値（DWORD）が `0` に設定されている場合、`cscript.exe` および `wscript.exe` はスクリプトの実行を拒絶する。また、プロセス起動時にOSのポリシーエンジンがこれを検知するため、VBScriptのコード内から通常のファイルI/OやWMIクエリを発行する前に、レジストリの直接参照による事前チェックが必須となる。
ここで重要となるのは、「VBScriptの実行そのものが禁止されている環境で、どうやってその状態を安全に読み取るか」というパラドックスの解決である。
—
2. オブジェクトのライフサイクルとWSHランタイムの極限最適化
VBScriptを実行する際、メモリリークの防止とCOMオブジェクトの適切な解放（`Set obj = Nothing`）は基本中の基本だが、WSH自体のポリシー検証においては、`WScript.Shell` オブジェクトのインスタンス化コストを最小限に抑え、例外ハンドリングのスコープを極限まで狭める必要がある。
以下に、レジストリの `TrustPolicy` および `Enabled` 状態を動的に検証し、ブロックされている場合はGUI/CLIに応じた親切なメッセージを出して安全にイグジットするプロダクション品質のコードを示す。
実装コード：`WshPolicyGuard.vbs`
‘ ==============================================================================
‘ Script Name: WshPolicyGuard.vbs
‘ Description: WSH/VBScript Execution Policy Pre-Diagnostic Engine
‘ Architecture: Chief Architect Grade VBScripting
‘ ==============================================================================
Option Explicit
‘ メイン処理の実行
Call Main()
Sub Main()
Dim lngPolicyStatus
‘ 1. レジストリからWSHの実行ポリシーを強制取得
lngPolicyStatus = GetWshExecutionPolicy()
‘ 2. ポリシー状態に基づく分岐処理
Select Case lngPolicyStatus
Case 0 ‘ 無効化されている (Enabled = 0)
Call NotifyAndExit( _
“【実行ブロック検知】” & vbCrLf & _
“この環境では、セキュリティポリシーによりVBScript/WSHの実行が制限されています。” & vbCrLf & _
“システム管理者にお問い合わせください。”, _
vbCritical, _
“WSH Policy Guard – Execution Denied” _
)
Case 1 ‘ 有効 (Enabled = 1 またはキーが存在しないデフォルト状態)
‘ ここに本来の業務ロジックを展開する
Call ExecuteBusinessLogic()
Case -1 ‘ 読み取りエラー（権限不足やレジストリ破損）
Call NotifyAndExit( _
“【診断エラー】” & vbCrLf & _
“WSHの実行ポリシーを読み取ることができませんでした。アクセス権限を確認してください。”, _
vbExclamation, _
“WSH Policy Guard – Read Error” _
)
End Select
End Sub
‘ ——————————————————————————
‘ Function: GetWshExecutionPolicy
‘ Purpose: HKLMおよびHKCUのWSH Settingsを走査し、実行可否を判定する
‘ Return: 0 (Disabled), 1 (Enabled), -1 (Error)
‘ ——————————————————————————
Function GetWshExecutionPolicy()
Dim objShell, strRegPathHKLM, strRegPathHKCU, lngValue
On Error Resume Next
Set objShell = CreateObject(“WScript.Shell”)
If Err.Number <> 0 Then
‘ WScript.Shellすら生成できない環境（完全ロックダウン状態）
GetWshExecutionPolicy = 0
Exit Function
End If
‘ レジストリパスの定義
strRegPathHKLM = “HKLM\Software\Policies\Microsoft\Windows Script Host\Settings\Enabled”
strRegPathHKCU = “HKCU\Software\Microsoft\Windows Script Host\Settings\Enabled”
lngValue = 1 ‘ デフォルトは有効と仮定
‘ 優先度高：HKLM (グループポリシー) の確認
Err.Clear
lngValue = objShell.RegRead(strRegPathHKLM)
If Err.Number = 0 Then
If lngValue = 0 Then
GetWshExecutionPolicy = 0
Set objShell = Nothing
Exit Function
End If
End If
‘ 優先度中：HKCU (ユーザー設定) の確認
Err.Clear
lngValue = objShell.RegRead(strRegPathHKCU)
If Err.Number = 0 Then
If lngValue = 0 Then
GetWshExecutionPolicy = 0
Set objShell = Nothing
Exit Function
End If
End If
On Error GoTo 0
‘ 明示的なオブジェクト解放（メモリ最適化）
Set objShell = Nothing
‘ ブロックされていなければ有効 (1) を返す
GetWshExecutionPolicy = 1
End Function
‘ ——————————————————————————
‘ Sub: NotifyAndExit
‘ Purpose: ホスト環境（CUI/GUI）を自動判別し、安全にメッセージを表示して終了
‘ ——————————————————————————
Sub Sub NotifyAndExit(strMessage, intIcon, strTitle)
Dim strHostFullName
strHostFullName = LCase(WScript.FullName)
‘ Cscript環境の場合は標準エラー出力へ、Wscriptの場合はポップアップを表示
If InStr(strHostFullName, “cscript.exe”) > 0 Then
WScript.StdErr.WriteLine strTitle & vbCrLf & strMessage
Else
MsgBox strMessage, intIcon, strTitle
End If
‘ プロセスを安全に終了
WScript.Quit 1603 ‘ ERROR_INSTALL_FAILUREに準じた異常終了コード
End Sub
‘ ——————————————————————————
‘ Sub: ExecuteBusinessLogic
‘ Purpose: ポリシーチェックを通過した後に実行される本丸の処理
‘ ——————————————————————————
Sub ExecuteBusinessLogic()
‘ 実際のシステム連携やファイル操作コードをここに記述
If InStr(LCase(WScript.FullName), “cscript.exe”) > 0 Then
WScript.StdOut.WriteLine “[INFO] WSH Execution Policy verified. Running business logic…”
End If
‘ [ここにメインの自動化処理を実装]
End Sub
—
3. チーフアーキテクトの知見：なぜこの実装が必要なのか？
1. フォールバックの多重化
GPOによる制限（`HKLM`）とローカルユーザー設定（`HKCU`）の両方を監視対象に含めることで、企業内ドメイン環境からスタンドアロンのワークステーションまで、あらゆるトポロジに対応する。
2. ホスト環境の動的抽象化
運用自動化スクリプトは、タスクスケジューラからのバックグラウンド実行（`cscript`）と、オペレーターによる手動実行（`wscript`）の両方で使われる。`WScript.FullName` を解析して出力インターフェースを切り替える設計により、バックグラウンド実行時にダイアログがポップアップして処理がフリーズする（いわゆる「ゾンビプロセス化」）を防いでいる。
3. 終了コードの標準化
単に `WScript.Quit` するのではなく、`1603` などの明確なエラーコードを返すことで、System Center (SCCM) やAnsible、PowerShell等の上位オーケストレーションツールから呼び出された際にも、異常検知を確実なものにしている。
レガシー技術とモダンなセキュリティ要件が交差する現場において、VBScriptを「ただ動かす」時代は終わった。堅牢なガードを纏わせ、自律的に環境を診断するコードこそが、現代のインフラストラクチャを支えるエンジニアリングの極みである。
