Accessの「GUIクエリ」と「動的SQL」の境界線：極限のアーキテクチャ設計術
Access開発において、多くのエンジニアが陥る罠がある。それは「すべてをGUIで完結させる」か、あるいは「すべてをVBAで動的生成する」という極端な二元論だ。
伝説的なシステムは、常にその境界線を冷徹に見極めている。本稿では、保守性とパフォーマンスを両立させるための、シニア層に向けた設計思想を説く。
—
1. 境界線を定義する：聖域と戦場
まず、設計の原則を定義する。
- GUI（クエリ定義）の聖域：
- 静的なデータソース（参照用マスター、定型帳票の基盤）。
- Accessのクエリ最適化エンジン（Jet/ACE）が最も効率的に実行計画を立てられる「素のSQL」。
- VBA（動的生成）の戦場：
- 検索条件が5つ以上、あるいは「条件の有無が不確定」な動的フィルター。
- 複雑な一時テーブル操作や、外部システムと連携するストアドプロシージャの呼び出し。
「クエリデザインビュー」は、複雑なJOINを視覚的に検証するためのツールであり、最終出力場所ではない。 運用フェーズに入れば、クエリ定義ファイル（QueryDef）自体がブラックボックス化し、デバッグの足かせになるからだ。
—
2. パラメータクエリの極致：QueryDefの再利用戦略
動的SQLを盲目的に`CurrentDb.Execute`で投げつけるのは素人仕事だ。実行計画をキャッシュさせるためには、`QueryDef`オブジェクトを明示的に操作し、パラメータをバインドさせる手法が不可欠である。
実装例：最適化されたパラメータ注入
Public Sub ExecuteOptimizedQuery(ByVal param1 As String, ByVal param2 As Long)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
Set db = CurrentDb
‘ 定義済みのクエリを呼び出し、再コンパイルを抑制する
Set qdf = db.QueryDefs(“qry_TargetTemplate”)
‘ パラメータの明示的指定（型安全を担保）
qdf.Parameters(“prm_UserCode”) = param1
qdf.Parameters(“prm_StatusID”) = param2
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
‘ ここでデータを加工…
‘ オブジェクトのライフサイクルを厳格に管理
rs.Close
qdf.Close
Set rs = Nothing
Set qdf = Nothing
Set db = Nothing
End Sub
この手法の肝は、「SQLをコード内で組み立てない」ことにある。クエリ定義自体をテンプレートとし、パラメータだけを流し込むことで、ACEエンジンは実行計画をメモリ上にキャッシュしやすくなる。
—
3. 動的生成が必要な場面：メタプログラミングの境界
どうしても動的SQLが必要な場合（例：ユーザーがUIで自由に検索条件を組み合わせる場合）、文字列連結によるSQL生成は脆弱性の温床となる。
ここで私が推奨するのは、「クエリビルダークラス」の導入だ。文字列結合を直接コードに書くのではなく、部品化されたSQL断片をリスト構造で管理し、最後に結合する。
堅牢なSQL生成のヒント
‘ メソッドチェーンのように条件を追加する設計が理想
Public Function BuildDynamicSQL(ByVal baseSQL As String, ByVal filterDict As Object) As String
Dim sb As String
sb = baseSQL & ” WHERE 1=1″
Dim key As Variant
For Each key In filterDict.Keys
‘ ここでSanitize（SQLインジェクション対策）を徹底する
sb = sb & ” AND ” & key & ” = ” & FormatSQLValue(filterDict(key))
Next key
BuildDynamicSQL = sb
End Function
※ `FormatSQLValue`内では、シングルクォーテーションの置換（`Replace(str, “‘”, “””)`）を忘れてはならない。
—
4. パフォーマンスを最大化するメモリアーキテクチャ
大規模なAccessシステムでメモリリークを引き起こす最大の要因は、`CurrentDb`の乱用と、オブジェクトの解放忘れだ。
1. CurrentDbのキャッシュ化: `CurrentDb`は呼び出すたびに新しいインスタンスを生成する。大規模ループ内では必ず変数に代入して使い回せ。
2. DAOオブジェクトの明示的解放: `Set obj = Nothing`は気休めではない。循環参照を防ぐための最低限の儀式だ。
3. スナップショットの活用: 更新が不要な参照用データには、必ず `dbOpenSnapshot` を指定せよ。ダイナセット（`dbOpenDynaset`）はロック管理のオーバーヘッドが重く、パフォーマンスを削ぐ。
—
5. チーフアーキテクトからの助言
Accessを「単なるデスクトップDB」と侮るな。適切に設計されたQueryDefと、厳格なライフサイクル管理を施したVBAは、並のWebアプリよりも高速で堅牢なデータ処理基盤となる。
- 小規模なクエリ： GUIで設計し、SQLビューで検証して終わり。
- 中規模なロジック： QueryDefに保存し、パラメータをVBAから注入。
- 大規模な動的処理： SQL生成ロジックをクラス化し、再利用可能なパーツにする。
この「三層構造」を徹底するだけで、あなたの管理するシステムは、5年後も10年後も「レガシーの墓場」ではなく「現役の基幹システム」として君臨し続けるだろう。
コードを書く前に、データが流れるパスを想像せよ。それがエンジニアの品格である。
