【テクニカル・上級編】オブジェクト変数のSetとNothing：メモリリークを確実に防ぐ作法 – Excel VBA解析バイブル

オブジェクト変数のSetとNothing：メモリリークを確実に防ぐ極限の作法

VBA（Visual Basic for Applications）は、その手軽さゆえに「動けば正義」という文化が蔓延しやすい言語である。しかし、数万行規模の業務システムや、外部COMコンポーネント、Excelと他のプロセス（Word、Outlook、APIなど）を密連携させるミッションクリティカルな環境において、メモリ管理の無知は致命的な障害を引き起こす。

「処理が終わったから変数は勝手に消えるだろう」
「プログラムが終了すればメモリは解放されるはずだ」

もし君がそう考えているなら、今すぐその認識を改める必要がある。VBAの裏側でうごめくCOM（Component Object Model）のライフサイクルと参照カウンタの仕組みを理解していなければ、デスクトップアプリとしてのExcelは徐々にリソースを蝕まれ、やがて不可解な「メモリ不足」や「オートメーションエラー」を引き起こしてクラッシュする運命にある。

今回は、オブジェクト変数の `Set` と `Nothing` に焦点を当て、プロフェッショナルだけが知るメモリ管理の極限の知見を授けよう。

—

1. VBA裏社会の真実：COMオブジェクトと参照カウンタ

私たちがVBAで `Dim ws As Worksheet` や `Set ws = ThisWorkbook.Sheets(1)` と書いた時、何が起きているのか。

VBAのプリミティブ型（LongやStringなど）とは異なり、オブジェクト変数は実体を直接保持しない。保持しているのは「ポインタ（メモリ上のアドレス）」である。そして、背後にあるCOMオブジェクトは「参照カウンタ（Reference Counter）」という仕組みで管理されている。

• `Set ws = ThisWorkbook.Sheets(1)` が実行された瞬間、対象オブジェクトの参照カウンタが +1 される。
• 別の変数に代入したり、関数の引数として渡したりすると、さらに参照カウンタが増加する。
• 変数がスコープを抜ける、あるいは `Nothing` が代入されると、参照カウンタが -1 される。
• 参照カウンタが「0」になった瞬間初めて、COMオブジェクトはメモリ上から消滅（解放）する。

ここで問題になるのが、VBA特有の「スコープ終了時の暗黙の解放」のタイムラグと、循環参照、そしてExcelプロセス自体の居座り現象である。

—

2. なぜ `Set … = Nothing` が不可欠なのか？

「プロシージャを抜ければ自動で変数は解放されるのだから、わざわざ `Nothing` を代入する必要はない」という言説をよく耳にする。簡単なマクロであればそれは事実だ。しかし、以下のシチュエーションでは致命的なメモリリーク（あるいはゾンビプロセスの発生）を引き起こす。

1. 長寿命なオブジェクト（グローバル変数やクラスモジュール内のメンバ変数）
2. 大量のオブジェクトを生成・破棄するループ処理
3. 外部アプリケーション（WordやInternetExplorer、COMアドイン）の操作

特に、ExcelからWordや別インスタンスのExcelを操作する際、親オブジェクトの参照が残ったままExcelのプロセスを閉じようとすると、プロセスがバックグラウンドに残り続け（ゾンビプロセス）、次回起動時にファイルがロックされるなどの大惨事を引き起こす。

現場で頻発する最悪のアンチパターン

‘ 【悪夢のループ処理】
Sub BadMemoryLeakSample()
Dim i As Long
Dim xlApp As Object

For i = 1 to 10000
‘ 毎回新しいインスタンスを生成し、参照を上書きしているが元の参照は…？
Set xlApp = CreateObject(“Excel.Application”)
‘ 何らかの処理
xlApp.Quit
‘ Set xlApp = Nothing を書いていない！
Next i

‘ ループを抜けても、OSのメモリ上にはゾンビExcelが大量に残り続ける
End Sub

このコードを実行すると、タスクマネージャーのメモリ使用量がみるみる跳ね上がり、PCがフリーズするかVBA側で「メモリ不足（Error 7）」が発生する。`Set xlApp = Nothing` によって参照カウンタを強制的にゼロにしに行かなければ、ガベージコレクションのタイミングが制御できないVBAではメモリが解放されないのだ。

—

3. 実務で通用する「オブジェクト解放」の鉄則コード

では、巨大なデータ構造や外部COMを安全に扱い、確実にメモリを解放するための実践的なコードパターンを示そう。

エラーハンドリング（`On Error Goto`）を実装する場合、途中でエラーが発生してプロシージャが中断すると、`Nothing` を代入するコードに到達せずメモリリークを起こす。これを防ぐため、「単一終了地点（Single Exit Point）」の原則を適用する。

Option Explicit

Sub EnterpriseDataProcessor()
Dim wsTarget As Worksheet
Dim rngData As Range
Dim dictCache As Object

‘ エラーハンドラーの準備
On Error GoTo ErrorHandler

‘ — オブジェクトの生成と取得 —
Set wsTarget = ThisWorkbook.Sheets(“DataSheet”)
Set rngData = wsTarget.Range(“A1:Z10000”)

‘ 早期バインディングによるDictionaryの生成（参照カウンタ +1）
Set dictCache = CreateObject(“Scripting.Dictionary”)

‘ — メイン処理 —
‘ （ここに高速化のためのVariant配列処理などを記述）
Dim rawData As Variant
rawData = rngData.Value

‘ 処理ロジック…

‘ — 正常終了時のクリーンアップへ —
GoTo CleanUp

ErrorHandler:
‘ 致命的エラーのキャッチとログ出力
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical

CleanUp:
‘ — 確実なメモリ解放（LIFO: 後入れ先出しの順序が安全） —
‘ 1. コレクションや辞書の内部要素を先にクリアしてから破棄
If Not dictCache Is Nothing Then
dictCache.RemoveAll
Set dictCache = Nothing
End If

‘ 2. 範囲オブジェクトの解放
Set rngData = Nothing

‘ 3. ワークシートオブジェクトの解放
Set wsTarget = Nothing

‘ エラー状態のクリア
On Error GoTo 0
End Sub

このコードのアーキテクチャ的解説

• `If Not obj Is Nothing Then` のガード句: 既に解放されている、あるいは初期化に失敗して `Nothing` の状態の変数に対して `Nothing` を再代入しても問題はないが、明示的なチェックを入れることでコードの意図が明確になり、予期せぬオブジェクトエラーを防げる。
• 逆順（LIFO）での解放: 依存関係がある場合、生成した順番の逆（最後に使ったもの、末端のオブジェクトから）に `Nothing` を代入していくのがCOMプログラミングの鉄則である。

—

Windows API 連携時のハンドル解放の極意

さらにレベルの高い現場では、Excelのオブジェクトだけでなく、Windows API（例: `OpenProcess`, `CreateFile`, `FindWindow` など）を呼び出してOSリソースを直接触るケースがある。
これらはCOMオブジェクトではないため、`Nothing` では解放できない。「ハンドル（Handle）」という整数値を適切なAPI関数（`CloseHandle` など）で破棄しなければ、完全にメモリリーク（およびリソースリーク）を引き起こす。

‘ Windows APIの宣言例（プロセスハンドルの取得と解放）
If VBA7 Then
Private Declare PtrSafe Function OpenProcess Lib “kernel32” (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As LongPtr
Private Declare PtrSafe Function CloseHandle Lib “kernel32” (ByVal hObject As LongPtr) As Long
Else
‘ 3ッドレガシー環境への配慮（必要に応じた分岐）
End If

Const PROCESS_QUERY_INFORMATION As Long = &H400

Sub CallWindowsApiSafely()
Dim hProcess As LongPtr

‘ ハンドルの取得
hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, 0&, 1234) ‘ 1234はダミーのPID

If hProcess = 0 Then
MsgBox “ハンドルの取得に失敗しました。”, vbExclamation
Exit Sub
End If

On Error GoTo ApiErrorHandler

‘ — APIを利用した高度な処理 —

GoTo ApiCleanUp

ApiErrorHandler:
‘ エラー処理

ApiCleanUp:
‘ OSリソースの明示的解放（これが漏れるとWindows全体のメモリが枯渇する）
If hProcess <> 0 Then
CloseHandle hProcess
hProcess = 0 ‘ 念のため無効な値でクリア
End If

On Error GoTo 0
End Sub

VBAにおける `Set … = Nothing` と、APIにおける `CloseHandle`。
これらは本質的に同じ概念である。「自分が確保したリソースの責任は、自分で確実に（かつ確実に実行されるルートで）手放す」。この規律を守れないプログラマーに、大規模なVBAシステムの保守を任せることはできない。

—

4. チーフアーキテクトからの提言

レガシーとモダンが混在する現場において、VBAは依然として強力な自動化の武器である。しかし、それは「適切に管理されていれば」という強烈な条件付きだ。

「マクロが時々フリーズする」「Excelを閉じてもタスクマネージャーにプロセスが残り続ける」――もし君の管理するシステムでこれらの症状が見られるなら、それはコードのあちこちに野放しにされたオブジェクト変数の怨念（メモリリーク）に他ならない。

明日から、いや、今書いているコードから、すべてのオブジェクト変数に `Set` を使ったら、プロシージャの出口で必ず `Nothing` を返す習慣を徹底せよ。その厳格さこそが、アマチュアとプロのエンジニアを分かつ境界線である。