モジュールレベル変数とプロシージャレベル変数の境界線：メモリ消費を抑えるスコープ設計
VBA（Visual Basic for Applications）は、その手軽さゆえに「動けば正義」というプログラティズムが蔓延しがちだ。しかし、数万行規模の業務システムや、外部API連携、巨大なCOMオブジェクトを扱うアーキテクチャにおいて、変数のスコープ（有効範囲）とライフサイクル（寿命）を軽視する設計は、致命的なメモリリークとパフォーマンス低下を招く。
今回は、モジュールレベル変数とプロシージャレベル変数の境界線を厳密に引き直し、ガベージコレクションを持たないVBA環境下において「いかにメモリを支配するか」を、チーフアーキテクトの視点から徹底解説する。
—
1. 変数のライフサイクルとメモリの実態
VBAのランタイム（VBA7 / 32bit・64bit共通）において、メモリ管理の基本原則は「いつ生まれ、いつ消えるか」だ。
- プロシージャレベル変数 (`Dim` in Sub/Function):
プロシージャが呼び出された瞬間にスタック領域（またはヒープ）に領域が確保され、プロシージャが `End Sub` や `Exit Function` で抜けた瞬間に破棄される。
- モジュールレベル変数 (`Dim` / `Private` at Module Header):
プロジェクトが稼働している間、あるいはその標準モジュール/クラスモジュールがロードされている間、プロセスが終了するまでメモリ上に常駐し続ける。
- グローバル変数 (`Public`):
モジュールレベルと同様の寿命を持ちつつ、アプリケーション全体のどこからでも参照・書き換えが可能という、カプセル化の概念を破壊する諸悪の根源。
悪しきアンチパターン：すべての変数をモジュール上部に宣言する者たち
レガシーなコードベースで見かける「とりあえず上に変数書いとけ」というスタイルは、VBAのメモリモデルにおいて最悪の選択だ。使われていない間もメモリを占有し続け、さらにマルチインスタンス化や再入可能性（Reentrancy）を完全に殺す。
—
2. 境界線の設計思想：スコープを極限まで狭める理由
変数のスコープは「必要最小限」にするのがエンジニアリングの鉄則だ。これをVBAで実践する理由は単なる美学ではない。「ポインタの迷子」と「予期せぬ状態共有（State Pollution）」を防ぐためである。
以下のコードを見てほしい。モジュールレベル変数で状態を保持する悪例と、プロシージャレベルで完結させる正統派の比較だ。
【アンチパターン】状態が汚染されるモジュールレベル変数の乱用
‘ 悪しき標準モジュール: Module_Bad
Option Explicit
Private m_LastProcessedRow As Long ‘ モジュールレベル変数
Sub ProcessDataA()
m_LastProcessedRow = 100
‘ 何らかの処理…
Call SubRoutineX
End Sub
Sub ProcessDataB()
‘ ProcessDataAを通ったかどうかで挙動が変わるバグの温床
If m_LastProcessedRow > 0 Then
Debug.Print “前回の行数: ” & m_LastProcessedRow
End If
End Sub
この設計では、`ProcessDataB` を単体で実行したときの挙動が、直前にどのプロシージャが走ったかに依存してしまう。デバッグが極めて困難になる典型例だ。
【正統派】プロシージャ閉包と引数・戻り値による完全カプセル化
‘ 研ぎ澄まれた標準モジュール: Module_Good
Option Explicit
Sub MasterController()
Dim processedRow As Long
‘ データを局所化し、スコープをプロシージャ内に閉じ込める
processedRow = ProcessDataA()
Call ProcessDataB(processedRow)
End Sub
Private Function ProcessDataA() As Long
Dim localRow As Long
localRow = 100
‘ 処理…
ProcessDataA = localRow
End Function
Private Sub ProcessDataB(ByVal targetRow As Long)
If targetRow > 0 Then
Debug.Print “対象行数: ” & targetRow
End If
End Sub
変数の寿命はそれぞれのスコープの枠内に限定され、メモリは即座に解放される。状態の受け渡しは「引数」を介すことで、依存関係が明瞭になる。
—
3. オブジェクト変数の明示的解放とCOMの罠
数値や文字列といったプリミティブ型であればVBAのランタイムが自動的にメモリを回収してくれるが、問題は COMオブジェクト（`Worksheet`, `Range`, `Scripting.Dictionary`, ADODB.Connection など） である。
モジュールレベルでCOMオブジェクトを保持し続けると、Excelの終了時までメモリが解放されず、最悪の場合Excelプロセス（EXCEL.EXE）がタスクマネージャー上に残る（ゾンビプロセス現象）。
オブジェクトのライフサイクルを制御する厳格な作法
Option Explicit
Sub ExportDataToExternalAPI()
‘ 1. 宣言と同時に Nothing 初期化
Dim http As Object
Set http = Nothing
On Error GoTo ErrorHandler
‘ 2. 遅延バインディングによるAPIオブジェクト生成
Set http = CreateObject(“MSXML2.ServerXMLHTTP.6.0”)
http.Open “POST”, “https://api.example.com/v1/submit”, False
http.setRequestHeader “Content-Type”, “application/json”
http.send “{‘data’: ‘payload’}”
If http.Status = 200 Then
Debug.Print “Success: ” & http.responseText
End If
CleanUp:
‘ 3. 必ず明示的に Nothing を代入し、参照カウントをデクリメントする
If Not http Is Nothing Then Set http = Nothing
Exit Sub
ErrorHandler:
Debug.Print “Error: ” & Err.Description
Resume CleanUp
End Sub
【重要】 `Set http = Nothing` を省略するプログラマが多いが、VBAの参照カウンタ方式において、ローカルスコープを抜ける瞬間の暗黙的な解放に頼るのは甘えである。特にエラー発生時のジャンプ（`On Error Goto`）を経由した場合、参照が残ったままメモリリークを起こす確率が跳ね上がる。必ず `CleanUp` ラベル等で明示的に破棄せよ。
—
4. Windows API連携におけるメモリ管理の極限
システム間連携やパフォーマンスチューニングのために、Windows API（`kernel32` や `user32` など）をVBAから叩くシーンがある。ここでモジュールレベル変数の設計を誤ると、メモリ破損（Access Violation）によるExcelの強制終了を引き起こす。
特にメモリブロックの確保やポインタを扱う場合、変数の寿命管理は生死を分ける。
例：APIへ渡すバッファとメモリのスコープ管理
Option Explicit
‘ Windows APIの宣言（ウィンドウのテキストを取得する例）
If VBA7 Then
Private Declare PtrSafe Function GetWindowText Lib “user32” Alias “GetWindowTextA” (ByVal hwnd As LongPtr, ByVal lpString As String, ByVal cch As Long) As Long
Else
Private Declare Function GetWindowText Lib “user32” Alias “GetWindowTextA” (ByVal hwnd As Long, ByVal lpString As String, ByVal cch As Long) As Long
End If
Sub FetchWindowTitle(ByVal targetHwnd As LongPtr)
‘ バッファとして機能する文字列変数は、必ずプロシージャレベルで十分なサイズを確保する
Dim buf As String
buf = String(255, Chr$(0)) ‘ 255バイトのヌル終端バッファ
Dim retLength As Long
retLength = GetWindowText(targetHwnd, buf, Len(buf))
If retLength > 0 Then
‘ ヌル文字以降をトリミング
Debug.Print “Window Title: ” & Left$(buf, retLength)
End If
‘ プロシージャ終了と同時に buf が指すヒープ領域は安全に解放される
End Sub
もし、この `buf` をモジュールレベル変数として定義し回し飲みした場合、他の処理で予期せぬ文字列のゴミ（残骸）が混入したり、マルチスレッド（VBAはシングルスレッドだが非同期イベント等）での競合リスクを生むことになる。APIに渡す一時バッファは、常に最小スコープのプロシージャ内で完結させるべきだ。
—
5. チーフアーキテクトからの提言：クリーンアーキテクチャのVBAへの適用
VBAだからといって、設計の妥協をしてはならない。変数のスコープ設計は、コードの保守性、実行速度、メモリ効率のすべてに直結する。
1. 原則としてすべての変数はプロシージャレベル (`Dim`) で宣言せよ。
2. モジュールレベル変数 (`Private`) は、クラスのプロパティや、どうしても状態を共有せざるを得ない真のシングルトン的モジュールにのみ限定せよ。
3. `Public` 変数によるグローバル共有は、設計の敗北と心得よ。データは常に「引数」で渡し、「戻り値」で受け取れ。
4. COMオブジェクトは使い捨ての精神で扱い、用が済んだら即座に `Set obj = Nothing` で参照を断ち切れ。
メモリの制約が厳しいレガシーな現場や、ミッションクリティカルな自動化スクリプトにおいて、この変数ライフサイクルの厳格なコントロールこそが、プロとアマを分かつ絶対的な境界線である。
