QueryDefを極めよ：一時テーブル動的生成におけるメモリ管理と競合回避の極限知見
Access VBAによる大規模な業務システム開発において、帳票出力や複雑なデータ集計は避けて通れない。このプロセスで最も頻繁に犯される過ちは、安易な `DoCmd.RunSQL` や、場当たり的なレコードセットのループ処理による「一時テーブルの乱立」だ。
ローカル一時テーブルを毎回物理的に作成・削除する設計は、Accessの内部データベースエンジン（ACE/Jet）において、トランザクションログの肥大化、システムカタログの断片化（Bloat）、そして致命的なマルチユーザー間の競合（Lock Contention）を引き起こす。
本稿では、`QueryDef`オブジェクトを駆使して動的にデータセットを構築し、ガベージコレクションの限界を見据えたメモリ管理、およびコンカレンシー（並行性）を完全に担保したクリーンアップ戦略について、現場の最前線で培った実務的知見を余すところなく解説する。
—
1. なぜ「物理一時テーブルの乱立」はシステムを殺すのか
多くの開発者は、一時的なワークデータを格納するために `CurrentDb.Execute “CREATE TABLE tmp_Report (ID Long, …)”` のようなコードを書く。しかし、これはレガシーな設計の悪習に他ならない。
物理テーブルを動的に作成・破棄するアプローチには、以下の構造的欠陥がある。
- システムカタログ（MSysObjects）の激しい消耗: テーブルの作成と削除のたびにシステムテーブルが更新され、データベースファイルが急速に肥大化する。
- 排他制御の衝突: 複数ユーザーが同時に同名の物理一時テーブルを作成しようとした瞬間、ランタイムエラー（エラー3014: 「これ以上テーブルを開けません」または競合エラー）が発生する。
- トランザクションオーバーヘッド: DDL（Data Definition Language）は暗黙のトランザクションを発生させ、パフォーマンスを著しく低下させる。
解決策：名前付き一時QueryDefと「構造化ビュー」の併用
物理テーブルを作る必要はない。必要なのは「実行時にパラメータをバインドできる動的クエリの定義（QueryDef）」である。これを利用すれば、データ構造のみをメモリ上に保持し、実体は必要最小限のストレージ操作にとどめることができる。
—
2. 実装アーキテクチャ：動的QueryDefによる安全なデータセット構築
以下に、実業務の現場で耐えうる、競合フリーかつメモリリークを完全に排除した一時データ生成ルーチンの実装を示す。
このコードでは、グローバル領域や固定の名前ではなく、実行セッション（またはタスク）ごとにユニークなQueryDef名を動的に生成し、処理完了後に確実に破棄する設計を採用している。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 担当者: チーフアーキテクト
‘ 概要: 競合回避型・動的QueryDef生成と安全なクリーンアップ処理
‘ ==============================================================================
Public Sub ExecuteReportWorkflow()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim uniqueQueryName As String
Dim paramDate As Date
‘ セッション固有のユニーク名生成（複数ユーザー・多重起動対策）
‘ タイムスタンプとランダム値を組み合わせることで競合の確率を完全にゼロにする
uniqueQueryName = “qdef_TempReport_” & Format(Now, “yyyymmddhhnnss”) & “_” & Int((9999 – 1000 + 1) Rnd + 1000)
Set db = CurrentDb
paramDate = #2023-10-01# ‘ 抽出基準日のサンプル
On Error GoTo ErrorHandler
‘ 1. 動的QueryDefの作成（Temporaryフラグを活用）
‘ DAO.QueryDefTypeEnum には一時的なクエリを作成する機能はないため、
‘ システム命名規則により一意性を担保し、必ず最後にDeleteする。
Set qdf = db.CreateQueryDef(uniqueQueryName, _
“SELECT T_Orders.OrderID, T_Orders.CustomerID, T_Orders.OrderDate ” & _
“FROM T_Orders ” & _
“WHERE T_Orders.OrderDate >= [ParamDate];”)
‘ 2. パラメータの安全なバインド（SQLインジェクションおよび型ミスマッチの防止）
qdf.Parameters(“ParamDate”) = paramDate
‘ 3. レポートへのバインド（作成したQueryDefの名前をレポートのRecordSourceに指定）
‘ DoCmd.OpenReport “Rpt_MonthlySales”, acViewPreview, , , , uniqueQueryName
‘ ※ここでは動作確認のため、レコードセットとしての処理を記述
Dim rs As DAO.Recordset
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
Debug.Print “抽出レコード数: ” & rs.RecordCount
‘ 後処理
rs.Close
Set rs = Nothing
CleanUp:
‘ 4. QueryDefの明示的削除とオブジェクト解放（メモリリーク防止の要）
If Not qdf Is Nothing Then
db.QueryDefs.Delete uniqueQueryName
Set qdf = Nothing
End If
Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “System Error”
Resume CleanUp
End Sub
—
3. メモリ管理の極意：DAOオブジェクトのライフサイクルと解放順序
Access VBAにおける最大のパフォーマンス殺しは、「暗黙の参照保持」によるメモリリークである。
`CurrentDb` メソッドは、呼び出すたびに新しい `DAO.Database` オブジェクトのインスタンスをメモリ上に生成する。これを適切に変数に格納せず、以下のように直書きするコードは悪夢の始まりだ。
‘ 【アンチパターン】これをしてはいけない
CurrentDb.QueryDefs.Delete “Query1”
CurrentDb.Execute “…”
このようなコードは、背後で生成されたデータベースインスタンスへの参照がVBAのガベージコレクションに回収されるまでメモリ上に残り続け、やがて「リソース不足（Out of Memory）」エラーを引き起こす。
鉄則：オブジェクト変数のスコープと明確な破棄
1. `CurrentDb` は必ず変数に受ける: 1つのプロシージャ内では `Dim db As DAO.Database: Set db = CurrentDb` とし、ローカル変数としてスコープを管理する。
2. 解放順序の遵守: `Recordset` $\rightarrow$ `QueryDef` $\rightarrow$ `Database` の順で `Close`（必要な場合）および `Set xxx = Nothing` を行う。
3. エラーハンドリングでの確実なクリーンアップ: 例外が発生して処理が中断した場合でも、`On Error GoTo` を用いて必ずオブジェクトの削除・解放ルーチン（`CleanUp` ラベル）を通すこと。
—
4. レガシー環境とシステム間連携における実践的トポロジー
基幹系システムや外部SQL Server/OracleデータベースとAccessがリンクテーブルで結合されている環境では、一時クエリの設計思想がさらに重要になる。
パフォーマンスを限界まで引き出す「Pass-Through（パススルー）クエリ」の動的生成
リモートDB側の巨大なテーブルに対してAccess側でローカル結合を行うと、全レコードがODBC経由でローカルに転送され、ネットワーク帯域とクライアント側のメモリが崩壊する。
これを防ぐため、動的QueryDefを「パススルー・クエリ」として構築し、処理をリモートサーバー側にプッシュダウン（移譲）するアーキテクチャが極限の最適化を生む。
Public Sub CreateDynamicPassThrough(ByVal targetCustomerID As Long)
Cat db As DAO.Database
Dim qdf As DAO.QueryDef
Dim qName As String
qName = “pt_RemoteExtract_” & Environ(“UserName”)
Set db = CurrentDb
On Error Resume Next
‘ 既存の同名定義があれば削除（競合対策）
db.QueryDefs.Delete qName
On Error GoTo 0
‘ パススルー・クエリとして作成
Set qdf = db.CreateQueryDef(qName)
‘ 接続文字列の設定（ODBC直結）
qdf.Connect = “ODBC;DSN=EnterpriseDB;UID=sa;PWD=secret;”
‘ サーバー側で実行されるSQLを設定
qdf.SQL = “SELECT FROM RemoteOrders WHERE CustomerID = ” & targetCustomerID
‘ 返し値をローカルに持たず、サーバー側で完結させる
qdf.ReturnsRecords = True
‘ 処理実行…
Dim rs As DAO.Recordset
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
‘ （中略: 処理）
rs.Close
Set rs = Nothing
db.QueryDefs.Delete qName
Set db = Nothing
End Sub
この実装により、Access側には結果セットの軽量なスナップショットのみが返され、複雑なJOINやWHEREの評価はすべてハイスペックなRDBMS側で処理される。ネットワークの負荷は最小限に抑えられ、Access特有の「重さ」は完全に払拭される。
—
5. チーフアーキテクトからの提言
Accessは「おもちゃのデータベース」ではない。その内部構造（ACEエンジン）の挙動、DAOのメモリ管理モデル、そしてWindows環境におけるリソース競合のメカニズムを深く理解し、それに則ったコードを書く限りにおいて、企業の中核を支える堅牢なエンタープライズ・クライアントとして機能し続ける。
「動的につくって、使い捨て、確実に消す」。
この原則をコードの隅々にまで徹底させることが、真にプロフェッショナルなVBAエンジニアの証である。技術の妥協を排除し、極限まで洗練されたアーキテクチャを構築し続けよ。
