プロシージャ終了時の自動クリーンアップ：クラスモジュールのTerminateイベントを活用したリソース管理術
Excel VBAの現場において、未だに散見される悪習がある。膨大なオブジェクト変数を定義し、プロシージャの末尾で律儀に `Set obj = Nothing` を並べ立てるコードだ。
「メモリリークを防ぐためにすべての変数を解放している」
そうドヤ顔で語るジュニアエンジニアや、過去の遺物を踏襲し続ける保守担当者に問いたい。その手動解放、本当に意味があると分かってやっているのか？ そして、途中でエラーハンドリング（`On Error GoTo`）が発動し、ジャンプしてスキップされた解放コードの残骸をどう始末するつもりか。
VBAの実行環境（VBAコンテキスト）のライフサイクル、そしてCOMオブジェクトの参照カウンタの仕組みを理解していれば、プロシージャレベルのローカル変数に対する個別の `Set Nothing` がいかに無意味であり、逆に「書き手の保身」のための冗長なノイズに過ぎないかが痛感されるはずだ。
真に堅牢なVBAアーキテクチャとは、プロシージャの出口（出口の数さえ問わない）に依存せず、ランタイムのスコープ脱出とオブジェクトのライフサイクルを完全に同期させる自動クリーンアップ設計にある。
今回は、クラスモジュールの `Class_Terminate` イベントをハックし、外部リソース（Windows API、ADODB接続、COMオートメーションオブジェクト）の解放を完全に自動化・カプセル化する極限の知見を公開する。
—
1. VBAランタイムにおける変数解放の真実
まず、VBAのメモリ管理の根本を再確認する。プロシージャ内で宣言されたローカル変数は、そのプロシージャの実行コンテキストがスタック上に生成された時点で領域が確保され、プロシージャが終了（`End Sub` または `Exit Sub`）した瞬間に、VBAランタイムによって自動的に破棄される。
値型（LongやStringなど）はもちろん、オブジェクト変数（参照型）であっても、変数自体が保持していた「ポインタ（参照先）」はスコープの消滅とともに消え去る。
では、なぜ「明示的な解放」が必要だと言われるのか？
それは、COMオブジェクトが持つ「参照カウンタ（Reference Counter）」の存在ゆえだ。VBAからExcel以外のCOMコンポーネント（Word、Outlook、ADODB、あるいは独自作成のActiveX DLLなど）を生成すると、その実体の参照カウントがインクリメントされる。VBA側で変数に `Nothing` を代入するか、スコープが切れることで、VBAランタイムは内部的にそのオブジェクトの `IUnknown::Release` を呼び出す。これにより参照カウントがデクリメントされ、カウンタがゼロになった時点でOS上のメモリから実体が消滅する。
致命的な罠：「途中抜け」と「参照の循環」
ここに大きな落とし穴がある。
1. エラーによるジャンプ: `On Error GoTo ErrorHandler` でプロシージャ途中からジャンプアウトした場合、末尾に書いた `Set obj = Nothing` は実行されない。
2. 参照の循環（Circular Reference）: オブジェクトAがオブジェクトBを保持し、BもAを指している場合、スコープが切れても参照カウンタがゼロにならず、VBAプロセス内にゾンビメモリ（メモリリーク）が残留する。
これらを「人間の手動コーディング」で制御しようとすること自体が、設計の敗北である。すべての終了パスにおいて確実にクリーンアップを実行するには、「スコープを抜けることそのものをトリガーにする」仕組みが必要なのだ。
—
2. クラスモジュールによる「RAIIパターン」のVBA実装
C++におけるRAII（Resource Acquisition Is Initialization：資源取得は初期化時）の概念を、VBAのクラスモジュールで模倣する。
VBAにはデストラクタの構文はないが、クラスが破棄される直前に必ず発火する `Class_Terminate` イベントが存在する。これを利用する。すなわち、「管理したいリソースを包み込むラッパークラス」を定義し、そのクラスのスコープをプロシージャと同期させるのだ。
プロシージャが終了し、ローカル変数であるラッパークラスのスコープが切れた瞬間、VBAランタイムは自動的に `Class_Terminate` を呼び出す。その内部で、保持している重いリソースの解放やAPIの終了処理を完全に自動完結させる。
—
3. 実装例：Windows APIと外部リソースを制御する「AutoCleanerクラス」
以下の実装は、実務で頻出する「安全に閉じなければならないリソース（例：開いたファイルハンドル、高度なCOMオブジェクト、排他制御のミューテックス）」を自動管理するための実践的なコードである。
クラスモジュール名: `clsAutoResource`
Option Explicit
‘ 宣言セクション：管理対象のオブジェクトやハンドルを保持
Private m_TargetObject As Object
Private m_Handle As LongPtr
Private m_CleanupCallback As Scripting.Dictionary ‘ 必要に応じた拡張用
‘ 初期化イベント（コンストラクタの代替）
Private Sub Class_Initialize()
m_Handle = 0
Set m_TargetObject = Nothing
End Sub
‘ 終了イベント（デストラクタ）：スコープアウト時に強制発火
Private Sub Class_Terminate()
Call Me.ReleaseNow
End Sub
‘ 外部からリソースを登録するプロパティ
Public Sub Attach(ByVal TargetObj As Object, Optional ByVal Handle As LongPtr = 0)
Set m_TargetObject = TargetObj
m_Handle = Handle
End Sub
‘ 明示的、または自動実行される解放処理の実体
Public Sub ReleaseNow()
On Error Resume Next
‘ 1. Windows APIハンドルの解放（例としてのKernel32 API呼び出し）
If m_Handle <> 0 Then
‘ 実際には CloseHandle などのAPIをここに叩く
‘ 例: CloseHandle(m_Handle)
m_Handle = 0
End If
‘ 2. COMオブジェクトの解放
If Not m_TargetObject Is Nothing Then
‘ メソッドがあれば明示的にクローズ
m_TargetObject.Close
End If
Set m_TargetObject = Nothing
On Error GoTo 0
End Sub
呼び出し側標準モジュール
Option Explicit
Sub ExecuteComplexProcess()
‘ 自動クリーンアップクラスのインスタンスをローカル変数として宣言
Dim cleaner As clsAutoResource
Set cleaner = New clsAutoResource
‘ 重いCOMオブジェクトやAPIハンドルを生成・取得
Dim wsApp As Object
Set wsApp = CreateObject(“Word.Application”)
‘ クラスにリソースをアタッチ（これでライフサイクルが完全に委譲される）
cleaner.Attach wsApp
‘ — ここから業務ロジック —
wsApp.Visible = False
‘ 途中でエラーが発生するような複雑な処理を想定
If 1 = 1 Then
‘ 例として意図的な処理スキップやエラー脱出を想定
‘ ここで Exit Sub や Error が発生しても問題ない
‘ GoTo ErrorHandler
End If
‘ —————————-
‘ ※プロシージャの最後で明示的に `Set cleaner = Nothing` を書く必要すらない。
‘ End Sub に到達した瞬間、cleanerのスコープが切れ、Class_Terminate -> ReleaseNow が自動実行される。
End Sub
この設計の強みは、「プロシージャがどこで、どのような理由で終了しようとも、ローカル変数 `cleaner` がスタックからポップされる瞬間に必ずクリーンアップが走る」という点にある。開発者が「解放し忘れ」を起こす余地を構造的に排除しているのだ。
—
4. シニアエンジニアが知るべき「VBAメモリ管理の暗黒面と対策」
クラスモジュールの `Class_Terminate` による自動解放は強力だが、VBA特有のアーキテクチャ上の制約とバグについても熟知しておかなければならない。
1. アプリケーション異常終了時（Endステートメント）の罠
VBAコード内で `End` ステートメントが実行された場合、または実行時エラーによってVBAが強制停止した場合、すべてのクラスの `Terminate` イベントはバイパス（無視）される。
したがって、致命的なエラーハンドラーや `End` の多用は厳に慎むべきであり、異常系であっても適切にプロシージャの正常な出口（`Exit Sub`）へ誘導する設計が不可欠である。
2. 参照の循環（Circular Reference）によるメモリリークの発生
前述の通り、クラスAがクラスBを保持し、クラスBもクラスAをプロパティ等で保持している場合、お互いの参照カウンタが1残ったままとなり、スコープを抜けても `Class_Terminate` が絶対に呼ばれないという最悪のバグを引き起こす。
これを防ぐためには、親子関係の構築において「子から親への参照は保持しない（必要なら Weak Reference 的なポインタ処理や、親のインスタンスIDのみを保持する）」といった厳格な設計規約が必要となる。
3. DoEvents と非同期処理の競合
VBAからCOMオブジェクトを操作し、裏で非同期の処理を行わせている最中にプロシージャが終了し、`Terminate` によってオブジェクトが強制解放されると、COMサーバ側でアクセス違反（落ちる、またはハングアップ）を起こすケースがある。
これを防ぐためには、ラッパークラスの `Terminate` 内で、必要に応じて処理の完了を待機（ポーリング）させるか、あるいは安全にバックグラウンドタスクをキャンセルするシグナルを送るコードを組み込む必要がある。
—
5. チーフアーキテクトからの提言
「VBAだから適当でいい」「動けば正義」という時代はとうに終わった。レガシーと呼ばれるシステムであっても、その内部で稼働するロジックは、企業の重要なデータとリソースを扱っている。
変数の解放を人間の記憶力や注意力に依存するコードは、プロフェッショナルの仕事ではない。
言語仕様の隙間を突き、ランタイムのイベントライフサイクルをハックして「構造的に安全な状態を強制する」ことこそが、真のエンジニアリングである。
明日からあなたのコードベースにある無数の `Set xxx = Nothing` を削除し、代わりに堅牢なライフサイクル管理クラスを導入せよ。それこそが、保守性の地獄からVBAシステムを救い出す唯一にして最上のアプローチである。
