【WSH実行制限ポリシー検証】レジストリ直叩きでVBScriptの「ブロック死」をスマートに回避する極限の防壁設計
開発現場で自動化スクリプトを配布した際、エンドユーザーの端末で突然 `Windows Script Host は無効にされています。` という冷酷なダイアログが表示され、頭を抱えた経験はないだろうか。
セキュリティが厳格化された昨今の企業インフラにおいて、WSH（Windows Script Host）やVBScriptの実行は、グループポリシー（GPO）やレジストリによってデフォルトで無効化されているケースが多々ある。
プロとして許されないのは、「実行権限がない環境でスクリプトを走らせ、ユーザー環境で予期せぬエラー（あるいは完全な沈黙）を発生させること」だ。スクリプトがクラッシュしてから原因究明に時間を溶かすのは、自動化エンジニアとして最も非効率なアプローチである。
今回は、スクリプトの起動直後に自身の稼働環境がWSHブロック対象になっていないかをレジストリ（TrustPolicy）から自律的に診断し、未然に美しく安全終了（Graceful Exit）させるためのプロダクションコードを伝授する。
—
なぜ「実行時エラー」を待ってはいけないのか
初学者がやりがちなアンチパターンは、WSHが無効化された環境でVBScriptを直接実行し、OSが吐き出すダイアログに処理を委ねることだ。
しかし、このアプローチには致命的な欠点がある。
1. ユーザーに不親切: 専門知識のない業務担当者がパニックを起こし、ヘルプデスクに無駄なチケットが起票される。
2. サイレント実行時の完全な闇: タスクスケジューラやバックグラウンドバッチ経由で走らせた場合、エラーダイアログすら表示されずにプロセスが沈黙（ゾンビ化）し、ログにも何も残らない。
プロのアーキテクトが取るべき設計は「自己防衛」だ。
処理の1行目でレジストリを静かに覗き、ポリシーの検閲をくぐり抜けられる状態であるかを自ら検証する。門前払いすべき環境であれば、誰にも迷惑をかけず、親切な業務エラーメッセージを残して优雅にプロセスを消滅させる。これが堅牢な自動化ツールの絶対条件である。
—
診断の核心：WSHを制限するレジストリの正体
WindowsにおけるWSHの有効/無効は、主に以下のレジストリキーで制御されている。
- パス: `HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\` または `HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\`
- 値の名前: `Enabled` （DWORD値）
- `0` : 無効（ブロック状態）
- `1` （または値が存在しない）: 有効
※企業環境では、グループポリシー（GPO）によって `DisallowRun` やポリシー用のレジストリパスが強制されている場合もあるが、大元のWSHエンジン自体の生死は上記の `Enabled` フラグ、および全体の実行ポリシー（TrustPolicy）が鍵を握る。
今回は、最も確実かつ安全にWSHの稼働ステータスを判定するため、WMI（Windows Management Instrumentation）の `StdRegProv` クラスを活用するアプローチを採用する。外部のコマンドプロセスの呼び出し（`WScript.Shell` の `RegRead`）は、権限昇格やセキュリティソフトの誤検知を誘発するため、VBScriptネイティブかつセキュアなWMI経由のレジストリ走査がベストプラクティスとなる。
—
【プロダクションコード】WSH実行制限・事前自動診断スクリプト
以下のコードを `.vbs` ファイルの先頭（すべての業務ロジックの実行前）に配置してほしい。
‘ ==============================================================================
‘ Script Name: WSH_Policy_Guard.vbs
‘ Description: WSH実行制限ポリシーをレジストリから事前診断し、安全に終了する防壁モジュール
‘ Author: Enterprise Automation Architect
‘ ==============================================================================
Option Explicit
‘ メイン処理の実行
Call Main()
Sub Main()
‘ 1. 実行環境の事前バリデーション（WSH有効性チェック）
If Not CheckWshExecutionPolicy() Then
‘ ブロックされている場合は、ユーザーに親切な案内を出して即座に安全終了
MsgBox “【実行環境エラー】” & vbCrLf & _
“お使いのPC環境では、セキュリティポリシーにより” & vbCrLf & _
“VBScript (WSH) の実行が制限されています。” & vbCrLf & _
“システム管理者にお問い合わせください。”, _
vbCritical + vbOKOnly, “自動化ツール・セキュリティガード”
WScript.Quit(1)
End If
‘ 2. ポリシーチェックを通過した安全な環境でのみ、本来の業務ロジックを実行
Call ExecuteBusinessLogic()
End Sub
‘ ——————————————————————————
‘ 機能: レジストリを検証し、WSHが有効化されているかを判定する
‘ 戻り値: Boolean (True = 実行可能, False = ブロック中)
‘ ——————————————————————————
Function CheckWshExecutionPolicy()
Dim oReg, sKeyPath, sValueName, iValue
Const HKEY_CURRENT_USER = &H80000001
Const HKEY_LOCAL_MACHINE = &H80000002
On Error Resume Next
‘ WMIのレジストリプロバイダ接続（ローカルマシン）
Set oReg = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv”)
If Err.Number <> 0 Then
‘ WMI自体が無効化されている極端な環境へのフォールバック（保守的な安全策として許可）
CheckWshExecutionPolicy = True
Exit Function
End If
On Error GoTo 0
sKeyPath = “Software\Microsoft\Windows Script Host\Settings”
sValueName = “Enabled”
‘ まず HKEY_CURRENT_USER を確認（ユーザーポリシー優先）
oReg.GetDWORDValue HKEY_CURRENT_USER, sKeyPath, sValueName, iValue
‘ 値が存在し、かつ 0 (無効) の場合
If Err.Number = 0 And Not IsNull(iValue) Then
If iValue = 0 Then
CheckWshExecutionPolicy = False
Exit Function
End If
End If
‘ 次に HKEY_LOCAL_MACHINE を確認（マシンポリシー）
oReg.GetDWORDValue HKEY_LOCAL_MACHINE, sKeyPath, sValueName, iValue
If Err.Number = 0 And Not IsNull(iValue) Then
If iValue = 0 Then
CheckWshExecutionPolicy = False
Exit Function
End If
End If
‘ 制限設定が見つからない、または有効（1）の場合は実行可能と判定
CheckWshExecutionPolicy = True
End Function
‘ ——————————————————————————
‘ 機能: 本来の業務自動化ロジック（ここに実処理を記述）
‘ ——————————————————————————
Sub ExecuteBusinessLogic()
‘ — ここから下に実際のファイル操作やDB連携のコードを記述する —
MsgBox “WSHポリシーチェックを正常に通過しました。” & vbCrLf & _
“業務ロジックを実行します。”, vbInformation, “実行中”
‘ 例: 処理成功の終了コード
WScript.Quit(0)
End Sub
—
コードのアーキテクチャ解説：なぜこの設計が「プロフェッショナル」なのか
1. `Option Explicit` の強制
変数の宣言漏れによる暗黙のバグ（Typoによる予期せぬ挙動）を完全に封じ込めている。プロダクションコードにおいてこれを外すことは論外である。
2. WMI `StdRegProv` の採用による堅牢性
VBScript標準の `WScript.Shell` のレジストリ読み取りは、キーが存在しない場合に実行時エラー（トラップ困難な場合がある）を発生させやすい。WMI経由であれば、存在しないキーへのアクセスもメソッドの戻り値と `Err` オブジェクトでスマートにハンドリングできる。
3. HKCUとHKLMの二重走査
Windowsのポリシー評価順序（ユーザー設定がマシン設定を上書きする挙動）を考慮し、ローカルユーザーとローカルマシンの両方を上から順に監査する精密な設計にしている。
4. 安全な終了コードの返却 (`WScript.Quit`)
単に処理を中断するだけでなく、エラー時は `1`、正常時は `0` という標準的な終了コード（Exit Code）をOSに返している。これにより、Jenkinsやタスクスケジューラ、上位のPowerShellバッチからこのVBScriptを呼び出した際も、成否の判定が極めて容易になる。
—
アーキテクトからの最終インサイト
現場のエンジニアから「なぜか動かない」という問い合わせを受けたとき、コードの構文ばかりに目を向けてはならない。「コードが走る土壌（環境）が整っているか」をスクリプト自身に最初に疑わせる――このメタ認知的なアプローチこそが、サポート工数を激減させ、ツール自体の信頼性を担保する秘訣である。
インフラの制約に屈するのではなく、制約をコード側で優雅に検知し、適切なメッセージで身を引く。この「スマートな防壁」をあなたの自動化ポートフォリオの標準装備にしてほしい。
