1. イントロダクション：なぜ大量メール送信でOutlookは「沈黙」するのか
数千件規模のメールを一括生成・送信するバッチ処理をOutlook VBAで実行したとき、画面が白く濁り、タイトルバーに「応答なし」の文字が浮かび上がる――。システム管理者や社内開発者なら、誰もが一度は直面する悪夢である。
この現象の本質は、単なる「PCのスペック不足」ではない。
Outlookの本質的なアーキテクチャ、すなわちシングルスレッド（STA: Single-Threaded Apartment）モデルと、Windowsのメッセージループ（Queue）、そしてMAPI（Messaging Application Programming Interface）のセッション制限が複雑に絡み合った結果生じる、必然的な「システムの窒息」である。
多くの開発者は、この問題に対し安易に`DoEvents`をループ内に挿入する。しかし、それは別の地獄への入り口に過ぎない。
- 過剰なDoEventsによるパフォーマンスの極端な低下
- 再入（Reentrancy）による予期せぬ多重実行やクラッシュ
- COMオブジェクトの解放漏れによるメモリ（RPCチャンネル）の枯渇
本稿では、レガシーかつ現役であるOutlook VBAにおいて、数千件のメール送信を「ミリ秒単位の制御」と「完全な安定性」を両立させながら完遂するための極限の最適化技術を解説する。
—
2. アーキテクチャの核心：フリーズのメカニズムとボトルネック
最適化アルゴリズムを設計する前に、敵の正体を正確に把握する必要がある。Outlookがフリーズする原因は主に3つある。
① Windowsメッセージキューの滞留
Windowsのウィンドウ（Outlookのメインウィンドウやインスペクター）は、OSから送られてくるメッセージ（描画要求 `WM_PAINT`、マウスクリック `WM_LBUTTONDOWN` など）を「メッセージループ」で処理することで動作している。
VBAのループ処理がCPU（シングルスレッド）を占有し続けると、このメッセージループが完全に停止する。OSは応答を諦め、プロセスを「応答なし」と判定する。
② MAPI接続制限と「RPC制限」
OutlookはバックエンドでExchangeサーバーやローカルのPST/OSTファイルとMAPIプロトコルで通信している。
一回のアセンプリ（MailItemの作成）ごとに、MAPIは内部的にRPC（Remote Procedure Call）チャンネルを開放する。VBAでオブジェクトを明示的に破棄（`Set MailItem = Nothing`）しないままループを回すと、最大同時オープン接続数（通常255〜500程度）を瞬時に突破し、`「サーバーが利用できません」`あるいは`「メモリが不足しています」`という致命的エラーを吐いて沈没する。
③ `DoEvents` の罠：再入性（Reentrancy）
`DoEvents` は、一時的に制御をOSに返し、溜まったメッセージを処理させるコマンドである。一見万能に見えるが、メッセージキューを処理するということは、「実行中のVBAのトリガーとなったボタンを、ユーザーが再度クリックできる状態にする」ことを意味する。
これにより、同一の送信処理が多重起動し、コールスタックが破壊され、メモリ破壊（アクセス違反）による強制終了を引き起こす。
—
3. 解決策：プロアクティブなメモリ管理とハイブリッド待機
この課題を克服するため、我々は以下の3つのアーキテクチャを採用する。
1. ページング（バッチ）処理と「時間ベース」のDoEvents
すべてのループで `DoEvents` を呼ぶのは愚策である。1回呼ぶごとに数百ミリ秒のオーバーヘッドが発生するためだ。
「50件ごと」といったカウンタベース、あるいは「前回実行から500ミリ秒経過後」といった時間ベースのインターバルで実行するのが最適である。
2. 再入防止セマフォの実装
`DoEvents` を呼ぶ前に、モジュールレベルのフラグ（セマフォ）を立て、ユーザーによる二重実行や他のイベント割り込みを完全にシャットアウトする。
3. Windows APIによる高精度な非ブロッキング待機
VBAの標準機能にはミリ秒単位の待機関数が存在しない。`Application.Wait` は秒単位であり、その間スレッドを完全にロックする。
ここでは、Windows APIである `Sleep`、およびメッセージキューを監視しながら待機する `MsgWaitForMultipleObjects` の概念をハイブリッドで導入し、CPU使用率を0%に維持しつつOSに描画処理を行わせる。
—
4. 極限のVBA実装：堅牢な一括メール生成・送信エンジン
以下に、実戦に耐えうる極限まで最適化された堅牢な一括メール送信コードを示す。32bit/64bit双方のOffice環境に対応したWindows API宣言を内包している。
Option Explicit
‘ —————————————————————————–
‘ Windows API 宣言 (32bit / 64bit 互換)
‘ —————————————————————————–
If VBA7 Then
Private Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
Private Declare PtrSafe Function GetTickCount Lib “kernel32” () As Long
Else
Private Declare Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
Private Declare Function GetTickCount Lib “kernel32″ () As Long
End If
‘ —————————————————————————–
‘ グローバル/モジュール変数
‘ —————————————————————————–
Private m_IsProcessing As Boolean ‘ 再入防止セマフォ（多重実行フラグ）
”’
”’
Public Sub BulkMailSenderEngine()
‘ 二重起動防止
If m_IsProcessing Then
MsgBox “現在、別の送信処理が実行中です。割り込みは許可されていません。”, vbCritical, “セキュリティ警告”
Exit Sub
End If
m_IsProcessing = True
Dim outlookApp As Outlook.Application
Dim outlookNs As Outlook.NameSpace
Dim targetFolder As Outlook.MAPIFolder
Set outlookApp = Outlook.Application
Set outlookNs = outlookApp.GetNamespace(“MAPI”)
‘ 送信トレイ（Outbox）を明示的に確保
Set targetFolder = outlookNs.GetDefaultFolder(olFolderOutbox)
‘ ダミーの宛先リスト（実務ではデータベースやExcelシートから取得）
Dim totalMails As Long
totalMails = 1000 ‘ 例として1,000件
Dim i As Long
Dim mailItem As Outlook.mailItem
‘ パフォーマンス計測用
Dim startTime As Long
Dim lastYieldTime As Long
startTime = GetTickCount()
lastYieldTime = startTime
‘ バッチ制御用パラメータ
Const BATCH_SIZE As Long = 50 ‘ 50件ごとに強制ウェイト
Const YIELD_INTERVAL_MS As Long = 200 ‘ 200ミリ秒ごとにDoEventsを実行
Const SLEEP_DURATION_MS As Long = 100 ‘ 描画とスレッド解放のための待機時間
On Error GoTo ErrorHandler
‘ 大量処理の開始にあたり、画面描画の更新ストレスを低減（可能な限り）
‘ ※Outlook VBAには Application.ScreenUpdating がないため、設計でカバーする
For i = 1 To totalMails
‘ 1. MailItemの生成
Set mailItem = outlookApp.CreateItem(olMailItem)
‘ 2. メールのプロパティ設定 (COM参照を最小限にするため、ブロック内で処理)
With mailItem
.To = “recipient_” & i & “@example.com”
.Subject = “【重要】システム自動配信通知 (ID: ” & i & “)”
.BodyFormat = olFormatPlain
.Body = “本メールはシステムから自動送信されています。” & vbCrLf & _
“処理インデックス: ” & i & vbCrLf & _
“送信時刻: ” & Now()
‘ 送信トレイに格納（即時送信ではなく、キューイング）
.Save
.Send
End With
‘ 3. COMオブジェクトの明示的かつ即時の解放 (最重要)
‘ Closeメソッドを呼び、バッファを強制破棄。Nothing代入により参照カウントを確実にデクリメントする。
Set mailItem = Nothing
‘ 4. インターバル制御（DoEvents & Sleep のハイブリッド制御）
Dim currentTime As Long
currentTime = GetTickCount()
‘ 指定ミリ秒が経過している、またはバッチサイズに達した場合に割り込み処理を許可
If (currentTime – lastYieldTime > YIELD_INTERVAL_MS) Or (i Mod BATCH_SIZE = 0) Then
‘ Windowsに制御を戻し、メッセージキューをフラッシュ（フリーズ・「応答なし」の回避）
DoEvents
‘ CPUの占有を解き、他プロセス（Outlook本体の描画スレッド含む）にCPU時間を割り当てる
Sleep SLEEP_DURATION_MS
‘ 最終処理時刻の更新
lastYieldTime = GetTickCount()
‘ デバッグログ（必要に応じてイミディエイトウィンドウに出力）
Debug.Print “Processed: ” & i & ” / ” & totalMails & ” (Elapsed: ” & (lastYieldTime – startTime) & ” ms)”
End If
Next i
‘ 送信トレイの同期（強制的な送受信のトリガー）
‘ これを行わないと、送信トレイに溜まったまま送信が開始されない場合がある
outlookNs.SendAndReceive (True)
MsgBox “全 ” & totalMails & ” 件のメール送信処理が完了しました。” & vbCrLf & _
“総所要時間: ” & Format((GetTickCount() – startTime) / 1000, “0.00”) & ” 秒”, vbInformation, “処理完了”
CleanUp:
‘ オブジェクトの安全な解放（逆順）
If Not mailItem Is Nothing Then Set mailItem = Nothing
Set targetFolder = Nothing
Set outlookNs = Nothing
Set outlookApp = Nothing
m_IsProcessing = False
Exit Sub
ErrorHandler:
Dim errDetail As String
errDetail = “エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description & vbCrLf & _
“発生インデックス: ” & i
MsgBox “致命的なエラーが発生したため、処理を中断しました。” & vbCrLf & errDetail, vbCritical, “システムエラー”
Resume CleanUp
End Sub
—
5. コード解説：プロフェッショナルが施した設計意図
このコードには、単なる入門書には書かれていない、過酷な実務環境を生き抜くための仕掛けがいくつも施されている。
① `Set mailItem = Nothing` の絶対原則
ループ内で `mailItem` を使い回す際、`Next` に入る前に必ず `Set mailItem = Nothing` を実行している。
VBAのガベージコレクションは参照カウンタ方式である。これを行わない場合、ループが次のイテレーションに入っても、内部的なCOMラッパーがメモリ上に残存し続ける。これが数千件積み重なると、OutlookのMAPI層がクラッシュする。
② `DoEvents` と `Sleep` のハイブリッド・スロッリング
If (currentTime – lastYieldTime > YIELD_INTERVAL_MS) Or (i Mod BATCH_SIZE = 0) Then
この条件分岐が、本エンジンの心臓部（スロットル）である。
毎ループで `DoEvents` を呼ぶと、1万件の処理に10倍以上の時間がかかる。時間（ミリ秒）と件数（バッチサイズ）の論理和（OR）を取ることで、マシンの処理速度に依存せず、常に最適なタイミングでOSに制御を返すことができる。
③ セマフォ変数 `m_IsProcessing` による防御壁
`DoEvents` が実行されると、ユーザーはOutlookのUI（VBAを実行したボタンなど）をクリックできるようになる。
万が一、ユーザーが「フリーズしている」と勘違いしてボタンを連打した場合、このセマフォがないと同一マクロが多重でコールスタックに積まれ、メモリ競合（Access Violation）を起こしてOutlookごと強制終了する。これを完全に防いでいる。
—
6. 本番運用における最終チェックリストとレガシー環境の保守
社内システムやクライアントのレガシー環境にこのコードを組み込む際、以下の実務的な壁にぶつかることがある。事前にこれらをクリアしておくこと。
1. 「プログラムによる電子メールの送信」警告への対処
Outlookのセキュリティ設定によっては、サードパーティ（VBA含む）からの自動送信に対して「プログラムが自動的にメールを送信しようとしています」という警告ポップアップが表示され、処理が1件ごとにストップする。
- 対策: クライアントPCのウイルス対策ソフトが「有効（有効期限内）」であることをWindowsが認識していれば、この警告は表示されない。GPO（グループポリシー）で「プログラムによるアクセス」を「警告を表示しない」に変更するか、社内システムであればデジタル署名（自己署名証明書: Self-Cert）をVBAプロジェクトに付与して「信頼できる発行元」に登録する。
2. OST/PSTファイルの書き込み遅延（ディスクI/Oボトルネック）
`mailItem.Send` を実行した瞬間、メールは即座にインターネットに飛び立つわけではない。一度ローカルの「送信トレイ（OST/PSTファイル）」に書き込まれる。
ディスクのI/O速度（特にHDD環境や、ネットワークドライブ上にPSTを置いている極悪な環境）が遅い場合、VBAの処理速度がディスク書き込み速度を上回り、書き込みキューが溢れてエラーになる。
- 対策: `BATCH_SIZE` を小さくし（例: 20）、`SLEEP_DURATION_MS` を長め（例: 300）に設定して、ディスクへのフラッシュ時間を意図的に確保する。
3. Exchange Serverの受信コネクタ流量制限（Throttling）
オンプレミスのExchangeやMicrosoft 365（Exchange Online）には、1アカウントあたりの「1分間あたりの送信上限数」が厳格に定められている（例：M365では1分間に最大30通など、プランによる）。
これを超えると、サーバー側から送信を拒否され、送信トレイに残ったままエラーが返される。
- 対策: 大量送信を行う場合は、あらかじめインフラ担当者に「送信レート制限（Rate Limit）」の緩和を申請するか、VBA側で1件送信ごとに意図的に `Sleep 2000`（2秒待機）などを挟み、サーバーのポリシーを遵守する設計（ポリシー・シェーピング）を行うこと。
—
7. 結言
大量メール送信という、一見単純なタスクこそ、エンジニアの「OSとCOMに対する理解の深さ」が如実に現れる。
単に動くだけのコードから、「システムのライフサイクルを完全にコントロールし、いかなる高負荷環境でも沈黙しない極限のコード」へ。本稿に示した知見を、貴方のシステムの守護神として役立ててほしい。
