【PowerPoint VBA】無人自動化の「闇」を照らす。イベントログ直結型・死活監視アーキテクチャの極意
業務自動化の現場において、PowerPoint VBAは「脆弱なGUIオートメーション」の代名詞として語られがちだ。しかし、それはVBAが悪いのではない。エラーを握りつぶし、闇の中で沈黙するコードが悪いのだ。
無人稼働するサーバーやPCでプレゼンテーションの一括変換（PDF化など）を行っているとき、ディスク容量不足やファイルロック、あるいは権限喪失が発生した際、あなたは「ログファイル」をわざわざ見に行っているのか？
それでは遅い。真のエンタープライズ環境では、WindowsイベントログというOS標準の監視網に、VBAから直接「叫び」を上げる必要がある。今回は、堅牢な監視モジュールを実装するためのアーキテクチャを伝授する。
—
1. なぜ「MsgBox」や「テキストログ」では不十分なのか
初心者は `On Error Resume Next` でエラーを無視し、あるいは `Print #1` でテキストファイルにログを吐く。だが、考えてみてほしい。
- テキストログの脆弱性: ディスク容量不足でシステムが停止しているとき、ログファイルへの追記もまた失敗する。
- 可視性の欠如: 運用担当者が個別のテキストファイルを巡回するのは非効率だ。
- イベントログの強み: WindowsイベントログはOSレベルのサービスであり、ログ収集サーバー（SIEM等）との親和性が極めて高い。
VBAからOSのイベントログへ直接書き込むには、Windows APIを叩くか、`WScript.Shell` を利用するのが正攻法だ。今回は、最も保守性が高く、かつ追加DLLを必要としない `WScript.Shell` を介した `eventcreate` コマンドの実行 という設計を採用する。
—
2. 堅牢な監視モジュールの実装コード
このモジュールは、プレゼンテーション処理における「例外処理の要塞」となる。
‘ —————————————————————————
‘ モジュール名: LoggerModule
‘ 機能: Windowsイベントログへの直接書き込みによる監視・通知機能
‘ —————————————————————————
Option Explicit
‘ イベントログにメッセージを送信するプロシージャ
Public Sub WriteToEventLog(ByVal msg As String, Optional ByVal eventType As String = “ERROR”)
Dim shell As Object
Dim cmd As String
‘ WScript.Shellを使用してOSコマンドを実行
‘ /T: イベントタイプ(ERROR/WARNING/INFORMATION)
‘ /ID: イベントID (1000はカスタムエラー用として定義)
‘ /L: ログの種類 (APPLICATION)
‘ /SO: ソース名 (VBA_Automation_PPT)
Set shell = CreateObject(“WScript.Shell”)
‘ コマンド文字列の構築
cmd = “eventcreate /T ” & eventType & ” /ID 1000 /L APPLICATION /SO VBA_Automation_PPT /D “”” & msg & “”””
‘ コマンド実行 (ウィンドウを表示せず、終了を待機)
On Error Resume Next
shell.Run cmd, 0, True
On Error GoTo 0
Set shell = Nothing
End Sub
‘ —————————————————————————
‘ 利用例: プレゼンテーション処理の実装パターン
‘ —————————————————————————
Public Sub ProcessPresentation(ByVal filePath As String)
Dim pptApp As Object
Dim pptPres As Object
On Error GoTo ErrorHandler
‘ 処理開始
Set pptApp = CreateObject(“PowerPoint.Application”)
Set pptPres = pptApp.Presentations.Open(filePath)
‘ ここにPDF変換などのメインロジックが入る
‘ …
pptPres.Close
pptApp.Quit
Exit Sub
ErrorHandler:
‘ 発生したエラーの全容をイベントログへ飛ばす
Dim errorMsg As String
errorMsg = “プレゼンテーション処理中に例外発生” & vbCrLf & _
“File: ” & filePath & vbCrLf & _
“Error: ” & Err.Number & ” – ” & Err.Description
Call WriteToEventLog(errorMsg)
‘ 最後にオブジェクトをクリーンアップし、プロセスを確実に終了させる
On Error Resume Next
If Not pptPres Is Nothing Then pptPres.Close
If Not pptApp Is Nothing Then pptApp.Quit
Set pptPres = Nothing
Set pptApp = Nothing
‘ 再度エラーを発生させ、呼び出し元へ通知するか、ここで止めるかは設計次第
Err.Clear
End Sub
—
3. プロフェッショナルが守るべき3つの掟
① 常に「ゾンビプロセス」を想定せよ
PowerPointの `Application.Quit` が失敗した際、メモリ上にプロセスが残り続けることがある。特に無人サーバーでは、これが積み重なるといずれ「リソース不足」で全システムが共倒れする。`ErrorHandler` 内での確実な `Set = Nothing` は必須だ。
② 権限の分離を考慮する
イベントログへの書き込みには管理者権限が必要な場合がある。ツールを実行するWindowsユーザーが、該当のイベントソースに対して書き込み権限を持っているか、あるいは「イベントログの管理者」グループに含まれているかを、インフラ担当者と事前に握っておくこと。
③ ログの粒度を最適化する
すべての処理をログに吐いてはいけない。イベントログは「異常」を検知するためのものだ。正常終了をすべて記録すると、本当に注目すべき「エラー」がノイズに埋もれる。ログを出すのは、システムが自律的に回復できない致命的な障害のみに絞るのが、運用のプロフェッショナルとしての矜持だ。
—
最後に：自動化とは「信頼」を積み上げること
コードを書いて終わりではない。「何が起きたか」を誰よりも早く知ることが、自動化システムの運用保守における最大の防衛線となる。
このモジュールをあなたのプロジェクトに組み込めば、深夜の障害対応で右往左往する事態は確実に減るはずだ。次は、このイベントログをトリガーにして、SlackやTeamsへ自動通知を飛ばすボットと組み合わせると良いだろう。
さあ、コードを書いて、静寂を支配しよう。
