Outlook大量送信の「応答なし」を撲滅する。VBAアーキテクトが教える非同期制御の真髄
業務自動化の現場でよく見る光景がある。「数千件のメール送信ボタンを押すと、Outlookが真っ白になり、タスクマネージャーで強制終了するしかない」という悲劇だ。
これはVBAのせいではない。「プロセスの実行順序」と「UIスレッドの占有」に対する無知が生んだ設計ミスだ。
今日は、Outlookの内部構造を理解し、堅牢で「落ちない」メール送信エンジンを構築するための極限の知見を授ける。
—
なぜ `DoEvents` を適当に入れてはいけないのか
多くの初学者は、「とりあえずループの中に `DoEvents` を入れればフリーズしない」と教わる。これは半分正解で、半分は地獄への入り口だ。
`DoEvents` はOSに対して「制御を返せ」と命令するものだが、これを多用しすぎるとCPU負荷が急上昇し、かえって処理速度を低下させる。また、ユーザーが送信中に「×」ボタンを押してプログラムを中断させた場合、オブジェクトがメモリ上に中途半端に残る「ゾンビ状態」を招く。
堅牢な設計の鉄則
1. UIスレッドの開放は最小限に: `DoEvents` は10件〜50件に1回など、適度なインターバルで呼ぶ。
2. オブジェクトの生存期間（ライフサイクル）を短く: `MailItem` をループの先頭で生成し、送信直後に `Set = Nothing` で即座に解放する。
3. エラーハンドリングの孤立化: 1通の送信失敗が全体の崩壊を招かないよう、ループ内で完結するエラー制御を行う。
—
プロダクション環境に耐えうる「送信エンジン」コード
以下は、メモリリークを抑止し、UIの応答性を維持するプロトタイプだ。この構造をベースに、各々のDB連携ロジックを組み込んでほしい。
Option Explicit
‘ 大量送信時のフリーズを防ぐための定数
Private Const BATCH_INTERVAL As Long = 20
Public Sub SendBulkMails()
Dim olApp As Outlook.Application
Dim mailItem As Object
Dim i As Long
Set olApp = New Outlook.Application
‘ 送信リストのシミュレーション（実際はDBやCSVから取得）
For i = 1 To 1000
On Error Resume Next ‘ 個別メールの失敗を全体に波及させない
Set mailItem = olApp.CreateItem(0) ‘ olMailItem = 0
With mailItem
.To = “target-” & i & “@example.com”
.Subject = “業務自動化テスト: 第” & i & “報”
.Body = “自動送信テストです。”
.Send
End With
‘ オブジェクトの明示的解放（重要：これがメモリリークを防ぐ）
Set mailItem = Nothing
‘ UIの応答性を維持しつつ、負荷を抑える制御
If i Mod BATCH_INTERVAL = 0 Then
DoEvents
‘ 必要に応じて短いウェイトを置く（SMTPサーバーへの負荷軽減）
‘ Sleep 100
End If
On Error GoTo 0
Next i
Set olApp = Nothing
MsgBox “送信完了”, vbInformation
End Sub
—
現場で陥る「見えない罠」への対策
1. Outlookの送信トレイ（Outbox）の過負荷
コードで `.Send` を叩くと、メールは一旦「送信トレイ」に溜まる。数千件を一度に叩き込むと、Outlookの同期プロセスが追いつかなくなり、結果としてアプリがフリーズする。
- 解決策: 送信数が極端に多い場合、Outlookの「オフライン作業」モードで起動し、全メールを準備した後にオンラインに戻す等の運用上の工夫も検討せよ。
2. DB連携時のデータ整合性
大量送信中にネットワークが切断されると、どこまで送信したか分からなくなる。
- 解決策: 「送信済みフラグ」をデータベース側に持ち、トランザクション単位でコミットを行うこと。プログラムが落ちても、再開時に未送信分だけを抽出できる設計が、エンジニアとしての最低限のたしなみだ。
3. 添付ファイルという名の爆弾
`MailItem.Attachments.Add` をループ内で行う場合、ファイルパスの参照が重なるとパフォーマンスが劇的に落ちる。
- 解決策: 添付ファイルは事前読み込み（バイナリとしてメモリ保持）は避け、必ずフルパスで指定せよ。また、ファイルが存在しない場合の `On Error` は必須である。
—
アーキテクトからの提言
あなたが書くコードは、単なるスクリプトではない。業務を支える「自動化基盤」だ。
「動けばいい」という段階を卒業し、「予期せぬ中断が起きても安全に再開できるか」「メモリを食い潰していないか」という視点を持て。それができるようになった時、あなたの書くVBAは、誰にも文句を言わせない「堅牢な資産」に変わる。
まずはこのコードをコピーし、手元の環境でその安定性を体感してほしい。次に必要なのは、エラーログの書き出しと、再開ロジックの実装だ。それができれば、あなたはもう現場のリーダーだ。
