【イベントログ出力】WScript.Shell.LogEvent を用いたWindowsイベントログへのカスタム監査ログ書き込み
レガシーシステムの維持、あるいはスタンドアロンなタスクスケジューラによるバッチ自動化の現場において、「ログをどこに残すか」は永遠の課題である。テキストファイル（`FileSystemObject`による`.log`出力）は手軽だが、ディスク容量の圧迫、ローテーション機構の自前実装、そして何よりも統合監視システム（SIEMやZabbix、System Center等）からの監視のしにくさという致命的な弱点を抱える。
Windows環境におけるインフラストラクチャの王道は、やはり Windowsイベントログ（Windows Event Log） への統合だ。
今回は、VBScript（WSH）の `WScript.Shell` オブジェクトが持つ `LogEvent` メソッドに焦点を当てる。サードパーティ製のDLLや複雑なPowerShellラッパーに頼らず、OS標準機能だけでアプリケーションイベントログにカスタム監査ログを刻み込む極限の知見を、実戦的なコードと共に解説する。
—
1. なぜ `WScript.Shell.LogEvent` なのか？
VBScriptからイベントログを書き込む手法としては、古くは `WScript.Shell` の `LogEvent` があり、より高度な方法としては WMI (`WMI` の `Win32_NTLogEvent`) や COMコンポーネント経由のAPI呼び出しが存在する。
しかし、業務自動化の現場において、余計な依存関係（Dependencies）を増やすことは「悪」である。`WScript.Shell` はあらゆるWindowsクライアントおよびサーバー（Windows Server 2003から最新の Windows Server / Windows 11に至るまで）でネイティブに稼働する。
`LogEvent` の仕様と限界を理解する
`LogEvent` メソッドの構文は以下の通りだ。
objShell.LogEvent intSeverity, strMessage [, strTarget]
- `intSeverity` (ログレベル):
- `0` : SUCCESS（成功）
- `1` : ERROR（エラー）
- `2` : WARNING（警告）
- `4` : INFORMATION（情報）
- `8` : AUDIT_SUCCESS（監査成功 – レジストリ設定に依存）
- `16` : AUDIT_FAILURE（監査失敗 – レジストリ設定に依存）
- `strMessage` (出力メッセージ): イベントビューアの「詳細」または「全般」に記録される文字列。
- `strTarget` (リモートコンピュータ名): 省略時はローカルマシン。リモート書き込みには権限とRPCの開放が必要なため、実務ではほぼ使用しない。
> 【アーキテクトの警告】
> `LogEvent` は手軽な反面、イベントソース名が強制的に 「WSH」 (Windows Script Host) に固定される。独自のイベントソース（例: `MyCorp_Automation_Engine` など）をイベントビューアのツリーに刻みたい場合は、純粋な `LogEvent` ではなく、レジストリへのイベントソース登録とWMI/PowerShellの併用が必要となる。しかし、単一のバッチ処理の成否や致命的な例外を「アプリケーションログ」に集約するという目的においては、`WSH` ソースであっても運用監視上は十分機能する。
—
2. 【実践】堅牢性を極めたイベントログ出力スクリプト
以下のコードは、単にログを出力するだけでなく、実行時例外の捕捉、メモリ最適化（COMオブジェクトの明示的解放）、および構造化されたメッセージフォーマットを実装したプロダクション品質のテンプレートである。
Option Explicit
‘ ==============================================================================
‘ Script Name: WriteAuditLog.vbs
‘ Description: WScript.Shell.LogEvent を用いた堅牢なイベントログ監査スクリプト
‘ Architecture Note:
‘ – エラーハンドリングを徹底し、ログ出力失敗によるスクリプトのクラッシュを防ぐ
‘ – オブジェクトはスコープ終了前に必ず Nothing を代入してメモリリークを防止
‘ ==============================================================================
‘ メイン処理の実行
Call Main()
Sub Main()
Dim objShell
Dim lngResult
‘ 1. オブジェクトのインスタンス化
On Error Resume Next
Set objShell = CreateObject(“WScript.Shell”)
If Err.Number <> 0 Then
‘ シェルオブジェクトすら取得できない極限状態でのフォールバック
WScript.Echo “CRITICAL: WScript.Shell could not be instantiated. Error: ” & Hex(Err.Number)
WScript.Quit 2
Sub_Exit:
End If
On Error GoTo 0
‘ 2. 監査ログデータの構築（システム名、プロセスID、処理名を付与）
Dim strTaskName, strMessage, intLogLevel
strTaskName = “MonthlyBillingBatch”
intLogLevel = 1 ‘ 1: ERROR, 4: INFORMATION
‘ 監視ツールがパースしやすいように構造化テキストで出力する
strMessage = “[Task:” & strTaskName & “] [User:” & CreateObject(“WScript.Network”).UserName & “] ” & _
“Batch execution failed due to database timeout at Step 3.”
‘ 3. イベントログへの書き込み実行
‘ ここではエラーレベル（1）として書き込む例
lngResult = WriteEventLog(objShell, 1, strMessage)
‘ 4. 結果に応じた終了コードの返却
If lngResult Then
WScript.Echo “Event log successfully written.”
WScript.Quit 0
Else
WScript.Echo “Failed to write event log.”
WScript.Quit 1
End If
‘ 5. オブジェクトの明示的解放（メモリ最適化）
Set objShell = Nothing
End Sub
‘ ——————————————————————————
‘ Function: WriteEventLog
‘ Arguments:
‘ ByRef sh – WScript.Shell インスタンス
‘ ByVal sev – ログレベル (0:Success, 1:Error, 2:Warning, 4:Information)
‘ ByVal msg – 記録するメッセージ文字列
‘ Returns: Boolean (True:成功, False:失敗)
‘ ——————————————————————————
Function WriteEventLog(ByRef sh, ByVal sev, ByVal msg)
Dim bSuccess
bSuccess = False
On Error Resume Next
‘ LogEvent実行
sh.LogEvent sev, msg
If Err.Number = 0 Then
bSuccess = True
Else
‘ イベントログ書き込み権限がない場合などのエラーをトレース
‘ ※標準エラー出力等へのフォールバック
WScript.Echo “LogEvent Error: ” & Err.Description & ” (Code: ” & Hex(Err.Number) & “)”
bSuccess = False
End If
On Error GoTo 0
WriteEventLog = bSuccess
End Function
—
3. チーフアーキテクトが教える「現場の知見」とアンチパターン
VBScriptによるWSH実行環境の運用において、数々の現場を見てきた中で陥りがちな罠と、それを回避するための知見を共有する。
① オブジェクトのライフサイクルと「ゾンビプロセス」の回避
VBScriptのガベージコレクタは、スクリプト終了時に自動的にCOMオブジェクトを解放する。しかし、常駐型のバッチや、タスクスケジューラから短時間で何重にも起動されるスクリプトにおいて、`Set obj = Nothing` を怠ることはメモリリークやハンドルリークの温床となる。
特に `WScript.Shell` はレジストリやプロセス空間へのフックを持つため、用が済んだら即座に `Nothing` を代入し、参照カウントをデクリメントする習慣を徹底すべきである。
② イベントログの「ノイズ問題」と監視設計
`LogEvent` を用いる際、すべてのデバッグメッセージを `INFORMATION (4)` や `ERROR (1)` で流し込むのは最悪のアンチパターンだ。
- 監視ツール（Zabbix等）は「ERROR」や「WARNING」の発生回数でアラートを飛ばすよう設定されていることが多い。
- 許容される例外や、単なる処理の通過点（「〜処理を開始しました」など）を安易にログへ書き込むと、オペレータがアラート疲れを起こし、真の障害を見落とす原因になる。
- 原則として、自動化スクリプトが「異常終了（リトライ不可能なエラー）」した瞬間のみ `ERROR (1)` を書き込む。 正常終了時は、テキストログに詳細を任せ、イベントログを汚さない設計がプロフェッショナルである。
③ 権限の壁（UACとセキュリティコンテキスト）
Windows Vista以降、ユーザーアカウント制御（UAC）が導入された。
タスクスケジューラから「最上位の特権で実行する」にチェックが入っていない状態で、特定のセキュリティ制限がかけられたイベントログや、カスタムイベントカテゴリへ書き込もうとすると、`LogEvent` はエラーを吐かずに無視されるか、実行時エラーを引き起こす。
バッチ処理でイベントログを活用する場合は、必ず実行ユーザーが「イベントログに書き込む権限（Administrators または Event Log Readers / 適切なセキュリティポリシー）」を持っていることを担保し、タスクの実行権限を厳密に設計すること。
—
4. 総括
VBScriptはレガシーな言語として扱われがちだが、OSの深部（Win32 APIやWSHコンポーネント）にダイレクトに触れられるその特性は、インフラストラクチャの自動化において今なお強烈な武器となる。
`WScript.Shell.LogEvent` は、複雑なセットアップを必要とせず、Windowsの監視エコシステムへスクリプトの生存確認とエラーを統合するための最もシンプルかつ強力な手段である。本記事で示したエラーハンドリングと構造化の知見を実装に落とし込み、貴社の運用監視体制をワンランク上の信頼性へと引き上げてほしい。
