【実務・中級編】【中級者向け】メール受信イベントで「返信済み」ステータスを検知し、自動でフォローアップフラグをクリアする排他制御 – Outlook VBA解析バイブル

Outlook VBA

2026.11.05

Outlook VBAを掌握する極限の知見：PropertyAccessorによる「状態管理」と排他制御の設計論

Outlook VBAを掌握する極限の知見：PropertyAccessorによる「状態管理」と排他制御の設計論

自動化エンジニアとして、あるいは業務ツール開発のリーダーとして、君たちは一度は「なぜか挙動が不安定になる」という壁にぶち当たるはずだ。

「メールを受信したらフラグを立てる。そして、返信したらそのフラグを消す」

一見、中学生でも書けそうな単純なロジックに見えるだろう？だが、これを「止まらない、バグらない、業務で使い物になるプロダクションコード」として実装しようとすると、話は全く別だ。

標準的な `MailItem.FlagStatus` だけを弄っているうちは、素人の域を出ない。ネットワークの遅延、Outlookの同期タイミング、あるいはユーザーの操作との競合——それらが重なった瞬間、君のコードは二重にフラグを立て、あるいは消すべきフラグを消し忘れる「不整合」を引き起こす。

今日は、プロフェッショナルが現場で使うPropertyAccessorを用いた隠しプロパティの操作と、状態の不整合を防ぐための排他制御（State Management）について、その設計思想を叩き込む。

1. なぜ、君のコードは「二重動作」を起こすのか

多くの開発者が陥る罠は、「イベントの発生」と「オブジェクトの状態」を同一視してしまうことだ。

Outlookの `NewMailEx` や `ItemAdd` イベントは、必ずしも「一回、一回、正確に」実行される保証はない。特にExchangeサーバーとの同期が走る環境では、同じアイテムに対して複数のイベントが極めて短い間隔で発火することがある。

このとき、以下のようなシナリオが発生する：
1. イベントAが発火し、メールをスキャン。
2. イベントAが「フラグを立てる処理」を実行中。
3. イベントAが完了する前に、イベントBが同じメールに対して発火。
4. イベントBも「フラグを立てる処理」を実行しようとする。

これが「フラグの二重付与」や「処理の重複」の正体だ。これを防ぐには、単にコードを書くのではなく、「今、このアイテムは処理中か？」という状態を、アイテム自身に持たせる設計が必要になる。

2. 真実のソース（Source of Truth）を掴む：PropertyAccessor

標準の `MailItem` オブジェクトが公開しているプロパティは、あくまで「人間が見やすいように加工された窓口」に過ぎない。

エンジニアリングの観点では、MAPI（Messaging Application Programming Interface）が保持している生のプロパティに直接アクセスしなければならない。ここで登場するのが `PropertyAccessor` だ。

今回、我々が監視すべきは `PR_LAST_VERB_EXECUTED` という隠しプロパティだ。
これには、そのメールに対して最後に行われたアクション（返信、転送、未読など）が数値として格納されている。

返信（Reply）が行われたことを検知するには、このプロパティの値を読み取る。
処理済みであることをマークするには、カスタムのMAPIプロパティを書き込む。

これにより、「メールの見た目（FlagStatus）」ではなく、「メールの履歴（MAPI State）」に基づいてロジックを組むことが可能になる。

3. 実装：堅牢な自動フラグ制御エンジン

以下に、実務でそのまま利用可能なレベルの設計思想に基づいたコードを示す。
このコードの肝は、「カスタムプロパティによる処理ロック」と「MAPIプロパティによるアクション検知」の組み合わせだ。

' --- Standard Module: AutomationEngine ---
Option Explicit

' MAPIプロパティの定義 (Property Tag)
' カスタムプロパティとして「処理中フラグ」を定義するために使用
' 0x80000000 以上の範囲を使用するのが定石
Private Const PR_CUSTOM_LOCK As String = "http://schemas.microsoft.com/mapi/proptag/0x851F0003"
' 返信アクションを特定するためのタグ (PR_LAST_VERB_EXECUTED)
Private Const PR_LAST_VERB_EXECUTED As String = "http://schemas.microsoft.com/mapi/proptag/0x10810003"

' 返信アクションの定数 (MAPI値)
Private Const VERB_REPLY As Long = 102
Private Const VERB_REPLY_ALL As Long = 103

''' <summary>
''' メールの状態を解析し、必要に応じてフラグを制御するメインエンジン
''' </summary>
''' <param name="itm">対象のMailItem</param>
Public Sub ProcessMailState(itm As Outlook.MailItem)
    On Error GoTo ErrorHandler

    Dim pa As Outlook.PropertyAccessor
    Set pa = itm.PropertyAccessor

    ' 1. 排他制御: すでに処理中のアイテムではないかを確認
    ' カスタムプロパティをチェックし、存在すれば「処理中」とみなしてスキップ
    If IsProcessing(pa) Then
        Debug.Print "Skipping: Item is already under processing. ID: " & itm.EntryID
        Exit Sub
    End If

    ' 2. 処理開始のロックをかける
    SetLock pa

    ' 3. 状態判定ロジック
    ' 返信済みかどうかをMAPIプロパティから直接取得
    Dim lastVerb As Long
    On Error Resume Next ' プロパティが存在しない場合（初回受信時など）のハンドリング
    lastVerb = pa.GetProperty(PR_LAST_VERB_EXECUTED)
    On Error GoTo ErrorHandler

    If lastVerb = VERB_REPLY Or lastVerb = VERB_REPLY_ALL Then
        ' 【返信済みの場合】フォローアップフラグをクリアする
        If itm.FlagStatus <> olFlagNone Then
            itm.FlagStatus = olFlagNone
            Debug.Print "Action: Cleared flag for replied mail. ID: " & itm.EntryID
        End If
    Else
        ' 【新規受信/未返信の場合】業務ルールに基づきフラグを立てる
        ' ここでは例として、特定の条件（例：件名に[重要]がある）でフラグを立てる
        If InStr(itm.Subject, "[重要]") > 0 And itm.FlagStatus = olFlagNone Then
            itm.FlagStatus = olFlagYes
            Debug.Print "Action: Set follow-up flag. ID: " & itm.EntryID
        End If
    End If

    ' 4. ロックの解除
    Unlock pa

CleanUp:
    Exit Sub

ErrorHandler:
    ' エラー発生時はロックを解除して、システムのハングアップを防ぐ
    Debug.Print "Error in ProcessMailState: " & Err.Description
    Unlock pa
    Resume CleanUp
End Sub

' --- 内部補助関数 (Private Helpers) ---

Private Function IsProcessing(pa As Outlook.PropertyAccessor) As Boolean
    On Error Resume Next
    ' プロパティが存在するかどうかで判定
    Dim val As Variant
    val = pa.GetProperty(PR_CUSTOM_LOCK)
    IsProcessing = (Err.Number = 0)
    On Error GoTo 0
End Function

Private Sub SetLock(pa As Outlook.PropertyAccessor)
    ' 処理中であることを示すカスタム値を書き込む
    pa.SetProperty PR_CUSTOM_LOCK, "PROCESSING"
End Sub

Private Sub Unlock(pa As Outlook.PropertyAccessor)
    ' ロック解除。プロパティを削除することで、次回の検知を可能にする
    On Error Resume Next
    pa.DeleteProperty PR_CUSTOM_LOCK
    On Error GoTo 0
End Sub

4. アーキテクトの視点：なぜこの設計なのか

# ① カスタムプロパティによる「永続的なロック」

`Static` 変数を使ったメモリ上のロックは、Outlookが再起動したり、イベントが別プロセスから飛んできたりした場合には無力だ。
`PropertyAccessor` を使い、アイテムそのものに「今、俺は処理中だ」という刻印を刻む。これにより、たとえイベントが同時に二つ発生しても、二つ目は `IsProcessing` で確実に弾かれる。これが真の排他制御だ。

# ② 状態の「真実」を追う

`itm.FlagStatus` は「ユーザーがどう見ているか」であって、「何が起きたか」ではない。
`PR_LAST_VERB_EXECUTED` を見ることで、ユーザーが「返信」ボタンを押したという事実（Fact）に基づいた自動化が可能になる。これは、UIの表示状態に依存しない、極めて堅牢なロジックだ。

# ③ エラーハンドリングの責務

`ErrorHandler` 内で必ず `Unlock` を実行している点に注目してほしい。もし処理の途中でエラーが起きてロックを解除し忘れたら、そのメールは二度と自動処理されなくなる。「失敗しても、システムを元の健全な状態に戻す」。これがプロフェッショナルのコードだ。

5. 実務への応用と注意点

このロジックをさらに発展させる場合、以下の点に留意せよ。

1. 外部DBとの連携:
もし処理結果をSQL ServerやCSVに記録する場合、`EntryID` を主キーとして使用せよ。VBA側で二重処理を防いでも、DB側で `EntryID` のユニーク制約がなければ、ログが重複するリスクがある。
2. パフォーマンスの重み:
`PropertyAccessor` は強力だが、全ての受信メールに対して高頻度で呼び出すと、Exchangeサーバーとの通信負荷が増大する。`InStr` 等による簡易的なフィルタリングを先に済ませ、「対象となる可能性が高いメール」にのみ `PropertyAccessor` を適用するのが賢明な設計だ。
3. 同期のラグ:
モバイル端末（iPhone/Android）から返信した場合、その情報はサーバー経由でPCのOutlookに同期される。その際、`PR_LAST_VERB_EXECUTED` が正しく同期されるかは環境に依存するため、開発環境と実稼働環境での徹底的な検証が不可欠だ。

結論

自動化ツールにおける「動けばいい」という考えは、現場では「負債」でしかない。
`PropertyAccessor` を使いこなし、オブジェクトの状態を厳密に管理する。この一歩が、君の書くコードを「スクリプト」から「システム」へと昇華させる。

健闘を祈る。