枯れた技術を研ぎ澄ます：WMI `Win32_NTLogEvent` を用いた「真」のイベント監視術
VBScriptは死んでなどいない。現代のクラウドネイティブな監視ツールが肥大化し、エージェントがメモリを喰らい尽くす中で、OS標準のWSH（Windows Script Host）という極めて軽量な実行環境は、依然として「最後の砦」としての価値を失っていない。
今回は、イベントログの海から、業務を停止させる特定のノイズのみを抽出する、メモリ効率を極めた監視スクリプトを構築する。単なるコードの羅列ではなく、システムアーキテクトが意識すべき「リソースの最適化」という視点で論じる。
—
1. WMIクエリの深淵：`Win32_NTLogEvent` の罠
多くのエンジニアが陥る罠が、`Select From Win32_NTLogEvent` を無条件で叩くことだ。これは、数万件のイベントレコードをすべてメモリ上のオブジェクトに展開しようとする自殺行為である。
WMIクエリは、サーバーサイドでフィルタリング（Where句）を完結させることが鉄則だ。
正しいクエリの設計思想
- プロパティ指定: “ を避け、`EventCode, SourceName, Message` など必要なカラムのみを射影する。
- インデックスの意識: WMIの内部プロバイダはクエリを最適化するが、Where句で指定するプロパティの順序と属性がパフォーマンスを左右する。
—
2. 実践：高効率イベント抽出スクリプト
以下のコードは、単にログを出すだけではない。COMオブジェクトを明示的に解放し、メモリリークを徹底的に排除した、長期常駐監視にも耐えうる設計だ。
‘ — WMIイベント監視ツール: Win32_NTLogEvent 抽出エンジン —
Option Explicit
Dim objWMIService, colLoggedEvents, objEvent
Dim strQuery
Dim strComputer: strComputer = “.”
‘ 監視対象の定義（定数化して保守性を確保）
Const TARGET_EVENT_ID = 1000
Const TARGET_SOURCE = “Application Error”
‘ WMI接続: セキュリティコンテキストを意識し、名前空間を明示
Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)
‘ クエリ最適化: 必要な項目のみを射影し、サーバーサイドでフィルタリング
strQuery = “SELECT EventCode, SourceName, Message, TimeGenerated ” & _
“FROM Win32_NTLogEvent ” & _
“WHERE EventCode = ” & TARGET_EVENT_ID & _
” AND SourceName = ‘” & TARGET_SOURCE & “‘”
Set colLoggedEvents = objWMIService.ExecQuery(strQuery)
‘ 列挙処理
If colLoggedEvents.Count > 0 Then
For Each objEvent In colLoggedEvents
‘ ログ出力と通知処理
WScript.Echo “Detected: ” & objEvent.EventCode & ” [” & objEvent.SourceName & “]”
‘ ここにCDO.Messageによるメール通知処理などを実装
Next
Else
WScript.Echo “No events found.”
End If
‘ メモリ最適化: 参照を明示的に解放 (重要)
Set colLoggedEvents = Nothing
Set objWMIService = Nothing
—
3. シニアエンジニアが守るべき3つの掟
① オブジェクトの「無慈悲な解放」
VBScriptのガベージコレクタを信用してはならない。`Set obj = Nothing` を怠ることは、小規模なスクリプトでは無視できても、タスクスケジューラで頻繁に起動するプロセスでは、ハンドルリークやメモリ断片化の温床となる。
② 日付形式のパース処理
`Win32_NTLogEvent` の `TimeGenerated` プロパティは、DMTF形式（`YYYYMMDDHHMMSS…`）という独自の文字列で返される。これをそのまま扱うのではなく、`SWbemDateTime` オブジェクトを使用して、ローカルタイムに変換する処理を挟むのがプロの矜持だ。
③ エラーハンドリングの極意
`On Error Resume Next` をただの「逃げ」に使ってはいけない。
On Error Resume Next
‘ 危険な処理
If Err.Number <> 0 Then
‘ イベントログへの書き込みや、管理用ログへのエラー詳細出力
Err.Clear
End If
On Error GoTo 0
このブロック単位の制御こそが、予期せぬ外部要因（WMIサービスの停止や権限不足）によるスクリプトのクラッシュを防ぐ。
—
4. 最後に：レガシーを「レガシー」で終わらせないために
新しい技術に飛びつくのは簡単だ。しかし、システムの基盤を支えるのは、OSが提供するAPIを深く理解し、そのリソースを枯渇させない「謙虚なコード」である。
このスクリプトは、あなたの環境の「ノイズ」を排除し、真に重要なエラーのみを浮き彫りにするだろう。もし、より大規模なシステム連携が必要であれば、このVBScriptをコンソールアプリケーションのトリガーとして使い、後ろで強力なバックエンド処理を回せば良い。
道具の性能を最大限に引き出すのは、いつだってその道具の仕様を骨の髄まで理解したエンジニア自身だ。健闘を祈る。
