【実務・中級編】【イベントログ出力】WScript.Shell.LogEvent を用いたWindowsイベントログへのカスタム監査ログ書き込み – VBScript (Visual Basic Scripting Edition)解析バイブル

【イベントログ出力】WScript.Shell.LogEvent を用いたWindowsイベントログへのカスタム監査ログ書き込み

こんにちは。チーフアーキテクトの私だ。
現場でVBScriptによる業務自動化スクリプトやバッチ処理を組んでいる君たちなら、一度はこう思ったことがあるはずだ。

「エラー発生時に `WScript.Echo` や `MsgBox` を出しても、無人のサーバー上では誰も気づかない」
「テキストファイルへの独自ログ出力は、ディスク容量の圧迫やログローテーションの管理が面倒だ」
「統合運用監視ツール（ZabbixやSCOMなど）と連携させたいのに、標準出力だけでは監視の網から漏れてしまう」

こうした現場の課題を一刀両断し、エンタープライズレベルの堅牢性を手に入れるための特効薬が、`WScript.Shell.LogEvent` によるWindowsイベントログへの直接書き込みだ。

今回は、単なる「APIの使い方」の解説で終わらせない。オブジェクトのライフサイクル、COMの挙動、そして実運用で絶対に踏み抜いてはならない「設計の罠」まで、プロの知見を余すところなく伝授しよう。

—

1. なぜ `LogEvent` なのか？ ── 簡易ファイルロギングの限界

多くの開発者は、エラーハンドリングの際に以下のようなコードを書く。

‘ 【アンチパターン】テキストファイルへの直接追記
Sub WriteLog(msg)
Dim fso, ts
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set ts = fso.OpenTextFile(“C:\Logs\error.log”, 8, True) ‘ 8 = ForAppending
ts.WriteLine Now & ” – ” & msg
ts.Close
Set ts = Nothing
Set fso = Nothing
End Sub

このアプローチは一見シンプルだが、本番環境では以下の致命的な問題（Technical Debt）を抱える。

1. ファイルロック競合: 複数スクリプトが同時実行された際、ファイル書き込み権限で `Permission Denied (エラー 70)` が発生し、肝心のエラーログが抜け落ちる。
2. 監視コスト: 監視エージェントにテキストファイルのtail監視を設定する必要があり、文字コード（UTF-8/Shift-JIS）の差異で文字化けを起こす。
3. セキュリティとアクセス権: ログファイルの保存先ディレクトリに対するACL（アクセスコントロールリスト）の管理が必要になり、権限不足で書き込めなくなる。

これに対し、Windowsの「アプリケーション」イベントログに書き込む `LogEvent` を使えば、OSのイベントログ機構が排他制御、タイムスタンプ、セキュリティ監査をすべて肩代わりしてくれる。運用監視ツールとの親和性も圧倒的に高い。

—

2. `WScript.Shell.LogEvent` の仕様と設計哲学

`LogEvent` メソッドの構文は非常にシンプルだ。

object.LogEvent(intType, strMessage [, strTarget])

しかし、この引数の選択を誤ると、監視担当者から「ノイズばかりで使い物にならないログ」と烙印を押される。各パラメータの正確な意味を押さえよう。

引数 `intType`（ログレベル）の正しい使い分け

> アーキテクトの知見:
> 開発者は「すべてをエラー（`1`）」にしたがるが、それは「オオカミ少年」現象を招き、真の障害アラートが埋もれる原因となる。
> – リトライで復旧したエラー $\rightarrow$ `WARNING (2)`
> – キャッチされずにスクリプトが堕ちた致命傷 $\rightarrow$ `ERROR (1)`
> – バッチの正常終了 $\rightarrow$ `SUCCESS (0)`
> この3つを厳格に峻別せよ。

—

3. 【プロダクションコード】堅牢なイベントロギング・ラッパー

それでは、実際の現場でそのまま組み込める、保守性と安全性を極限まで高めたプロダクションコードを提示する。
エラーハンドリング（`On Error Resume Next`）を適切にカプセル化し、ログ書き込み自体が失敗してもスクリプト全体がクラッシュしない設計にしている。

‘ ==============================================================================
‘ スクリプト名: EnterpriseLogger.vbs
‘ 概要: Windowsイベントログへ構造化されたカスタム監査ログを出力するラッパー
‘ 著作権: (c) 202X Your Corporation. All Rights Reserved.
‘ ==============================================================================

Option Explicit

‘ — テスト実行用のメインルーチン —
Call Main()

Sub Main()
Dim logger
Set logger = New EventLogger

‘ アプリケーション名のプレフィックスを定義
logger.SourceNane = “AutomatedBatchEngine”

‘ 1. 処理開始のログ（情報）
logger.Log 0, “バッチ処理を開始しました。対象モジュール: DataSync_v2”

On Error Resume Next
‘ 【シミュレーション】何らかの処理エラーを発生させる
Dim result
result = 1 / 0 ‘ 0除算エラー

If Err.Number <> 0 Then
‘ 2. 異常終了時のエラーログ
logger.Log 1, “致命的なエラーを検出し中断しました。エラー番号: ” & Err.Number & ” / 説明: ” & Err.Description
Err.Clear
Else
‘ 3. 正常終了ログ
logger.Log 0, “バッチ処理が正常に完了しました。”
End If

Set logger = Nothing
End Sub

‘ ==============================================================================
‘ クラス名: EventLogger
‘ 目的: WScript.Shell を安全にラップし、イベントログ出力の抽象化を提供する
‘ ==============================================================================
Class EventLogger
Private m_Shell
Private m_SourceName

‘ 初期化 (Constructor)
Private Sub Class_Initialize()
Set m_Shell = CreateObject(“WScript.Shell”)
‘ デフォルトのソース名
m_SourceName = “VBScriptApplication”
End Sub

‘ 終了処理 (Destructor)
Private Sub Class_Terminate()
Set m_Shell = Nothing
End Sub

‘ プロパティ: イベントソース名（必要に応じて変更可能）
Public Property Let SourceNane(ByVal val)
m_SourceName = val
End Property

‘ メソッド: イベントログ出力実行コア
‘ intLevel: 0(Success), 1(Error), 2(Warning)
‘ strMessage: ログ本文
Public Sub Log(ByVal intLevel, ByVal strMessage)
Dim formattedMessage

‘ プレフィックスとメッセージを結合し、どのスクリプトからの発信か特定しやすくする
formattedMessage = “[” & m_SourceName & “] ” & strMessage

‘ WScript.Shell.LogEvent の実行
‘ 注意: リモートマシン（strTarget）を指定することも可能だが、
‘ 権限やネットワークの観点から原則としてローカル（引数省略）を推奨する。
On Error Resume Next
m_Shell.LogEvent intLevel, formattedMessage

If Err.Number <> 0 Then
‘ イベントログへの書き込み自体が失敗した場合のフォールバック
‘ 標準エラー出力（CScript環境の場合）に緊急避難させる
WScript.StdErr.WriteLine “CRITICAL: イベントログへの書き込みに失敗しました – ” & Err.Description
Err.Clear
End If
On Error GoTo 0
End Sub
End Class

—

4. アーキテクトが教える「運用の罠」とベストプラクティス

このコードを導入するにあたり、現場のエンジニアが必ず直面する「落とし穴」と、その対策を共有しておこう。

罠1: イベントソースの制限と権限

`WScript.Shell.LogEvent` を用いた場合、イベントビューアの「Windows ログ」>「アプリケーション」には、ソース名として `WSH`（Windows Script Host） が記録される。
個別のアプリケーション名（例: `MyPayrollBatch` など）をイベントソースの「固有の名前」としてイベントビューアに登録したい場合は、本来レジストリへの書き込み（イベントカテゴリの登録）が必要になる。
しかし、一般的な業務自動化の現場では権限管理が厳しいため、上記コードのようにメッセージの先頭に `[ApplicationName]` というプレフィックスを付与し、イベントビューアの検索・フィルタ機能で絞り込む手法が最も現実的かつ安全である。

罠2: CScript と WScript の実行ホストの選択

イベントログへの出力を行うバッチ処理や自動化スクリプトは、必ず `cscript.exe` で実行するようにタスクスケジューラや呼び出し元バッチファイルを設計せよ。
`wscript.exe`（GUIホスト）で実行すると、万が一エラーや標準出力へのフォールバックが発生した際に、ダイアログボックスがポップアップし、無人サーバーの処理がそこで永久にフリーズ（ハングアップ）する。

:: 模範的なタスク実行バッチファイルの記述
@echo off
cscript.exe //Nologo “C:\Automation\Scripts\EnterpriseLogger.vbs”
exit /b %ERRORLEVEL%

罠3: ログの過剰出力（スパム化）によるイベントログの肥大化

ループ処理の中で毎回 `LogEvent` を呼び出す愚行は避けたほうがいい。イベントログサービス（EventLog）に負荷がかかり、ディスク領域が圧迫されるだけでなく、本当に重要なログが上書きされて消えてしまう。
「処理の開始」「重要なマイルストーン」「例外発生時」のみに絞り、ループ内の詳細なトレースは従来通りテキストファイル（あるいはデバッグ用の一時ログ）に出力するなど、ハイブリッドな設計をとるのがプロの選択だ。

—

総括

`WScript.Shell.LogEvent` は、レガシーと揶揄されがちなVBScriptを、エンタープライズの監視網に直結させるための強力な武器だ。
今回解説したカプセル化クラスと設計思想を取り入れれば、あなたの作る自動化ツールは「野良スクリプト」から、運用担当者に愛される「堅牢なインフラコンポーネント」へと昇華する。

現場の信頼を勝ち取るアーキテクチャを、今すぐ君の手で実装してほしい。