DAO.Recordsetの呪縛を解く：`dbOpenDynaset`と`dbOpenSnapshot`の極限最適化とメモリ管理
レガシーシステムの心臓部としていまだ稼働し続けるMicrosoft Access。そのパフォーマンスチューニングにおいて、避けて通れず、そして最も多くのエンジニアが踏み絵を踏む領域が、DAO（Data Access Objects）のレコードセットオープンである。
「なぜ、10万件のデータを処理するだけでAccessがフリーズするのか？」
「なぜ、サーバーのメモリが徐々に枯渇し、最終的にIISや周辺の連携プロセスまで巻き込んでクラッシュするのか？」
その原因の多くは、`OpenRecordset`メソッドの第2引数に指定する「カーソルタイプ（Type）」の選定ミス、そしてAccessオブジェクトモデルのライフサイクル管理の欠落にある。
本稿では、`dbOpenDynaset`と`dbOpenSnapshot`の内部挙動の違いをメモリとパフォーマンスの観点から丸裸にし、大量データ処理時のフリーズを完全に回避する「極限の知見」を提示する。
—
1. カーソルタイプの真実：なぜ`dbOpenDynaset`は重いのか
多くのアマチュアプログラマは、データを取得する際に深く考えず`dbOpenDynaset`を使用する。「データを編集するかもしれないから、動的な方が安全だろう」という安易な理由だ。しかし、この惰性がシステムを死に至らしめる。
`dbOpenDynaset` の内部構造とコスト
`dbOpenDynaset`は、ダイナセット型レコードセットを生成する。これは、他のユーザーや自分自身が行ったデータの変更（追加・削除・更新）がリアルタイムに反映される双方向の強力なカーソルである。
しかし、その代償は重い。
- ロックとトランザクションのオーバーヘッド: 同時実行制御のため、ページレベルのロック管理やブックマークの維持に膨大なリソースが割かれる。
- Jet/ACEエンジンキャッシュの肥大化: クエリの結果セットだけでなく、結合（JOIN）された元テーブルのインデックスやデータページをメモリ上に保持し続けるため、レコード数に比例してメモリ消費量が幾何級数的に増加する。
`dbOpenSnapshot` の圧倒的な優位性
一方、`dbOpenSnapshot`は、レコードセットが作成された瞬間の「スナップショット（静的な静止画）」をメモリ（または一時ファイル）上に切り取る。
- 完全なリードオンリー: データの更新・追加・削除はできない（厳密にはできない仕様になる）。
- ロックフリー: 他者との競合がないため、排他制御のオーバーヘッドがゼロ。
- メモリ効率: 変更を追跡する必要がないため、Jet/ACEエンジンは最小限のリソースで結果を保持できる。
【鉄則】 データを「参照（集計、帳票出力、別システムへのエクスポート）」するだけであれば、`dbOpenSnapshot`以外を選定する理由は一切ない。
—
2. 大量データ処理でフリーズを引き起こす「メモリリーク」の正体
Access VBAにおけるメモリ管理の最大の問題点は、COMコンポーネント（DAOやADO）の参照カウンタとガベージコレクションのタイミングにある。
プロシージャ内で `CurrentDb.OpenRecordset` を呼び出した際、明示的にオブジェクト変数を解放（`Nothing`を代入）しなかった場合、そのメモリ領域はプロシージャが終了しても即座には解放されない。これが数千回のループや長時間のバッチ処理で行われると、「Accessのメモリ肥大化（Bloat）」を引き起こし、最終的にOSのリソースを食い潰してフリーズする。
さらに悪質なのは、DAOの`QueryDef`や`Database`オブジェクトの暗黙的なインスタンス化である。
‘ 【アンチパターン】これぞ典型的なメモリリークの温床
Dim i As Long
For i = 1 to 1000
‘ CurrentDbは呼び出すたびに新しいDatabaseオブジェクトのインスタンスをヒープに生成する！
‘ 参照が解放されないままループすると、メモリリークが爆発的に進行する。
Dim rs As DAO.Recordset
Set rs = CurrentDb.OpenRecordset(“SELECT FROM T_HeavyData”, dbOpenDynaset)
‘ 何らかの処理…
rs.Close
‘ Set rs = Nothing すら省略されている地獄のコード
Next i
—
3. 実装の極み：極限まで最適化されたレコードセット制御パターン
プロフェッショナルの現場では、例外発生時（エラー時）であっても確実にメモリが解放される構造化されたコードを書く必要がある。以下に、大量データ処理において破綻しない実用的なVBAコードを示す。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 務用バッチ処理モジュール：高速・安全なデータストリーミング処理
‘ =========================================================================
Public Sub ProcessLargeVolumeData()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strSQL As String
Dim lngCount As Long
‘ 1. CurrentDbは必ず変数に格納し、インスタンスの乱立（メモリリーク）を防ぐ
Set db = CurrentDb()
‘ 2. 参照専用であることが明白なため、dbOpenSnapshotを選択
‘ さらに dbForwardOnly を組み合わせることで、ブックマーク機能を排除し極限までメモリを削減
strSQL = “SELECT ID, TargetCode, Value FROM T_MassiveLog WHERE Processed = False”
On Error GoTo ErrorHandler
‘ dbForwardOnly + dbOpenSnapshot の組み合わせは、数百万件のストリーミング処理において最強の速度を誇る
Set rs = db.OpenRecordset(strSQL, dbOpenSnapshot, dbForwardOnly)
lngCount = 0
‘ 3. レコードが存在しない場合のハンドリング
If rs.EOF Then
MsgBox “処理対象データが存在しません。”, vbInformation
GoTo Cleanup
End If
‘ 4. 高速ループ処理
Do While Not rs.EOF
‘ — 実際の業務処理（例：別処理への受け渡し等） —
‘ ※ dbForwardOnlyのため、MoveNext以外の移動（MovePrevious等）はできない点に注意
lngCount = lngCount + 1
‘ 10,000件ごとに進捗をイミディエイトウィンドウに出力（UIフリーズ防止と生存確認）
If lngCount Mod 10000 = 0 Then
Debug.Print lngCount & “件処理完了…”
DoEvents ‘ 必要に応じてUIの応答性を維持
End If
rs.MoveNext
Loop
MsgBox “バッチ処理が正常終了しました。総処理件数: ” & lngCount, vbInformation
Cleanup:
‘ =========================================================================
‘ 5. 厳格なオブジェクトの明示的解放（ライフサイクル管理の徹底）
‘ =========================================================================
On Error Resume Next
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
If Not db Is Nothing Then
Set db = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
Resume Cleanup
End Sub
—
4. チーフアーキテクトからの提言：レガシーとモダンインフラの境界線
もし、あなたの扱っているAccessデータベースのデータ量が数百万件を超え、ネットワーク越し（ファイルサーバー上）の共有フォルダで動作しているのであれば、もはやVBAのコードレベルのチューニングだけで解決するフェーズは過ぎている。
1. Jet/ACEの限界の認識: Accessのバックエンド（ACCDB）は、ファイルロック方式の限界から、同時接続数や大規模データでのインデックス破損リスクを常に抱えている。
2. SQL Server / Azure SQLへのオフロード: 大量データの集計や更新処理は、スナップショットやDynasetを使うまでもなく、PassthroughクエリやADODBを通じたサーバーサイド（T-SQL）での処理に移行すべきだ。
3. API連携への昇華: VBAから外部のWeb APIを叩くようなアーキテクチャでは、オブジェクトの解放漏れがそのままソケットリークやハンドルの枯渇に直結する。
DAOのカーソルタイプを正しく選定し、メモリのライフサイクルを完全に掌握すること。それは、レガシーシステムを延命させる技術であると同時に、よりモダンなシステムアーキテクチャへ移行するための基礎体力なのだ。
妥協のないコードだけが、システムを永遠に稼働させ続ける。
