【入門編】ADOの接続プーリングを意識した、長時間稼働アプリのメモリリーク対策 – Access VBA解析バイブル

「動けばいい」のその先へ。長時間稼働アプリを支えるADO接続管理と、メモリリークを防ぐ極意

こんにちは。開発の現場へようこそ。

マクロの記録から一歩踏み出し、「自分でコードを書いて、システムを動かしたい」と願い始めたあなた。素晴らしい志です。Access VBAは、正しく扱えば非常に強力な武器になります。

しかし、多くの開発者が最初にぶつかる「見えない壁」があります。それは、「開発した直後は完璧に動いていたのに、数日経つとアプリが重くなり、最終的に強制終了（クラッシュ）してしまう」という現象です。

これはバグではありません。「オブジェクトのライフサイクル」と「リソースの解放」という、プロフェッショナルへの登竜門とも言える概念を理解していないために起こる、いわば「設計の歪み」なのです。

今日は、長時間稼働する業務アプリにおいて避けては通れない、ADO（ActiveX Data Objects）の接続管理とメモリリーク対策について、その本質を紐解いていきましょう。

1. DAOとADO：その役割と「重み」の違いを知る

まず、Access VBAでデータを扱うための2つの主要な技術、DAOとADOの違いを整理しておきましょう。ここを混同していると、設計の段階で迷子になってしまいます。

「Access内のテーブルをいじるだけならDAO、SQL Serverなどの外部サーバーと連携するならADO」。これが鉄則です。

しかし、ADOを使う場合、一つだけ覚悟しておかなければならないことがあります。それは、ADOは「ネットワークという不確実な世界」と通信するため、接続（Connection）の管理が非常にシビアであるということです。

2. 接続プーリングという「魔法」と、その副作用

ADOには「接続プーリング（Connection Pooling）」という非常に便利な仕組みが備わっています。

通常、データベースに接続するには「握手（ハンドシェイク）」という重たい手続きが必要です。毎回これを行うとアプリが遅くなるため、ADOは一度作った接続を「使い回せるようにプール（貯水池）」に溜めておいてくれます。これがプーリングです。

一見、非常に効率的な仕組みに見えますが、ここにメモリリークの罠が潜んでいます。

なぜメモリが足りなくなるのか？

長時間稼働するアプリで、以下のようなコードを書いていないでしょうか？

' 【危険な例：メモリリークの温床】
Sub BadExample()
    Dim cn As ADODB.Connection
    Set cn = New ADODB.Connection
    cn.Open "接続文字列..."
    
    ' 何かの処理...
    
    ' ここで cn.Close だけして、Set cn = Nothing を忘れている
    cn.Close 
End Sub

一見、`Close` しているので問題なさそうに見えますよね。しかし、VBAの世界では「オブジェクトを使い終わったら、明示的に『空（Nothing）』にする」という儀式が不可欠です。

`Close` は「通信の扉を閉める」行為ですが、`Set cn = Nothing` は「そのオブジェクトが占有していたメモリ領域を解放する」行為です。この儀式を忘れると、ADOの接続プール内に「幽霊のような接続オブジェクト」が残り続け、メモリをじわじわと食いつぶしていきます。これが、数日後にアプリが落ちる正体です。

3. 実践：メモリリークを許さない「黄金のパターン」

では、どのように書けば安全なのでしょうか？
プロの現場で使われる、「エラーが起きても、必ず確実にリソースを解放する」ための黄金パターンを紹介します。

ポイントは、`On Error GoTo` を使ったエラーハンドリングと、必ず通る「掃除（Cleanup）セクション」を設けることです。

堅牢なADO実行用テンプレート

以下のコードは、そのままあなたのプロジェクトの部品として活用できるレベルの設計にしています。

''' <summary>
''' 外部DBからデータを安全に取得するための標準的な関数例
''' </summary>
Public Sub SafeExecuteQuery()
    ' 1. オブジェクトの宣言（スコープを最小限にする）
    Dim cn As ADODB.Connection
    Dim rs As ADODB.Recordset
    Dim strSql As String
    
    ' エラーハンドリングの設定
    On Error GoTo ErrorHandler

    ' 2. オブジェクトの生成
    Set cn = New ADODB.Connection
    Set rs = New ADODB.Recordset

    ' 3. 接続の確立
    ' ※接続文字列は環境に合わせて適切に設定してください
    cn.ConnectionString = "Provider=SQLOLEDB;Data Source=YourServer;Initial Catalog=YourDB;Integrated Security=SSPI;"
    cn.Open

    ' 4. SQLの実行
    strSql = "SELECT TOP 10 * FROM SalesData ORDER BY SaleDate DESC"
    rs.Open strSql, cn, adOpenStatic, adLockReadOnly

    ' 5. データの処理（例としてイミディエイトウィンドウに出力）
    Do While Not rs.EOF
        Debug.Print rs.Fields(0).Value
        rs.MoveNext
    Loop

    ' --- 正常終了時の出口 ---
CleanExit:
    ' 6. 【最重要】リソースの解放儀式
    ' Recordsetを先に閉じ、次にConnectionを閉じる
    ' エラーが起きても、必ずここを通るように設計します
    On Error Resume Next ' 解放処理中のエラーは無視する
    If Not rs Is Nothing Then
        If rs.State = adStateOpen Then rs.Close
        Set rs = Nothing
    End If
    
    If Not cn Is Nothing Then
        If cn.State = adStateOpen Then cn.Close
        Set cn = Nothing
    End If
    On Error GoTo 0
    Exit Sub

ErrorHandler:
    ' エラーが発生した場合の処理
    MsgBox "予期せぬエラーが発生しました。" & vbCrLf & _
           "番号: " & Err.Number & vbCrLf & _
           "内容: " & Err.Description, vbCritical, "システムエラー"
    
    ' エラーが起きても、必ず「掃除セクション」へ飛ばす
    Resume CleanExit
End Sub

このコードの「凄み」を解説します

1. `On Error GoTo ErrorHandler`:
何かが起きた瞬間に、処理を中断してエラー処理へジャンプさせます。これにより、中途半端な状態で処理が止まるのを防ぎます。
2. `Resume CleanExit`:
ここがプロの技です。エラーが起きた後、そのまま終了するのではなく、「掃除セクション（CleanExit）」へ合流させます。これにより、エラーが起きても必ず `Set Nothing` が実行されます。
3. `If Not rs Is Nothing Then`:
「もしオブジェクトが既に存在していたら」というチェックです。これがないと、オブジェクト生成に失敗した状態で `Close` を呼ぼうとして、二次災害（別のエラー）が発生します。
4. `On Error Resume Next` (Cleanup内):
掃除の最中にエラーが起きても、止まらずに最後まで掃除を完遂させるための、最後の守りです。

4. まとめ：ここをクリアすれば、あなたはもう初級者ではない

「動くコード」を書くのは簡単です。しかし、「止まらないシステム」を書くには、コンピュータの裏側で何が起きているかを想像する力が必要です。

• ADOは接続プーリングを使うが、メモリの解放は自分で行う必要がある。
• `Close` だけでは不十分。`Set … = Nothing` までがセット。
• エラーが起きても必ず「掃除」を通るルートを設計する。

この3点を意識するだけで、あなたの作るAccessアプリの信頼性は劇的に向上します。

最初は少し面倒に感じるかもしれません。でも、この「丁寧な作法」こそが、プロフェッショナルなエンジニアへの第一歩です。大丈夫、一歩ずつ進んでいきましょう。応援していますよ。