エラーハンドリングと変数の初期化：On Error GoTo発生時の変数状態の整合性管理
VBAにおける `On Error GoTo` は、多くの開発者が日常的に使用する基本的な構文である。しかし、この構文が発動した瞬間に、メモリ空間や変数群がどのような状態に置かれるかを深く理解している者は少ない。
アマチュアは「エラーが出たらエラー処理ラベルにジャンプしてメッセージを出せばいい」と考える。だが、シニアエンジニアやミッションクリティカルなシステムを預かるアーキテクトが懸念するのは、「エラー発生時の不整合な状態のまま継続・終了するプロセスが、他のリソースに与える致命的な影響」である。
特に、Windows APIの動的リンク、COMオブジェクトの参照保持、動的配列のメモリリーク、そしてトランザクションの未解放が絡むシステムにおいて、エラー発生時の変数状態の管理は死活問題となる。
本稿では、VBAのランタイムが抱えるエラーと変数のライフサイクルの闇を暴き、極限の環境下でも破綻しない堅牢なエラーハンドリングの設計思想を解説する。
—
1. `On Error GoTo` 発生時の変数状態の「本当の姿」
VBAのエラーハンドラーへジャンプした瞬間、プロシージャ内の変数は以下のような状態に陥る。
- 値型（Long, Stringなど）: エラー発生直前の値が保持されるが、それが「処理途中の中途半端な状態」であることに気づけない。
- オブジェクト型（Object, ADODB.Connectionなど）: メモリ上にインスタンスが残留したまま、参照カウントのデクリメントがスキップされるリスクがある。
- エラーフラグやステータス変数: 「どこまで処理が進んだか」を示す状態変数が曖昧なままトラップに入るため、クリーンアップ処理の分岐を誤る。
とりわけ、「エラーが発生した行の直前までどのような操作が行われていたか」が揮発するため、部分的に書き換わったデータや、開いたままのファイルハンドル、ロックされたデータベースのレコードが放置されるのが最大の脅威である。
—
2. 堅牢なエラーハンドリングの基本構造：三層防御モデル
プロダクション環境に耐えうるコードでは、エラーハンドリングを「正常系」「終了・クリーンアップ系」「例外捕捉系」の3つの層に厳密に分離しなければならない。
以下のコードは、Windows APIの呼び出しとCOMオブジェクトの操作を内包する処理において、変数の整合性を完全に担保するテンプレートである。
Option Explicit
‘ サンプルとしてのWindows API宣言（メモリ管理やプロセス制御を想定）
If VBA7 Then
Private Declare PtrSafe Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
Else
Private Declare Sub Sleep Lib “kernel32” (ByVal dwMilliseconds As Long)
End If
Public Sub ExecuteMissionCriticalProcess()
‘ — 【層1: 宣言と初期化（スコープの明確化）】 —
Dim wsTarget As Worksheet
Dim cnDB As Object // 外部接続用COMオブジェクト
Dim lngProcessID As Long
Dim blnTransActive As Boolean
‘ 異常時に誤動作を防ぐため、すべての変数を確実に初期化
Set wsTarget = Nothing
Set cnDB = Nothing
lngProcessID = 0
blnTransActive = False
On Error GoTo ErrorHandler
‘ — 【層2: 正常系ビジネスロジック】 —
Set wsTarget = ThisWorkbook.Sheets(“DataSheet”)
‘ COMオブジェクトの生成
Set cnDB = CreateObject(“ADODB.Connection”)
cnDB.Open “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=” & ThisWorkbook.Path & “\data.accdb”
‘ トランザクション開始
cnDB.BeginTrans
blnTransActive = True
‘ 何らかの重い処理（ここでエラーが発生する想定）
‘ 例: 存在しないセルへのアクセスやAPIの異常終了
wsTarget.Range(“A1”).Value = “Processing…”
‘ 意図的なエラーテスト（コメントアウト解除で検証可能）
‘ Err.Raise 9999, “TestError”, “意図的なシステム例外の発生”
‘ 正常終了時のコミット
cnDB.CommitTrans
blnTransActive = False
‘ — 【正常終了時のクリーンアップ】 —
GoTo CleanUp
ErrorHandler:
‘ — 【層3: 例外捕捉と状態整合性の復旧】 —
Dim lngErrNumber As Long
Dim strErrDesc As String
lngErrNumber = Err.Number
strErrDesc = Err.Description
‘ トランザクションが中途半端に残っている場合のロールバック
On Error Resume Next ‘ クリーンアップ中のエラーをマスク
If blnTransActive Then
cnDB.RollbackTrans
blnTransActive = False
End If
On Error GoTo 0 ‘ エラー監視を復元
‘ ユーザーへの通知やログ出力（必要に応じて）
MsgBox “致命的なエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & lngErrNumber & vbCrLf & _
“詳細: ” & strErrDesc, vbCritical, “System Error”
CleanUp:
‘ — 【共通リソース解放と変数の再初期化】 —
On Error Resume Next
‘ オブジェクトの明示的解放（メモリリークの根絶）
If Not cnDB Is Nothing Then
If cnDB.State = 1 Then cnDB.Close
Set cnDB = Nothing
End If
Set wsTarget = Nothing
lngProcessID = 0
On Error GoTo 0
‘ エラー伝播が必要な場合はここで再発生させる
If lngErrNumber <> 0 Then
‘ Err.Raise lngErrNumber, , strErrDesc
End If
End Sub
—
3. コードの深層解説：なぜこの構造が必要なのか？
① 変数の初期化とスコープの罠
VBAでは、プロシージャの先頭で変数を宣言しても、実際のメモリ割り当てと初期化（特にオブジェクトや動的配列）は実行行が通過したタイミングで行われる。
しかし、エラーが発生して `GoTo ErrorHandler` にジャンプした際、「宣言だけされて初期化されていない変数」や「途中で値が書き換わった変数」を参照してクリーンアップ処理を行おうとすると、さらなる実行時エラー（オブザーバーパターン破綻によるオブジェクト変数の不整合など）を引き起こす。
そのため、プロシージャの最序盤で全ての変数を `Nothing` や `0`、`False` で明示的に初期化する防衛的プログラミングが不可欠となる。
② `On Error Resume Next` の限定的かつ厳格な運用
エラーハンドラー内、あるいはクリーンアップ処理内（`CleanUp` ラベル以降）では、すでにエラーが発生している、あるいはオブジェクトが既に破棄されている可能性が高い。
ここで通常の処理を続けると、「オブジェクト変数が見つかりません (Error 91)」といった二次エラーが発生し、本来の根本原因（一次エラー）が闇に葬られる。
これを防ぐため、クリーンアップブロックに突入する直前、または内部では、一時的に `On Error Resume Next` を宣言し、破棄処理の安全性を担保する。ただし、このスコープを広げすぎてはならない。クリーンアップが終わったら即座に `On Error GoTo 0` で監視を戻す、あるいはエラー状態をローカル変数に退避させるのが鉄則である。
③ COMオブジェクトの厳格な参照解放とメモリ最適化
VBAのガベージコレクタは、プロシージャが終了するまでローカルスコープのCOMオブジェクトを解放しないケースがある。特にループ処理や巨大なExcelマクロシステムにおいて、これを放置するとVBAの背後で動くCOMコンポーネントがメモリを圧迫し、最終的にExcelそのものがクラッシュする（いわゆる「メモリリークによるフリーズ」）。
`Set obj = Nothing` を明示的に実行し、さらに `State` プロパティなどを確認して安全にクローズするプロセスは、プロのVBAエンジニアにとっての義務である。
—
4. レガシー環境・システム間連携における実践知
Excel VBAから外部のデータベース（SQL Server, Oracle等）や、Windows API、あるいはCOMコンポーネントを操作するシステム間連携では、エラーハンドリングの不備が「データの二重更新」「孤立したセッション（Zombie Process）」を誘発する。
- ステータス変数の保持: 処理が「どこまで成功したか」をビットフラグや列挙型（Enum）で厳密に管理し、エラーハンドラーはそのステータスを見て「どこをロールバックすべきか」を動的に判断させること。
- API呼び出し時のエラー境界: Windows APIを呼び出す際、戻り値や `GetLastError` の結果を即座にVBAの `Err` オブジェクトに同期させ、VBA側の例外機構とC言語由来のAPIエラーをシームレスに結合する設計が求められる。
総括
エラーハンドリングとは、単に「エラーメッセージを表示させてマクロを止まらせないためのおまじない」ではない。それは、異常事態に直面したシステムが、自身の状態を安全に巻き戻し、メモリと外部リソースの整合性を完全に保ったまま美しく退避するための高次なアーキテクチャである。
この境地に到達したとき、あなたの書くVBAコードは、もはや「スクリプト」の領域を脱し、堅牢なエンタープライズ・アプリケーションのそれと同等の信頼性を獲得するだろう。
