大規模データ処理におけるメモリ解放の真実：Nothing代入のタイミングとスコープの寿命
VBA（Visual Basic for Applications）は、その手軽さゆえに「おもちゃの言語」と揶揄されることがある。しかし、我々シニアエンジニアが向き合う現場は、数百万行のデータ処理、外部COMコンポーネントの制御、そしてWindows APIを駆使した極限のシステム連携だ。この戦場でVBAを扱う時、メモリ管理のメカニズムを誤れば、Excelの強制終了（クラッシュ）や、プロセスがタスクマネージャーに残留し続ける「ゾンビプロセス問題」という悪夢に直結する。
特に、大規模データ処理におけるオブジェクトのライフサイクルとスコープの寿命管理は、VBAエンジニアの技量が最も色濃く出る領域だ。
本稿では、教科書的な「プロシージャを抜けたら自動で解放される」という神話を解体し、COMの参照カウントの本質と、`Nothing`代入の正しいタイミング、そしてメモリリークを根絶するための極限の知見を授ける。
—
1. VBAのメモリ管理の裏側：COM参照カウントとスコープの罠
VBAで扱う `Worksheet`, `Range`, `Scripting.Dictionary`, あるいは `ADODB.Recordset` などの実体は、すべてCOM（Component Object Model）オブジェクトである。これらはVBAの通常の変数領域ではなく、ヒープメモリ上で管理され、「参照カウント方式（Reference Counting）」によって生死が決まる。
スコープ終了時の挙動の真実
プロシージャ内で宣言されたローカル変数は、そのプロシージャが終了（`End Sub` または `Exit Sub`）した瞬間にスコープを抜け、変数の入れ物自体は破棄される。
しかし、「変数が破棄されたこと」と「参照されているCOMオブジェクトが解放されたこと」は同義ではない。
Excelの内部エンジン（COMサーバー）は、複数の参照が保持されている可能性を常に考慮している。変数のスコープが切れても、内部的な参照カウンタが0になっていなければ、オブジェクトはメモリ上に残り続ける。これが、長時間のバッチ処理やループ処理の中でメモリが徐々に枯渇していく根本原因である。
—
2. なぜ「暗黙の解放」だけでは不十分なのか
以下のコードを見てほしい。一見、何の問題もないように思えるだろう。
Sub BadProcessLargeData()
Dim i As Long
For i = 1 to 100000
Dim ws As Worksheet
Set ws = ThisWorkbook.Sheets(“Sheet1”)
‘ 大量のセル操作
ws.Cells(i, 1).Value = “Processing…”
‘ wsの解放を記述していない
Next i
End Sub
このコードは、VBAの仕様上、ループのイテレーションごとに `ws` 変数のスコープが新しく作られ、古い参照は上書きされていく。しかし、ExcelのCOMオブジェクトに対する内部ポインタの解放タイミングはVBAのガベージコレクタの気まぐれに依存するため、高速なループ内では参照カウントのデクリメントが追いつかない。結果として、メモリ消費量が右肩上がりに跳ね上がり、最悪の場合、エラー 7「メモリ不足」を引き起こす。
—
3. `Nothing` 代入の正しいタイミングとスコープ設計
メモリリークを確実に防ぐための鉄則は、「使い終わった瞬間に、自らの手で参照を断ち切る（`Set xxx = Nothing`）」ことだ。特に、ループ内や巨大なオブジェクトを扱うプロシージャでは、この規律が生死を分ける。
実践的アーキテクチャ：大規模データ一括処理の模範例
以下に、メモリを極限まで最適化したデータ処理プロシージャの設計を示す。
Option Explicit
‘ Windows APIの宣言（必要に応じてプロセス監視やメモリフラッシュに使用）
If VBA7 Then
Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
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 Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
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 AdvancedMassiveDataProcessor()
Dim conn As Object
Dim rs As Object
Dim wsTarget As Worksheet
Dim 判定Dict As Object
On Error GoTo ErrorHandler
‘ 1. オブジェクトの生成
Set wsTarget = ThisWorkbook.Sheets(“Result”)
Set 判定Dict = CreateObject(“Scripting.Dictionary”)
Set conn = CreateObject(“ADODB.Connection”)
‘ 2. 処理の実行（例：外部DBやファイルからの大量データ読込）
‘ （ここに高速化のための処理を記述。ScreenUpdating等の無効化は前提とする）
Application.ScreenUpdating = False
Application.Calculation = xlCalculationManual
‘ — メイン処理のシミュレーション —
Dim r As Long
For r = 1 To 50000
‘ 階層化されたオブジェクトアクセスは参照リークの温床
‘ 必ずローカル変数にキャッシュし、使い捨てる
Dim rngCell As Range
Set rngCell = wsTarget.Cells(r, 1)
rngCell.Value = “Data_” & r
‘ 使い終わったら即座に解放
Set rngCell = Nothing
Next r
‘ 3. 正常終了時のクリーンアップ
GoTo CleanUp
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
CleanUp:
‘ 4. 逆順での明示的解放（重要）
‘ 生成した順序とは逆に、依存関係の低いものからNothingを代入していく
If Not 判定Dict Is Nothing Then
判定Dict.RemoveAll
Set 判定Dict = Nothing
End If
If Not rs Is Nothing Then
If rs.State Then rs.Close
Set rs = Nothing
End If
If Not conn Is Nothing Then
If conn.State Then conn.Close
Set conn = Nothing
End If
Set wsTarget = Nothing
‘ 5. Excelの描画・計算モードの復元
Application.Calculation = xlCalculationAutomatic
Application.ScreenUpdating = True
‘ 6. OSへのメモリ返還要請（Windows APIの極限活用）
Call ForceReleaseMemory
End Sub
Private Sub ForceReleaseMemory()
‘ VBAが抱え込んでいた物理メモリのワーキングセットをOSに強制返還させる
Dim hProc As LongPtr
hProc = GetCurrentProcess()
‘ -1 を渡すことで、現在プロセスが必要とする最小限のメモリまでパージする
Call SetProcessWorkingSetSize(hProc, -1, -1)
End Sub
—
4. シニアエンジニアが知るべき「解放の鉄則」
上記のコード実装を踏まえ、現場で絶対に守るべき3つの知見を提示する。
① 参照の連鎖（ドットつなぎ）を排除せよ
`ThisWorkbook.Sheets(“Sheet1”).Range(“A1”).Value = 1`
このようなコードは一見スマートに見えるが、VBAの裏側で一時的なCOMオブジェクト（`Sheets`や`Range`）が暗黙裏に生成され、それらに対する参照をコード側で保持・解放する術がないため、一時的なメモリリークの温床となる。
大規模処理では、オブジェクトの取得は必ず1階層ずつ変数に代入し、使い終わったら個別に `Nothing` を代入せよ。
② 解放順序は「生成の逆順」
複数のCOMオブジェクトを制御する場合、親オブジェクトを子オブジェクトより先に解放してはならない。依存関係を考慮し、生成した順序とは逆の順序で `Set xxx = Nothing` を実行すること。
③ Windows APIによるメモリの物理パージ
VBAで数万行のデータ処理や外部COM（Excelの別インスタンス操作やWord連携など）を大量に行うと、VBA側で処理が完了しても、Windowsのプロセスがメモリを解放しきらない現象（ワーキングセットの膨張）が頻発する。
前述のサンプルコードで示した `SetProcessWorkingSetSize` APIの呼び出しは、レガシー環境や長時間稼働する常駐マクロにおいて、メモリプレッシャーを強制的にリセットする極めて強力な一手となる。
—
終わりに
VBAにおけるメモリ管理は、コンパイラ言語のような洗練されたガベージコレクションが存在しない以上、開発者自身の規律に委ねられている。「動けばいい」という妥協のコードは、やがて社内ニッチシステムの暴走を招き、メンテナンス担当者を絶望させる。
プロシージャの出口を制し、参照カウントのメカニズムを掌握し、適切なタイミングで `Nothing` を置く。この徹底的なディシプリンこそが、プロフェッショナルなVBAエンジニアと、その他大勢を分かつ境界線である。
