【上級者向け】大量メール送信でOutlookが沈黙する日：メモリリークを完全撲滅するオブジェクト管理とプロセス制御の極意
開発プロジェクトのリーダーである私のもとに、よくこんな悲鳴が届く。
「夜間に数千件の自動送信バッチを回すと、朝にはOutlookがフリーズしているか、最悪の場合はPCごとクラッシュしている」
原因は明白だ。VBA初学者が書くようなコードをそのまま大規模処理に流し込み、「COMオブジェクトのライフサイクル」を完全に無視しているからに他ならない。
Outlook VBAにおける `CreateItem` や `GetNamespace` は、背後で重厚長大かつ複雑なCOM（Component Object Model）プロセスを動かしている。ループ内でこれらを生成し続け、適切に解放（破棄）しないと、ガベージコレクションが追いつかず、瞬く間にメモリリークを引き起こす。
今回は、数千件規模の連続送信であってもメモリ消費量を完全にフラットに保ち、フリーズとは無縁の「要塞のようなプロダクションコード」の設計思想と実装を伝授する。
—
1. なぜOutlookのループ処理はメモリリークを起こすのか
まずは「なぜ非効率なのか」をロジカルに理解しよう。
多くのエンジニアがやりがちなアンチパターンがこれだ：
‘ 【悪夢のアンチパターン】絶対にやってはいけない書き方
Sub BadLoop()
Dim i As Long
For i = 1 to 5000
Dim olApp As Object
Set olApp = CreateObject(“Outlook.Application”)
Dim mail As Object
Set mail = olApp.CreateItem(0)
mail.Subject = “テスト ” & i
mail.To = “target@example.com”
mail.Send
‘ ❌ ループ内で変数を解放せず、スコープを抜けてもCOM参照が残存する
Next i
End Sub
致命的な問題点
1. 暗黙のインスタンス生成と参照の蓄積: ループのたびに `CreateObject` や `CreateItem` を呼び出すと、OSのプロセス間に強烈なCOM参照のカウントが蓄積される。
2. VBAのガベージコレクションの限界: VBAのランタイムは賢くない。特にCOMオブジェクトは、明示的に `Nothing` を代入して参照カウンタをゼロに落とさなければ、メモリ空間にゾンビのように居座り続ける。
3. Outlookのセッション肥大化: `Send` メソッドを実行したメールオブジェクトが送信トレイや送信済みアイテムに絡みつき、プロセス内のメモリを圧迫し続ける。
—
2. バグを出さないための堅牢な設計原則
大量メール自動送信ツールを現場に導入するにあたり、以下の3原則を鉄則とする。
- 原則1：Applicationインスタンスはループ外で1度だけ生成する
Outlookのプロセスを何回も呼び出すのはリソースの無駄だ。1つのセッションを使い回せ。
- 原則2：使い捨てのオブジェクトはイテレーション（ループ）ごとに必ず `Nothing` を代入する
`MailItem` や `Recipients` などの子オブジェクトは、1通処理するごとに確実にメモリからパージする。
- 原則3：DBやファイル連携時は「例外処理」と「バッチ分割（チャンク）」を実装する
万が一のネットワーク切断やデータ不正に備え、500件〜1000件ごとに一度イミディエイトな小休止（DoEvents等）を挟むか、プロセスをリフレッシュする設計にする。
—
3. 【プロダクションコード】メモリリーク完全撲滅モデル
実務でそのまま使える、極限まで最適化された堅牢な送信プロシージャを公開する。
このコードでは、データベースやCSVからデータを読み込み、大量のメールを安定して捌く構造を想定している。
Option Explicit
‘ ==============================================================================
‘ 処理名: 堅牢な大量メール動的送信エンジン
‘ 概要 : オブジェクトのライフサイクルを完全に制御し、メモリリークを防ぐ
‘ ==============================================================================
Sub SendMassEmailsProductionModel()
Dim olApp As Object ‘ Outlook.Application (ループ外で1度のみ生成)
Dim olNs As Object ‘ NameSpace
Dim olMail As Object ‘ MailItem (ループ内で生成・破棄を繰り返す)
Dim i As Long
Dim totalCount As Long
Dim startTime As Double
startTime = Timer
totalCount = 5000 ‘ 例: 5000件の送信を想定
On Error GoTo ErrorHandler
‘ — 1. アプリケーションインスタンスの確立 (原則1) —
‘ 既に起動していればそれを捉え、なければ新規起動
Set olApp = CreateObject(“Outlook.Application”)
Set olNs = olApp.GetNamespace(“MAPI”)
olNs.Logon , , False, False ‘ 既存セッションを利用
‘ — 2. メインループ処理 —
For i = 1 To totalCount
‘ 毎回新しくMailItemを生成
Set olMail = olApp.CreateItem(0) ‘ 0 = olMailItem
With olMail
.Subject = “自動配信テストメール (No.” & i & “)”
.HTMLBody = “
いつもお世話になっております。
これはテスト配信 ” & i & ” 件目です。
”
.To = “client_” & i & “@example.com”
.BCC = “archive-log@example.com”
‘ 遅延送信やフラグ制御が必要な場合はここでプロパティ設定
‘ .DeferredDeliveryTime = DateAdd(“n”, 5, Now)
‘ 送信実行 (プロファイルや設定によっては送信トレイを経由)
.Send
End With
‘ — 3. イテレーションごとの厳格なオブジェクト解放 (原則2) —
‘ ここがメモリリークを防ぐ最大の肝
Set olMail = Nothing
‘ — 4. プロセス疲弊防止とUIフリーズ回避 —
‘ 100件ごとにOSに処理を返し、メモリの断片化を防ぐ
If i Mod 100 = 0 Then
DoEvents
Debug.Print i & “件送信完了。経過時間: ” & Format(Timer – startTime, “0.00”) & “秒”
End If
Next i
‘ 正常終了処理
MsgBox “全 ” & totalCount & ” 件の送信処理が正常に完了しました。”, vbInformation, “完了”
GoTo Finally
ErrorHandler:
‘ 予期せぬエラー時のハンドリング
MsgBox “重大なエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“内容: ” & Err.Description, vbCritical, “エラー”
Finally:
‘ — 5. ループ外オブジェクトの最終クリーンアップ (原則1の完結) —
Set olMail = Nothing
Set olNs = Nothing
Set olApp = Nothing
End Sub
—
4. チーフアーキテクトからの実践的アドバイス
上記のコードをベースに、さらに現場のシステムと連携させる際の注意点をいくつか共有しておこう。
① ファイルやデータベース（ADO）連携時の罠
もしCSVやExcel、あるいはSQL Serverからデータを取得しながらループを回す場合、「データリーク」と「COMリーク」のコンボに気をつける必要がある。
レコードセット（Recordset）やファイルストリームを開きっぱなしにせず、メール送信処理のブロックとは完全にスコープを分けるか、データは事前にメモリ上の配列（Array）にすべてロードし、VBAの高速なメモリ内処理とOutlook送信を分離させるのがセオリーだ。
② `.Send` と `.Save` の違いによる容量肥満
大量送信時に `.Send` を使う場合、Outlookの「送信済みアイテム」フォルダに何千ものメールが同期・保存される。これが原因でOutlookのデータファイル（PST/OST）が膨れ上がり、動作が重くなるケースがある。
もし送信控えをフォルダに残す必要がない、あるいは外部システム側でログを取っている場合は、以下のように送信済みアイテムへの保存を抑制するプロパティを活用するのも、長期運用におけるテクニックの一つだ。
(※ただし、監査要件などで保存が必須な場合はこの限りではない)
‘ 送信済みアイテムに保存しない設定（必要に応じて）
‘ olMail.DeleteAfterSubmit = True
—
総括
プログラミングにおいて「動くコード」を書くことはスタートラインに過ぎない。
「何時間稼働させてもリソースを食いつぶさない、タフなコード」を書くことこそが、プロフェッショナルな業務自動化エンジニアの仕事だ。
今回解説したオブジェクトのライフサイクル管理と適切なスコープの設計を取り入れれば、あなたの作るOutlook自動化ツールは、深夜のバッチ処理でもビクともしない、極めて高い信頼性を手に入れるはずだ。
