Access VBAを掌握する極限の知見：DAO.Parameterオブジェクトがもたらす「真の型安全」とSQLインジェクション完全防御のアーキテクチャ
長年、数多の基幹系Accessシステムのリビジョンを見上げてきた。その中で、未だに散見されるのが、画面上のテキストボックスの値をそのまま文字列結合してSQLを生成する、いわゆる「SQLインジェクションの温床」とも呼べる稚拙なコード群だ。
「社内ネットワーク内だから大丈夫だ」「ユーザーは入力などしない」――そのような甘えが、データ破損や予期せぬ構文エラー（特にシングルクォートのエスケープ漏れによるクラッシュ）を引き起こしてきた。
Access VBAにおけるデータベース操作の王道は、ADOではない。DAO（Data Access Objects）、そしてその中核に存在する`QueryDef`と`DAO.Parameter`オブジェクトの完全な掌握こそが、堅牢なエンタープライズ・アプリケーションを構築するための唯一にして最大の解である。
今回は、動的SQLの生成におけるパラメータークエリの極意を、メモリ管理や型安全性の観点から徹底的に解説する。
—
1. なぜ文字列連結の動的SQLは「悪」なのか？
実務において、以下のようなコードを書いた（あるいは見た）ことはないだろうか。
‘ 【アンチパターン】絶対にやってはならない文字列連結
Dim strSQL As String
strSQL = “SELECT FROM T_Order WHERE CustomerName = ‘” & Me.txtCustomer & “‘ AND OrderDate >= #” & Me.txtDate & “#;”
Set rs = CurrentDb.OpenRecordset(strSQL)
このアプローチには、致命的な欠陥が3つ存在する。
1. SQLインジェクションの脆弱性：入力値に悪意あるSQL断片が混入した場合、意図しないクエリが実行される。
2. 型とエスケープの地獄：日付型は `#` で囲み、文字列型は `’` で囲み、さらに文字列内にシングルクォートが含まれていた場合の `Replace()` 処理の漏れは、即座に「構文エラー」を引き起こす。
3. Execution Plan（実行計画）のキャッシュ破棄：毎回異なるSQL文字列を動的に生成・実行することは、Jet/ACEデータベースエンジンに無駄なパース処理を強制し、パフォーマンスを著しく低下させる。
これらを一網打尽に解決するのが、パラメータ化された `QueryDef` である。
—
2. `DAO.Parameter` オブジェクトの真髄
パラメータクエリとは、SQLの条件値をプレースホルダー（`?` または名前付きパラメータ）として定義し、後から型を明確に指定して値をバインドする手法である。
DAOでは、あらかじめ定義されたクエリ（保存済みクエリ）だけでなく、VBAコード上で動的に `QueryDef` オブジェクトを作成し、その `Parameters` コレクションを操作することで、完全に型安全なクエリを実行できる。
実装パターン：動的パラメータクエリの模範解答
以下のコードは、SQLインジェクションを完全に無効化し、かつパフォーマンスと型安全性を極限まで高めた実用コードである。
‘ ==============================================================================
‘ メソッド名: GetSecureFilteredOrders
‘ 概要: DAO.Parameterを使用して安全かつ高速にレコードセットを取得する
‘ ==============================================================================
Public Function GetSecureFilteredOrders(ByVal customerName As String, ByVal thresholdDate As Date) As DAO.Recordset
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
On Error GoTo ErrorHandler
Set db = CurrentDb()
‘ 1. 動的にQueryDefを作成（名前なしで一時的に作成する場合は””を指定）
‘ ※パフォーマンスを重視し、既存の保存済みクエリを流用する場合は CurrentDb.QueryDefs(“qryName”) を使用する
Set qdf = db.CreateQueryDef(“”, _
“PARAMETERS pName Text (255), pDate DateTime; ” & _
“SELECT OrderID, CustomerName, OrderDate, TotalAmount ” & _
“FROM T_Order ” & _
“WHERE CustomerName LIKE [pName] AND OrderDate >= [pDate];”)
‘ 2. Parametersコレクション経由で型安全に値をバインド
‘ 文字列連結は一切行わず、エンジン側で型を厳密に解釈させる
qdf.Parameters(“pName”) = “%” & customerName & “%”
qdf.Parameters(“pDate”) = thresholdDate
‘ 3. レコードセットの取得
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
‘ 呼び出し元へレコードセットを返却（※QueryDefのスコープとライフサイクルに注意）
Set GetSecureFilteredOrders = rs
CleanExit:
‘ 【重要】QueryDefオブジェクトの明示的解放
‘ VBAの暗黙の解放に頼らず、メモリリークを防ぐため確実に破棄する
If Not qdf Is Nothing Then
qdf.Close
Set qdf = Nothing
End If
Set db = Nothing
Exit Function
ErrorHandler:
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
Resume CleanExit
End Function
—
3. シニアエンジニアが押さえるべき「メモリ最適化」と「オブジェクトのライフサイクル」
Access VBAの裏でうごめくDAO/Jetエンジンは、COMオブジェクトのラッパーである。そのため、ガベージコレクションの挙動を理解していないと、メモリリークやリソース枯渇（Error 3048: オープンできるファイル数が多すぎます）の悪夢に見舞われる。
クイッククエリ（`CurrentDb.OpenRecordset`）の罠
多くの開発者がやりがちなのが、以下の記述だ。
‘ 【アンチパターン】DBインスタンスとQueryDefの参照が宙に浮く
Set rs = CurrentDb.OpenRecordset(“SELECT FROM T WHERE ID = ” & id)
`CurrentDb` は呼び出すたびに新しいDatabaseオブジェクトのインスタンスをヒープ上に生成する。このコードでは、生成されたDatabaseオブジェクトへの参照が失われたままRecordsetだけが残り、内部的なポインタやロックが適切に解放されないリスクを孕む。
堅牢なメモリ管理の鉄則
1. `CurrentDb` は必ず変数に格納せよ：同一プロシージャ内では `Dim db As DAO.Database: Set db = CurrentDb()` として使い回す。
2. オブジェクトの階層順に解放せよ：
- `Recordset` を閉じる (`rs.Close`)
- `QueryDef` を閉じる (`qdf.Close`)
- オブジェクト変数を `Nothing` に明示的に設定する (`Set rs = Nothing`, `Set qdf = Nothing`, `Set db = Nothing`)。
—
4. レガシー環境・システム間連携における実戦知見
Accessをフロントエンド、SQL ServerやOracleをバックエンドとする「クライアント・サーバー（ADP代替含む）」構成や、外部CSV/Excelとの連携を行う際、`DAO.Parameter` の挙動はさらに重要になる。
外部ODBCデータソース（Pass-Throughクエリ）での応用
Jet/ACEのローカルテーブルだけでなく、ODBCDirectやパススルー・クエリ（Pass-Through Query）においても、パラメータの概念は極めて有効だ。特にSQL ServerへODBC経由でクエリを投げる場合、文字列連結で日付や数値を渡すと、サーバー側のロケール設定（YYYY-MM-DDかMM-DD-YYYYか）によって深刻なバグを生む。
パススルー・クエリに `DAO.Parameter` を直接バインドすることはできないが、VBA側でパラメータクエリを一旦ローカルのJetエンジン上で構築し、その中でODBCのテーブルをラップするか、あるいはADOの `Command` オブジェクトと `Parameter` オブジェクトを使い分けるアーキテクチャ設計が求められる。
シニアエンジニアたるもの、Accessの限界（同時接続数、トランザクションの粗さ）を直視しつつ、DAOが持つ本来の高速なローカルキャッシュ機能と、パラメータバインドによる堅牢性を常に両立させなければならない。
—
総括
`DAO.Parameter` オブジェクトの活用は、単なる「SQLインジェクション対策」というセキュリティの枠にとどまらない。それは、コードの可読性を劇的に高め、型変換エラーを未然に防ぎ、データベースエンジンの実行計画最適化の恩恵を受けるための、プロフェッショナルのための必須教養である。
「動的SQL＝文字列の結合」という安易な思考回路を今すぐ捨て去り、型安全なパラメータ駆動型のアーキテクチャへとシフトせよ。それこそが、レガシーと呼ばれがちなAccess VBAのコードベースを、堅牢でモダンなエンタープライズ・システムへと昇華させる唯一の道である。
