揮発するリソースを掌握せよ：DAO Recordsetのライフサイクルとメモリ解放の極致
多くの開発者が「コードが動くこと」にのみ執着し、その裏側で蠢く「リソースの腐敗」を看過している。Access VBAの世界において、Recordsetのクローズ漏れは単なる作法の問題ではない。それは、システムの長時間稼働におけるパフォーマンスの減衰、予期せぬファイルロック、そして最悪の場合、データベースの破損を招く致命的な設計ミスである。
本稿では、DAO（Data Access Objects）のRecordsetを巡るオブジェクトのライフサイクルを徹底的に解剖する。プロシージャのスコープ、フォームの生存期間、そしてメモリ空間における「明示的な破棄」が持つ真の重みについて、シニアエンジニアが備えておくべき知見を提示する。
1. 参照カウントの幻想と「決定論的破棄」の欠如
VBAはCOM（Component Object Model）技術に基づいている。オブジェクトの寿命は「参照カウント」によって管理される。参照がゼロになれば、オブジェクトはメモリから解放される――理論上はそうだ。
しかし、DAOのRecordsetは単なるメモリ上の構造体ではない。それはACE/Jetエンジンというデータベースエンジンと密接に結びついた、外部リソースへの「ハンドル」である。エラーハンドリングの不備や、スコープの誤認によって参照カウントが正しく減少しなかった場合、Recordsetは「幽霊オブジェクト」としてメモリ上に居座り続ける。
これが積み重なると、Windowsのワーキングセット（物理メモリ使用量）は膨れ上がり、Accessのプロセスはスワップを繰り返して鈍重化する。我々が目指すべきは、オブジェクトの寿命を運任せにするのではなく、「決定論的破棄（Deterministic Destruction）」、すなわち「使い終わった瞬間に確実に、かつ明示的に、リソースを解放する」制御である。
2. 二つの戦場：プロシージャ・スコープとフォーム・スコープ
Recordsetをどこに定義するかによって、解放の戦略は劇的に変わる。
2.1 プロシージャ・スコープ（局所的生存）
最も基本的かつ、最もエラーが起きやすい領域だ。ローカル変数として宣言されたRecordsetは、プロシージャを抜ければ参照は外れる。しかし、エラーが発生してプロシージャが途中で脱落した場合、あるいは `End` ステートメントが不用意に呼ばれた場合、クローズ処理はスキップされる。
鉄則： エラーハンドリングの出口（Exit Handler）において、必ず `Close` と `Set = Nothing` を実行せよ。
2.2 フォーム・スコープ（長期的生存）
フォームのモジュールレベル（宣言部）でRecordsetを保持する場合、その寿命はフォームの生存期間と同期する。これは「フォームを開いている間、常に最新のデータを保持する」という設計には適しているが、解放のタイミングを誤ると、フォームを閉じた後も `.laccdb`（ロックファイル）が残り続けたり、メモリリークを引き起こしたりする。
鉄則： フォームの `Unload` または `Close` イベントにおいて、明示的にリソースを解体せよ。
3. 実装における極限のテンプレート
以下に、プロフェッショナルが実装すべき、堅牢なリソース管理のコードパターンを示す。
3.1 局所的スコープにおける「黄金のパターン」
エラーが発生しても、必ずクリーンアップ・ルーチンへ到達させる構造だ。
''
' 特定の条件に基づきデータを抽出するプロシージャ
' 異常系が発生してもリソースを確実に解放する設計
''
Public Sub ExecuteDataProcessing()
Dim db As DAO.Database
Dim rs As DAO.Recordset
' エラーハンドリングの構築
On Error GoTo Err_Handler
Set db = CurrentDb
' SQL実行（ここでリソースが割り当てられる）
Set rs = db.OpenRecordset("SELECT * FROM T_Critical_Data WHERE Status = 'Active'", dbOpenSnapshot)
' --- メインロジック ---
If Not rs.EOF Then
' 何らかの重い処理...
Debug.Print "Processing record: " & rs!ID
End If
' --------------------
Exit_Handler:
''
' クリーンアップ・セクション
''
' 1. Recordsetのクローズと参照解除
' エラーが発生していても、オブジェクトが存在すれば確実に解放する
If Not rs Is Nothing Then
On Error Resume Next ' クローズ中のエラーによる二重エラーを防止
rs.Close
Set rs = Nothing
End If
' 2. Databaseオブジェクトの参照解除
If Not db Is Nothing Then
Set db = Nothing
End If
Exit Sub
Err_Handler:
' エラーログの記録（実務ではログファイルやテーブルへ出力）
Debug.Print "Error " & Err.Number & ": " & Err.Description
Resume Exit_Handler
End Sub3.2 フォーム・スコープにおける「ライフサイクル管理」
フォームレベルで保持するRecordsetは、フォームの破棄プロセスと完全に同期させる必要がある。
Option Compare Database
Option Explicit
' フォームの生存期間中、データを保持するためのモジュールレベル変数
Private m_rs As DAO.Recordset
''
' フォームロード時にデータセットを構築
''
Private Sub Form_Load()
On Error GoTo Err_Handler
' フォーム表示に必要なデータを保持
Set m_rs = CurrentDb.OpenRecordset("SELECT * FROM T_Master_Config", dbOpenSnapshot)
' データの利用...
Exit Sub
Err_Handler:
MsgBox "Load Error: " & Err.Description, vbCritical
End Sub
''
' フォームが閉じられる際の、究極のクリーンアップ
' Unloadイベントは、フォームがメモリから取り除かれる直前のタイミング
''
Private Sub Form_Unload(Cancel As Integer)
On Error Resume Next ' 解放処理中のエラーは無視して、メモリ解放を優先する
' Recordsetの明示的な破棄
If Not m_rs Is Nothing Then
m_rs.Close
Set m_rs = Nothing
End If
Debug.Print "Form Unload: Resources successfully released."
End Sub4. アーキテクトの視点：なぜ `Set rs = Nothing` だけでは不十分なのか
若手エンジニアはよく、「`Set rs = Nothing` を書いているから大丈夫だ」と主張する。しかし、それは半分正解で半分は致命的な誤解だ。
1. `Close` メソッドの重要性: `Close` はデータベースエンジンに対し、「このカーソルと、それに紐づくファイルロック、一時的なメモリバッファを即座に解放せよ」という命令を出す。
2. `Set = Nothing` の役割: これはVBAの参照カウントを減らす操作だ。
もし `Close` を呼ばずに `Set = Nothing` だけを行った場合、参照カウントはゼロになるかもしれないが、データベースエンジン側で「まだこのRecordsetに関連する処理が続いている」と誤認され、リソースが解放されるまでにタイムラグが生じる。これが、「ファイルが使用中のため、開けません」という、Access開発における忌まわしいエラーの正体である。
5. 総括：規律がシステムを救う
Access VBAにおけるメモリ最適化とは、高度なアルゴリズムを組むことではない。「オブジェクトの誕生から死までを、完全にコントロール下に置く」という、極めて規律正しいプログラミングを徹底することである。
- エラーハンドリングを設計の主役に据えよ。
- スコープを明確にし、生存期間を管理せよ。
- `Close` と `Set = Nothing` をセットで、かつ確実に実行せよ。
この規律を守れる者だけが、数千、数万のレコードを扱う大規模なレガシーシステムにおいても、揺るぎない安定性とパフォーマンスを提供できるのだ。
