【VBA深層】異常系における「負の遺産」を断つ：生存変数とメモリ汚染の完全制御
業務自動化の現場で最も恐ろしいのは、エラーそのものではない。「エラーによって中途半端に書き換えられた変数が、次回実行時に正当な値として誤認されること」だ。
VBAは、C#やJavaのような厳格なガベージコレクションを持つモダン言語ではない。`On Error Resume Next` の乱用がもたらすメモリ上の「亡霊」が、いかにして企業の業務基盤を蝕むか。今日は、伝説的なアーキテクトの視点から、異常終了時の状態管理とクリーンアップの極限技法を伝授する。
—
1. 異常系が変数を「汚染」するメカニズム
VBAの変数は、プロシージャのスコープを抜けない限り、その値を保持し続ける。特に静的変数（`Static`）やモジュールレベル変数は顕著だが、ローカル変数であっても、実行時エラーで処理が中断された際、`Err`オブジェクトのクリア漏れと相まって、メモリ空間が汚染される。
なぜ「中途半端な再実行」が致命的なのか
複雑なシステム連携（API呼び出しやファイルI/O）において、エラー発生時に「状態フラグ」や「キャッシュ」が中途半端に更新されたままだと、次の実行時に誤ったロジックがトリガーされる。これが「再現性のないバグ」の正体だ。
—
2. 鋼鉄のクリーンアップ設計：`Finally` パターンの実装
VBAには標準で `try-finally` 構文がない。しかし、我々は「ラベル」と「GoTo」を駆逐するのではなく、むしろそれを活用して「単一出口（Single Exit Point）」を強制するアーキテクチャを構築する。
実践的コード：クリーンアップ・テンプレート
Public Sub ExecuteCriticalTask()
‘ 外部リソース（API接続用オブジェクト等）の宣言
Dim http As Object
‘ エラーハンドラの設定
On Error GoTo ErrorHandler
‘ 初期化処理
Set http = CreateObject(“MSXML2.XMLHTTP”)
‘ — メインロジック —
‘ 複雑なAPI連携処理など
‘ 正常終了時へ飛ぶ
GoTo CleanUp
ErrorHandler:
‘ 異常発生時のログ出力と通知
Debug.Print “Error: ” & Err.Description
‘ 必要に応じてAPI側のセッション終了信号を送る等の処理
CleanUp:
‘ 正常・異常に関わらず必ず実行される終了処理
‘ オブジェクトの明示的解放はメモリ最適化の要
If Not http Is Nothing Then
Set http = Nothing
End If
‘ エラーオブジェクトの完全リセット
Err.Clear
End Sub
—
3. レガシー環境におけるメモリ最適化の極意
特にWindows APIを多用する環境では、オブジェクトの参照カウンタが0にならず、メモリリークが蓄積されるケースが後を絶たない。
究極のメモリ解放術
単に `Set obj = Nothing` をするだけでは不十分な場合がある。特に `ComObject` がバックグラウンドでプロセスを掴んでいる場合、以下の手法を検討せよ。
1. 明示的な `Quit` / `Close` メソッド: `Application` オブジェクトや `Connection` オブジェクトは、解放前に必ず終了メソッドを呼び出す。
2. スコープの細分化: 巨大なプロシージャを避け、生存期間を最小化する。オブジェクトを保持する変数は、必要最小限のスコープに押し込め。
3. APIによる強制クリーンアップ: 稀なケースだが、メモリが逼迫した際には `SetProcessWorkingSetSize` APIを呼び出し、プロセスのワーキングセットを最適化する荒技も存在する。
—
4. システム間連携における「状態の正規化」
システム連携において、エラーハンドリングは「単なるログ記録」ではない。「システムを、実行前のクリーンな状態へ巻き戻す（ロールバックのシミュレーション）」ことこそが本質だ。
アーキテクトの戒律
- 変数の初期化は宣言と同時に行う: VBAにおいて `Dim` はメモリ確保に過ぎない。可能な限り `Initialize` 処理をセットで行え。
- グローバル変数の使用禁止: 異常時にどこが状態を書き換えたか追跡不能になる。依存関係注入（DI）の概念をVBAで模倣し、クラスのプロパティとして管理せよ。
- フラグの二重チェック: APIのレスポンスを受信する際、`Status = 200` だけを見るな。前回の実行結果が残っていないか、タイムスタンプやユニークなIDと照合するガード句を必ず入れよ。
—
結論：システムは「壊れること」を前提に設計せよ
VBAコードを書く際、「エラーが起きないこと」を期待してはならない。「エラーが起きた瞬間に、メモリがどれほど汚染され、再実行時にどれほど有害な影響を及ぼすか」を想像し、それを無力化するクリーンアップ処理を実装すること。
それが、レガシーシステムを十年先まで延命させるための、唯一の道である。
貴殿のコードが、異常系においても静謐であることを願う。
