長時間稼働するAccessアプリを蝕む「リソース枯渇」を断つ：ADO接続プーリングとメモリ管理の極限設計
業務自動化の現場において、Accessは単なる「小規模ツール」ではない。数千件のトランザクションを捌き、サーバー上のSQL Serverと密に連携し、一日中、あるいは数日間、ユーザーの操作を待ち続ける「ミッションクリティカルな基幹システム」へと昇華される場面が多々ある。
しかし、多くの開発者が陥る罠がある。それは、「動いているから、問題ない」という慢心だ。
開発直後は完璧に動作していたツールが、数日経つと動作が重くなる。あるいは、特定の操作を繰り返すと「メモリ不足」や「接続エラー」で突如としてクラッシュする。この現象の正体は、多くの場合、ADO（ActiveX Data Objects）のオブジェクトライフサイクル管理の失敗、すなわちメモリリークと接続プーリングの誤用である。
本稿では、設計レベルでの「Connectionオブジェクト」の扱いを再定義し、長時間稼働に耐えうる堅牢なアーキテクチャを伝授する。
1. なぜあなたのコードは「死」に向かうのか
まず、現場で見られる「典型的な失敗パターン」を2つ挙げる。これらに心当たりがあるなら、君の設計は既に破綻している。
パターンA：使い捨ての乱用（オーバーヘッドの増大）
関数を呼び出すたびに `Connection.Open` し、処理が終わったら `Close` する。
「接続を維持しないから安全だ」と考えがちだが、これは致命的な間違いだ。ADOには接続プーリング（Connection Pooling）という、物理的な接続を再利用してパフォーマンスを劇的に向上させる仕組みが備わっている。頻繁すぎるOpen/Closeは、このプーリングの恩恵を阻害し、ネットワークスタックとCOM（Component Object Model）のオーバーヘッドを増大させ、CPUリソースを無駄に浪費する。
パターンB：グローバル変数の依存（メモリリークとゾンビ接続）
`Public cn As ADODB.Connection` のように、標準モジュールで接続オブジェクトを保持し続ける。
これは最も危険な設計だ。接続が「生きたまま」保持されるため、ネットワークの瞬断やタイムアウトが発生した際、オブジェクトが「ゾンビ状態（無効なハンドルを保持したままメモリ上に残る状態）」になり、再接続を試みてもエラーが解消されない。また、参照カウントが適切に解放されず、メモリ断片化を招く。
2. アーキテクチャの正解：スコープ化された接続管理
プロフェッショナルが採用すべき戦略は、「接続のライフサイクルをクラスのインスタンス寿命に同期させる」ことである。
具体的には、接続を管理する専用の「コンテキスト・クラス」を作成し、そのクラスのインスタンスが生存している間だけ、接続が有効であることを保証する設計をとる。これにより、オブジェクトの生成・破棄が決定論的（Deterministic）になり、メモリリークを物理的に排除できる。
実装の鍵となる設計指針
1. Connectionオブジェクトは、クラスのプライベート変数として隠蔽する。
2. Class_Terminateにて、確実に `Close` と `Nothing` を実行する。
3. トランザクションは、単一のConnectionインスタンス内で完結させる。
3. プロダクション・コード：堅牢なConnectionマネージャー
以下に、そのまま実戦投入可能な、メモリ管理を極めた `clsDBContext` クラスの設計例を示す。
クラスモジュール: `clsDBContext`
'-------------------------------------------------------------------------------
' Class Name: clsDBContext
' Description: ADO接続のライフサイクルを管理し、メモリリークと接続不備を防ぐ
'-------------------------------------------------------------------------------
Option Explicit
Private mConn As ADODB.Connection
Private mConnectionString As String
' 初期化時に接続文字列を受け取る
Private Sub Class_Initialize()
' 接続文字列は外部（設定ファイル等）から注入することを推奨
End Sub
' 接続の確立
Public Function Connect(ByVal strConn As String) As Boolean
On Error GoTo ErrorHandler
mConnectionString = strConn
Set mConn = New ADODB.Connection
' 接続プーリングを最大限活用するための設定
' ※ConnectionStringの属性により制御されるが、明示的なOpenを行う
mConn.ConnectionString = mConnectionString
mConn.CursorLocation = adUseClient ' クライアントサイドカーソルで柔軟な操作を可能にする
mConn.Open
Connect = True
Exit Function
ErrorHandler:
Debug.Print "Connection Error: " & Err.Description
Set mConn = Nothing
Connect = False
End Function
' 接続オブジェクトの提供（読み取り専用に近い形で利用させる）
Public Property Get Connection() As ADODB.Connection
Set Connection = mConn
End Property
' トランザクション開始
Public Sub BeginTrans()
If Not mConn Is Nothing Then
If mConn.State = adStateOpen Then mConn.BeginTrans
End If
End Sub
' トランザクション確定
Public Sub CommitTrans()
If Not mConn Is Nothing Then
If mConn.State = adStateOpen Then mConn.CommitTrans
End If
End Sub
' トランザクションロールバック
Public Sub RollbackTrans()
If Not mConn Is Nothing Then
If mConn.State = adStateOpen Then mConn.RollbackTrans
End If
End Sub
' クラス破棄時のクリーンアップ（ここがメモリ管理の肝）
Private Sub Class_Terminate()
On Error Resume Next
If Not mConn Is Nothing Then
' 接続が開いていれば閉じる
If mConn.State = adStateOpen Then
mConn.Close
End If
' オブジェクトを完全に解放し、参照カウントをゼロにする
Set mConn = Nothing
End If
On Error GoTo 0
End Sub標準モジュールでの利用例
'-------------------------------------------------------------------------------
' 実務での利用イメージ
'-------------------------------------------------------------------------------
Option Explicit
Sub ExecuteBusinessProcess()
Dim dbCtx As clsDBContext
Dim rs As ADODB.Recordset
Dim strConn As String
strConn = "Provider=SQLOLEDB;Data Source=SERVER_NAME;Initial Catalog=DB_NAME;Integrated Security=SSPI;"
' 1. インスタンス化（ここからライフサイクルが始まる）
Set dbCtx = New clsDBContext
' 2. 接続確立
If Not dbCtx.Connect(strConn) Then
MsgBox "データベース接続に失敗しました。", vbCritical
Exit Sub
End If
On Error GoTo TransactionError
' 3. トランザクションの開始
dbCtx.BeginTrans
' 4. データ操作
Set rs = New ADODB.Recordset
rs.Open "SELECT * FROM Orders WHERE Status = 'Pending'", dbCtx.Connection, adOpenStatic, adLockOptimistic
If Not rs.EOF Then
' 何らかの更新処理
dbCtx.Connection.Execute "UPDATE Orders SET Status = 'Processed' WHERE Status = 'Pending'"
End If
' 5. コミット
dbCtx.CommitTrans
Debug.Print "Transaction Committed Successfully."
CleanUp:
' リソースの解放
On Error Resume Next
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
' 6. インスタンスの破棄（ここでClass_Terminateが走り、確実にメモリが解放される）
Set dbCtx = Nothing
Exit Sub
TransactionError:
MsgBox "エラーが発生したためロールバックします: " & Err.Description, vbExclamation
dbCtx.RollbackTrans
Resume CleanUp
End Sub4. 伝説のアーキテクトからのアドバイス
この設計を導入するにあたり、以下の3点を心に刻んでおいてほしい。
① 参照カウントを信じるな、明示的に殺せ
VBAのCOM管理は、時として不完全だ。`Set obj = Nothing` を書かないプログラマは、プロフェッショナルではない。特にエラーハンドリングのルート（`ErrorHandler`）において、オブジェクトが「開いたまま」放置されるケースが最も多い。必ず `CleanUp` ラベルへ飛ばし、確実に `Nothing` を代入する構造を作れ。
② カーソルロケーションの選択
`adUseClient`（クライアントサイドカーソル）は、メモリを消費するが、レコードセットの移動や操作が高速で、Accessからの操作には適している。しかし、数百万件のデータを一度に取得しようとすれば、クライアントのメモリを即座に食いつぶす。大規模データ扱う場合は、`adUseServer` を検討するか、SQL側で集計を済ませる設計にせよ。
③ DAOとの使い分け
Access内部のテーブル（Local Table）を操作するなら、DAO（`DAO.Database`）の方が圧倒的に軽量で高速だ。ADOはあくまで、SQL Server等の外部リソースへの「ブリッジ」として使え。一つの処理の中でDAOとADOを混在させるなら、それぞれの接続オブジェクトを明確に分離し、ライフサイクルを混ぜるな。
結論
優れたエンジニアは、コードが「動くこと」だけでなく、「止まり続けること」に価値を置く。
今回提示した `clsDBContext` パターンは、接続の効率性とメモリの安全性という、相反する要素を高い次元で両立させるための最小単位の設計である。これを君のプロジェクトの標準（Standard）に据え、堅牢なシステムを構築してほしい。
