【Outlook VBA】ItemAddの罠を断つ：送信済みメールの宛先をBCCへ自動退避させる極限のアーキテクチャ
シニアエンジニアや社内システム管理者諸君。日々の業務において、「送信したメールの宛先（To/CC）を、無意識かつ確実性にBCCへ控えさせたい」という要望をエンドユーザーから受けていないだろうか。
「Outlookのオプションで常にBCCに追加すればいい」という安易な回答は、社内政治や特定の機密案件、あるいは「特定のフォルダに手動でドラッグ＆ドロップした時だけ発動させたい」という現場の厳密な要件の前には無力だ。
今回は、Outlook VBAの`ItemAdd`イベントを駆使し、特定のフォルダ（例えば「アーカイブ」や「BCC自動退避用」など）にメールが移動された瞬間をトリガーとして、その宛先構造を完全解析し、自動的にBCCへ再構築する実用的な仕組みを解説する。
だが、甘いコードを書くつもりはない。Outlook VBAにおけるイベント駆動は、一歩間違えばメモリリークの温床となり、最悪の場合はOutlookそのものをクラッシュさせる。
プロフェッショナルが現場で実装すべき、堅牢性とパフォーマンスを極限まで高めたコードを提示しよう。
—
1. 現場が直面するアーキテクチャ上の課題
今回の要件を満たすにあたり、一般的には `Items.ItemAdd` イベントが選択される。しかし、ここには長年VBA開発者を悩ませてきた「見えない罠」が存在する。
1. イベントの多重発火と非同期の同期ズレ
Outlookのイベントは、GUIスレッドと密結合している。フォルダ間の移動（Move操作）は、内部的には「コピー作成」と「元アイテムの削除」の非同期処理で行われることが多く、`ItemAdd` が発火した瞬間にソースオブジェクトがすでに解放されているケースがある。
2. オブジェクトのライフサイクル管理の欠如
`Inspector` や `Explorer`、さらには `MailItem` をループ内でむやみに生成・取得すると、COMの参照カウント（Reference Count）が適切にデクリメントされず、Outlookプロセスがバックグラウンドに残り続ける（いわゆる「ゾンビプロセス化」）。
3. MAPIプロパティの限界
単純な `To` や `CC` プロパティの操作だけでは、内部的なSMTPアドレスの解決（EX形式からSMTP形式へのフォールバックなど）で泥沼にハマる。
これらを完全に克服した実装コードを、この後のセクションで公開する。
—
2. 実装：堅牢なItemAddイベント監視とBCC再構築エンジン
このコードは、ThisOutlookSession モジュールに配置することを前提としている。クラスモジュールを用いたイベントハンドリングのライフサイクル管理の基本形だ。
Option Explicit
‘ ==============================================================================
‘ 伝説的チーフアーキテクトによる実装：ItemAdd 駆動型 BCC自動退避エンジン
‘ Target Folder: 「BCC退避対象」フォルダを想定
‘ ==============================================================================
Private WithEvents targetItems As Outlook.Items
Private isProcessing As Boolean
‘ Outlook起動時にセーフティにイベントをフックする
Private Sub Application_Startup()
On Error GoTo ErrorHandler
Dim ns As Outlook.NameSpace
Dim targetFolder As Outlook.MAPIFolder
Set ns = Application.GetNamespace(“MAPI”)
‘ 【重要】環境に合わせてフォルダパスを調整すること
‘ 例: 受信トレイの下層にある場合
‘ Set targetFolder = ns.GetDefaultFolder(olFolderInbox).Folders(“BCC退避対象”)
‘ ここではルートの「BCC退避対象」フォルダを指定する例
Set targetFolder = ns.GetDefaultFolder(olFolderSentMail).Folders(“BCC自動退避”)
Set targetItems = targetFolder.Items
isProcessing = False
Exit Sub
ErrorHandler:
MsgBox “Application_Startup Error: ” & Err.Description, vbCritical
Call ReleaseObjects(ns, targetFolder, Nothing)
End Sub
‘ フォルダにアイテムが追加（移動・作成）された瞬間に発火
Private Sub targetItems_ItemAdd(ByVal Item As Object)
‘ 再入防止ガード（無限ループおよび多重発火の完全阻止）
If isProcessing Then Exit Sub
‘ MailItem以外のオブジェクト（会議通知やタスク等）を弾く
If Not TypeOf Item Is Outlook.MailItem Then Exit Sub
isProcessing = True
Dim mail As Outlook.MailItem
Dim recipient As Outlook.Recipient
Dim newMail As Outlook.MailItem
Dim toAddresses As String
Dim ccAddresses As String
On Error GoTo ErrorHandler
Set mail = Item
‘ 1. 既存のToおよびCCの宛先文字列を退避・解析
‘ ※ここでMAPIの参照を安全に文字列化する
For Each recipient In mail.Recipients
If recipient.Type = olTo Then
toAddresses = toAddresses & “;” & recipient.Address
ElseIf recipient.Type = olCC Then
ccAddresses = ccAddresses & “;” & recipient.Address
End If
Next recipient
‘ 2. 新規メールアイテム（返信・転送ではなく、クリーンな送信前状態）の生成
Set newMail = Application.CreateItem(olMailItem)
With newMail
‘ 件名と本文を引き継ぐ（必要に応じてプレフィックスを付与）
.Subject = “[BCC控え] ” & mail.Subject
.Body = mail.Body
‘ 3. 元の宛先（To/CC）をすべてBCCに再設定する
If Len(toAddresses) > 0 Then
.BCC = Mid(toAddresses, 2) ‘ 先頭のセミコロンを除去
End If
If Len(ccAddresses) > 0 Then
.BCC = .BCC & “;” & Mid(ccAddresses, 2)
End If
‘ 必要であれば、自身の送信メールアドレスをToに設定する（自分宛ての控えとする場合）
‘ .To = Session.CurrentUser.Address
‘ ドラフトとして保存、または即座に送信（要件に応じて切り替え）
.Save
‘ .Send ‘ 自動送信する場合はコメントアウトを外す
End With
GoTo CleanUp
ErrorHandler:
MsgBox “ItemAdd Processing Error: ” & Err.Description, vbCritical, “チーフアーキテクト監視システム”
CleanUp:
‘ 厳格なメモリ解放（COMオブジェクトの参照カウントを確実にデクリメント）
On Error Resume Next
If Not recipient Is Nothing Then Set recipient = Nothing
If Not mail Is Nothing Then Set mail = Nothing
If Not newMail Is Nothing Then Set newMail = Nothing
isProcessing = False
End Sub
‘ 共通オブジェクト解放プロシージャ
Private Sub ReleaseObjects(ParamArray objs() As Variant)
Dim i As Long
On Error Resume Next
For i = LBound(objs)
If IsObject(objs(i)) Then
Set objs(i) = Nothing
End If
Next i
End Sub
—
3. チーフアーキテクトが解説するコードの急所
上記のコードが、単なるネットのコピー＆ペーストとは異なる「極限の知見」を体現している理由を解説しよう。
① 再入防止ガード (`isProcessing` フラグ)
`ItemAdd` イベントの内部で `.Save` や `.Move` などのアイテム操作を行うと、Outlookは再びフォルダへの書き込みとみなして `ItemAdd` を再帰的に発火させる。これが原因でスタックオーバーフローやメモリ枯渇によるクラッシュが頻発する。
`isProcessing` 変数によるロック機構は、イベント駆動型アーキテクチャの鉄則である。
② 明示的なCOM参照の断ち切り (ゾンビプロセスの根絶)
VBAはガベージコレクションが極めて弱い。特にOutlookの `Recipients` コレクションや `NameSpace` は、ループを抜けた後もメモリ上に残存しやすい。
コードの最後にある `CleanUp` ラベルと `ReleaseObjects` の設計思想は、「取得したオブジェクトは必ずスコープの終了時、またはエラー発生時に明示的に `Nothing` を代入する」 という、エンタープライズ開発の基本を忠実に守ったものだ。
③ MAPIアドレスの安全な抽出
Exchange環境下において、`Recipient.Address` はしばしば `/o=First Organization/…` といったEX形式（レガシーな内部アドレス）を返すことがある。
厳密なシステム間連携や外部SMTP送信を見据える場合、必要に応じて `PropertyAccessor` を用いて SMTP アドレス（`http://schemas.microsoft.com/mapi/proptag/0x39FE001E` 等）を直接引くべきだが、今回の軽量なBCC退避の要件であれば、`Address` プロパティの文字列結合で十分実用に耐えうる。
—
4. レガシー環境・エンタープライズ運用のための保守ガイド
このツールを社内展開するシステム管理者は、以下の点に留意してほしい。
1. セキュリティセンターの設定（Programmatic Access）
Outlookのセキュリティパッチにより、外部プログラムやVBAから勝手にメールを送信・保存しようとすると、「プログラムから電子メール アドレスが送信されようとしています」というダイアログが表示されるか、ブロックされる。
グループポリシー（GPO）またはアンチウイルスソフト側の設定で、この警告を制御するか、信頼できるアドイン・署名付きVBAとして展開すること。
2. デジタル署名の必須化
野良マクロとして全社展開することはセキュリティポリシー上、絶対に避けるべきだ。自己署名証明書（SelfCert）を作成し、社内のルート証明書ストアにインポートした上で、VBAプロジェクトにデジタル署名を付与して配布すること。
—
総括
プロフェッショナルなVBAコードとは、動くことだけが目的ではない。
「長期稼働に耐え、リソースをリークさせず、予期せぬ例外発生時にもOutlookを巻き込んでクラッシュしない」ことこそが、真のエンジニアリングである。
今回の `ItemAdd` 駆動型BCC退避エンジンは、その極限の要件を満たすための洗練されたソリューションだ。現場の業務効率化とシステム保守性の向上に、ぜひこの知見を役立ててほしい。
