【Access VBA極限知見】CurrentDb.QueryDefsとParametersコレクション：型不一致を駆逐する動的パラメータ制御の極意
レガシーシステムの最前線において、Microsoft Accessは今なお強烈な存在感を放っている。数百万レコードを抱える巨大なmdb/accdb、複雑に絡み合うクエリ群、そして現場の要望を受けて肥大化したVBAコードベース。
このエコシステムにおいて、最も頻発し、かつ開発者を絶望の淵に追い込むエラーの筆頭が 「実行時エラー ‘3061’: パラメータが少なくなっています。1 つ以上必要です。」 あるいは曖昧な 「型不一致」 である。
今回は、DAOの `QueryDef` オブジェクトと `Parameters` コレクションを完全に掌握し、暗黙の型変換の呪縛から逃れて「堅牢性」と「極限のパフォーマンス」を手に入れるための技術的真髄を紐解く。
—
1. なぜ `CurrentDb.QueryDefs` なのか？（アーキテクチャの根幹）
多くの初学者、あるいは中級プログラマですら、クエリの実行には `DoCmd.OpenQuery` や、SQL文を直接文字列として組み立てた `CurrentDb.Execute` を多用しがちだ。しかし、エンタープライズレベルの堅牢性が求められるシステムにおいて、これらの手法は技術的負債でしかない。
文字列結合によるSQLインジェクションとパフォーマンスの罠
SQLをVBA内で文字列として結合し、それを都度評価させる手法は、以下の致命的な欠点を抱える。
1. プランキャッシュの効かないアドホッククエリの乱立: データベースエンジンは毎回新しいSQL文と解釈するため、実行計画の最適化コストが無駄に発生する。
2. エスケープ漏れによるバグと脆弱性: 日付型（`#`囲み）や文字列型（`’`囲み）のクォーテーションのミスによる構文エラーが頻発する。
これに対し、あらかじめデザインビュー等で作成したクエリ（あるいはコード上で永続的に定義したクエリ）を `QueryDef` として保持し、パラメータのみをバインドする手法こそが、近代データベース設計の基本思想に最も合致する。
—
2. `Parameters` コレクションの罠と「暗黙の型変換」の恐怖
Accessのクエリデザイナでパラメータ（例: `[Forms]![frmMain]![txtStartDate]` や `[Enter Start Date]`）を定義したとき、何が起きているか？
Jet/ACEデータベースエンジンは、渡された値の型を「推論」しようとする。この推論機能が、VBAとAccessの境界領域において悪夢を引き起こす。
VBA側でVariant型や適切な型変換（`CDate`, `CLng`等）を行わずにクエリを呼び出すと、エンジンは勝手に型を解釈し、予期せぬ「型不一致」や、最悪の場合は暗黙の型変換によるインデックスの不活用（フルスキャン）を引き起こす。
この挙動を完全に制御し、VBA側から明示的に型をバインドするのが、`QueryDef.Parameters` コレクションの真の役割である。
—
3. 実装コード：型指定パラメータバインドの極致
以下のコードは、単に動的にパラメータを渡すだけでなく、オブジェクトの明示的解放（メモリリークの防止）、トランザクション管理、そしてDAOの型定義（DataTypeEnum）の厳密な指定を行ったプロダクション品質のテンプレートである。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 担当: チーフアーキテクト
‘ 概要: QueryDefのParametersコレクションを明示的に型指定して実行する堅牢なルーチン
‘ ==============================================================================
Public Sub ExecuteParametricQuery_Safe()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rst As DAO.Recordset
‘ パフォーマンスと整合性を担保するため、CurrentDbを変数にキャッシュする
‘ ※CurrentDbは呼び出すたびに新規インスタンスを生成するため、必ず変数に受けて参照を維持すること。
Set db = CurrentDb
On Error GoTo ErrorHandler
‘ 1. QueryDefオブジェクトの取得
‘ あらかじめデザインビューで作成してあるクエリ名を指定
Set qdf = db.QueryDefs(“qryMonthlySalesSummary”)
‘ 2. Parametersコレクションの明示的型指定とバインド
‘ Accessクエリデザイナ側でパラメータのデータ型が曖昧であっても、ここで強制的に型をバインドする。
‘ これにより「型不一致エラー」を完全に根絶する。
‘ dbDate (8) : 日付/時刻型
qdf.Parameters(“[prmStartDate]”) = CDate(“2023-04-01”)
qdf.Parameters(“[prmStartDate]”).Type = dbDate
qdf.Parameters(“[prmEndDate]”) = CDate(“2023-04-30”)
qdf.Parameters(“[prmEndDate]”).Type = dbDate
‘ dbLong (4) : 長整数型 (Long)
qdf.Parameters(“[prmDivisionID]”) = CLng(105)
qdf.Parameters(“[prmDivisionID]”).Type = dbLong
‘ 3. レコードセットとしての実行（または qdf.Execute dbFailOnError）
‘ 参照渡しによりメモリ上に結果を展開
Set rst = qdf.OpenRecordset(dbOpenSnapshot)
‘ 4. 結果の処理（極限まで最適化されたイテレーション）
If Not (rst.BOF And rst.EOF) Then
rst.MoveFirst
Do Until rst.EOF
‘ ビジネスロジックの処理
‘ Debug.Print rst!SalesAmount
rst.MoveNext
Loop
Else
MsgBox “指定された条件に一致するデータはありません。”, vbInformation, “情報”
End
GoTo Cleanup
ErrorHandler:
‘ 本番環境ではここにログ出力機構（Windowsイベントログや独自テーブルへの書き込み）を実装する
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
Cleanup:
‘ ==========================================================================
‘ メモリ最適化とオブジェクトの明示的解放
‘ Access VBAにおけるCOMオブジェクトの解放漏れは、激しいメモリフラグメンテーションを引き起こす。
‘ ==========================================================================
If Not rst Is Nothing Then
rst.Close
Set rst = Nothing
End If
If Not qdf Is Nothing Then
‘ QueryDef自体の参照解放（CurrentDbから取得したインスタンスの破棄）
Set qdf = Nothing
End If
If Not db Is Nothing Then
Set db = Nothing
End If
Exit Sub
End Sub
—
4. シニアエンジニアが知るべき「裏の挙動」とメモリ最適化の哲学
`CurrentDb` の正体を理解せよ
多くのプログラマが犯す最大の過ちは、コード内で幾度となく `CurrentDb.QueryDefs…` や `CurrentDb.Execute…` と記述することだ。
`CurrentDb` メソッドは、呼び出されるたびに新しいDAOのDatabaseオブジェクトをメモリ上に生成し、システム資源を消費する。さらに、これらはVBAのスコープを抜けても即座にOSレベルで解放されるとは限らない。
必ず冒頭で `Set db = CurrentDb` と変数に参照を保持し、処理の最後で確実に `Set db = Nothing` を行うこと。この一手間が、何十万回と実行されるバッチ処理や、長期間稼働する常駐型Accessシステムのメモリリークを防ぐ防壁となる。
パラメータクエリの動的生成（永続クエリ vs 一時クエリ）
毎回デザインビューにクエリを用意するのではなく、VBAコード内動的に `QueryDef` を作成・破棄したい場合もある。その場合は以下のように `CreateQueryDef` を使用する。
Dim qdfTemp As DAO.QueryDef
‘ 名前を空文字列にすることで、システムカタログに永続化されない「一時QueryDef」を作成可能
Set qdfTemp = db.CreateQueryDef(“”, “SELECT FROM tblTransactions WHERE TxDate >= [prmDate]”)
qdfTemp.Parameters(“[prmDate]”).Type = dbDate
qdfTemp.Parameters(“[prmDate]”) = Date
Set rst = qdfTemp.OpenRecordset(dbOpenSnapshot)
‘ … 処理 …
‘ 一時QueryDefはCloseメソッドを持たないため、オブジェクト変数を解放することで自動消滅する
Set qdfTemp = Nothing
この「一時QueryDef（名前なしQueryDef）」のテクニックは、動的にSQLの構造が変わるがパラメータの安全性を維持したいシーンにおいて、極めて強力な武器となる。
—
5. 総括
Access VBAは、オールドファッションな言語と見なされがちだ。しかし、その内部で稼働しているJet/ACEエンジンとDAOの仕組みは、適切に扱えば非常に堅牢で高速なデータ処理プラットフォームに変貌する。
`CurrentDb.QueryDefs` と `Parameters` コレクションの型明示的バインド。
この作法をプロジェクトの標準（コーディング規約）として徹底すること。それだけで、「原因不明の型不一致エラー」や「運用フェーズでのデータ型に起因するバグ」は、あなたのコードベースから完全に駆逐される。
妥協なき設計と、オブジェクトのライフサイクルに対する絶対的な支配力を持つ者だけが、レガシーの荒野を制覇できるのだ。
