Outlook VBAを掌握する極限の知見：大量メール送信時のメモリリーク完全制圧とプロセス管理
`.CreateItem`。誰もが最初に叩くそのメソッドが、ループの渦中でどのようにVBAランタイムとOutlook（`OUTLOOK.EXE`）のヒープ領域を蝕んでいくか、君は本当に理解しているか？
「数千件のメールを一斉送信するバッチを組んだら、途中でOutlookがフリーズした」「タスクマネージャーのメモリ使用量が右肩上がりに膨れ上がり、最終的にCOM例外でクラッシュした」。
これは、多くの開発者が一度は通過する悪夢であり、そして多くのアマチュアが『VBAの限界』と誤認して諦めるポイントだ。
だが、ハッキリ言おう。限界なのはVBAではない。オブジェクトのライフサイクル管理とCOM相互運用性の本質を無視した、その場しのぎのコードだ。
今回は、数万件規模のエンタープライズ環境であっても、タスクマネージャーのメモリ波形を完全にフラットに保ち、ノーエラーで完走させるための「極限のメモリ管理術」を授けよう。
—
1. なぜOutlook VBAはメモリリークを起こすのか？
根本的な原因は、VBAランタイムとCOMコンポーネント（Outlookプロセス）の間にある参照カウンタ（Reference Counting）の非対称性にある。
VBAのコード内で `Set myMail = olApp.CreateItem(olMailItem)` と書いた瞬間、以下の2つの事象が発生している。
1. Outlookのプロセス（RPCサーバー）側で新しいMailItemオブジェクトが生成され、参照カウントがインクリメントされる。
2. VBAランタイム（COMクライアント）側に、そのオブジェクトを指し示すRCW（Runtime Callable Wrapper / 実際にはVBA固有のCOMラッパー）が生成される。
問題は、ループ内で `Set myMail = Nothing` を書かなかったり、あるいはドットつなぎのメソッドチェーン（いわゆる「アンチパターン」）を使用した場合だ。
‘ 【最悪のアンチパターン】
For i = 1 to 10000
‘ 参照されない隠れオブジェクト（インターフェース）がヒープに残留する
olApp.CreateItem(olMailItem).To = “test@example.com”
olApp.CreateItem(olMailItem).Send
Next i
このコードでは、変数に代入されなかった暗黙のCOMオブジェクトがガベージコレクションのタイミングを失い、Outlookプロセスのメモリ空間に幽霊のように居座り続ける。これが、数千回繰り返されたときに発生する「真のメモリリーク」の正体だ。
—
2. メモリリークを防ぐための鉄則：3つのアーキテクチャ
大規模送信バッチを設計する上で、シニアエンジニアが遵守すべき鉄則は以下の3点である。
1. すべてのCOMオブジェクト変数をループの各イテレーションで完全に解放する
2. ドットつなぎ（メソッドチェーン）を絶対に行わず、変数に受けてから明示的に破棄する
3. 一定のバッチサイズ（例：100件ごと）でガベージコレクションを強制し、COMプロセスの肥大化を防ぐ
これらを実装した、実戦投入レベルのプロダクションコードを提示しよう。
—
3. 【実装例】極限まで最適化された大量送信プロシージャ
以下のコードは、数千件の宛先に対して、メモリリークを1バイトたりとも発生させずにメールを生成・送信するアーキテクチャの完成形だ。
Option Explicit
‘ Windows API: プロセスのワーキングセット（物理メモリ）を最小化し、OSへのメモリ返還を促す
If VBA7 Then
Declare PtrSafe Function SetProcessWorkingSetSize Lib “kernel32” ( _
ByVal hProcess As LongPtr, _
ByVal dwMinimumWorkingSetSize As LongPtr, _
ByVal dwMaximumWorkingSetSize As LongPtr) As Long
Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
Else
Declare Function SetProcessWorkingSetSize Lib “kernel32” ( _
ByVal hProcess As Long, _
ByVal dwMinimumWorkingSetSize As Long, _
ByVal dwMaximumWorkingSetSize As Long) As Long
Declare Function GetCurrentProcess Lib “kernel32” () As Long
End If
Sub EnterpriseBulkEmailSender()
Dim olApp As Object
Dim olNs As Object
Dim olFolder As Object
Dim olMail As Object
Dim i As Long
Dim batchCount As Long
Const BATCH_FLUSH_SIZE As Long = 50 ‘ 50件ごとにメモリ最適化を実行
On Error GoTo ErrorHandler
‘ 1. Outlookアプリケーションインスタンスの取得（セーフバインド）
‘ 事前バインディング(New Outlook.Application)は参照切れを起こしやすいため、
‘ 大規模処理では実行時バインディング(CreateObject)を推奨する。
Set olApp = CreateObject(“Outlook.Application”)
Set olNs = olApp.GetNamespace(“MAPI”)
olNs.Logon , , False, False
‘ 2. メインループ
For i = 1 to 5000
‘ — 【重要】必ず変数に受ける（メソッドチェーン禁止） —
Set olMail = olApp.CreateItem(0) ‘ 0 = olMailItem
With olMail
.To = “target_” & i & “@example.com”
.Subject = “負荷テストメール #” & i
.Body = “これはメモリ管理テストの自動送信メールです。”
‘ 送信（.Sendを実行すると、Outlook内部でオブジェクトの状態が変化する）
.Send
End With
‘ — 【重要】即座にオブジェクト参照を破棄 —
Set olMail = Nothing
‘ 3. プロセス肥大化を防ぐためのパージ処理
batchCount = batchCount + 1
If batchCount >= BATCH_FLUSH_SIZE Then
‘ 参照の完全解放を確実にするためDoEventsを挟み、VBAランタイムにCPU時間を譲渡
DoEvents
‘ 定期的なメモリ解放（ワーキングセットの縮小）
Call ForceGarbageCollection
batchCount = 0
End If
‘ 進行状況の表示（ステータスバー）
If i Mod 10 = 0 Then
Application.StatusBar = “送信中… ” & i & ” 件完了”
End If
Next i
MsgBox “すべてのメール送信がメモリリークなしで完了しました。”, vbInformation
GoTo CleanUp
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
CleanUp:
‘ 4. すべてのルートオブジェクトの厳格な解放
Set olFolder = Nothing
Set olNs = Nothing
Set olApp = Nothing
Application.StatusBar = False
‘ 最終的なメモリクリーンアップ
Call ForceGarbageCollection
End Sub
‘ ——————————————————————————–
‘ @Summary: Windows APIを用いてVBA/Outlookプロセスの物理メモリ使用量を最適化する
‘ ——————————————————————————–
Private Sub ForceGarbageCollection()
Dim hProc As LongPtr
hProc = GetCurrentProcess()
‘ ワーキングセットの最小/最大サイズを強制的に絞り込み、OSにメモリを解放させる
‘ ※多用しすぎるとパフォーマンスに影響するため、バッチ処理の節目でのみ実行すること
Call SetProcessWorkingSetSize(hProc, -1, -1)
‘ COMのガベージコレクションを明示的に誘発
VBA.Set audible = Nothing ‘ トリガーとしてのダミー
GC_Collect
End Sub
Private Sub GC_Collect()
‘ 独自のCOM参照解放トリガー（VBA単体では完全なGCがないため、APIとDoEventsの併用が極意となる）
DoEvents
End Sub
—
4. コードの深層解説：なぜこの構造が必要なのか？
① 事前バインディング vs 実行時バインディング
大規模バッチにおいて、`Dim olApp As New Outlook.Application` のような事前バインディングは自殺行為だ。OutlookのCOMサーバーが何らかの理由で応答しなくなった際、参照がゾンビ化し、VBA側からコントロール不能に陥る。
`CreateObject(“Outlook.Application”)` による動的バインディングを使用し、例外発生時や処理終了時に確実に入口の参照(`olApp`)を断ち切る設計が必須である。
② Windows API `SetProcessWorkingSetSize` の真価
VBAやCOMオブジェクトがメモリを解放しても、Windowsのメモリマネージャーは「いつかまた使うかもしれない」という理由で、プロセスに物理メモリ（Working Set）を保持し続ける仕様になっている。
これが「タスクマネージャーで見るとメモリが増え続けているように見える」原因だ。
コード内で呼び出している `SetProcessWorkingSetSize(hProc, -1, -1)` は、OSに対して「現在不要になった物理メモリを即座に回収し、ページファイルへ退避または解放せよ」と直接命令する、極めて強力なシステムコールである。
③ ループ内での `Set olMail = Nothing` の不可欠性
VBAの変数は、スコープ（この場合は `Sub` 全体、あるいは `For` ブロック）を抜けるまでメモリ上に残り続ける特性がある。
もしループ内で `Set olMail = Nothing` を行わなければ、5000回のループ中、5000個すべてのMailItemラッパーオブジェクトがメモリ上に蓄積され続けることになる。これを毎回 `Nothing` に明示することで、COMの参照カウントをデクリメントし、即座にガベージコレクションの対象へと転送できるのだ。
—
5. チーフアーキテクトからの提言
システム開発において、「動けばいいや」で作られたコードは、プロトタイピングの段階では美しく見えても、実運用（インフラの長期稼働、数万件のデータ突合）という名の荒波に揉まれた瞬間、必ず牙をむく。
今回解説したメモリ管理とプロセス制御の思想は、Outlook VBAだけに留まらず、Excel、Word、あるいは外部COMコンポーネントを操作するすべてのVBAアーキテクチャに通じる「普遍的なエンジニアリングの極意」である。
もし君が、明日からも安定して稼働し続ける、真に堅牢な自動化システムを構築したいのであれば、コードの「見た目のスマートさ」に惑わされるな。
オブジェクトの生と死、そのライフサイクルを完全に支配しきること。 それこそが、プロフェッショナルの仕事である。
