【テクニカル・上級編】実務中級者向け：Sessionオブジェクトで複数アカウント環境を判別し、正しいアカウントでメールを送信する – Outlook VBA解析バイブル

Outlook VBAにおけるマルチアカウント制御の真髄：`Session.Accounts`を完全掌握し、誤送信事故を抹消するエンタープライズ構築論

現代のエンタープライズ環境において、単一のOutlookプロファイルに「個人用アカウント」「部門共通アカウント」「委託・グループ会社アカウント」など、複数のメールアカウントが紐付いている構成はもはや日常である。

しかし、Outlook VBAでメール送信ロジックを実装する際、多くの開発者が`Application.CreateItem(olMailItem)`の挙動を盲信し、「意図しない送信元アカウントからメールが差出され、情報漏洩事故やセキュリティポリシー違反を引き起こす」という致命的なバグを埋め込んでいる。

本稿では、実務中級者からシニアアーキテクトを目指すエンジニアに向けて、`Session.Accounts`コレクションの内部構造、MAPI層における送信アカウントの決定メカニズム、そしてCOMオブジェクトの決定論的解放までを考慮した、堅牢かつ安全なマルチアカウント制御手法を徹底解説する。

—

1. なぜ「デフォルト送信」は破壊的なのか？（アーキテクチャの真実）

Outlook VBAで単に以下のようなコードを書いた場合、送信元アドレスは何によって決まるのだろうか。

‘ 危険な実装例：送信元が環境依存になる
Dim mail As Outlook.MailItem
Set mail = Application.CreateItem(olMailItem)
mail.To = “target@example.com”
mail.Subject = “テスト”
mail.Send ‘ ← どのアカウントから送信されるかは不定！

結論から言えば、このコードの差出人は「現在アクティブなエクスプローラー（フォルダ画面）が所属しているアカウント」または「プロファイルの規定のアカウント」に動的に依存する。

システム管理者がバックグラウンド処理やタイマーイベントでメールを非同期送信させようとした場合、ユーザーのUI操作状況によって送信元アカウントがコロコロと変わってしまうのだ。

この問題を根本解決するためには、MAPIセッションのコンテキスト（`Application.Session`）から正しく`Accounts`コレクションを取得し、`MailItem.SendUsingAccount`プロパティへ目的のAccountオブジェクトを明示的に参照割り当てしなければならない。

—

2. Shared Mailbox（共有メールボックス）とMulti-Accountの構造的違い

実装に入る前に、エンタープライズ設計で最も混同される「マルチアカウント」と「共有メールボックス（代理送信/差出人変更）」の違いを整理しておく。ここを誤ると、コードは意図通りに動作しない。

`Session.Accounts`コレクションに存在するアカウントは前者の「マルチアカウント」のみである。共有メールボックスからの送信を制御したい場合は`SentOnBehalfOfName`プロパティにSMTPアドレスを指定するアプローチとなる。

今回は、最も事故が起きやすく、かつ正確なトランスポート制御が求められる「マルチアカウント環境（`SendUsingAccount`）」の完全制御に焦点を当てる。

—

3. 実践コード：堅牢なアカウント識別＆送信ルーチン

以下に、エンタープライズ環境の厳しい運用に耐えうるプロダクションクオリティのVBAコードを示す。

このコードは以下の要件を完全にクリアしている。
1. `Session.Accounts`を走査し、指定されたSMTPアドレスに一致するアカウントを大文字・小文字を区別せず（Case-Insensitive）探索する。
2. アカウントが存在しない場合は送信処理を直ちに中断し、適切なエラーハンドリングを行う（サイレントな不整合送信の防止）。
3. 送信後、使用したCOMオブジェクト（`Account`, `Accounts`, `MailItem`）の参照カウントを明示的に解放し、メモリリークを抑止する。

プロダクションコード：`mod_AccountMailSender.bas`

Option Explicit

‘ ==============================================================================
‘ 概要: 指定された送信元SMTPアドレスを使用して安全にメールを送信する
‘ 引数: strFromSmtp – 送信元として使用したいアカウントのSMTPアドレス
‘ strTo – 宛先アドレス
‘ strSubject – 件名
‘ strBody – 本文
‘ 戻値: Boolean – 成功時True、失敗時False
‘ ==============================================================================
Public Function SendMailTargetedAccount( _
ByVal strFromSmtp As String, _
ByVal strTo As String, _
ByVal strSubject As String, _
ByVal strBody As String) As Boolean

On Error GoTo ErrorHandler

Dim olApp As Outlook.Application
Dim olSession As Outlook.NameSpace
Dim olAccounts As Outlook.Accounts
Dim olTargetAccount As Outlook.Account
Dim olMail As Outlook.MailItem
Dim i As Long
Dim isAccountFound As Boolean

SendMailTargetedAccount = False
isAccountFound = False

‘ 1. MAPIセッションとAccountsコレクションの取得
Set olApp = Outlook.Application
Set olSession = olApp.Session
Set olAccounts = olSession.Accounts

‘ 2. Session.Accounts コレクションの完全走査
‘ 注: 1-indexed コレクションである点に注意
For i = 1 To olAccounts.Count
Set olTargetAccount = olAccounts.Item(i)

‘ SmtpAddressプロパティのNULLチェックおよび大文字小文字を無視した厳密比較
If Len(olTargetAccount.SmtpAddress) > 0 Then
If LCase$(Trim$(olTargetAccount.SmtpAddress)) = LCase$(Trim$(strFromSmtp)) Then
isAccountFound = True
Exit For
End If
End If

‘ 目的のアカウントでない場合はループ内で明示解放
Set olTargetAccount = Nothing
Next i

‘ 3. 指定アカウントの存在チェック（存在しない場合は安全に中断）
If Not isAccountFound Or olTargetAccount Is Nothing Then
Err.Raise vbObjectError + 1001, “SendMailTargetedAccount”, _
“指定された送信元アカウントが見つかりません: ” & strFromSmtp
End If

‘ 4. MailItemの作成と送信アカウントの明示的設定
Set olMail = olApp.CreateItem(olMailItem)
With olMail
‘ 最重要: 発信トランザクションに使用するアカウントオブジェクトのバインド
Set .SendUsingAccount = olTargetAccount

.To = strTo
.Subject = strSubject
.Body = strBody

‘ ※ビジネスロジックに応じて .Display または .Send を選択
‘ 送信前にMAPIトランスポートキューへ正しくロードされたことを確認して送信
.Send
End With

SendMailTargetedAccount = True

Cleanup:
‘ 5. COMオブジェクトの確定的な明示的解放（メモリリーク・参照残存の防止）
On Error Resume Next
If Not olMail Is Nothing Then Set olMail = Nothing
If Not olTargetAccount Is Nothing Then Set olTargetAccount = Nothing
If Not olAccounts Is Nothing Then Set olAccounts = Nothing
If Not olSession Is Nothing Then Set olSession = Nothing
‘ olApp は Application インスタンスのため解放は任意だが、安全のためNULL化
Set olApp = Nothing
On Error GoTo 0
Exit Function

ErrorHandler:
‘ ログ記録または呼び出し元への例外伝播
Debug.Print “[ERROR] ” & Err.Number & “: ” & Err.Description & ” (” & Err.Source & “)”
SendMailTargetedAccount = False
Resume Cleanup
End Function

‘ — テスト呼び出し用サブルーチン —
Public Sub Exec_TestSend()
Dim bResult As Boolean

‘ プロファイリングされている正確なSMTPアドレスを指定
bResult = SendMailTargetedAccount( _
strFromSmtp:=”sub-account@your-domain.com”, _
strTo:=”client@example.com”, _
strSubject:=”【自動送信】システムレポート”, _
strBody:=”本メールは指定アカウントより正常に送信されました。” _
)

If bResult Then
MsgBox “メール送信が正常に完了しました。”, vbInformation
Else
MsgBox “メール送信に失敗しました。ログを確認してください。”, vbCritical
End If
End Sub

—

4. チーフアーキテクトが教える極限の知見・ハマりポイント

実務で巨大なレガシーVBAシステムや、バッチ処理でOutlookを自動化する際に遭遇する「教科書には載っていない落とし穴」について解説する。

① `Account.SmtpAddress` が空を返す特殊ケース（POP3 / IMAP / Exchangeの挙動差）

ExchangeやOffice 365（Exchange Online）環境では、`Account.SmtpAddress` は常に正しくプライマリSMTPアドレスを返す。しかし、一部のレガシーなPOP3/IMAP4アカウント構成、あるいはサードパーティ製MAPIプロバイダでは、`SmtpAddress` プロパティが空文字列（`””`）を返すケースが稀に存在する。

万全を期すのであれば、フォールバックとして `Account.UserName` や `Account.DisplayName` の検証ロジックを組み込む設計が推奨される。

‘ SmtpAddressが空の場合のフォールバック判定ロジック例
Dim strAccAddr As String
strAccAddr = olTargetAccount.SmtpAddress

If Len(strAccAddr) = 0 Then
‘ POP3/IMAP等でSmtpAddressが取得できない場合の代替評価
strAccAddr = olTargetAccount.UserName
End If

② COM参照の未解放による `OUTLOOK.EXE` のプロセス残存問題

C#（.NET）からのCOMインターフェイス呼び出し（`Marshal.ReleaseComObject`）で有名な問題だが、純粋なVBA内部であっても、ループ処理内で `Accounts.Item(i)` を解放せずに大量生成したり、グローバル変数に `Account` オブジェクトを保持し続けたりすると、Outlook終了時にプロセスが正常終了せずタスクマネージャーに残存する現象が発生する。

前述のコードに示す通り、`For` ループ内および `Cleanup` ラベル下での `Set obj = Nothing` による決定論的解放（Deterministic Clean-up）を厳格に守らなければならない。

③ バックグラウンド処理時の Windows API によるダイアログ制御

Outlookのセキュリティ仕様（プロンプトGuard）により、外部プロセス（Excel VBAやAccess VBAなど）からOutlookの `Session.Accounts` にアクセスしメールを連続送信しようとすると、「プログラムが自動的にメールを送信しようとしています」という警告ダイアログが表示され、スレッドがストップすることがある。

これを回避・検知するために、シニアエンジニアは必要に応じて Win32 API を用いてOutlookウィンドウの最前面状態を制御したり、処理の非同期ブロックを回避するアーキテクチャを組む。

‘ （参考）ウィンドウ制御が必要な場合に用いられるWin32 API宣言パターン
If VBA7 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String) As LongPtr
Private Declare PtrSafe Function SetForegroundWindow Lib “user32” ( _
ByVal hwnd As LongPtr) As Long
Else
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String) As Long
Private Declare Function SetForegroundWindow Lib “user32” ( _
ByVal hwnd As Long) As Long
End If

※同一Outlookプロセス内（Outlook内VBA）で実行する分には送信警告は発生しないが、別OfficeアプリケーションからのMAPI連携（OLE Automation）を行う場合は、このMAPIセキュリティコンテキストの差が決定的なボトルネックとなることを覚えておいてほしい。

—

5. まとめ

Outlook VBAにおけるマルチアカウント制御は、単なるプロパティの代入作業ではない。それは「MAPIセッション構造の理解」「トランスポート層への明示的バインド」「COMライフサイクルの管理」が一体となった高度な設計領域である。

1. `Session.Accounts` を完全走査し、送信元アカウントを特定する。
2. `MailItem.SendUsingAccount` プロパティへ確定的にバインドする。
3. アカウントが見つからない場合は絶対に送信せず、例外として処理する。
4. 使用したオブジェクトは `Set = Nothing` で確実に破棄する。

この4原則を徹底することで、貴社・貴プロジェクトのVBAシステムから「送信元間違いによる誤送信トラブル」は永久に撲滅される。レガシー技術だからこそ、本質を理解した極限の堅牢性を追求していただきたい。