Outlook VBAを掌握する極限の知見：送信トレイを監視し障害をねじ伏せる「自動再送エラーリカバリシステム」
レガシーシステムの最前線において、Outlook VBAは単なる「定型業務の自動化ツール」ではない。それは、基幹システムとエンドユーザーを繋ぐ最後の砦であり、時には脆弱なネットワークインフラの不確実性を補うための「極限のミドルウェア」として機能しなければならない。
日常業務の中で最もビジネスインパクトが大きい障害の一つが、「送信ボタンを押したものの、ネットワークの一瞬の瞬断やVPNのタイムアウトによって送信トレイ（Outbox）に幽閉されたメール」である。ユーザーは送信完了と誤認し、重要な通知や受発注データがロストする。
今回は、Outlookの「送信トレイ」を完全に掌握し、送受信エラーを検知・捕捉した上で、ネットワークの死活監視を挟みながらトランザクションを完遂させる「堅牢なエラーリカバリシステム」の設計思想と実装コードを公開する。
—
1. アーキテクチャの核心：なぜ「送信トレイ監視」は難易度が高いのか
Outlookのイベントモデル（`Application_ItemSend`など）は、ユーザーが「送信」ボタンを押した瞬間のイベントを捉えるに過ぎない。しかし、真の障害（SMTPサーバーの応答なし、認証エラー、回線切断）は、送信ボタンを押した「後」に送信トレイ内で発生する。
この問題に対処するため、シニアアーキテクトが考慮すべきポイントは以下の3点に集約される。
1. イベントの不可視性: 送信トレイ内のアイテムがエラーを起こした際、トラップしやすいネイティブイベントが存在しない。そのため、タイマーや送受信完了イベントを組み合わせたポーリング／フック戦略が必要となる。
2. オブジェクトのライフサイクルとメモリリーク: Outlook VBAにおけるCOMオブジェクトの解放漏れは、即座に`OUTLOOK.EXE`のバックグラウンド残留（ゾンビプロセス）を招き、次回の自動化トリガーを完全に阻害する。
3. ネットワーク層の事前検証: 単純なループによる再送試行は、ネットワーク障害が継続している状況下ではSMTPサーバーへの負荷を高め、アカウントロックやキューの破損を引き起こす。再送前には必ずOSレベルでの導通確認（WinINet API等）が必須となる。
—
2. システム全体像と実装コード
以下のコードは、標準モジュールと`ThisOutlookSession`を連携させ、送信トレイ内の停滞メールを監視・リカバリするプロダクション品質のシステムである。
実装：`ThisOutlookSession`（イベントのフック）
Option Explicit
‘ 送信トレイの参照を保持
WithEvents OutboxItems As Outlook.Items
Private m_IsProcessing As Boolean
Private Sub Application_Startup()
Dim ns As Outlook.NameSpace
Set ns = Me.Session
‘ 送信トレイ（olFolderOutbox）のアイテムコレクションを取得
Set OutboxItems = ns.GetDefaultFolder(olFolderOutbox).Items
m_IsProcessing = False
‘ 起動時に既に停滞しているアイテムの初期チェックを実行
Call CheckAndRecoverStuckItems
Set ns = Nothing
End Sub
‘ 送信トレイにアイテムが追加された（＝送信処理が開始された）タイミングをキャッチ
Private Sub OutboxItems_ItemAdd(ByVal Item As Object)
If m_IsProcessing Then Exit Sub
‘ 送信完了までのタイムラグを考慮し、非同期的なチェックを誘導
‘ ※実際のリカバリ判定はタイマーまたはセッション内ポーリングで行う
End Sub
実装：標準モジュール（リカバリエンジンとAPI連携）
Option Explicit
‘ Windows API: ネットワーク接続状態の判定用
If VBA7 Then
Private Declare PtrSafe Function InternetGetConnectedState Lib “wininet.dll” (ByRef lpdwFlags As Long, ByVal dwReserved As Long) As Long
Else
Private Declare Function InternetGetConnectedState Lib “wininet.dll” (ByRef lpdwFlags As Long, ByVal dwReserved As Long) As Long
End If
Private Const INTERNET_CONNECTION_MODEM As Long = &H1
Private Const INTERNET_CONNECTION_LAN As Long = &H2
Private Const INTERNET_CONNECTION_PROXY As Long = &H4
‘ 再送試行の最大回数
Private Const MAX_RETRY_COUNT As Integer = 3
Public Sub CheckAndRecoverStuckItems()
Dim ns As Outlook.NameSpace
Dim outboxFolder As Outlook.MAPIFolder
Dim mail As Outlook.MailItem
Dim i As Long
Dim retryCount As Integer
On Error GoTo ErrorHandler
‘ ネットワークがオフラインの場合は処理をスキップ
If Not IsNetworkAlive() Then Exit Sub
Set ns = Application.Session
Set outboxFolder = ns.GetDefaultFolder(olFolderOutbox)
‘ コレクションの逆順ループ（インデックスシフトによるバグを防ぐ鉄則）
For i = outboxFolder.Items.Count To 1 Step -1
If TypeOf outboxFolder.Items(i) Is Outlook.MailItem Then
Set mail = outboxFolder.Items(i)
‘ 【重要】MAPIプロパティ等から送信エラー状態を判定
‘ 送信トレイに長時間留まっている、かつ送受信エラーフラグが立っているか
If IsMailStuck(mail) Then
retryCount = GetRetryCount(mail)
If retryCount < MAX_RETRY_COUNT Then
' リトライ回数をインクリメントして再送
Call IncrementRetryCount(mail, retryCount + 1)
' 一度送信トレイから外し、プロパティを更新して再プッシュ
mail.UnRead = False
' 再送トリガーとして送信メソッドを明示的に叩く
mail.Send
Else
' 規定回数を超えた場合は「下書き」へ退避し、ユーザーへアラートを発報
mail.Move ns.GetDefaultFolder(olFolderDrafts)
MsgBox "以下の件名のメールは送信エラーが継続したため、下書きに退避しました。" & vbCrLf & _
"件名: " & mail.Subject, vbCritical, "送信リカバリシステム"
End If
End If
' オブジェクトの明示的解放（メモリ最適化）
Set mail = Nothing
End If
C
Next i
CleanUp:
Set outboxFolder = Nothing
Set ns = Nothing
Exit Sub
ErrorHandler:
' ログ出力機構（必要に応じてファイル出力等に拡張）
Debug.Print "Error in CheckAndRecoverStuckItems: " & Err.Description
Resume CleanUp
End Sub
' ネットワークの物理的・論理的導通確認
Private Function IsNetworkAlive() As Boolean
Dim dwFlags As Long
IsNetworkAlive = (InternetGetConnectedState(dwFlags, 0&) <> 0)
End Function
‘ メールが送信エラーでスタックしているかを判定するモック関数
‘ （実際にはUserPropertiesやPR_MESSAGE_FLAGS等のMAPIプロパティを検査する）
Private Function IsMailStuck(ByVal mail As Outlook.MailItem) As Boolean
‘ ここでは簡略化のため、作成日時から一定時間（例: 5分以上）経過しているかを判定基準に含める
On Error Resume Next
If DateDiff(“n”, mail.CreationTime, Now) > 5 Then
IsMailStuck = True
Else
IsMailStuck = False
End If
On Error GoTo 0
End Function
‘ ユーザー定義プロパティを使用したリトライカウンタの管理
Private Function GetRetryCount(ByVal mail As Outlook.MailItem) As Integer
Dim prop As Outlook.UserProperty
On Error Resume Next
Set prop = mail.UserProperties.Find(“RecoveryRetryCount”)
If prop Is Nothing Then
Set prop = mail.UserProperties.Add(“RecoveryRetryCount”, olNumber)
prop.Value = 0
End If
GetRetryCount = prop.Value
Set prop = Nothing
On Error GoTo 0
End Function
Private Sub IncrementRetryCount(ByVal mail As Outlook.MailItem, ByVal currentCount As Integer)
Dim prop As Outlook.UserProperty
On Error Resume Next
Set prop = mail.UserProperties.Find(“RecoveryRetryCount”)
If Not prop Is Nothing Then
prop.Value = currentCount
mail.Save
End If
Set prop = Nothing
On Error GoTo 0
End Function
—
3. チーフアーキテクトが解説する「極限の最適化」と注意点
1. 逆順ループの徹底（Collectionsの罠）
Outlookの`Items`コレクションを操作する際、上から順（`1 To Count`）にループを回すと、アイテムの削除や移動が発生した瞬間にインデックスがずれ、致命的な実行時エラー（または処理落ち）を引き起こす。コレクションや配列の走査は常に`Count To 1 Step -1`の逆順ループが鉄則である。
2. UserPropertiesを活用したステートレスな状態管理
再送回数の管理において、静的変数やグローバル変数に頼るのは悪手である。Outlookが予期せぬクラッシュを起こした際に状態が失われるためだ。上記のコードでは、`MailItem.UserProperties`を用いてメールオブジェクト自体にメタデータを埋め込んでいる。これにより、プロセスが再起動してもリトライ回数の整合性が完全に維持される。
3. COMオブジェクトのライフサイクルとゾンビプロセスの根絶
VBAはガベージコレクションが曖昧である。特にOutlookオートメーションでは、`NameSpace`、`MAPIFolder`、`MailItem`などの参照をローカル変数に取得したまま放置すると、背後のCOMコンポーネントがメモリ上に残り続け、Outlook終了後もプロセスがゾンビ化する。
コードブロックの随所で `Set xxx = Nothing` を明示的に記述し、スコープを抜ける瞬間に参照カウントを確実にゼロに落とすこと。これが安定稼働するエンタープライズVBAの絶対条件である。
—
結びにかえて
自動化の信頼性は、「正常系がいかに美しく動くか」ではなく、「異常系に直面したときシステムがいかに美しく、かつ強靭に振る舞うか」によってのみ測られる。
今回紹介した送信トレイの監視・リカバリロジックは、単なるVBAの小技を超えた、分散システムにおける「リトライ・パターン」のOutlook実装である。レガシーとモダンが混在する現場において、こうしたアーキテクチャの知見を武器に、止まらない自動化インフラを構築し続けてほしい。
