Outlook VBAを掌握する極限の知見：メモリリークを根絶する厳格なオブジェクト解放とGCシミュレーション
長年、数万通規模のメール自動化バッチや基幹システム連携の裏側を支えてきたエンジニアなら、一度は恐怖したことがあるはずだ。
——「最初は順調に動いていたプロセスが、数千件を超えたあたりから急激に重くなり、最終的にOutlookごとフリーズする、あるいはCOM例外でクラッシュする」
原因の多くは、VBAランタイムとCOMコンポーネント（Outlook Application）の間に巣食う「メモリリーク」である。
今回は、ドキュメントの隅にも書かれていない、Outlook COMオブジェクトのライフサイクルの真実と、メモリを極限まで最適化するための実践的アプローチを解説する。
—
1. なぜOutlook VBAはメモリリークを起こすのか？
VBA（Visual Basic for Applications）は、一見するとガベージコレクション（GC）を備えたモダンな言語のように錯覚しがちだが、その実態はCOM（Component Object Model）ラッパーの上で動くプリミティブな環境に過ぎない。
プログラマが `Set myItem = olNamespace.CreateItem(olMailItem)` と書いた瞬間、何が起きているか？
1. COM参照カウンタのインクリメント：Outlookプロセス（OUTLOOK.EXE）側でオブジェクトが生成され、ポインタの参照カウンタが上がる。
2. VBA側ランタイムのプロキシ生成：VBAのメモリ空間に、そのCOMオブジェクトを操作するためのCOMCallableWrapper（CCW）やRuntimeCallableWrapper（RCW）の影が作られる。
ここで発生する最大の罠が、「ドット（.）つなぎの暗黙的な参照」である。
‘ 【アンチパターン】これぞメモリリークの温床
Debug.Print Application.Session.GetDefaultFolder(olFolderInbox).Items.Count
この1行の裏で、`Application`、`Session`（NameSpace）、`GetDefaultFolder`（Folder）、`Items`（Items）という4つのCOMオブジェクトが背後で実体化している。しかし、変数に格納していないため、VBAはこの参照を明示的に解放する手段を持たない。結果として、Outlookプロセス側のメモリ空間にゾンビのような参照が残り続け、VBAの終了、あるいはOutlookの再起動まで解放されない。
—
2. 鉄則：すべてのCOMオブジェクトは「連鎖的」に解放せよ
大量送信や一括処理を行うループ内で上記のコードを書けば、数分でメモリは枯渇する。
これを防ぐ唯一にして絶対のルールは、「取得したすべてのCOMオブジェクトを変数に受け、スコープの抜け際、あるいはループの各イテレーションの最後に、必ず `Nothing` を代入して参照カウンタを明示的にデクリメントする」ことだ。
実装コード：完全解放を担保するメール一括生成エンジン
以下のコードは、数千件規模のメール作成において、メモリリークを完全に排除するための設計パターンである。
Option Explicit
Sub GenerateBulkEmailsWithoutMemoryLeak()
Dim olApp As Object
Dim olNs As Object
Dim olFolder As Object
Dim olMail As Object
Dim i As Long
‘ 1. Applicationオブジェクトの取得（CreateObjectではなくGetObject推奨：多重起動防止）
On Error Resume Next
Set olApp = GetObject(, “Outlook.Application”)
If olApp Is Nothing Then
Set olApp = CreateObject(“Outlook.Application”)
End If
On Error GoTo 0
If olApp Is Nothing Then
MsgBox “Outlookの起動に失敗しました。”, vbCritical
Exit Sub
End If
On Error GoTo ErrorHandler
‘ 2. 名前空間とフォルダの取得（独立した変数に分ける）
Set olNs = olApp.GetNamespace(“MAPI”)
Set olFolder = olNs.GetDefaultFolder(6) ‘ olFolderInbox
‘ 大量処理ループのシミュレーション（例：10,000件）
For i = 1 to 10000
‘ メールアイテムの生成
Set olMail = olApp.CreateItem(0) ‘ olMailItem
With olMail
.Subject = “自動生成メール #” & i
.Body = “メモリ最適化テスト送信です。”
.Recipients.Add “target@example.com”
.ResolveName
‘ 送信せずに下書き保存（または .Send）
.Save
End With
‘ 【極めて重要】ループの都度、生成したアイテムの参照を完全に断つ
Set olMail = Nothing
‘ 定期的にVBAのメモリ管理を促す（数千件ごとのパージ）
If i Mod 500 = 0 Then
DoEvents
End If
Next i
MsgBox “10,000件の処理がメモリリークなしで完了しました。”, vbInformation
CleanUp:
‘ 3. 上位オブジェクトの逆順での確実な解放
Set olFolder = Nothing
Set olNs = Nothing
Set olApp = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
—
3. GCシミュレーションとWindows APIによるメモリ監視
「本当にメモリが解放されているのか？」
シニアエンジニアたる者、感覚で語らず数値で証明できなければならない。VBA単体では正確なヒープ使用量やCOMの参照カウンタを観測できないため、Windows API（Kernel32.dll）を叩き、自プロセスのワーキングセット（メモリ消費量）をリアルタイムで監視・シミュレーションする手法を紹介する。
以下のコードを標準モジュールに実装し、処理の前後やループ内で呼び出すことで、メモリリークの有無を完全に可視化できる。
‘ 32ビット/64ビット環境両対応のAPI宣言
If VBA7 Then
Private Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
Private Declare PtrSafe Function ProcessIdToSessionId Lib “kernel32” (ByVal dwProcessId As Long, pSessionId As Long) As Long
Private Declare PtrSafe Function GetProcessMemoryInfo Lib “psapi.dll” ( _
ByVal hProcess As LongPtr, _
BypecProcessMemoryCounters As PROCESS_MEMORY_COUNTERS, _
ByVal cb As Long) As Long
Else
Private Declare Function GetCurrentProcess Lib “kernel32” () As Long
Private Declare Function GetProcessMemoryInfo Lib “psapi.dll” ( _
ByVal hProcess As Long, _
BypecProcessMemoryCounters As PROCESS_MEMORY_COUNTERS, _
ByVal cb As Long) As Long
End If
Private Type PROCESS_MEMORY_COUNTERS
cb As Long
PageFaultCount As Long
PeakWorkingSetSize As LongPtr
WorkingSetSize As LongPtr
QuotaPeakPagedPoolUsage As LongPtr
QuotaPagedPoolUsage As LongPtr
QuotaPeakNonPagedPoolUsage As LongPtr
QuotaNonPagedPoolUsage As LongPtr
PagefileUsage As LongPtr
PeakPagefileUsage As LongPtr
End Type
‘ 現在のVBAホスト（ExcelまたはOutlook）のメモリ消費量（MB）を取得する関数
Public Function GetCurrentMemoryUsageMB() As Double
Dim pmc As PROCESS_MEMORY_COUNTERS
Dim hProcess As LongPtr
pmc.cb = LenB(pmc)
hProcess = GetCurrentProcess()
If GetProcessMemoryInfo(hProcess, pmc, pmc.cb) <> 0 Then
‘ WorkingSetSize（物理メモリ使用量）をMB換算
#If VBA7 Then
GetCurrentMemoryUsageMB = CDbl(pmc.WorkingSetSize) / (1024 1024)
#Else
GetCurrentMemoryUsageMB = CDbl(CLng(pmc.WorkingSetSize)) / (1024 1024)
#End If
Else
GetCurrentMemoryUsageMB = 0
End If
End Function
監視の実践
これを先ほどのループ内に組み込み、`Debug.Print GetCurrentMemoryUsageMB()` を出力させてグラフ化してみるとよい。
正しく `Set olMail = Nothing` が機能していれば、メモリ使用量は緩やかなノコギリ波（ガベージコレクションの挙動）を描き、右肩上がりに発散することはない。逆に、`Nothing` を忘れた瞬間、メモリグラフは垂直に跳ね上がり、クラッシュへのカウントダウンが始まる。
—
4. チーフアーキテクトからの提言：レガシー環境の限界を超えるために
Outlook VBAによる自動化は強力だが、数百MB、数GB単位のメールデータを扱う領域に達した場合、VBAのシングルスレッド制約とCOMのオーバーヘッドは限界を迎える。
もしあなたが、
- 数万件の宛先へのダイレクトメール配信
- 添付ファイルの動的動的分割・暗号化を伴う高速バッチ
- クラウドAPI（Microsoft Graph API）とのハイブリッド連携
を求められているのなら、VBA単体での泥臭いメモリ管理に固執するべきではない。
COMオブジェクトのライフサイクル管理に疲弊したときは、COM Add-in（C# / .NET Framework or .NET Core）への移行、あるいはOutlookを介さずにSMTP/Graph APIを直接叩くアーキテクチャへのリプレイスを強く推奨する。
しかし、社内ニッチなインフラや、即時展開が求められる現場において、VBAは依然として最強の即効薬である。だからこそ、「オブジェクトを支配し、確実に解放する」というエンジニアリングの基本を極めること。それこそが、レガシーとモダンを繋ぐプロフェッショナルの矜持である。
