なぜ24時間稼働のOutlook監視VBAは数日後に沈黙するのか
基幹システムと連携し、共有メールボックスへ絶え間なく届く伝票メールやアラートを監視・自動処理する――。このようなミッションクリティカルな業務において、最も忌避すべき事象は「プロセスのサイレントフリーズ」と「メモリの線形増大によるクラッシュ（`Out of Memory`）」です。
多くのエンジニアは、VBAがランタイムによってメモリ管理される言語であるという錯覚を抱いています。しかし、実態は大きく異なります。Outlook VBAとは、COM（Component Object Model）サーバーを操作するための薄いラッパーに過ぎません。
その背後には厳格な`IUnknown`インターフェース（`AddRef` / `Release`）に基づく参照カウント方式が存在し、開発者がCOMオブジェクトの寿命を1ビットでも見誤れば、参照カウントは永久にゼロにならず、プロセス空間にゾンビオブジェクトが蓄積され続けます。
本稿では、数日〜数ヶ月のスパンで無人稼働し続けるOutlookにおいて、メモリリークを分子レベルで根絶し、イベントハンドラを安全に制御するためのアーキテクチャを提示します。
—
1. COM参照カウントの深淵：リークが起きる真の理由
ドットチェーンが生成する「名もなきCOMラッパー」
典型的なアンチパターンとして、以下のコードを検証します。
‘ 破滅への第一歩：ドットチェーンによるCOMオブジェクトの暗黙生成
Sub BadPractice()
Dim mailSubject As String
mailSubject = Application.Session.GetDefaultFolder(olFolderInbox).Items(1).Subject
End Sub
この1行の背後で、COMレイヤーでは以下のオブジェクトが自動生成されています。
1. `NameSpace` (`Session`)
2. `Folder` (`GetDefaultFolder(olFolderInbox)`)
3. `Items` コレクション (`.Items`)
4. `MailItem` (`(1)`)
VBAランタイムは、これらの中間COMラッパーに対して`AddRef`を発行します。しかし、明示的なオブジェクト変数にバインドされていないため、スコープを抜けるまで（最悪の場合はプロセスが死ぬまで）ランタイムが`Release`を呼ぶタイミングを制御できません。
長時間のループ処理やイベント駆動ループでこれを繰り返せば、非ページプールおよびヒープ領域は瞬く間に食い潰されます。「1つのドットには1つの明示的変数」。これがCOMプログラミングの絶対律です。
`WithEvents` と循環参照の罠
Outlookのメール受信監視で多用される`WithEvents`。ここに最大の落とし穴があります。
[Outlook Items Collection]
▲ │
(Events) │ (Strong Reference via WithEvents)
│ ▼
[Monitor Class Instance]
`WithEvents`修飾子を付与した変数は、対象のCOM接続ポイント（`IConnectionPoint`）に対してアドバイズ（`Advise`）を行い、内部的にイベントシンクインターフェースを登録します。この結合は強力な参照関係を構築します。
明示的にイベント接続を絶たない限り、親オブジェクト（例：`ThisOutlookSession`やクラスモジュール）が破棄されようとしても、COMサーバー側が参照を掴み続け、デストラクタ（`Class_Terminate`）すら実行されないゾンビ状態に陥ります。
—
2. 破綻なきイベントハンドリングアーキテクチャ
安全な監視システムを構築するために、以下の設計原則を適用します。
1. イベント購読の完全なライフサイクル管理：
起動時に`Advise`し、終了時には必ず逆の`Unadvise`（変数の`Nothing`化）を明示的な順序で行う。
2. 階層化された参照の完全明示化：
`Application` -> `NameSpace` -> `MAPIFolder` -> `Items` の全段階を変数として保持し、逆順で解放する。
3. `Items.ItemAdd` イベントのバッファリングと欠落対策：
大量のメールがミリ秒単位で同時着信した場合、`ItemAdd`は容易にイベントドロップを引き起こす。このため、イベントはトリガーに留め、処理自体は未処理フラグや内部キューを基準にポーリング併用型で設計する。
—
3. 実践コード：24/365稼働に耐えうるメール監視エンジン
それでは、プロダクション環境で耐えうる堅牢な監視クラスの実装に入ります。
クラスモジュールと標準モジュールに分割して構築します。
クラスモジュール：`clsMailMonitor`
監視対象フォルダとイベントシンクをカプセル化し、明示的な初期化（`Initialize`）と終了処理（`TerminateMonitor`）を提供するクラスです。
VERSION 1.0 CLASS
BEGIN
MultiUse = -1 ‘True
END
Attribute VB_Name = “clsMailMonitor”
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False
Option Explicit
‘ ==============================================================================
‘ クラス名: clsMailMonitor
‘ 責務: 指定フォルダの完全なライフサイクル管理および安全なイベントハンドリング
‘ ==============================================================================
‘ イベント受信用変数（最重要：明示的な解放が必要）
Private WithEvents m_Items As Outlook.Items
Attribute m_Items.VB_VarHelpID = -1
‘ 保持するCOMオブジェクト参照（階層順）
Private m_App As Outlook.Application
Private m_NS As Outlook.NameSpace
Private m_Folder As Outlook.MAPIFolder
‘ 状態管理フラグ
Private m_IsRunning As Boolean
Private Sub Class_Initialize()
m_IsRunning = False
End Sub
Private Sub Class_Terminate()
‘ クラスが予期せず破棄される場合でも強制的にリソースを回収する
Call TerminateMonitor
End Sub
”’
”’
”’ 監視対象のOutlook.MAPIFolder
Public Sub Initialize(ByVal targetFolder As Outlook.MAPIFolder)
On Error GoTo ErrHandler
If m_IsRunning Then
Call TerminateMonitor
End If
If targetFolder Is Nothing Then
Err.Raise vbObjectError + 1001, “clsMailMonitor”, “ターゲットフォルダがNothingです。”
End If
‘ ルートから順に参照を固定
Set m_App = Outlook.Application
Set m_NS = m_App.GetNamespace(“MAPI”)
Set m_Folder = targetFolder
‘ Itemsオブジェクトを取得し、イベントシンクを確立
Set m_Items = m_Folder.Items
m_IsRunning = True
Exit Sub
ErrHandler:
Call TerminateMonitor
Err.Raise Err.Number, Err.Source, “初期化に失敗しました: ” & Err.Description
End Sub
”’
”’
Public Sub TerminateMonitor()
On Error Resume Next
‘ 1. イベントシンクの遮断（Unadviseをトリガーさせる）
If Not m_Items Is Nothing Then
Set m_Items = Nothing
End If
‘ 2. 各階層のCOMオブジェクトを末端から解放
If Not m_Folder Is Nothing Then
Set m_Folder = Nothing
End If
If Not m_NS Is Nothing Then
Set m_NS = Nothing
End If
If Not m_App Is Nothing Then
Set m_App = Nothing
End If
m_IsRunning = False
On Error GoTo 0
End Sub
”’
”’
Private Sub m_Items_ItemAdd(ByVal Item As Object)
On Error GoTo ProcessErr
‘ アイテムがMailItem（メールメッセージ）であるか型検証
‘ （ReportItemやMeetingItemなどの別オブジェクトが飛来するリスクを排除）
If TypeOf Item Is Outlook.MailItem Then
Dim oMail As Outlook.MailItem
Set oMail = Item
‘ 実処理の呼び出し
Call ProcessIncomingMail(oMail)
‘ 明示的解放
Set oMail = Nothing
End If
Finalize:
‘ 引数として渡されたCOMオブジェクトの解放
If Not Item Is Nothing Then
Set Item = Nothing
End If
Exit Sub
ProcessErr:
‘ ログ記録などをここで行う
Debug.Print “[ERROR] ItemAdd: ” & Err.Description
Resume Finalize
End Sub
”’
”’
Private Sub ProcessIncomingMail(ByRef oMail As Outlook.MailItem)
‘ ※ここにドットチェーンを排した処理を記述
Debug.Print “検知: ” & oMail.ReceivedTime & ” | ” & oMail.Subject
‘ 【重要】処理後に参照先を操作した場合は都度Saveや適切なフラグ付けを行う
‘ 例: フラグを立てて保存
‘ oMail.UnRead = False
‘ oMail.Save
End Sub
—
標準モジュール：`mod_MemoryOptimization`
Windows APIを導入し、OSレベルでのプロセスメモリの最適化、ならびに監視マネージャーの起動・停止ロジックを実装します。
Option Explicit
‘ ==============================================================================
‘ 外部Windows APIの宣言
‘ ==============================================================================
‘ プロセスのワーキングセット（物理メモリ使用量）を最小化するAPI
Private Declare PtrSafe Function SetProcessWorkingSetSize Lib “kernel32.dll” ( _
ByVal hProcess As LongPtr, _
ByVal dwMinimumWorkingSetSize As LongPtr, _
ByVal dwMaximumWorkingSetSize As LongPtr) As Long
‘ 自プロセスの擬似ハンドルを取得するAPI
Private Declare PtrSafe Function GetCurrentProcess Lib “kernel32.dll” () As LongPtr
‘ システム全体のメモリステータスを取得する構造体とAPI
Private Type MEMORYSTATUSEX
dwLength As Long
dwMemoryLoad As Long
ullTotalPhys As Currency
ullAvailPhys As Currency
ullTotalPageFile As Currency
ullAvailPageFile As Currency
ullTotalVirtual As Currency
ullAvailVirtual As Currency
ullAvailExtendedVirtual As Currency
End Type
Private Declare PtrSafe Function GlobalMemoryStatusEx Lib “kernel32.dll” ( _
ByRef lpBuffer As MEMORYSTATUSEX) As Long
‘ グローバル監視インスタンス
Public g_Monitor As clsMailMonitor
”’
”’
Public Sub StartSystemMonitoring()
If g_Monitor Is Nothing Then
Set g_Monitor = New clsMailMonitor
End If
Dim oNS As Outlook.NameSpace
Dim oTargetFolder As Outlook.MAPIFolder
Set oNS = Application.GetNamespace(“MAPI”)
‘ 受信トレイを取得
Set oTargetFolder = oNS.GetDefaultFolder(olFolderInbox)
‘ 監視開始
g_Monitor.Initialize oTargetFolder
‘ 取得用変数は即座に切断
Set oTargetFolder = Nothing
Set oNS = Nothing
Debug.Print “[SYSTEM] メール監視が正常に初期化されました。”
End Sub
”’
”’
Public Sub StopSystemMonitoring()
If Not g_Monitor Is Nothing Then
g_Monitor.TerminateMonitor
Set g_Monitor = Nothing
Debug.Print “[SYSTEM] メール監視を正常に停止・解放しました。”
End If
‘ 解放後にワーキングセットを刈り込む
Call FlushProcessWorkingSet
End Sub
”’
”’ メモリ断片化（フラグメンテーション）が深刻化する前に定期実行することを推奨。
”’
Public Sub FlushProcessWorkingSet()
On Error Resume Next
Dim hProc As LongPtr
hProc = GetCurrentProcess()
‘ 特殊フラグ (-1, -1) を渡すことで、未使用の物理ページをOSへ回収させる
If SetProcessWorkingSetSize(hProc, -1, -1) <> 0 Then
Debug.Print “[MEMORY] ワーキングセットの刈り込みに成功しました。”
Else
Debug.Print “[MEMORY] ワーキングセットの刈り込みに失敗しました。”
End If
On Error GoTo 0
End Sub
—
4. イベント駆動だけに頼らない「レジリエンス」の獲得
Outlookを常時稼働させるにあたり、`Items.ItemAdd`だけを信頼してはいけません。
1. `ItemAdd` イベントの構造的限界
Outlookは、ネットワーク瞬断からの復帰時やExchangeキャッシュモードの同期時、一括して数十〜数百件のアイテムをローカルに取り込みます。このとき、COMのイベントキューが飽和し、10件受信したにもかかわらず`ItemAdd`が3回しか発火しないという事態が頻発します。
2. 対策：イベントトリガー型「キャッチアップ・ポーリング」の実装
常時ポーリング（タイマーで1秒毎にスキャン等）はリソースの浪費を招きます。堅牢なシステムでは、以下のハイブリッドアプローチを採ります。
[メール受信] ──> [ItemAdd 発火]
│
▼
[未処理メールの存在確認]
│
├─ 対象メールを処理
└─ まだ未処理（既読フラグなし、特定カテゴリなし等）が
フォルダ内に残っていないか「同期スキャン」を実行
これを行えば、仮に3回しかイベントが呼ばれなくても、最初の1回目のハンドラ内で未処理の10件すべてを`Folder.Items.Restrict`で取得して処理を完遂できます。
”’
”’
Private Sub DrainPendingMails()
Dim oTable As Outlook.Table
Dim strFilter As String
‘ 例：未読メールのみをDAV/DASL構文で高速抽出
strFilter = “@SQL=””urn:schemas:httpmail:read”” = 0″
‘ 高速イテレーションには Table オブジェクトを使用する（MailItemを展開しないため最速・低メモリ）
Set oTable = m_Folder.GetTable(strFilter, olHiddenItems)
Do Until oTable.EndOfTable
Dim oRow As Outlook.Row
Set oRow = oTable.GetNextRow()
‘ TableからエントリIDを取得し、必要な時だけMailItem化する
Dim entryID As String
entryID = oRow(“EntryID”)
Dim oMail As Outlook.MailItem
Set oMail = m_NS.GetItemFromID(entryID, m_Folder.StoreID)
‘ ロジック呼び出し
Call ProcessIncomingMail(oMail)
Set oMail = Nothing
Set oRow = Nothing
Loop
Set oTable = Nothing
End Sub
大量のオブジェクトプロパティにアクセスする際、`Folder.Items`を直接ループで回すのは最悪の手法です。アイテム数に比例してメモリ消費が爆発するためです。Outlook 2007以降で提供されている`Outlook.Table`オブジェクトを使用すれば、メモリ上にCOMラッパーを展開せず、レコードセット形式で軽量にスキャンできます。
—
5. 診断と検証：プロセスを外部から監視する
コードを実装したら、自身の端末や検証環境でリソース追跡を行います。タスクマネージャーの「メモリ」列を見るだけでは不十分です。
1. Sysinternals Process Explorer の活用:
- `OUTLOOK.EXE`のプロパティを開き、「Memory」タブの`Virtual Size`と`Private Bytes`を監視します。
- `Working Set`（物理メモリ）はOSによって変動しますが、`Private Bytes`が右肩上がりで増え続けている場合、COM参照の明示的解放漏れによるメモリリークが確実に発生しています。
2. GDIオブジェクト / USERオブジェクトのリーク確認:
- メールにUI操作やインスペクター（Inspector）表示を伴う処理を書いた場合、GDIリソースがリークして10,000個の上限に達し、VBAごとクラッシュすることがあります。プロセスエクスプローラーで`GDI Handles`が定常状態を保っているか確認してください。
—
結論：美学なきCOMの操作は破滅を招く
Outlook VBAは手軽に書ける反面、その実体はC++で組まれた巨大かつ複雑なCOMサブシステムです。
- 1ドット＝1オブジェクトとして変数を割り振ること
- 獲得したポインタは、獲得した逆順で`Nothing`に帰すこと
- `WithEvents`はクラス終了時に必ず明示切断すること
- 大量処理には重厚な`MailItem`の配列ではなく`Table`を用いること
- 定期的にOSのワーキングセットAPIを呼び出し、フットプリントを矯正すること
この5原則を遵守したとき、あなたのOutlook監視エンジンは、どれほど過酷なメールトラフィックに晒されようとも、一切のメモリリークを起こさず静粛に任務を完遂し続けます。レガシーを制する鍵は、徹底したライフサイクルの統御にあるのです。
