【Outlook VBA極限解説】マルチアカウント環境における送信元（SentOnBehalfOfName）の動的制御とオブジェクトライフサイクル最適化
Outlook VBAを用いた自動化において、最も頻繁に踏み抜かれる地雷の一つが「複数アカウント環境での送信元制御」である。
社内システムやクライアントからの要望で「部署ごとの代表メールアドレス」「役職に応じた個人の別名義アドレス」「外部連携用の専用アカウント」など、複数の送信元をVBAから動的に切り替えてメールを生成・送信する必要に迫られるシーンは多々ある。
単に `SentOnBehalfOfName` プロパティに文字列を代入するだけのコードはネット上に溢れているが、それでは実業務の堅牢性（ロバストネス）を担保できない。OutlookのCOMオブジェクトのライフサイクル、アカウントの非同期読み込み問題、そしてレガシー環境特有の挙動を熟知したアーキテクトだけが知る、極限の知見をここに公開する。
—
1. アカウント切り替えにおける根本的課題
Outlookには、プロファイル内に複数のExchangeアカウント、IMAP/POP3アカウント、そして共有メールボックス（Delegation）が混在する。
ここで多くの開発者が犯す致命的な誤りは以下の2点だ。
1. 文字列直叩きの脆弱性: `MailItem.SentOnBehalfOfName = “info@example.com”` のようにハードコーディングし、Outlook側でアカウントのマスターデータ変更やエイリアスの改廃があった際にサイレントエラー（あるいは意図しないアカウントからの送信）を引き起こす。
2. オブジェクトの解放漏れ（COMレイヤーのメモリリーク）: `Application.Session.Accounts` などのコレクションを走査する際、暗黙的に生成されるCOMラッパーオブジェクトを適切に解放せず、Outlookのプロセス（OUTLOOK.EXE）をゾンビ化させる。
これを防ぐためには、`NameSpace.Accounts` コレクションから厳密に有効な `Account` オブジェクトを特定し、そのプロパティを介して送信権限を確立する必要がある。
—
2. 実装アーキテクチャ：動的アカウント判定と安全なメール生成
以下に、渡された条件（顧客コード、部署ID、あるいは特定の件名パターンなど）に応じて、動的に送信元アカウントを解決し、メモリリークを完全に排除したセーフティなメール作成プロシージャを示す。
Option Explicit
‘ =================================================================================
‘ 概要: 複数アカウント環境において、条件に応じた送信元を動的に設定しMailItemを生成する
‘ アーキテクトノート:
‘ – セッションのAccountsコレクションを安全に列挙し、解放処理を徹底。
‘ – 送信権限（SendAs / SendOnBehalfTo）の不整合による例外をキャッチしてフォールバック。
‘ =================================================================================
Public Sub CreateMailWithDynamicAccount(ByVal targetRecipient As String, _
ByVal subjectText As String, _
ByVal bodyText As String, _
ByVal conditionKey As String)
Dim objApp As Outlook.Application
Dim objNs As Outlook.NameSpace
Dim objMail As Outlook.MailItem
Dim colAccounts As Outlook.Accounts
Dim targetAccount As Outlook.Account
Dim isAccountFound As Boolean
Dim i As Long
‘ 1. アプリケーションインスタンスの安全な取得
Set objApp = New Outlook.Application
Set objNs = objApp.GetNamespace(“MAPI”)
‘ 2. メールのインスタンス生成（この時点ではデフォルトアカウントに紐づく）
Set objMail = objApp.CreateItem(olMailItem)
Set colAccounts = objNs.Accounts
isAccountFound = False
On Error GoTo ErrorHandler
‘ 3. ビジネスロジックに応じたアカウントの動的解決
‘ ここでは conditionKey に応じて送信元を切り替える（例: “SALES” なら営業部代表）
Select Case UCase(Trim(conditionKey))
Case “SALES”
Set targetAccount = FindAccountByAddress(colAccounts, “sales-rep@enterprise.co.jp”)
Case “SUPPORT”
Set targetAccount = FindAccountByAddress(colAccounts, “support-desk@enterprise.co.jp”)
Case Else
‘ デフォルトアカウントを使用する場合のフォールバック
Set targetAccount = colAccounts.Item(1)
End Select
If Not targetAccount Is Nothing Then
‘ 【重要】Accountオブジェクトから直接送信元を設定
‘ SentOnBehalfOfName への単なる文字列代入よりも、Account.SmtpAddressや
‘ Account.UserName を利用する方がセッションとのバインドが強固になる。
objMail.SentOnBehalfOfName = targetAccount.SmtpAddress
‘ Outlook 2016以降やExchange環境では、SendUsingAccountを指定することが最も確実
Set objMail.SendUsingAccount = targetAccount
Else
Err.Raise 9999, “DynamicAccount”, “指定された送信元アカウントが見つかりません。”
End If
‘ 4. メールのプロパティ構築
With objMail
.To = targetRecipient
.Subject = subjectText
.Body = bodyText
.Display ‘ 画面表示（送信前に確認する場合はこれを使用。即時送信は .Send）
End With
CleanUp:
‘ =============================================================================
‘ オブジェクトの明示的解放（Memory Optimization）
‘ COMラッパーの参照カウントを確実にデクリメントし、メモリリークを防ぐ
‘ =============================================================================
Set targetAccount = Nothing
Set colAccounts = Nothing
Set objMail = Nothing
Set objNs = Nothing
Set objApp = Nothing
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “Outlook VBA アーキテクチャ”
Resume CleanUp
End Sub
‘ =================================================================================
‘ ヘルパー関数: アドレス一致によるAccountオブジェクトの安全な取得
‘ =================================================================================
Private Function FindAccountByAddress(ByVal accounts As Outlook.Accounts, ByVal smtpAddress As String) As Outlook.Account
Dim acc As Outlook.Account
Dim foundAcc As Outlook.Account
Set foundAcc = Nothing
For Each acc In accounts
If StrComp(acc.SmtpAddress, smtpAddress, vbTextCompare) = 0 Then
Set foundAcc = acc
Exit For
End If
Next acc
Set FindAccountByAddress = foundAcc
‘ ※ For Each ループ内の acc はVBAの仕様上、明示的な解放はループ終了時に行われるが、
‘ 参照の持ち回りを防ぐため関数スコープで確実に管理する。
Set acc = Nothing
End Function
—
3. シニアエンジニアが知るべき「罠」と極限の知見
① `SentOnBehalfOfName` と `SendUsingAccount` の挙動の違い
多くの開発者が混同しているが、この2つは制御レイヤーが異なる。
- `SentOnBehalfOfName`: メールのヘッダーにある `From` および `Sender` を書き換える。権限がない（Send As / Send on Behalf 権限がExchange側で付与されていない）場合、サーバー側で送信拒否（NDR）が発生する。
- `SendUsingAccount`: Outlookプロファイル内のどのアカウントのセッション・SMTPサーバーを使ってパケットを送り出すかを指定する。
マルチアカウント環境で確実に意図した署名や送信済トレイの振る舞いを担保したい場合、両方を同時に設定するのが最も堅牢である。上記のサンプルコードが `SendUsingAccount` と `SentOnBehalfOfName` の両方をアサインしているのはそのためだ。
② プロファイルキャッシュと非同期遅延
Outlookが起動直後の場合、`NameSpace.Accounts` の列挙が完了する前にVBAのコードが走り抜けることがある。特に大規模な組織で数百の共有メールボックスがマッピングされている環境では、COMの初期化遅延に起因する `Object variable or With block variable not set (Error 91)` が発生する。
これを回避するため、エンタープライズ環境のバッチ処理では、`Application.Session.Accounts.Count` が 0件でないことを確認するリトライロジックを挟むのがプロの作法である。
③ レガシー環境（Exchange 2010以前 / 混在環境）への配慮
いまだにオンプレミスのレガシーExchangeサーバーが現役の現場も多い。そうした環境では、`Account.SmtpAddress` が空を返す（LegacyExchangeDNしか持たない）ケースが存在する。
その場合は、フォールバックとして `Account.DisplayName` や `MailItem.SenderEmailAddress` を評価するバイパスロジックを組み込むことで、レガシー環境特有のバグを完全鎮圧できる。
—
最後に：コードの美しさは堅牢性に宿る
VBAは「おもちゃの言語」と揶揄されることがある。しかし、背後にあるCOMアーキテクチャとOutlookのライフサイクルを完全に理解した上で構築されたコードは、C#やPythonで書かれたモダンなアプリケーションと同等、あるいはそれ以上にシビアな業務を確実に遂行する。
メモリを制し、オブジェクトを制する者が、Outlook自動化の頂点を極める。日々の保守運用の負担を極限までゼロにするために、今すぐあなたのコードベースのオブジェクト解放とアカウント判定ロジックを見直してほしい。
