CurrentDbとDBEngine(0)(0)の使い分け：DAOの接続効率を最大化するメモリ管理術
開発現場で、Access VBAによる大規模なデータ処理やバッチ処理を組んだことはあるだろうか。数万件のレコードをループ処理した途端にメモリ使用量が跳ね上がり、最悪の場合は「実行時エラー 3043: ディスクI/Oエラー」や、理由の分からないメモリリークでAccessごと強制終了する――。
この悪夢の原因の多くは、DAO（Data Access Objects）の接続インスタンス、すなわちデータベースントリの取得方法の誤りに起因している。
今回は、Access VBAのパフォーマンスチューニングにおいて避けて通れない「`CurrentDb`」と「`DBEngine(0)(0)`」の決定的な違いと、極限までメモリ効率を高めるための設計思想を伝授しよう。
—
1. 結論：どっちを使うべきか？
先に対策の結論を提示する。実務のプロダクションコードにおいて、どちらを採用すべきかの基準は明確だ。
- 基本方針：
データ操作を行うプロシージャ内では、`CurrentDb`を変数に1度だけ格納し、それをスコープ内で完全に使い回す。
- 例外（システム系・特殊用途）：
画面の再描画制御や、トランザクションの厳密な制御、あるいは`CurrentDb`のオーバーヘッドすら許されない極限の高速化が求められる一部のルーチンでは、`DBEngine(0)(0)`を直接叩く。
「毎回 `CurrentDb` を書けばいいや」という安易な設計は、Accessの内部メモリ構造を破壊し、パフォーマンスを確実に劣化させる。その理由を解き明かしていこう。
—
2. 内部メカニズムの深掘り：なぜ「毎回 `CurrentDb`」は悪なのか？
多くの初心者が犯す最大の過ちは、ループやプロシージャのあちこちで以下のように記述することだ。
‘ 【アンチパターン】絶対にやってはいけない書き方
Dim i As Long
For i = 1 to 10000
CurrentDb.Execute “UPDATE T_Log SET Status = 1 WHERE ID = ” & i, dbFailOnError
Next i
`CurrentDb` の正体
`CurrentDb`メソッドは、呼び出されるたびに新しいDAOのDatabaseオブジェクト（インスタンス）をメモリ上に生成し、開いているカレントデータベースへの新鮮な参照を返す。
つまり上記のコードは、1万回もデータベースの接続セッションを新規作成・破棄（オープンとクローズ）を繰り返していることになる。当然、メモリ上には不要なオブジェクトの残骸（参照カウントの未解放）が蓄積され、Accessの内部キャッシュがパンクする。これが「メモリリーク」の正体だ。
では `DBEngine(0)(0)` はどうか？
一方、`DBEngine(0)(0)` は、現在開いているワークスペース（Index 0）のデフォルトデータベース（Index 0）、すなわち現在のアクティブなデータベースへの永続的な単一インスタンス（シングルトン）を直接指す。
‘ DBEngine(0)(0) の参照
Dim db As DAO.Database
Set db = DBEngine(0)(0)
これは新しいインスタンスを作らず、すでにメモリ上に存在するマスターインスタンスへのポインタを返すため、`CurrentDb`のような生成コストがかからない。しかし、これにも「Accessの内部状態変化に追従しにくい」という設計上のトレードオフが存在する（これについては後述する）。
—
3. ベストプラクティス：CurrentDbの「変数キャッシュ」設計
メモリリークを防ぎつつ、安全かつ高速にDAOを操るための唯一の正解は、「`CurrentDb` をローカル変数に一度だけ代入し、そのスコープ内ではその変数を使い回す」ことだ。
実務で使える堅牢なプロダクションコード例
数万件の受発注データを一括処理し、エラーハンドリングとトランザクションを完備した堅牢なモジュールのサンプルを提示する。
Option Compare Database
Option Explicit
Public Sub ProcessLargeScaleData()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim startTime As Double
startTime = Timer
‘ 【重要】エラーハンドリングの準備
On Error GoTo ErrorHandler
‘ 1. CurrentDbをローカル変数に「1度だけ」格納する（これが最大のポイント）
Set db = CurrentDb
‘ 2. トランザクションの開始（パフォーマンスとデータの整合性を担保）
db.BeginTrans
‘ 3. パラメータクエリの事前コンパイル（QueryDefの活用）
‘ 毎回SQLをパースするオーバーヘッドを排除する
Set qdf = db.CreateQueryDef(“”, “UPDATE T_TargetData SET ProcessedFlag = -1 WHERE CategoryID = [prmCat];”)
qdf.Parameters(“prmCat”).Value = 10
‘ 4. 実行
qdf.Execute dbFailOnError
‘ トランザクションのコミット
db.CommitTrans
MsgBox “処理が正常に完了しました。 処理時間: ” & Format(Timer – startTime, “0.00”) & “秒”, vbInformation
CleanUp:
‘ 5. オブジェクトの明示的な解放（メモリ管理の鉄則）
On Error Resume Next
If Not qdf Is Nothing Then qdf.Close: Set qdf = Nothing
If Not db Is Nothing Then Set db = Nothing
Exit Sub
ErrorHandler:
‘ 異常発生時はロールバック
If Not db Is Nothing Then db.Rollback
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
このコードが堅牢である理由
1. インスタンスの乱造を防ぐ: `CurrentDb` の呼び出しはプロシージャ内で1回のみ。メモリリークの温床を断っている。
2. QueryDefによる高速化: 文字列結合によるSQLインジェクションのリスクを排除し、クエリの実行プランをキャッシュさせている。
3. 確実なメモリ解放: `CleanUp` ラベルを設け、エラー発生時であっても確実にオブジェクト変数を `Nothing` に明示解放している。
—
4. `DBEngine(0)(0)` を採用すべき特殊なケース
では、すべての場面で `CurrentDb` の変数キャッシュで良いかと言うと、そうではない。以下の特殊な要件下では、`DBEngine(0)(0)` が真価を発揮する。
① フォームや外部モジュールから頻繁に呼び出される汎用ユーティリティ関数
アプリケーション全体で共通利用する小さな関数（例：指定したマスタが存在するかをチェックする関数など）において、毎回 `CurrentDb` を変数定義して取得するのはコードが冗長になる。
‘ 汎用的な存在チェック関数（DBEngine(0)(0)が適している例）
Public Function IsRecordExists(ByVal strSQL As String) As Boolean
Dim rs As DAO.Recordset
‘ インスタンス生成のオーバーヘッドを極限まで削る
Set rs = DBEngine(0)(0).OpenRecordset(strSQL, dbOpenSnapshot)
IsRecordExists = Not (rs.BOF And rs.EOF)
rs.Close
Set rs = Nothing
End Function
② 注意点：なぜ常に `DBEngine(0)(0)` ではダメなのか？
`DBEngine(0)(0)` は強力だが、AccessのUI（画面）や外部からのデータ構造変更（DDL実行によるテーブル削除・再作成など）を検知した際、キャッシュが古くなっている場合がある。
特に、構造変更を伴う処理の直後に `DBEngine(0)(0)` を使うと、古いスキーマ情報を掴んでしまい「エントリが見つかりません」といった神隠しのようなバグを引き起こす。
そのため、データの読み書き（DML）が主体の日常的な処理では `CurrentDb`（の変数キャッシュ）、システムの深部や純粋な高速参照では `DBEngine(0)(0)` と使い分けるのが、シニアエンジニアの知見である。
—
5. まとめ
Access VBAにおけるメモリ管理とパフォーマンスチューニングは、オブジェクトの「ライフサイクル」を完全にコントロールすることと同義だ。
- `CurrentDb` は呼び出すたびに新規インスタンスを作る。 ループ内で直接呼び出すのは「メモリリークの自殺行為」。
- 必ずローカル変数に1度だけ格納し、使い回せ。
- 処理の終了時には必ず `Set db = Nothing` でメモリを解放せよ。
この鉄則をプロジェクトメンバー全員が遵守するだけで、Accessアプリの安定性は劇的に向上し、「突然落ちるブラックボックス」から解放されるはずだ。現場のコードを今すぐ見直し、洗練されたメモリ管理を実装してほしい。
