Accessを「生きた基幹系」に変える：QueryDefハイブリッド設計の極意
多くの開発者が、Accessの設計において二者択一の罠に陥る。
「すべてをクエリデザインビューで構築し、複雑な画面からの検索条件に悶絶する」か、「すべてをVBAの文字列結合でSQLとして組み立て、メンテナンス不能なスパゲッティコードを生み出す」か。
どちらもアーキテクチャの敗北だ。
シニアエンジニアであれば知っているはずだ。Accessの真のポテンシャルは、ビジュアルなクエリデザイナが持つ構造化の美しさと、VBAによる動的条件制御を完璧に融合させたハイブリッドアーキテクチャにある。
今回は、複雑な多重JOINや集計の骨組みをデザインビューで静的に担保しつつ、WHERE句の可変性だけをVBAで安全にインジェクトする『QueryDefハイブリッド設計』の極意を、メモリ管理と実行計画の最適化の観点から解き明かす。
—
1. なぜ「全VBA生成」や「全デザインビュー」は破綻するのか？
実務で数百万件規模のデータを扱う基幹系Accessシステムにおいて、愚直なアプローチは必ずシステムを崩壊させる。
- 全VBA動的SQLの弊害:
SQL文をVBA内で `strSQL = “SELECT … WHERE ” & me.txtCond` のように組み立てると、構文エラーの温床になるだけでなく、Jet/ACEエンジンが実行計画（Execution Plan）をキャッシュできず、クエリ実行のたびにパースコストが発生する。
- 全デザインビュー固定の弊害:
ユーザーの「あれもこれも」という多次元な検索条件に対応するため、クエリ側に `[Forms]![frmSearch]![txtParam]` のような直接参照を埋め込むと、フォーム名やコントロール名の変更に耐えられず、かつクエリの再利用性が完全に失われる。
解決解：骨組みは固定、条件は後付け
クエリの「構造（FROM句、JOIN、SELECT列、GROUP BY）」はQueryDefとしてあらかじめデザインビュー（または静的SQL）でコンパイル可能な状態で保持し、「WHERE句」と「パラメータ」のみをVBAから動的に差し込む。これが唯一の正解である。
—
2. 実装パターン：QueryDefハイブリッドの全貌
実際に現場で即座に使える、極限まで最適化されたコードパターンを示す。
ここでは、あらかじめデザインビューで作成しておいたベースクエリ `qry_Master_Base` に対し、VBAから安全にWHERE句を適用する手法をとる。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 概略: クエリ定義の骨組みを維持し、WHERE句のみを動的に再定義するプロシージャ
‘ アーキテクチャノート:
‘ 1. DBEngine(0)(0) の参照をローカル変数にキャッシュし、COMオブジェクトの解放漏れを防ぐ
‘ 2. パラメータクエリとして構築することでSQLインジェクションを根絶する
‘ =========================================================================
Public Sub ExecuteDynamicQuery(ByVal prmKeyword As String, ByVal prmDateFrom As Date, ByVal prmDateTo As Date)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim strWhere As String
Dim strSQL As String
‘ オブジェクトの明示的取得（グローバルなCurrentDb関数の乱用は暗黙のインスタンス生成を招くため避ける）
Set db = CurrentDb()
On Error GoTo ErrorHandler
‘ 1. 既存のベースクエリを取得
‘ ※あらかじめクエリデザイナで複雑なJOINとSELECT句を持つ「qry_Master_Base」を作っておく
Set qdf = db.QueryDefs(“qry_Master_Base”)
‘ 2. 動的WHERE句の構築
strWhere = ” 1=1″ ‘ 条件連結を容易にするためのプレースホルダー
If Len(Trim(prmKeyword)) > 0 Then
‘ パラメータ化クエリのプレースホルダーを使用する（文字列連結によるSQLインジェクションの排除）
strWhere = strWhere & ” AND (T1.CustomerName LIKE [p_Keyword] OR T1.Memo LIKE [p_Keyword])”
End If
If prmDateFrom > 0 Then
strWhere = strWhere & ” AND T1.OrderDate >= [p_DateFrom]”
End If
If prmDateTo > 0 Then
strWhere = strWhere & ” AND T1.OrderDate <= [p_DateTo]"
End If
' 3. SQLの再構築（ベースのSQLからWHERE句以降を置き換える、あるいは動的に付与する）
' ここではベースクエリが「SELECT ... FROM (...)」の形であり、WHERE句を持たない前提とする
' 実運用では、ベースクエリのSQL文字列を解析、あるいは「WHERE 1=1」で終わらせておくのが定石
' 【重要】QueryDefのSQLプロパティを書き換えることで、Jet/ACEエンジンに新しい実行計画を強制生成させる
' ※ただし、頻繁なDDL操作はシステムデータベース（ACCDB）の肥大化（Bloat）を招くため、
' パラメータコレクション（Parameters）の書き換えで済む場合はそちらを優先すべきである。
' パラメータコレクションへの値のバインド（型安全性の確保）
' あらかじめベースクエリ側にパラメータ宣言（PARAMETERS ...;）が存在するか、
' あるいはDAOのParametersコレクションを動的に操作する。
With qdf
' パラメータが存在する場合は値を注入
If Len(Trim(prmKeyword)) > 0 Then
.Parameters(“p_Keyword”) = “%” & prmKeyword & “%”
End If
If prmDateFrom > 0 Then
.Parameters(“p_DateFrom”) = prmDateFrom
End If
If prmDateTo > 0 Then
.Parameters(“p_DateTo”) = prmDateTo
End If
‘ レコードセットとしての利用、あるいはフォームのRecordSourceへの割り当て
Set Forms(“frmSearchResult”).Recordset = .OpenRecordset(dbOpenSnapshot)
End With
CleanUp:
‘ 4. メモリリークの完全防止（DAOオブジェクトの明示的破棄）
If Not qdf Is Nothing Then
qdf.Close
Set qdf = Nothing
End If
If Not db Is Nothing Then
db.Close
Set db = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “System Error”
Resume CleanUp
End Sub
—
3. チーフアーキテクトが教える：パフォーマンスとメモリ管理の極意
Access/VBA開発において、シニアとジュニアを分ける境界線は「COMオブジェクトのライフサイクル管理」と「データベースの物理構造（Bloat現象）」への理解度にある。
A. `CurrentDb` の罠とローカル変数キャッシュ
多くのプログラマブルコードで見かける `CurrentDb.Execute` や `CurrentDb.OpenRecordset`。
実は、`CurrentDb` を呼び出すたびに、Accessは内部で新しいDAO.Databaseインスタンスを生成している。これをループ内やイベント内で乱用すると、メモリリークを引き起こし、最悪の場合は「メモリ不足（Out of Memory）」エラーでプロセスがクラッシュする。
鉄則:
`Set db = CurrentDb()` として必ずローカル変数に参照を保持し、プロシージャの終了時に明示的に `Set db = Nothing` で解放すること。
B. ACCDB肥大化（Bloat）の回避とクエリキャッシュ
QueryDefの `SQL` プロパティをVBAから動的に書き換え（`qdf.SQL = …`）、それを保存（AppendやUpdate）するような設計をすると、Accessの内部データベースファイル（ACCDB）が急速に断片化し、メガバイト単位でファイルサイズが肥大化していく。
回避策:
構造そのものを動的に変更するのではなく、「クエリは静的に定義し、パラメータのみをバインドする」 または 「一時クエリ（TemporaryQueryDef）をメモリ上だけで作成・破棄する」 手法を徹底する。
DAOでは、名前に `~`（チルダ）を冠したクエリや、一時的なQueryDefオブジェクトをデータベースコンテナに永続化させずにメモリ上で扱う高度なテクニックが存在する。
‘ データベースに永続保存しない一時的なQueryDefの生成（ACCDBの肥大化を防ぐ）
Dim qdfTemp As DAO.QueryDef
Set qdfTemp = db.CreateQueryDef(“”, “SELECT FROM qry_Master_Base WHERE OrderDate >= [p_Date]”)
qdfTemp.Parameters(“p_Date”) = Date – 30
Set Me.Recordset = qdfTemp.OpenRecordset(dbOpenSnapshot)
‘ ※名前を “”（長さゼロの文字列）にすることで、システムカタログに書き込まれず、メモリ上だけで完結する。
—
4. レガシー環境・システム間連携における実戦的アドバイス
企業内システムにおいて、Accessは孤島ではない。基幹系SQL ServerやOracle、あるいは外部APIとの連携ハブとして使われることが多い。
このハイブリッドクエリ設計は、ODBC経由のパススルークエリ（Pass-Through Query）や、Linked Table（リンクテーブル）を用いた大規模データ処理においても絶大な効果を発揮する。
- パススルークエリへの応用:
重い集計処理はサーバー側（SQL Serverなど）のインデックスをフル活用させたい。
デザインビューでパススルークエリの「接続文字列」と「SQLの骨組み」を固定しておき、WHERE句の条件パラメータだけをVBAから動的に書き換えてリモート実行する。これにより、クライアント側（Access）へのデータ転送量を極限まで削減し、ネットワーク帯域を保護できる。
—
結言
Access VBAは、正しく扱えば、現代の巨大なエンタープライズシステムに対抗しうる「爆発的な開発生産性」を持つ極めて優秀なプラットフォームである。
「デザインビューの視覚的保守性」と「VBAの動的柔軟性」。
この二つを妥協なく融合させたハイブリッド設計こそが、レガシーの呪縛からシステムを解放し、真の「生きた基幹系」を構築唯一の道である。
コードの隅々にまで意図を宿せ。メモリのライフサイクルを支配しろ。それが、真のプロフェッショナルエンジニアの仕事だ。
