【テクニカル・上級編】DAOのRecordsetを閉じ忘れない：クラスモジュールを活用した自動クローズ設計 – Access VBA解析バイブル

資源解放の美学：DAO/ADOのライフサイクルを掌握するRAII設計

業務アプリケーションの現場において、もっとも「低俗」かつ「致命的」なバグは何か。それは、メモリリークでも、計算アルゴリズムの誤りでもない。「リソースの解放漏れ」だ。

特に、Access VBAを基盤とした大規模なエンタープライズシステムにおいて、DAO（Data Access Objects）やADO（ActiveX Data Objects）のRecordsetを適切に管理できていないコードは、時限爆弾を抱えているのと同義である。エラーハンドリングの隙間からこぼれ落ちたRecordsetは、メモリを蝕み、ファイルロックを維持し続け、最終的にはシステムの不整合を招く。

本稿では、単なる「Closeを忘れるな」という初歩的な教訓ではない。オブジェクトのライフサイクルを決定論的に制御するための、クラスモジュールを用いたRAII（Resource Acquisition Is Initialization）パターンの実装、およびそのアーキテクチャ的意義について、極限の視点から解説する。

1. 非決定的な破棄が招く「静かなる崩壊」

多くの開発者は、`rs.Close` を呼び出し、その後に `Set rs = Nothing` と書けば十分だと信じている。しかし、現実はそれほど甘くない。

なぜ `Set rs = Nothing` だけでは不十分なのか

VBAにおけるCOMオブジェクトの解放は、参照カウント（Reference Counting）に基づいている。エラーが発生し、プロシージャが異常終了（あるいは `On Error GoTo` によるジャンプ）した際、コード内の `rs.Close` を通過せずに制御が移った場合、そのRecordsetオブジェクトはメモリ上に浮遊し続ける。

この「浮遊するオブジェクト」は以下の問題を引き起こす：
1. ファイルロックの残留: `.laccdb` ファイルが解放されず、他のユーザーやプロセスがデータベースへアクセスできなくなる。
2. メモリ断片化（Memory Fragmentation）: 長期間稼働するシステムにおいて、解放されないオブジェクトがヒープ領域を占有し続け、Windowsのメモリ管理に負荷をかける。
3. トランザクションの不整合: Recordsetが保持している更新中の状態が、メモリ上に「中途半端な状態」で残ることで、後続の処理が予期せぬ挙動を示す。

我々プロフェッショナルが求めているのは、「コードの記述ミスやエラーの発生に関わらず、オブジェクトがスコープを外れた瞬間に、確実に、決定論的にリソースが解放される仕組み」である。

2. クラスモジュールによるRAIIの実装

C++などのモダンな言語では、オブジェクトのデストラクタがリソース解放を保証する。VBAにおいてこれに近い挙動を実現するには、クラスモジュールの `Class_Terminate` イベントを戦略的に利用する必要がある。

以下に、Recordsetをカプセル化し、そのライフサイクルを自動管理する「安全なラッパー」の設計例を示す。

実装例：`clsSafeRecordset`

このクラスは、Recordsetの生成から破棄までを完全に管理する。

' ======================================================================
' Module: clsSafeRecordset
' Description: DAO/ADO Recordsetのライフサイクルを自動管理するRAIAラッパー
' ======================================================================
Option Explicit

' 内部保持するRecordsetオブジェクト
Private m_rs As Object 

' ----------------------------------------------------------------------
' Property: rs
' Description: 実際のRecordsetオブジェクトへの参照を返す
' ----------------------------------------------------------------------
Public Property Get rs() As Object
    Set rs = m_rs
End Property

' ----------------------------------------------------------------------
' Method: Initialize
' Description: Recordsetの生成と初期化を行う
' ----------------------------------------------------------------------
Public Sub Initialize(ByRef targetRs As Object)
    ' 既存の参照をセット
    Set m_rs = targetRs
    
    ' ここで、オブジェクトが有効であることを検証するロジックを挟むことも可能
    If m_rs Is Nothing Then
        Err.Raise vbErr_InvalidArgument, "clsSafeRecordset.Initialize", "Recordset is Nothing."
    End If
End Sub

' ----------------------------------------------------------------------
' Event: Class_Terminate
' Description: クラスのインスタンスが破棄される際、確実にリソースを解放する
' ----------------------------------------------------------------------
Private Sub Class_Terminate()
    ' 開発者がCloseを忘れても、クラスが破棄される際に必ず実行される
    On Error Resume Next ' デストラクタ内でのエラーは致命的なため、最小限のハンドリングのみ
    
    If Not m_rs Is Nothing Then
        ' Recordsetがオープンしていれば閉じる
        ' ※ADO/DAOの仕様差を吸収するため、状態チェックを慎重に行う
        If m_rs.State = 1 Or m_rs.State = 2 Then ' adStateOpen (ADO) or dbOpenForwardOnly等 (DAO)
             m_rs.Close
        End If
        
        ' 参照を明示的に切断
        Set m_rs = Nothing
    End If
    On Error GoTo 0
End Sub

3. アーキテクチャへの統合：運用における実戦的コード

このクラスをどのように実務コードに組み込むか。肝要なのは、「Recordsetそのものを変数として持つのではなく、ラッパーとしてのクラスインスタンスをスコープ内に置く」ことである。

実装例：業務ロジック内での利用

' ======================================================================
' Module: modBusinessLogic
' Description: 実務における安全なデータ操作のデモンストレーション
' ======================================================================
Option Explicit

Public Sub ProcessLargeData()
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim safeRs As clsSafeRecordset ' ここが鍵となる
    
    Set db = CurrentDb
    
    On Error GoTo ErrorHandler
    
    ' 1. Recordsetの生成
    Set rs = db.OpenRecordset("SELECT * FROM T_TransactionLogs WHERE Processed = False", dbOpenDynaset)
    
    ' 2. ラッパーに委譲
    ' これにより、rsの寿命はsafeRsの寿命と同期する
    Set safeRs = New clsSafeRecordset
    safeRs.Initialize rs
    
    ' 3. メインロジック
    Do Until safeRs.rs.EOF
        ' 何らかの重い処理...
        Debug.Print "Processing ID: " & safeRs.rs!ID
        
        ' --- ここで予期せぬエラーが発生したと仮定 ---
        ' If Err.Number <> 0 Then Err.Raise vbErr_TestError 
        
        safeRs.rs.MoveNext
    Loop
    
    Debug.Print "処理完了。"

CleanExit:
    ' 4. 明示的な解放（推奨されるが、忘れてもClass_Terminateが救う）
    Set safeRs = Nothing
    Set rs = Nothing
    Set db = Nothing
    Exit Sub

ErrorHandler:
    MsgBox "致命的なエラーが発生しました: " & Err.Description, vbCritical
    Resume CleanExit
End Sub

4. 極限の知見：メモリとトランザクションの相関

ここで、シニアエンジニアが意識すべき、より深いレイヤーの話をしよう。

Windows APIとヒープの視点

VBAが動作する `msvbvm70.dll` や `VBE7.dll` は、Windowsのヒープ領域を管理している。`Class_Terminate` が呼ばれる際、COMの `IUnknown::Release` が呼び出され、参照カウントがゼロになると、初めてメモリが解放される。

もし、ループ内で大量のRecordsetを生成し、かつラッパーを使わずにエラーハンドリングを誤った場合、メモリの断片化（Fragmentation）が加速する。これは、単に「メモリが足りなくなる」問題ではなく、「連続したメモリブロックが確保できなくなる」問題であり、結果として `Out of Memory` エラーを誘発する。

トランザクションとの整合性

トランザクション（`DBEngine.BeginTrans`）を利用している場合、Recordsetの解放漏れは、トランザクションのコミット/ロールバックを阻害する要因となる。
Recordsetが「開いたまま」の状態では、データベースエンジンはデータの整合性を守るために、該当するレコードやページに対して排他ロックを保持し続ける。`Class_Terminate` を用いた決定論的な設計は、単なるメモリ管理術ではなく、「データベースの同時実行制御（Concurrency Control）を制御するための技術」なのである。

結論

「動けば良い」というコードは、開発者のエゴである。
「いかなる条件下でも、リソースを確実に、美しく解放する」コードこそが、プロフェッショナルが提供すべき資産である。

クラスモジュールによるRAIIパターンの導入は、一見すると冗長に思えるかもしれない。しかし、その数行の追加が、数年後に発生する「原因不明のシステム停止」を防ぐ唯一の防波堤となるのだ。

設計に妥協は許されない。リソースの制御こそが、アーキテクトの矜持である。