【極限のVBA】共有メールボックスから「確実に」送信するアーキテクチャの真髄
Outlook VBAを扱うエンジニアの多くが、共有メールボックス（Shared Mailbox）からの送信において「なぜか元の個人のメールアドレスで送られてしまう」「送信権限エラーで止まる」という壁に突き当たる。
これは単なるコードのミスではない。Outlookのオブジェクトモデルにおける「送信者（Sender）とアカウント（Account）の非対称性」を理解していないために起こる、設計上の敗北だ。今日は、堅牢かつセキュアな共有メールボックス送信の極意を、アーキテクトの視点から紐解く。
—
1. なぜ `.SentOnBehalfOfName` だけでは不十分なのか
初心者は `MailItem.SentOnBehalfOfName` を指定すれば解決すると信じている。だが、それはExchangeのキャッシュやプロファイル設定によっては不安定な挙動を示す。
真のプロフェッショナルは、「送信アカウント（Accountオブジェクト）を明示的に指定し、かつ送信者情報を同期させる」という二段構えのアプローチをとる。
送信元を切り替えるための核心ロジック
‘ 共有メールボックスから送信するための堅牢な関数
Public Sub SendFromSharedMailbox(ByVal TargetAddress As String, ByVal Recipient As String, ByVal Subject As String)
Dim olApp As Outlook.Application
Dim olMail As Outlook.MailItem
Dim olAccount As Outlook.Account
Set olApp = Outlook.Application
‘ 1. 対象となる共有メールボックスのアカウントオブジェクトを検索
Set olAccount = GetAccountByEmail(TargetAddress)
If olAccount Is Nothing Then
Err.Raise vbObjectError + 1000, , “指定された共有メールボックスがプロファイルに見つかりません。”
End If
‘ 2. MailItemの作成
Set olMail = olApp.CreateItem(olMailItem)
‘ 3. アカウントの動的バインド（ここが最重要）
‘ SentOnBehalfOfNameはあくまで表示上の制御であり、
‘ 通信層での送信元はSendUsingAccountで決定する
Set olMail.SendUsingAccount = olAccount
olMail.SentOnBehalfOfName = TargetAddress
With olMail
.To = Recipient
.Subject = Subject
.BodyFormat = olFormatPlain
.Body = “共有メールボックスからの自動送信テストです。”
‘ 送信前にバリデーションを行うのがアーキテクトの作法
.Save
.Send
End With
‘ メモリの解放：VBAのガーベジコレクションは信用するな
Set olMail = Nothing
Set olAccount = Nothing
End Sub
—
2. システム管理者が知るべき「権限とプロファイル」の暗部
共有メールボックスから送信できない原因の9割は、コードではなく「Outlookプロファイルに共有メールボックスが明示的に追加されていない」ことにある。
VBAから `SendUsingAccount` を指定する際、Outlookの `Session.Accounts` コレクションにそのアドレスが存在しなければ、当然ながらNullポインタ例外が発生する。
アカウント検索の最適化（パフォーマンス・チューニング）
毎回ループで全アカウントを走査するのは非効率だ。一度検索した結果はモジュールレベルの変数にキャッシュするか、あるいは起動時にハッシュマップ（Scripting.Dictionary）へ格納しておくべきだ。
Private Function GetAccountByEmail(Email As String) As Outlook.Account
Dim acc As Outlook.Account
For Each acc In Outlook.Application.Session.Accounts
‘ SMTPアドレスを比較し、前方一致や完全一致で安全に取得
If LCase(acc.SmtpAddress) = LCase(Email) Then
Set GetAccountByEmail = acc
Exit Function
End If
Next
End Function
—
3. エラーハンドリングの極限：権限不足を「予知」する
送信ボタンを押してから「アクセス許可がありません」というエラーをキャッチするのは三流の仕事だ。送信前に、現在のユーザーに「送信権限（Send As）」があるかを検証するロジックを組み込むのが、トラブルを未然に防ぐ唯一の道である。
APIレベルでの確認
もし高度な環境であれば、Exchange Online PowerShell (Remote PowerShell) をVBAから呼び出し、`Get-MailboxPermission` を実行して権限を事前確認する設計も検討せよ。`WScript.Shell` を経由して非同期で実行し、結果をCSV経由でVBA側が読み取る仕組みだ。
—
4. アーキテクトからの提言：メモリとライフサイクル
VBAにおいて「メモリリーク」は都市伝説ではない。特にOutlookの `NameSpace` や `MailItem` をループ内で生成・破棄する場合、明示的な `Set = Nothing` は必須だ。
- オブジェクトの解放: `Nothing` への代入は単なる儀式ではない。COMの参照カウンタを適切に減らさなければ、Outlookプロセスは背後で膨れ上がり、数日間の稼働でシステム全体を不安定にする。
- 例外の階層化: `On Error GoTo` を乱用せず、各メソッドごとにエラーハンドラーを局所化せよ。
結びに代えて
Outlook VBAは、正しく扱えば強力な自動化の武器となるが、不適切な設計は組織のメールインフラを麻痺させる諸刃の剣だ。
「共有メールボックスから送る」という単純な要件にこそ、そのエンジニアの「環境に対する敬意」と「オブジェクトモデルへの深い理解」が試される。
コードをコピペして満足するな。その背後にあるExchangeの認証フローと、Outlookのプロファイル構造をイメージできる者だけが、この領域を支配できる。諸君の健闘を祈る。
