異常系こそアーキテクチャの真価が問われる：VBAにおけるメモリリーク防衛と確実なクリーンアップ戦略
Excel VBAは「手軽に動かせるプロトタイピング言語」として扱われがちだが、大規模な業務システムや他システム連携の基盤として稼働し始めると、その評価は一変する。ガベージコレクションの挙動がブラックボックスであり、COMオブジェクトの参照カウントの管理を誤れば、Excelプロセスそのものがメモリ上に残存し続ける（いわゆる「ゾンビプロセス」の発生）。
特に、`On Error GoTo`によるエラーハンドリングを行う際、「エラーが発生した瞬間にどの変数が何を保持しており、どこで処理が中断されたか」を完全に制御できていなければ、アプリケーションの信頼性は担保できない。
本稿では、レガシー環境からモダンなAPI連携までを支える、VBAのエラーハンドリングとメモリクリーンアップの極限の知見を解説する。
—
1. VBAにおけるメモリリークの根源：COMオブジェクトと参照カウント
VBAで最も恐れべきは、単なる数値や文字列変数のメモリリークではない。`ADODB.Recordset`、`Scripting.Dictionary`、あるいは外部アプリケーションのCOMオブジェクト（Excel、Word、Outlookなど）の解放漏れである。
VBAのランタイムは参照カウント方式（Reference Counting）を採用している。オブジェクト変数を `Nothing` に明示的に代入するか、スコープを抜けて自動解放されるまで、その参照カウントはゼロにならない。しかし、エラーによって処理が途中でジャンプ (`On Error GoTo`) した場合、正常系ルートに記述された `Set obj = Nothing` は実行されない。
これが、長期間稼働するExcelマクロが徐々に動作を重くし、最終的に「メモリ不足（Error 7）」を引き起こすメカニズムの正体である。
—
2. 実践的パターン：単一脱出路（Single Exit Point）アーキテクチャ
アマチュアのVBAコードによれば、エラーハンドラやプロシージャ内のあちこちに `Exit Sub` や `Set … = Nothing` が散らばっている。これでは保守性が著しく低下し、改修漏れによるリソースリークの温床となる。
プロフェッショナルなVBAアーキテクチャでは、「プロシージャの出口は必ず1つにする（Single Exit Point）」原則を徹底する。
以下に、異常系・正常系を問わず、確実にリソースを回収するための「クリーンアップ・パターン」の実装例を示す。
Option Explicit
Public Sub ExecuteEnterpriseProcess()
‘ — 変数宣言セクション —
Dim conn As Object ‘ ADODB.Connection
Dim rs As Object ‘ ADODB.Recordset
Dim fso As Object ‘ Scripting.FileSystemObject
Dim targetFile As Integer
‘ 初期化（オブジェクトは必ず Nothing で初期化）
Set conn = Nothing
Set rs = Nothing
Set fso = Nothing
targetFile = 0
‘ — エラーハンドリング有効化 —
On Error GoTo ErrorHandler
‘ —————————————————-
‘ 業務ロジック・外部リソース取得
‘ —————————————————-
Set conn = CreateObject(“ADODB.Connection”)
conn.Open “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Data\Master.accdb;”
Set rs = conn.Execute(“SELECT FROM T_TargetData WHERE Processed = 0;”)
Set fso = CreateObject(“Scripting.FileSystemObject”)
If Not fso.FolderExists(“C:\Output”) Then
fso.CreateFolder “C:\Output”
End If
targetFile = FreeFile
Open “C:\Output\Log.txt” For Output As #targetFile
Print #targetFile, “Process Started: ” & Now
‘ (ここに実際のデータ処理ループが入る)
‘ —————————————————-
‘ 正常終了ルート
‘ —————————————————-
GoTo CleanUp
ErrorHandler:
‘ —————————————————-
‘ 異常系ハンドリング
‘ —————————————————-
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“Error #[Err.Number]: ” & Err.Description, vbCritical, “System Error”
‘ 必要に応じたログ出力やロールバック処理をここに記述
‘ If Not conn Is Nothing Then conn.RollbackTrans
CleanUp:
‘ —————————————————-
‘ 確実なクリーンアップ処理（正常・異常共通の出口）
‘ —————————————————-
‘ 1. ファイルハンドルの閉局
On Error Resume Next ‘ クリーンアップ中のエラーによるハングを防ぐ
If targetFile > 0 Then
Close #targetFile
End If
‘ 2. COMオブジェクトの解放（逆順または個別にNothing代入）
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
If Not conn Is Nothing Then
If conn.State = 1 Then conn.Close
Set conn = Nothing
End If
Set fso = Nothing
‘ エラー情報のクリア
On Error GoTo 0
Exit Sub
End Sub
このパターンの要諦
1. 変数の二重初期化の防止: プロシージャ冒頭で必ず `Set xxx = Nothing` を行い、ゴミ参照を排除する。
2. `On Error Resume Next` の限定的使用: クリーンアップブロック内では、すでに閉じられているオブジェクトを閉じようとして発生するランタイムエラーを無視するため、一時的にエラーを無効化する。
3. リソース種別に応じた解放順序: 依存関係にあるオブジェクト（ConnectionとRecordsetなど）は、下位のオブジェクトから順に明示的にメソッド（Close等）を呼び出した上で `Nothing` を代入する。
—
3. Windows API連携とハンドルリークの防衛
外部システム連携や高度なファイル操作において、Windows API（`kernel32`, `user32`など）をVBAから直接呼び出すケースがある。APIが返すハンドル（Handle）やメモリポインタ（GlobalAlloc / LocalAlloc 等）は、VBAのガベージコレクションの範疇外である。
もしAPI呼び出し後にエラーが発生し、ハンドルを解放する関数（`CloseHandle`, `GlobalFree` など）をスキップした場合、OSのリソースが枯渇し、ExcelだけでなくWindowsのセッション自体が不安定になる。
APIを使用する場合のクリーンアップの鉄則を以下に示す。
‘ Windows APIの宣言例（プロセス終了時のハンドル解放などのイメージ）
If VBA7 Then
Declare PtrSafe Function CloseHandle Lib “kernel32” (ByVal hObject As LongPtr) As Long
Else
Declare Function CloseHandle Lib “kernel32” (ByVal hObject As Long) As Long
End If
Sub ProcessWithAPI()
#If VBA7 Then
Dim hFile As LongPtr
#Else
Dim hFile As Long
#End If
hFile = 0
On Error GoTo ErrorHandler
‘ APIによるリソース獲得（例）
‘ hFile = CreateFile(…)
‘ If hFile = -1 Or hFile = 0 Then Err.Raise 1000, , “APIリソースの獲得に失敗”
‘ 処理…
GoTo CleanUp
ErrorHandler:
MsgBox “API処理中にエラー: ” & Err.Description, vbCritical
CleanUp:
‘ ハンドルの確実な解放
#If VBA7 Then
If hFile <> 0 And hFile <> -1 Then
CloseHandle hFile
hFile = 0
End If
#Else
If hFile <> 0 And hFile <> -1 Then
CloseHandle hFile
hFile = 0
End If
#End If
On Error GoTo 0
End Sub
APIのハンドルは「数値（Long/LongPtr）」であるため、オブジェクトのように `Nothing` を代入することはできない。そのため、「無効値（0や-1）で変数を上書きする」ことで、二重解放や不正なメモリ領域へのアクセスを防ぐ防衛的プログラミングが必須となる。
—
4. レガシー環境におけるスコープとメモリ肥大化の罠
長年改修を重ねられたVBAプロジェクトの多くは、変数をすべてプロシージャの先頭で宣言し、グローバル変数やモジュールレベル変数が氾濫している。
モジュールレベル変数（`Private m_LargeArray() As Variant` など）は、そのクラスや標準モジュールが破棄されるまでメモリ上に常駐する。エラーハンドリングにおいて、これらモジュールレベルの変数の「状態クリア（初期化）」を怠ると、次に同じプロシージャが呼び出された際に、前回のゴミデータが残存したまま処理が走り、予期せぬバグやメモリひっ迫を引き起こす。
シニアエンジニアへの提言
1. 状態の局所化: 可能な限り変数はローカルスコープで宣言し、プロシージャ終了と共にスタック領域やローカルヒープから消滅させる構造にする。
2. オブジェクト配列の破棄: 動的配列やコレクションをモジュールレベルで保持している場合は、エラーハンドラ内、あるいはクリーンアップフェーズで必ず `Erase arr` や要素のクリアを強制すること。
—
5. まとめ
VBAにおけるエラーハンドリングの本質は、「派手なエラーメッセージを表示すること」ではない。「いかなる例外状況（異常終了、ユーザーによる強制中断、リソース枯渇）に直面しようとも、システムが使用したすべてのリソースを完璧に原状復帰させ、OSやExcelに負荷を残さないこと」である。
今回解説した「単一脱出路（Single Exit Point）パターン」と「明示的なリソース解放の徹底」は、VBAを玩具から「堅牢なエンタープライズ・システム基盤」へと昇華させるための必須の共通言語である。
コードを書くときは常に自問せよ。
「この行でエラーが起きた瞬間、確保したメモリは1バイト残らず回収されるか？」
この問いに淀みなく「Yes」と答えられるコードだけが、現場で生き残る真のプログラムである。
