Outlook VBAの深淵：無限ループを封殺する「UserProperties」による受信監視の極意
業務自動化の現場において、Outlookの`NewMailEx`イベントや`Items.ItemAdd`イベントを用いた自動処理は、一見すると「魔法の杖」だ。しかし、その魔法はしばしば、自身の生成したメールを自ら受信して再処理するという「無限再帰の悪夢」を招く。
多くの初心者は、件名のプレフィックス（”FW:”など）で判定しようとする。だが、それはあまりに脆い。件名はクライアント側の言語設定や転送ルールで容易に改変され、システムは崩壊する。
本稿では、シニアエンジニアが到達すべき、Outlookのオブジェクトモデルを汚さずに「処理済み」を刻印する`UserProperties`を用いた堅牢な実装を解説する。
—
1. なぜ「件名判定」ではいけないのか
システムアーキテクトとして断言する。文字列一致による条件分岐は、技術的負債の最たるものだ。
- 国際化の壁: Outlookの言語設定が変われば、プレフィックスは変わる。
- 透過性の欠如: ユーザーが手動で件名を書き換えた瞬間、自動化ロジックは沈黙するか、あるいは暴走する。
我々が求めるべきは、「メールデータそのものに紐付き、かつ外部から干渉されないメタデータ」である。それが`UserProperty`だ。
—
2. カスタムプロパティによる状態管理の実装
Outlookの各アイテムには`UserProperties`コレクションが存在する。これはMAPIプロパティとしてメール本体に埋め込まれるため、サーバー間を移動しても、ローカルのキャッシュが消えても「処理済み」という事実は消失しない。
実装コード：無限ループを回避する転送処理
‘ ———————————————————
‘ 受信監視イベントの核心：無限ループを物理的に封殺する
‘ ———————————————————
Private Sub Application_NewMailEx(ByVal EntryIDCollection As String)
Dim objItem As Object
Dim objMail As MailItem
Dim processedProp As UserProperty
‘ EntryIDCollectionは複数のIDが含まれる可能性があるためカンマで分割する
Dim entryIDs() As String
entryIDs = Split(EntryIDCollection, “,”)
For Each id In entryIDs
Set objItem = Session.GetItemFromID(id)
‘ メールアイテムのみを対象とする（予定表通知などを弾く）
If TypeOf objItem Is MailItem Then
Set objMail = objItem
‘ 【極意】カスタムプロパティが存在するか確認
Set processedProp = objMail.UserProperties.Find(“IsProcessedBySystem”)
If processedProp Is Nothing Then
‘ プロパティがなければ未処理とみなす
Call ProcessMail(objMail)
‘ 処理済みフラグを付与（保存）
Set processedProp = objMail.UserProperties.Add(“IsProcessedBySystem”, olText)
processedProp.Value = “True”
objMail.Save
End If
End If
‘ 厳密なメモリ解放（循環参照の防止）
Set objMail = Nothing
Set objItem = Nothing
Next id
End Sub
Private Sub ProcessMail(ByVal mail As MailItem)
‘ 転送処理等のロジックをここに記述
‘ このメソッド内で再度メールを送信しても、フラグがあるためループしない
Dim fwdMail As MailItem
Set fwdMail = mail.Forward
fwdMail.Recipients.Add “archive@example.com”
fwdMail.Send
Set fwdMail = Nothing
End Sub
—
3. シニアエンジニアが意識すべき「メモリと安定性」の境界線
オブジェクトの明示的解放（Finalizationの強制）
VBAのガベージコレクションは非常に遅い。`Application_NewMailEx`のようなイベントハンドラ内でオブジェクトを生成し続けると、メモリリークは確実に発生する。
- ループ内での`Set obj = Nothing`は必須の儀式である。
- `Session.GetItemFromID`を使用する際は、必ず`Namespace`オブジェクトをキャッシュし、毎回`GetNamespace(“MAPI”)`を呼び出すような無駄なコストを避けること。
Windows APIによる「待機」の誘惑を断つ
自動化処理において、`Sleep` APIを多用して処理を待機させようとする設計を見かけるが、これは悪手だ。Outlookのメインスレッドをブロックすることは、UIのフリーズとタイムアウトを招く。
非同期処理が必要な場合は、`Application.OnTime`（Outlookには存在しないため、`WinAPI`の`SetTimer`あるいは`Task`の活用）を検討すべきだが、基本的にはイベントドリブンで完結させるのが最も低コストである。
—
4. 結び：レガシーを制御下に置くために
VBAはレガシーではない。適切に設計されたVBAは、Windows環境において極めて強力な「糊（Glue）」となる。
今回紹介した`UserProperties`による管理は、単なるループ防止策を超え、将来的なシステム統合のための「ステータス管理基盤」となる。
システム運用において、「何が起きたか」だけでなく「何が処理されたか」をデータとして保持すること。 これこそが、障害対応を深夜の緊急呼び出しから解放する唯一の道である。
貴方のコードが、次の世代のエンジニアに「なぜこうなっているのか」を説明する際、このフラグが雄弁に語ることを期待している。
