Access VBAを掌握する極限の知見：CurrentDb.QueryDefsとParametersコレクションによる「型安全」なクエリ実行
こんにちは。業務システム開発プロジェクトの現場において、数々のAccess地獄を見てきたチーフアーキテクトの私だ。
Access VBAによる開発で、最も多く見かける「悪臭（Bad Smell）」を放つコードの一つが、これだ。
‘ 【アンチパターン】文字列連結によるクエリ実行
Dim sql As String
sql = “SELECT FROM T_受注 WHERE 顧客ID = ” & Me.txtID & ” AND 注文日 >= #” & Me.txtDate & “#”
Set rs = CurrentDb.OpenRecordset(sql)
これをやっているエンジニアは、今すぐ手を止めてほしい。
SQLインジェクションのリスク、日付フォーマットの罠（US式と和暦・日本語OSの衝突）、そして「型不一致」による突然のランタイムエラー。これらは全て、手抜きな文字列連結が生み出す人災だ。
Accessの真のポテンシャルを引き出し、10年耐えうる堅牢なシステムを構築したいなら、`CurrentDb.QueryDefs` と `Parameters` コレクションを用いたパラメータの明示的型指定をマスターしなければならない。
今回は、実務の現場で即座に採用できる、プロフェッショナルなクエリ実行デザインを伝授する。
—
なぜ「文字列連結」や暗黙のパラメータ指定ではダメなのか？
初学者や、場当たり的なコーディングをするプログラマーは、クエリの抽出条件にフォームのコントロールを直接参照させたり（`Forms!F_Main!txtID`）、VBA内でSQL文を組み立てたりする。
しかし、これには致命的な欠点がある。
1. 暗黙の型変換の恐怖: Jet/ACEエンジンが勝手に型の解釈を行い、予期せぬ「実行時エラー 13: 型が一致しません。」を引き起こす。特に空白やNullが混入した瞬間にシステムがクラッシュする。
2. キャッシュとパフォーマンスの劣化: SQL文字列を都度生成すると、Query Plan（実行計画）のキャッシュが効かず、重い処理でデータベースファイル（.accdb）の肥大化とパフォーマンス低下を招く。
3. 保守性の欠如: SQL文の中にVBAの変数が埋め込まれていると、デバッグ時にSQL単体での動作確認（クエリデザイナでの検証）が極めて困難になる。
究極の解決策：QueryDefの Parameters コレクション
あらかじめデザインビューでパラメータクエリ（抽出条件に `[prmCustomerID]` のような名前付きプレースホルダーを持つクエリ）を作成し、VBA側から `QueryDefs` 経由で 明示的にデータ型を指定して値jected（注入）する。これが、Access VBAにおけるベストプラクティスだ。
—
プロダクションコード：堅牢なパラメータ設定の実装例
実務でそのまま使える、エラーハンドリング完備のモジュールを提示する。
あらかじめAccess側には、`Q_GetOrderByCustomer` という名前のパラメータクエリ（SQL内で `Parameters [prmCustomerID] Long, [prmStartDate] DateTime;` と型定義されている前提、あるいはVBA側から型を強制する）が存在するものとする。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 担当者名: チーフアーキテクト
‘ 概要 : パラメータクエリを安全かつ高速に実行し、レコードセットを返す
‘ =========================================================================
Public Function GetCustomerOrders(ByVal lngCustomerID As Long, ByVal dteStartDate As Date) As DAO.Recordset
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
On Error GoTo ErrorHandler
‘ CurrentDbは呼び出すたびに異なるインスタンスを返すため、変数に保持する
‘ ※これを怠ると、COMオブジェクトの参照リークや予期せぬロック問題の温床となる。
Set db = CurrentDb()
‘ QueryDefオブジェクトの取得
Set qdf = db.QueryDefs(“Q_GetOrderByCustomer”)
‘ 【極限の知見】Parametersコレクションへの明示的代入
‘ あらかじめ型が定義されたパラメータに対し、安全に値をバインドする。
‘ これにより、VBAとデータベースエンジン間で厳密な型チェックが行われる。
qdf.Parameters(“prmCustomerID”) = lngCustomerID
qdf.Parameters(“prmStartDate”) = dteStartDate
‘ レコードセットのオープン（SNAPSHOTまたはFORWARDONLYを推奨）
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
‘ 呼び出し元へレコードセットを返却
Set GetCustomerOrders = rs
‘ 正常終了時はオブジェクトの参照のみ解放（rsは呼び出し元で閉じさせるためここでは閉じない）
GoTo CleanUp
ErrorHandler:
‘ 業務システムにふさわしい、詳細なエラーログとハンドリング
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical, “システムエラー”
‘ エラー時はNothingを返却
Set GetCustomerOrders = Nothing
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
CleanUp:
‘ QueryDefオブジェクトの解放（メモリリーク防止の鉄則）
Set qdf = Nothing
Set db = Nothing
Exit Function
End Function
—
現場で役立つアーキテクチャの急所（知見の深掘り）
上記のコードには、単なる「動くコード」を超えた、プロフェッショナルだけが知る設計思想が組み込まれている。
1. `CurrentDb` の変数保持とライフサイクル管理
よくあるアンチパターンとして、`CurrentDb.QueryDefs…` のようにドットつなぎで直接メソッドを叩くコードがある。
あれは、呼び出すたびに裏側で新しいDAOのデータベースオブジェクト生成・破棄が行われており、パフォーマンス上の無駄であるばかりか、JETエンジンの内部キャッシュ機構を阻害する。
「`Set db = CurrentDb()` でローカル変数に受けて使い回す」。これはAccess VBA開発における絶対的鉄則だ。
2. パラメータの「型不一致」をコンパイル・バインド段階で防ぐ
VBAの変数（`Long` や `Date`）からDAOの `Parameters` コレクションへ値を渡す際、Accessのエンジンは暗黙の型変換を試みる。しかし、クエリ側（QueryDef）でパラメータのデータ型を明示しておけば、不正なデータ（文字列混入など）が入ってきた時点でVBA側（あるいはバインド時）に即座に例外を発生させることができる。
これにより、「データベースの破損」や「意図しない切り捨て・誤ったデータ保存」という最悪のシナリオを未然にハザード回避できるのだ。
3. レコードセットのスコープとメモリ管理
関数内で生成したDAOの `Recordset` は、呼び出し元（UI層など）へ渡してデータを消化させるため、関数内ではクローズしない。その代わり、クエリの定義情報を保持する `QueryDef` (`qdf`) は用済みになり次第、即座に `Set qdf = Nothing` で解放している。
この「どれを解放し、どれを上位に引き渡すか」のオブジェクトライフサイクルのコントロールこそが、Accessアプリを何年経っても軽快に動作させ続けるための秘訣である。
—
まとめ
Accessは「おもちゃのデータベース」ではない。
背後に控えるJet/ACEデータベースエンジンは、正しく使えば非常に堅牢で、中小規模の業務システムにおいて無類の開発生産性を発揮する強力なツールだ。
「動けばいい」の精神で文字列連結のSQLを量産する時代は終わった。
`CurrentDb.QueryDefs` と `Parameters` コレクションを駆使した「型安全な設計」をプロジェクトの標準とし、バグの入り込む余地のない、美しく強靭なシステムを構築してほしい。
健闘を祈る。
