Excel VBAを掌握する極限の知見：オブジェクト変数のSetとNothing — メモリリークを確実に防ぐ作法
こんにちは。大規模な業務自動化システムの設計・開発を率いるチーフアーキテクトの私だ。
日々の業務効率化のためにVBAを書く。「動くものが正義」として、とりあえずコードを書き散らしていないか？
もし、次のようなコードを平然と書いているなら、あなたのVBAプログラムは「目に見えないメモリの爆弾」を抱えていると言わざるを得ない。
‘ ありがちな危険なコード
Sub BadExample()
Dim ws As Worksheet
Set ws = Worksheets(“Data”)
ws.Range(“A1”).Value = “Processing…”
‘ 処理が終わったのでそのまま終了
End Sub
「プロシージャを抜ければ変数は消えるんだから、`Nothing`なんて不要だろ？」
そう思ったそこのあなた。その認識こそが、Excelの挙動を不安定にし、数日稼働させるとExcelごとフリーズする怪奇現象を引き起こす元凶なのだ。
今回は、Excel VBAにおけるオブジェクト変数のライフサイクル、そして`Set`と`Nothing`の正しい作法について、プロの現場で通用する極限の知見を授けよう。
—
1. なぜ「プロシージャ終了＝メモリ解放」という幻想が崩壊するのか
VBAのプリミティブ型変数（`Long`や`String`など）は、プロシージャが終了した瞬間にスタック領域から消え去る。しかし、オブジェクト変数は別格だ。
`Set ws = Worksheets(“Data”)` と書いた瞬間、何が起きているか？
Excelの内部では、COM（Component Object Model）という仕組みを通じて、C++で作られた重厚長大なExcel本体のオブジェクトへの「参照（ポインター）」がVBA側に渡される。この時、COMの参照カウンタが「＋1」される。
プロシージャが終了してVBA側の変数 `ws` が消滅しても、参照カウンタが即座にゼロになるとは限らない。特に以下のような悪条件が重なると、Excelプロセス内にゾンビのようなメモリ領域が居座り続ける。
- 複数のオブジェクトが複雑に参照し合っている（循環参照）
- 他アプリケーション（WordやOutlook、Accessなど）のCOMオブジェクトを操作している
- 巨大なワークブックやデータベース接続（ADODB）を保持している
これが、VBAにおけるメモリリークの正体だ。
—
2. 実務で必須となる「明示的な解放（Nothing）」の鉄則
メモリリークや「オートメーションエラー」を防ぐためのアプローチは極めてシンプルだ。
「使ったら、自分で責任を持って `Set xxx = Nothing` で参照を断ち切る」。これに尽きる。
特に以下の3つの場面では、`Nothing` による解放を義務化してほしい。
1. ループ内でオブジェクト変数を使い回すとき
2. 外部アプリケーション（Excel外）を操作するとき
3. エラーハンドリング（`On Error Goto`）を通る複雑な処理のとき
危険なループ内でのメモリ蓄積
例えば、大量のワークブックを順に開いて処理するマクロを想像してほしい。
‘ 【アンチパターン】ループ内で変数を上書きし続ける
Sub LoopMemoryLeak()
Dim i As Long
Dim wb As Workbook
For i = 1 to 100
Set wb = Workbooks.Open(“C:\Data\file_” & i & “.xlsx”)
‘ 何かしらの処理
wb.Close False
‘ Set wb = Nothing をしていない！
Next i
End Sub
このコード、一見問題なく動くように見えるが、内部的には古いワークブックの参照が解放されないまま新しい参照が上書きされ、ガベージコレクションのタイミングが掴めずにメモリ消費量がジワジワと増大していく。最悪の場合、途中で「メモリ不足」エラーで強制終了する。
—
3. 【プロダクションコード】堅牢性と保守性を極めた実務テンプレート
では、実務の現場でそのまま使える、堅牢なエラーハンドリングと適切なオブジェクト解放を組み込んだテンプレートを提示しよう。
このコードは、データベース（AccessやSQL Server等）からデータを取得し、Excelに転記した上で、各種リソースを確実に解放する設計になっている。
Option Explicit
Sub ProductionReady_DataImport()
‘ 1. 変数の宣言（スコープは最小限に）
Dim cn As Object D’ ADODB.Connection
Dim rs As Object ‘ ADODB.Recordset
Dim wsTarget As Worksheet
Dim query As String
‘ エラーハンドラーの有効化
On Error GoTo ErrorHandler
‘ 2. 画面描画の停止（パフォーマンス爆速化の基本）
With Application
.ScreenUpdating = False
.Calculation = xlCalculationManual
.EnableEvents = False
End With
‘ 3. オブジェクトの生成と取得
Set wsTarget = ThisWorkbook.Sheets(“ImportResult”)
wsTarget.Cells.Clear
‘ 外部接続のシミュレーション（ADODB）
Set cn = CreateObject(“ADODB.Connection”)
cn.Open “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Data\Master.accdb;”
query = “SELECT FROM M_Product WHERE Status = 1”
Set rs = cn.Execute(query)
‘ 4. データ転記
If Not rs.EOF Then
wsTarget.Range(“A2”).CopyFromRecordset rs
End If
‘ 正常終了時の処理へジャンプ
GoTo CleanUp
ErrorHandler:
‘ 異常時のハンドリング
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “システムエラー”
CleanUp:
‘ =========================================================================
‘ 5. 【最重要】作成した順とは逆の順序で、確実にオブジェクトを解放する
‘ =========================================================================
On Error Resume Next ‘ 解放時のエラーを無視して確実に最後まで実行させる
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
If Not cn Is Nothing Then
If cn.State = 1 Then cn.Close
Set cn = Nothing
End If
Set wsTarget = Nothing
‘ 6. アプリケーション設定の復元
With Application
.ScreenUpdating = True
.Calculation = xlCalculationAutomatic
.EnableEvents = True
End With
On Error GoTo 0
If Err.Number = 0 Then
MsgBox “処理が正常に完了しました。”, vbInformation, “完了”
End If
End Sub
アーキテクトからのコード解説
1. 逆順での解放: オブジェクトは依存関係の末端から順に閉じる（`Recordset` $\rightarrow$ `Connection` $\rightarrow$ `Worksheet`）。
2. `On Error Resume Next` の正しい使い方: クリーンアップ処理（`CleanUp:`ラベル以降）では、すでに閉じられているオブジェクトを操作してエラーになるのを防ぐため、一時的にエラーを無視する防護壁を張る。
3. Applicationプロパティの確実に復元: エラーで処理が中断した場合でも、画面描画停止や手動計算モードが解除されないまま放置される最悪の事態を防ぐ構造になっている。
—
4. まとめ：プロのVBAプログラマーへの第一歩
「動けばいいコード」から「保守しやすく壊れないコード」へ脱皮するために、今日から以下のルールを徹底してほしい。
- オブジェクト変数は使い捨ての意識を持つ。
- プロシージャの出口（正常系・異常系問わず）では、必ず `Set xxx = Nothing` で参照を断ち切る。
- 外部プロセス（ADO, Word, Outlookなど）を扱うときは、解放順序に細心の注意を払う。
この作法を身につけたあなたなら、もはや「なぜか動かないExcelファイル」に頭を悩ませることはなくなるはずだ。
セキュアで、エレガントで、プロフェッショナルなVBAコードを、次の開発現場からさっそく実装して見せてほしい。
