CurrentDbとDBEngine(0)(0)のメモリ管理：DAO接続を最適化する設計パターン
レガシーシステムの寿命は、細部のメモリ管理の精度で決まる。
Access VBAの現場において、`CurrentDb`と`DBEngine(0)(0)`は、すべてのデータ操作の根幹をなすDAO（Data Access Objects）のエントリポイントである。しかし、この2つの挙動の違いとメモリ上のライフサイクルを正確に理解している開発者は、驚くほど少ない。
「とりあえず動くから」と、ループの内部で安易に`CurrentDb`を呼び出していないか？
その実装は、裏でCOMコンポーネントの生成と破棄を繰り返し、Jet/ACEエンジンに深刻なメモリリークとパフォーマンス劣化を引き起こしている。
本稿では、Access VBAのオブジェクトモデルの深層に踏込み、DAO接続のオーバーヘッドを極限まで削ぎ落とすための設計パターンを提示する。
—
1. `CurrentDb` vs `DBEngine(0)(0)` の本質的差異
まず、この2つのアクセシビリティの根本的な違いを定義する。
- `DBEngine(0)(0)` (または `DBEngine.Workspaces(0).Databases(0)`)
現在のセッションにおけるデフォルトのワークスペース、かつデフォルトのデータベース（つまり現在開いているAccDB/MDB自体）への永続的な参照を返す。一度評価されたポインタはキャッシュされ、プロセスが生存する限り同じインスタンスを指し続ける。
- `CurrentDb`
関数が呼び出されるたびに、新しいDAOのDatabaseオブジェクトを動的に生成（インスタンス化）する。さらに、内部でシステムテーブルの再同期やセッション情報の刷新を行うため、極めて重い処理が走る。
なぜ `CurrentDb` は遅いのか？
`CurrentDb`の裏側では、単なるポインタの返却ではなく、COMのインスタンス生成、セッションのコンテキスト構築、さらには隠しテーブルのロック管理などが実行されている。
これを数千件のループ内で毎回呼び出すことは、毎回のデータベースファイルに対して新規接続を確立・切断しているようなものであり、Jet/ACEエンジンのワーキングセットを肥大化させる直接の原因となる。
—
2. 致命的なアンチパターン：ループ内での `CurrentDb` 乱用
以下のコードを見てほしい。一見して何の問題もない、よくある業務システムの更新処理である。
‘ 【アンチパターン】ループ内でCurrentDbを叩き続ける最悪の実装
Sub UpdateMaster_Bad()
Dim i As Long
For i = 1 to 10000
‘ 毎回新しいDatabaseオブジェクトが生成され、メモリを圧迫する
CurrentDb.Execute “UPDATE T_Master SET Processed = True WHERE ID = ” & i, dbFailOnError
Next i
End Sub
このコードを実行すると、何が起きるか。
10,000回のループごとに`CurrentDb`が呼ばれ、10,000個のDAO.Databaseオブジェクトがヒープ領域に生成される。VBAのガベージコレクションやCOMの参照カウント解放のタイミングによっては、メモリが解放しきれず、Access全体の動作が重くなる、あるいは「リソース不足」エラーでクラッシュする。
—
3. シニアエンジニアの設計パターン：データベース変数のスコープ管理
この問題を解決するアプローチは極めてシンプルである。「一度だけ取得し、使い回し、明示的に解放する」。
DAOのDatabaseオブジェクトをプロシージャのスコープ（あるいはモジュールレベル）で変数に保持し、ループの外で一度だけ`CurrentDb`を評価する。
‘ 【推奨パターン】オブジェクトのライフサイクルを制御した最適化実装
Sub UpdateMaster_Optimized()
Dim db As DAO.Database
Dim i As Long
‘ 1回だけCurrentDbを呼び出し、ローカル変数に参照を保持する
Set db = CurrentDb
‘ トランザクションの適用でさらにI/Oを最適化
db.BeginTrans
On Error GoTo ErrorHandler
For i = 1 To 10000
‘ 保持した変数を使い回す（オーバヘッドはゼロに近い）
db.Execute “UPDATE T_Master SET Processed = True WHERE ID = ” & i, dbFailOnError
Next i
db.CommitTrans
‘ 明示的な解放
Set db = Nothing
Exit Sub
ErrorHandler:
db.Rollback
Set db = Nothing
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
End Sub
なぜ `Set db = Nothing` が必須なのか？
VBAのランタイムはいずれ変数のスコープ外に出た際にメモリを回収するが、COMオブジェクト（DAOやADO）は参照カウントが0になるタイミングが厳密ではない。特にAccessのイミディエイトウィンドウやエラーハンドリング時、参照が残ったままになると、Accessを終了するまでメモリ上にデータベースへのロックやセッションが残存する。
プロシージャの終了前には必ず `Set db = Nothing` を記述し、リソースを即座に返却するのがプロフェッショナルの作法である。
—
4. 極限のパフォーマンス：`DBEngine(0)(0)` の使い所とリスク
では、すべての場面で `CurrentDb` の代わりに `DBEngine(0)(0)` を使えばいいかというと、そうではない。ここがアーキテクトの腕の見せ所である。
`DBEngine(0)(0)` はすでにキャッシュされたインスタンスを返すため、`CurrentDb` よりも圧倒的に高速である。しかし、致命的な弱点がある。
> 警告: `DBEngine(0)(0)` は、構造変更（DDL）や一部のセッション依存の操作を行った際に、内部状態が同期されないリスクがある。また、他の外部プロセスやマルチユーザ環境での排他制御において、古いスキーマキャッシュを参照し続ける危険性がある。
したがって、`DBEngine(0)(0)` を採用してよいのは、以下の条件を満たす「閉じた高速処理」の場合に限られる。
1. 構造変更（TableDefの変更やクエリの動的生成など）を伴わない純粋なDML（SELECT, UPDATE, INSERT, DELETE）であること。
2. 数千・数万件のレコードを高速に処理するバッチ処理やトランザクション内であること。
実装例：`DBEngine(0)(0)` を用いた高速バルク処理
Sub HighSpeedBatch_Extreme()
Dim db As DAO.Database
‘ キャッシュされたデフォルトインスタンスを直接取得
Set db = DBEngine(0)(0)
db.Execute “INSERT INTO T_Log (LogTime, Message) VALUES (Now(), ‘Batch Start’)”, dbFailOnError
‘ ※注意: DBEngine(0)(0) 自体は Nothing で解放してはならない（プロセス全体で共有されるため）
‘ 変数 db は単なる「参照のエイリアス」として扱う
Set db = Nothing
End Sub
注意: `DBEngine(0)(0)` を変数に代入した場合、`Set db = Nothing` とするのは「変数 `db` の参照を切る」だけであり、基底のデータベースエンジンそのものを破壊するわけではない。ただし、混乱を避けるため、直接 `DBEngine(0)(0).Execute …` と記述するか、明確にスコープを限定して扱うべきである。
—
5. まとめ：アーキテクチャ選定の基準
実務におけるシステム設計の指針を以下にまとめる。
| 評価項目 | `CurrentDb` | `DBEngine(0)(0)` |
| :— | :— | :— |
| 速度 | やや遅い（毎回インスタンス生成） | 圧倒的に高速（キャッシュ参照） |
| 安全性 | 高い（常に最新のセッション状態を反映） | 中程度（構造変更やマルチ環境で同期ズレのリスク） |
| 推奨用途 | 通常のフォーム処理、データメンテ、構造変更を伴う処理 | 大量データの高速更新、閉じたバッチ処理 |
| 最適化手法 | 変数に受けて使い回し、最後に `Nothing` 解放 | 必要箇所で直接呼び出し、またはスコープ限定 |
レガシーシステムのパフォーマンスチューニングにおいて、ボトルネックの多くはSQLの書き方ではなく、「オブジェクトの生成と破棄のコスト」にある。
`CurrentDb` の挙動の裏側を理解し、適切なスコープ管理とメモリ解放を徹底することで、Access VBAとは思えないほどの堅牢性と高速性を手に入れることができる。コードの細部に神は宿る。明日からの実装にこの知見を即座に反映させてほしい。
