こんにちは！Access VBAの世界へようこそ。
日々、フォームのボタンを押したら動くマクロの延長でVBAを書いていたり、「なんだかよく分からないけれど、クエリが突然エラーを吐いて止まるんだよね…」と頭を抱えていたりしていませんか？
大丈夫。ここをクリアすれば、あなたのAccess VBAのスキルは「動くだけの初心者」から「システムを意のままに操るエンジニア」へと一気にランクアップします。
今回は、Access開発の現場で避けて通れない「パラメータクエリの動的制御と型の明示」について、プロの現場の知見を交えて優しく、そして深く解説していきますね。
—
なぜ、パラメータクエリでエラーが頻発するのか？
Accessを使っていると、クエリ条件にフォームのテキストボックスの値などを指定することがありますよね。
例えば、こんなSQLやクエリを作ったことはありませんか？
SELECT FROM T_売上 WHERE 顧客ID = [Forms]![F_検索]![txt顧客ID];
これ自体はとても便利なのですが、VBAからこのクエリを操作したり、実行しようとした途端に「実行時エラー: 3061 パラメータが少なくなっています。1 以上の値が指定されています。」や、悪名高い「型が一致しません」というエラーに直面したことはないでしょうか？
このエラーの根本原因は、Access（厳密にはデータベースエンジンであるDAO）が、「渡された値のデータ型を勝手に推測しようとして盛大にミスをする」点にあります。
VBAからクエリに値を渡すとき、何もしないと「文字なのか、数値なのか、日付なのか」が曖昧になりがちです。特に空欄（Null）が渡された瞬間、Accessは大パニックを起こします。
—
解決の切り札：`QueryDefs` と `Parameters` コレクション
この混沌とした型不一致地獄から私たちを救い出してくれるのが、`CurrentDb.QueryDefs` と、クエリが持つ `Parameters` コレクション です。
これを使うと、「このクエリのこのパラメータは、必ずこのデータ型（Long型やString型など）として扱え！」とVBAから厳格に命令（型指定）できるようになります。
図解：データ渡しのイメージ
従来のいい加減な渡し方：
> VBA ――（適当な文字列として投げる）――＞ Accessクエリ（「えっ、これ文字？数字？わかんない！」⇒ 💥エラー）
今回の極限の知見（型指定の渡し方）：
> VBA ――（「これは整数型（Long）です」と明示して渡す）――＞ QueryDef ――＞ 安全に実行！✨
—
実践！安全なパラメータ設定コード
百聞は一見に如かず。実際にフォームから安全にパラメータ付きクエリを実行するサンプルコードを見てみましょう。
ご自身の開発環境のモジュールに、そのままコピペして検証できるように丁寧にコメントを書いています。
Sub ExecuteSecureQuery()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rst As DAO.Recordset
On Error GoTo ErrorHandler
‘ 1. 現在のデータベースへの参照を取得（CurrentDbの二重評価を防ぐベストプラクティス）
Set db = CurrentDb
‘ 2. 対象となるクエリの定義（QueryDef）オブジェクトを取得
‘ ※あらかじめデザインビューで「Q_売上抽出」という名前のパラメータクエリを作っておきます
Set qdf = db.QueryDefs(“Q_売上抽出”)
‘ 3. 【最重要】パラメータのデータ型を明示的に指定して値を代入する
‘ ここで型をバシッと固定することで、型不一致やパラメータ不足エラーを完全に封じ込めます
‘ 顧客ID（数値型：Longの場合）
If Not IsNull(Forms(“F_検索”)!txt顧客ID) Then
qdf.Parameters(“[Forms]![F_検索]![txt顧客ID]”) = CLng(Forms(“F_検索”)!txt顧客ID)
Else
‘ 未入力時のハンドリング（Nullを許容する場合）
qdf.Parameters(“[Forms]![F_検索]![txt顧客ID]”) = Null
End If
‘ 抽出開始日（日付/時刻型：Dateの場合）
If Not IsNull(Forms(“F_検索”)!txt開始日) Then
qdf.Parameters(“[Forms]![F_検索]![txt開始日]”) = CDate(Forms(“F_検索”)!txt開始日)
Else
qdf.Parameters(“[Forms]![F_検索]![txt開始日]”) = Null
End If
‘ 4. パラメータがバインドされた状態でレコードセットを開く
Set rst = qdf.OpenRecordset(dbOpenSnapshot)
‘ 5. データの処理（例：レコード数の確認）
If Not (rst.BOF And rst.EOF) Then
MsgBox rst.RecordCount & ” 件のデータが見つかりました。”, vbInformation, “成功”
‘ ここにデータを処理するロジックを書きます
Else
MsgBox “該当するデータはありませんでした。”, vbExclamation, “通知”
End If
CleanUp:
‘ 6. オブジェクトの解放（メモリリークを防ぐプロの作法）
If Not rst Is Nothing Then rst.Close: Set rst = Nothing
If Not qdf Is Nothing Then Set qdf = Nothing
If Not db Is Nothing Then Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “エラー”
Resume CleanUp
End Sub
—
コードの深い解説：ここがプロのポイント
このコードには、Access VBAを安定稼働させるための極意が詰まっています。いくつか重要なポイントを解説しましょう。
1. `CurrentDb` は変数に受けて使い回せ
よく初心者のコードで見かけるのが、あちこちに `CurrentDb.QueryDefs…` や `CurrentDb.Execute…` と書くスタイルです。
実は `CurrentDb` というプロパティは、呼び出すたびに新しいデータベースオブジェクトをメモリ上に生成しています。これを連発すると、パフォーマンスが低下するだけでなく、内部のメモリ管理（オブジェクトのライフサイクル）が不安定になります。
プロは必ず `Dim db As DAO.Database` で受け、それを使い回します。
2. `CLng` や `CDate` による明示的な型変換
VBAの変数やフォームのコントロールは、基本的には「バリアント型（Variant）」という何でも屋として扱われます。
これを `qdf.Parameters(…) = …` に代入する際、`CLng()` や `CDate()` であらかじめ型を明示（キャスト）しておくことで、Accessエンジンに「これは間違いなく数値（または日付）だ！」と伝えることができます。これが型不一致を防ぐ最大の防壁です。
3. 使い終わったオブジェクトの確実な解放
`Set rst = Nothing` や `Set qdf = Nothing` です。
VBAのガベージコレクションはあまり賢くありません。これをサボると、Accessの内部メモリにゴミが溜まり続け、やがて「リソース不足」という不可解なフリーズを引き起こします。エラーが起きようとも `CleanUp` ラベルにジャンプして確実に解放する、これがプロの構えです。
—
まとめ
今回は `CurrentDb.QueryDefs` と `Parameters` コレクションを使った、型安全なパラメータクエリの制御法を解説しました。
最初は「お呪い（おまじない）が多くて面倒だな」と感じるかもしれません。しかし、運用フェーズに入ってから「特定の日付を入れた時だけ落ちる」「別の人格のPCだと型エラーになる」といった不可解なバグに悩まされないために、この書き方はあなたを何百時間ものデバッグ地獄から救い出してくれます。
ここをクリアすれば、Access VBAの基本はもうバッチリです！自信を持って、あなたのシステム開発に取り入れてみてくださいね。
