【カスタムイベントソース登録】レジストリ直叩きとWSH連携による、プロフェッショナル・イベントログ出力の極意
レガシーシステムの裏側で今もなお静かに、しかし強靭に稼働し続けるVBScript（Visual Basic Scripting Edition）。コンパイル不要の手軽さゆえに「とりあえず動く」コードが量産されがちだが、プロフェッショナルなインフラストラクチャの現場において、スクリプトのロギングは単なる `WScript.Echo` や無機質なテキストファイル出力にとどまるべきではない。
エンタープライズ環境で求められるのは、Windows標準の「イベントビューアー」と完全に統合された監視体制である。今回は、`WScript.Shell` を駆使してWindowsレジストリに独自のイベントソースを刻み込み、アプリケーションログの海から自作スクリプトの足跡を鮮明に浮き上がらせる、極限のロギングアーキテクチャを解説する。
—
1. なぜ「独自イベントソース」が必要なのか？
VBScriptから標準でイベントログを出力する場合、`WScript.Shell` の `LogEvent` メソッドを使うのが最も手軽だ。しかし、この方法には致命的な制限がある。
- イベントソースが固定される: 出力元は常に `WSH` または `WScript` となり、複数のスクリプトが稼働している環境では、どのスクリプトがエラーを吐いたのか判別がつかない。
- カテゴリやメッセージの構造化不足: 運用監視ツール（JP1, System Center, Datadog等）やWindows標準のイベントビューアーのフィルタリングにおいて、送信元（Source）単位でのアラート設定が事実上不可能になる。
これを解決するのが、レジストリへのカスタムイベントソース登録である。
Windowsのイベントログシステムは、レジストリの特定のハイブ（`HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application`）を監視している。ここに独自のキーと値を流し込むことで、イベントビューアーの「ソース」欄に自社システム名やスクリプト名を堂々と表示させることが可能になる。
—
2. アーキテクチャの全体像
実装のステップは以下の通りだ。管理者特権（UAC）が必須となる点に注意してほしい。
1. レジストリ登録フェーズ: `WScript.Shell` の `RegWrite` を用い、Applicationログの下位にカスタムソースのキーと、メッセージ DLL のパス（通常は標準の `eventmsg.dll` を流用）を書き込む。
2. イベント書込フェーズ: 登録したソース名を指定して `LogEvent`（またはWMI経由、あるいはシェル経由）でログを流し込む。
3. ライフサイクル管理: オブジェクトの明示的解放によるメモリリークの根絶。
—
3. 実装コード：レジストリ登録とイベント出力の完全版
以下のスクリプトは、レジストリの操作権限とエラーハンドリングを網羅した、現場でそのまま使える実用コードである。
‘ ==============================================================================
‘ Script Name : CustomEventLogger.vbs
‘ Description : レジストリへのカスタムイベントソース登録と高度なイベントログ出力
‘ Architecture: VBScript 5.8 / Windows Script Host (WSH)
‘ ==============================================================================
Option Explicit
‘ メイン処理の実行
Call Main()
Sub Main()
Dim objShell, strSource, strLogType
strSource = “EnterpriseAutomationEngine” ‘ 独自のイベントソース名
strLogType = “Application”
‘ 1. WScript.Shellのインスタンス生成（オブジェクトのライフサイクル開始）
Set objShell = WScript.CreateObject(“WScript.Shell”)
On Error Resume Next
‘ 2. レジストリへのカスタムイベントソース登録
Call RegisterEventSource(objShell, strSource, strLogType)
If Err.Number <> 0 Then
WScript.Echo “[-] レジストリ登録に失敗しました。管理者権限で実行しているか確認してください。Error: ” & Err.Description
Call ReleaseObjects(objShell)
Exit Sub
End If
‘ 3. カスタムソースを使用したイベントログの書き込み
‘ ※注意: WScript.ShellのLogEventはソース名を直接指定できないため、
‘ 標準出力やWMIを活用するか、あるいはVBScriptからPowerShellをインライン呼び出しするブリッジングが実用的です。
‘ ここではWSH標準の限界を超えるため、WMI (Win32_NTLogEvent) を組み合わせた高度なアプローチをとります。
Call WriteCustomEventViaWMI(strSource, “致命的なバッチ処理エラーが発生しました。トランザクションをロールバックします。”, 1) ‘ 1: Error
On Error GoTo 0
‘ 4. クリーンアップ
Call ReleaseObjects(objShell)
WScript.Echo “[+] カスタムイベントの登録およびログ出力が正常に完了しました。”
End Sub
‘ ——————————————————————————
‘ レジストリにカスタムイベントソースを登録するプロシージャ
‘ ——————————————————————————
Sub RegisterEventSource(ByRef shell, ByVal sourceName, ByVal logType)
Dim regPath
regPath = “HKLM\SYSTEM\CurrentControlSet\Services\EventLog\” & logType & “\” & sourceName & “\”
‘ イベントメッセージファイルとしてシステムの標準DLLを指定（自作DLLがない場合の定石）
‘ TypesSupportedで許可するログの種別（Error, Warning, Information）を指定 (値: 7 = 0x07 全て許可)
shell.RegWrite regPath & “EventMessageFile”, “C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll”, “REG_SZ”
shell.RegWrite regPath & “TypesSupported”, 7, “REG_DWORD”
End Sub
‘ ——————————————————————————
‘ WMIを使用してカスタムイベントソース名でログを書き込むプロシージャ
‘ (WScript.ShellのLogEventの制約を回避するプロフェッショナル・テクニック)
‘ ——————————————————————————
Sub WriteCustomEventViaWMI(ByVal sourceName, ByVal message, ByVal eventType)
Dim objWMIService, inputParameters, outParams
Set objWMIService = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2”)
Dim colEvents : Set colEvents = objWMIService.Get(“Win32_NTLogEvent”)
‘ Win32_NTLogEventのCreateメソッドを利用
‘ 引数: Logfile, RecordNumber, EventCode, EventType, Category, Message, TargetUser
‘ ※ 注意: OSのセキュリティポリシーによりWMI経由のイベント作成は制限される場合があるため、
‘ 実運用ではPowerShellへの処理委譲（橋渡し）も視野に入れること。
Dim objInParam
Set objInParam = colEvents.Methods_(“Create”).InParameters.SpawnInstance_
objInParam.Logfile = “Application”
objInParam.SourceName = sourceName
objInParam.EventCode = 1001
objInParam.EventType = eventType ‘ 1:Error, 2:Warning, 4:Information
objInParam.Message = message
‘ 実行
objWMIService.ExecMethod “Win32_NTLogEvent”, “Create”, objInParam
‘ オブジェクトの明示的破棄
Set objInParam = Nothing
Set colEvents = Nothing
Set objWMIService = Nothing
End Sub
‘ ——————————————————————————
‘ メモリ最適化：オブジェクトの明示的解放
‘ ——————————————————————————
Sub ReleaseObjects(ByRef obj)
If IsObject(obj) Then
Set obj = Nothing
End If
End Sub
—
4. チーフアーキテクトが指摘する「現場の罠」と最適化指針
A. オブジェクトのライフサイクル管理とメモリリーク
VBScriptのCOMコンポーネント（特に `WScript.Shell` や `WbemScripting.SWbemLocator`）は、スコープを抜けるまでメモリ上に居座り続ける特性がある。
特に長時間のループ処理や、常駐型のタスクスケジューラからキックされるスクリプトにおいて、`Set obj = Nothing` による明示的な参照切断を行わない設計は、メモリリークの温床となる。ガベージコレクションのタイミングに依存するな。リソースの解放はコードの行儀としてプロが徹底すべき鉄則である。
B. レジストリ権限（UAC）の壁
`HKLM`（HKEY_LOCAL_MACHINE）配下の書き換えには、当然ながら管理者特権が必要となる。一般ユーザー権限で動作するタスクスケジューラからこのスクリプトを実行した場合、`Permission denied`（エラー800a0046）が即座に発生する。
運用設計の段階で、実行コンテキスト（NT AUTHORITY\SYSTEM または特権管理者アカウント）を厳密に定義し、タスクスケジューラの「最高特権で実行」にチェックを入れることを忘れてはならない。
C. WMI経由の限界とPowerShellブリッジの選択肢
前述のコードではWMI（`Win32_NTLogEvent`）を用いたカスタムソース出力を示したが、Windowsのバージョン（特にWindows Server 2012以降のセキュリティ強化版）によっては、WMI経由のイベント生成が制限されているケースがある。
もし純粋なVBScriptの枠組みで書き込みエラーに直面した場合は、以下のように `WScript.Shell` からPowerShellのコマンドレット（`Write-EventLog`）を1行叩く「ブリッジ・パターン」を採用するのが、実務上最も堅牢かつスマートな解決策である。
‘ PowerShellをインラインで呼び出して確実にカスタムソースでログを書く極秘テクニック
Sub WriteEventViaPowerShell(ByVal sourceName, ByVal message)
Dim shell, cmd
Set shell = CreateObject(“WScript.Shell”)
‘ ソースが存在しない場合のエラーを回避しつつ、PowerShellでイベント書き込み
cmd = “powershell -Command “”if (![Diagnostics.EventLog]::SourceExists(‘” & sourceName & “‘)) { [Diagnostics.EventLog]::CreateEventSource(‘” & sourceName & “‘, ‘Application’) }; Write-EventLog -LogName Application -Source ‘” & sourceName & “‘ -EventId 1001 -Message ‘” & message & “‘ -EntryType Error”””
shell.Run cmd, 0, True ‘ 0: ウィンドウ非表示, True: 完了まで同期待機
Set shell = Nothing
End Sub
—
総括
レガシーな技術と侮るなかれ。VBScriptの根底にあるWindowsアーキテクチャへの深い理解があれば、最新の監視プラットフォームともシームレスに連携する堅牢なシステムを構築できる。
レジストリを直接制御し、イベントビューアーの景色を書き換える――この領域に踏み込んだ瞬間から、あなたの書くスクリプトは単なる「自動化のオマケ」ではなく、インフラストラクチャの一部としての風格をまとい始める。
コードの隅々にまで意図を宿せ。それが、プロフェッショナル・エンジニアの矜持である。
