現場の沈黙を許すな：VBAからWindowsイベントログへ直接打刻する「死活監視」の極意
多くのVBAエンジニアは、エラーが発生すると`MsgBox`を出し、あるいはログファイルに`Print #`で追記する手法で満足している。しかし、無人稼働するバックエンドサーバーや、深夜に一括処理を回す自動化ボットにおいて、それは「死」に等しい。なぜなら、そのログはサーバーの奥底で埋もれ、監視システムがその悲鳴を拾い上げることは永遠にないからだ。
真のエンタープライズアーキテクトは、アプリケーションの境界線を超え、OSの心臓部である「Windowsイベントログ」に直接刻印する。今回は、PowerPoint VBAからWindows APIを呼び出し、システムログとしてエラーを永続化する、堅牢な監視モジュールの実装を伝授する。
—
1. なぜ「イベントログ」なのか？
ファイルベースのログは、以下のリスクを抱えている。
- ディスクフルによる書き込み失敗: ログ自体が書けないという本末転倒。
- 権限喪失: ファイルシステムへの書き込み権限が剥奪された瞬間、デバッグ手段が消失する。
- 中央管理の欠如: 複数台の自動化サーバーを運用する場合、ログの散逸は致命的である。
Windowsイベントログに書き込むことは、OSの標準的な監視プロセス（System Center, Zabbix, Datadog等）に「このアプリは死んだ」と直接告げることと同義だ。
—
2. 実装の心臓部：Win32 APIの活用
VBA単体ではイベントログへのアクセス権限を持たないため、`advapi32.dll` を動的に呼び出す。以下のモジュールは、PowerPointが例外を吐いた際、OSレベルでイベントを記録するための基盤となる。
‘ EventLogReporter.bas
Option Explicit
If Win64 Then
Private Declare PtrSafe Function ReportEvent Lib “advapi32.dll” Alias “ReportEventW” _
(ByVal hEventLog As LongPtr, ByVal wType As Integer, ByVal wCategory As Integer, _
ByVal dwEventID As Long, ByVal lpUserSid As LongPtr, ByVal wNumStrings As Integer, _
ByVal dwDataSize As Long, ByVal lpStrings As LongPtr, ByVal lpRawData As LongPtr) As Long
Private Declare PtrSafe Function RegisterEventSource Lib “advapi32.dll” Alias “RegisterEventSourceW” _
(ByVal lpUNCServerName As LongPtr, ByVal lpSourceName As LongPtr) As LongPtr
Private Declare PtrSafe Function DeregisterEventSource Lib “advapi32.dll” Alias “DeregisterEventSource” _
(ByVal hEventLog As LongPtr) As Long
End If
‘ イベントログにエラーを刻印するラッパー関数
Public Sub LogToWindowsEvent(ByVal strMessage As String, Optional ByVal eventID As Long = 1001)
Dim hEventLog As LongPtr
Dim sourceName As String
sourceName = “VBA_Automation_Engine”
hEventLog = RegisterEventSource(0, StrPtr(sourceName))
If hEventLog <> 0 Then
‘ 1: Error, 4: Information
ReportEvent hEventLog, 1, 0, eventID, 0, 1, 0, VarPtr(StrPtr(strMessage)), 0
DeregisterEventSource hEventLog
End If
End Sub
—
3. オブジェクトのライフサイクルを管理せよ
PowerPointの自動化において、最も多いクラッシュ原因は「ゾンビ化したCOMオブジェクト」だ。`Application` や `Presentation` オブジェクトを解放し損ねると、メモリリークが発生し、やがてディスクI/Oのレイテンシが悪化、最終的にファイル破損を招く。
確実にキャッチし、ログを書き、クリーンアップする「防御的プログラミング」のテンプレートがこれだ。
Public Sub ProcessPresentation(ByVal filePath As String)
Dim pptApp As PowerPoint.Application
Dim pres As PowerPoint.Presentation
On Error GoTo ErrorHandler
Set pptApp = New PowerPoint.Application
Set pres = pptApp.Presentations.Open(filePath, ReadOnly:=msoTrue)
‘ ここに変換処理やロジックを記述
‘ …
pres.Close
pptApp.Quit
‘ 明示的な解放
Set pres = Nothing
Set pptApp = Nothing
Exit Sub
ErrorHandler:
‘ 発生したエラーをOSに通知
LogToWindowsEvent “Error in ” & filePath & ” | Code: ” & Err.Number & ” | Desc: ” & Err.Description
‘ リソースの強制解放（ゾンビ化防止）
If Not pres Is Nothing Then pres.Close
If Not pptApp Is Nothing Then pptApp.Quit
Set pres = Nothing
Set pptApp = Nothing
‘ 必要に応じて呼び出し元へ再スロー
Err.Raise Err.Number, “ProcessPresentation”, Err.Description
End Sub
—
4. シニアエンジニアのための極限の知見
1. イベントソースの事前登録: 本番環境では、PowerShellを用いて `New-EventLog -LogName Application -Source “VBA_Automation_Engine”` を一度だけ実行しておくこと。そうしなければ、`ReportEvent` は権限エラーで失敗する可能性がある。
2. メモリの断片化回避: 長時間稼働する自動化サーバーでは、`DoEvents` を極力減らし、オブジェクトの生成・破棄のサイクルを最小化すること。`PowerPoint.Application` は重いオブジェクトであるため、可能であれば使い回しを検討すべきだが、メモリリークを完全に防げない場合は、処理数ごとにプロセスを再起動する「プロセス・リサイクル」戦略を推奨する。
3. レガシーとの共存: 64bit/32bitの混在環境では、必ず `#If Win64` を使ってABIを分離すること。ここを疎かにすると、`ReportEvent` を呼び出した瞬間にホストプロセスが沈黙する。
最後に
自動化とは、単にコードを書くことではない。「失敗したときに、いかにして管理者に気づかせるか」という、システム運用の物語を設計することだ。VBAという古き良き言語であっても、OSの深部と対話する術を知っていれば、それは堅牢なエンタープライズの武器へと変貌する。
次回の運用保守で、あなたの書いたログがイベントビューアーに静かに、しかし確実に刻まれていることを願う。健闘を祈る。
