共有メールボックスの罠を突破せよ：UserPropertiesによる「二重処理」防止の極意
こんにちは。現場で数々の自動化システムを設計してきた、あなたの先輩エンジニアです。
Outlook VBAを学び、「マクロの記録」から一歩踏み出して、自分でロジックを書けるようになってきたあなた。素晴らしいステップアップです！「メールが来たら自動でフォルダ分けする」「特定の条件でフラグを立てる」といった処理が動いたとき、エンジニアとしての喜びを感じていることでしょう。
しかし、ここで一つ、「実戦（プロダクション）」特有の恐ろしい壁が立ちはだかります。
それは、「共有メールボックス」です。
「自分のPCでは完璧に動いたのに、チーム全員で共有しているメールボックスに適用したら、同じメールに対してマクロが2回、3回と重複して動いてしまった……」
そんな悲鳴が、開発現場からは日常的に聞こえてきます。今日は、この「二重処理（レースコンディション）」という難題を、Outlook VBAの深淵な機能である`UserProperties`を使って、エレガントに解決する方法を伝授します。
ここをクリアすれば、あなたの作るツールは「個人の便利ツール」から「プロが作る業務システム」へと昇華しますよ。
1. なぜ「二重処理」は起きるのか？
まず、敵の正体を知りましょう。
共有メールボックスは、複数のユーザーのOutlookクライアントから同時にアクセスされます。ここで何が起きるか、図解的にイメージしてみてください。
【悲劇のシナリオ】
1. 共有メールボックスに新しいメールが届く。
2. AさんのOutlookが「新着だ！」と検知し、マクロを開始。
3. BさんのOutlookも（ほぼ同時に）「新着だ！」と検知し、マクロを開始。
4. Aさんの処理： メールを「完了」フォルダへ移動。
5. Bさんの処理： （Aさんが移動する直前のタイミングで）同じメールを「完了」フォルダへ移動しようとする。
6. 結果： 二重に返信が飛ぶ、二重にデータベースへ書き込まれる、エラーで止まる……。
ここで重要なのは、「VBAの変数（Public変数など）では解決できない」という点です。変数は、その時動いている「そのPCのメモリ」の中にしか存在しません。AさんのPCのメモリにある変数を、BさんのPCが見ることはできないのです。
解決策はたった一つ。「メールアイテムそのものに、処理中であることを刻み込む」ことです。
2. 救世主：`UserProperties` とは？
Outlookのメールアイテム（MailItem）には、標準のプロパティ（件名や送信者など）以外に、開発者が自由に定義できる「隠しポケット」のようなものがあります。これが `UserProperties` です。
これを使うと、メールの中に「処理ステータス」という独自の項目を作り込み、そこに「処理中」や「完了」といった値を書き込むことができます。
ここが設計のキモです：
`UserProperties` に値を書き込んで `.Save` メソッドを呼び出すと、その情報はメールアイテム自体に保存され、サーバーを通じて他の人のOutlookにも同期されます。
これこそが、複数のPC間で「状態」を共有するための、最強の排他制御（ロック）メカニズムなのです。
3. 実装コード：堅牢な排他制御ロジック
それでは、実際に使えるコードを見てみましょう。
このコードは、`ThisOutlookSession` に記述する `NewMailEx` イベント（または `ItemAdd`）を想定した設計です。
' --- ThisOutlookSession 内に記述 ---
Option Explicit
' 定数定義：プロパティ名とステータス
Private Const PROP_NAME As String = "MyAutomationStatus"
Private Const STATUS_RUNNING As String = "RUNNING"
Private Const STATUS_DONE As String = "DONE"
''' <summary>
''' 新着メールを検知した際に呼び出されるメインルーチン
''' </summary>
''' <param name="EntryID">検知されたアイテムのEntryID</param>
Public Sub ProcessNewMail(ByVal EntryID As String)
Dim outlookApp As Outlook.Application
Dim ns As Outlook.NameSpace
Dim mailItem As Outlook.MailItem
Dim userProp As Outlook.UserProperty
Set outlookApp = New Outlook.Application
Set ns = outlookApp.GetNamespace("MAPI")
On Error GoTo ErrorHandler
' 1. アイテムの取得
Dim item As Object
Set item = ns.GetItemFromID(EntryID)
' メール以外（会議出席依頼など）は無視
If TypeOf item Is Not MailItem Then Exit Sub
Set mailItem = item
' 2. 【排他制御の核心】UserPropertiesの確認
' すでに「処理中」または「完了」なら、即座に終了する
Set userProp = mailItem.UserProperties.Find(PROP_NAME)
If Not userProp Is Nothing Then
If userProp.Value = STATUS_RUNNING Or userProp.Value = STATUS_DONE Then
' 他のクライアントが処理中、あるいは処理済み
Debug.Print "Skip: Item is already being processed or done. ID: " & EntryID
Exit Sub
End If
Else
' プロパティが存在しない場合は、新規作成する
' (初回実行時にプロパティを生成するためのステップ)
Set userProp = mailItem.UserProperties.Add(PROP_NAME, olText)
End If
' 3. 【ロック開始】ステータスを「RUNNING」に書き換え、即座に保存
' これにより、他のPCがこのメールを見た時に「処理中」だと判別できる
userProp.Value = STATUS_RUNNING
mailItem.Save ' ★超重要：これを忘れるとサーバーに同期されない！
Debug.Print "Lock acquired: " & EntryID
' ---------------------------------------------------------
' 4. 【メイン処理】ここに本来やりたい自動化ロジックを書く
' ---------------------------------------------------------
Debug.Print "Processing mail: " & mailItem.Subject
' 例：重い処理のシミュレーション
' DoEvents を挟むことで、OSへの制御を戻し、安定性を高める
DoEvents
' --- ここに実際の処理（フォルダ移動、返信、DB登録など）を記述 ---
' ---------------------------------------------------------
' 5. 【完了処理】ステータスを「DONE」に更新して保存
userProp.Value = STATUS_DONE
mailItem.Save
Debug.Print "Process completed successfully: " & EntryID
Exit Sub
ErrorHandler:
' エラーが発生した場合の処理
' 処理が途中で止まると「RUNNING」のまま残ってしまうため、
' 運用ルールとして「一定時間経過してもRUNNINGならリセットする」等の検討が必要
Debug.Print "Error occurred: " & Err.Description
' 必要に応じて、エラー時もステータスをクリアするなどのリカバリを検討
' mailItem.UserProperties.Remove(PROP_NAME)
End Sub4. エンジニアが教える「ここが落とし穴」
このコードを実戦投入する前に、プロの視点から3つの注意点を伝えておきます。
① `.Save` を忘れると、すべてが水の泡
`userProp.Value = STATUS_RUNNING` と書いただけでは、あなたのPCのメモリ内で値が変わっただけです。`mailItem.Save` を呼び出して初めて、その「ロック情報」がメールに書き込まれ、サーバーへ送られます。「ロックをかけたら即保存」。これは鉄則です。
② 「ゾンビ・ロック」問題
もし、マクロの実行中にPCがフリーズしたり、ネットワークが切断されたりしたらどうなるでしょうか？
メールには `STATUS_RUNNING` が書き込まれたまま、処理が完了しません。すると、そのメールは永久に二度と処理されない「ゾンビ」になってしまいます。
対策案：
実務レベルでは、`STATUS_RUNNING` に加えて「いつロックしたか」というタイムスタンプを別の `UserProperty` に保存しておく手法をとります。
「もし `RUNNING` かつ、書き込みから30分以上経過していたら、エラーとみなして再試行する」といったロジックを加えると、真に堅牢なシステムになります。
③ パフォーマンスへの配慮
`UserProperties` は非常に便利ですが、大量のメール（数千件など）を一度にループで処理する際に、一つずつ `.Save` を繰り返すと、サーバーとの通信（同期）が頻発し、Outlookが重くなる原因になります。
「監視（イベント駆動）」で使う分には全く問題ありませんが、バッチ処理として使う場合は、処理の塊ごとに保存するなど、バランスを考えてください。
まとめ：一歩先のエンジニアへ
「動けばいい」という段階から、「誰が、どこで、いつ動かしても、正しく、二重に動かない」という段階へ。
今回紹介した `UserProperties` を使った排他制御は、分散システム（複数のクライアントが動く環境）におけるもっとも基本的かつ重要な考え方です。これが理解できれば、あなたはもう単なる「マクロ使い」ではなく、「業務プロセスを設計できるエンジニア」の入り口に立っています。
一歩ずつ、着実に。
もしエラーが出ても、それは成長のチャンスです。コードを読み解き、オブジェクトの動きを観察してください。
応援していますよ！
