Outlook VBAの「応答なし」を撲滅せよ：大量送信を制御する極限の非同期設計
業務自動化の現場でよく見る「最悪の光景」がある。ループ内で `MailItem.Send` を連打し、Outlookが白濁して「応答なし」と表示され、最後にはプロセスごと強制終了する――。
VBAはシングルスレッドだ。しかし、Outlookの送信キューは別だ。この「非同期の非対称性」を理解せず、ただ `DoEvents` を挟めばいいと思っているなら、君のコードはただの「不安定な爆弾」だ。
今日は、プロの現場で通用する、堅牢かつスケーラブルな送信制御アーキテクチャを伝授する。
—
なぜ `DoEvents` だけでは不十分なのか
初心者は「重い処理の間に `DoEvents` を入れればフリーズしない」と教わる。半分正解だが、半分は甘い。
`DoEvents` はOSに制御を戻すためのものだが、「どのタイミングで、どれくらいの負荷をOSに返すか」の設計が抜けていると、イベントループが過負荷になり、かえって処理効率が低下する。また、連続送信はSMTPサーバー側のスロットリング（制限）に抵触し、アカウントの一時停止リスクも伴う。
我々が目指すべきは、「意図的な間隔制御（Throttling）」と「安全なイベントループ」の融合だ。
—
【プロダクションコード】堅牢な送信制御の実装
このモジュールは、指定した間隔で送信キューを捌く。単なるループではなく、`Timer`関数を用いた経過時間監視を行う設計だ。
Option Explicit
‘ 送信間隔（秒単位）- サーバー負荷を考慮し、最低でも1〜2秒は推奨
Private Const SEND_INTERVAL As Long = 2
”’
”’
Public Sub SendBulkEmails(targetList As Collection)
Dim mail As MailItem
Dim lastSentTime As Single
Dim i As Long
lastSentTime = Timer
For i = 1 To targetList.Count
‘ 1. メールの生成（抽象化を推奨）
Set mail = CreateMailItem(“宛先@example.com”, “件名”, “本文”)
‘ 2. 送信間隔の制御（非同期的な待機）
Do While (Timer – lastSentTime) < SEND_INTERVAL
' OSに制御を戻しつつ、CPU使用率を抑えるための微小な待機
DoEvents
' 24時を跨いだ時のTimerリセット対策
If Timer < lastSentTime Then lastSentTime = Timer
Loop
' 3. 送信実行
mail.Send
' 4. 次のループのために時刻を更新
lastSentTime = Timer
' メモリ解放の徹底（COMオブジェクトは即時解放が鉄則）
Set mail = Nothing
Next i
MsgBox "全送信完了", vbInformation
End Sub
Private Function CreateMailItem(toAddr As String, subject As String, body As String) As MailItem
Dim outApp As Outlook.Application
Set outApp = Outlook.Application
Dim item As MailItem
Set item = outApp.CreateItem(olMailItem)
With item
.To = toAddr
.Subject = subject
.Body = body
' 必要に応じて .Display で確認するか、直接 .Send させる
End With
Set CreateMailItem = item
End Function
---
開発者が知るべき「プロの注意点」
1. オブジェクトのライフサイクル管理
VBAの `Set = Nothing` は単なるマナーではない。OutlookのオブジェクトモデルはCOMベースであり、参照が残るとバックグラウンドでプロセスが生き続ける。特に大量送信時には、メモリリークが即座にパフォーマンス劣化に繋がる。`Set mail = Nothing` をループの直後に入れることは、メモリ負荷を平滑化するために不可欠だ。
2. ファイル連携・DB連携の罠
CSVやデータベースから宛先を読み込む際、「すべてメモリに展開して処理」してはならない。
数万件規模のリストなら、ADODB.Recordsetをカーソルモードで開き、1行ずつ読み込む設計にせよ。メモリを食いつぶすコードは、どんなにロジックが美しくても実務では「失敗」である。
3. 「送信済みトレイ」の肥大化対策
大量送信を行うと、自身の「送信済みアイテム」フォルダが数千件単位で埋まる。これはOutlook起動時のインデックス作成を極端に遅くする。可能であれば、送信後に特定のサブフォルダへ移動させるか、あるいは「送信済みアイテムに保存しない（`mail.DeleteAfterSubmit = True`）」オプションの使用も検討すべきだ。
—
まとめ：エンジニアとしての矜持
コードを書くとき、常に問いかけてほしい。
「もしこのプログラムが実行中に停電したら、どこまで送信済みか判別できるか？」
今回紹介したコードはベースに過ぎない。実務では、ここから「送信失敗時のログ記録」や「リトライ処理」を追加していくことになる。だが、まずはこの「送信間隔を制御し、OSを殺さない」というアーキテクチャを習得してほしい。
システムを止めるのは、複雑なバグではない。「設計の甘さからくる、予期せぬリソース枯渇」だ。
君の書くコードが、明日の業務を支える堅牢なインフラになることを期待している。
