Access VBAを掌握する極限の知見：DAO.Parameterが生む「真の堅牢性」
こんにちは。開発プロジェクトの現場において、数々のAccess基幹システムを救ってきたチーフアーキテクトだ。
Access VBAによる開発で、最も恐ろしい瞬間を知っているか？
それは、ユーザーが入力した文字列に「シングルクォート（`’`）」が含まれていたがためにSQLが構文エラーを起こし、システムが突如として沈黙した瞬間、あるいは悪意ある（あるいは偶然の）入力によってSQLインジェクションが成立してしまった瞬間だ。
「文字列を連結してSQLを作れば動くだろう」――この安易な設計が、どれほどのバグを生み、どれほどのエンジニアの夜を奪ってきたことか。
今回は、Accessのパフォーマンスと安全性を極限まで高める「DAO.Parameterオブジェクトを活用した安全なSQL実行の極意」を授けよう。初心者から一歩抜け出し、プロフェッショナルな堅牢システムを構築するための設計思想を叩き込む。
—
1. なぜ「文字列連結SQL」は悪なのか？
業務システムを作るとき、多くの初心者は次のようなコードを書く。
‘ 【アンチパターン】絶対に真似してはならないコード
Dim strSQL As String
Dim rs As DAO.Recordset
‘ ユーザー入力をそのままSQLに埋め込む
strSQL = “SELECT FROM T_顧客 WHERE 顧客名 = ‘” & Me.txtSearchName.Text & “‘”
Set rs = CurrentDb.OpenRecordset(strSQL)
このアプローチがなぜ地雷なのか。理由は3つある。
1. 構文エラー（SQLインジェクションの原型）の頻発
ユーザーが「O’Brien」のような名前を入力した瞬間、SQLは `WHERE 顧客名 = ‘O’Brien’` となり、シングルクォートの数が合わずにクラッシュする。
2. 型安全性の欠如
日付や数値の書式（特に米式・和式の日付フォーマットの差異）を文字列連結で正しく表現しようとすると、コードが複雑怪奇になり、環境依存のバグを生む。
3. 実行計画のキャッシュ効率（QueryDefの観点）
毎回異なるSQL文字列を動的に生成・実行していると、データベースエンジンは毎回クエリの解析（パース）と実行計画の生成を強いられ、パフォーマンスが著しく低下する。
これらを一網打尽に解決するのが、`QueryDef` オブジェクトと `Parameters` コレクションの組み合わせだ。
—
2. パラメータクエリの極意：DAO.Parameterの正体
DAO（Data Access Objects）におけるパラメータクエリとは、SQLの骨組みだけをあらかじめデータベースにコンパイル・保持させ、可変値の部分を「パラメータ」として安全に後から流し込む仕組みだ。
ここで重要なのは、「パラメータは単なる文字列の代入ではなく、厳密な『型』を持った変数としてSQLエンジンに渡される」という点である。これにより、SQLインジェクションの余地は完全に断絶される。
正しい設計の全体像
Accessのクエリデザイナであらかじめパラメータを定義しておく方法もあるが、実務の現場では、VBAのコード内で動的に `QueryDef` を生成し、そこにパラメータをバインドする手法が最もメンテナンス性が高く、デプロイも容易である。
—
3. 【プロダクションコード】コピペで使える堅牢な実装例
実務の現場でそのまま使える、極めて堅牢な関数を用意した。
画面上のテキストボックスから顧客名と下限売上金額を受け取り、安全にパラメータをバインドしてレコードセットを取得するサンプルだ。
‘ ==============================================================================
‘ 処理名: GetFilteredCustomers
‘ 概要: DAO.Parameterを使用して型安全かつインジェクションフリーにデータを抽出する
‘ 引数:
‘ prmName (String) – 検索する顧客名（部分一致）
‘ prmSales (Currency) – 最低売上金額
‘ 戻り値: DAO.Recordset
‘ ==============================================================================
Public Function GetFilteredCustomers(ByVal prmName As String, ByVal prmSales As Currency) As DAO.Recordset
Dim qdf As DAO.QueryDef
Dim db As DAO.Database
Dim sqlText As String
On Error GoTo ErrorHandler
Set db = CurrentDb()
‘ 1. プレースホルダー（? または 名前付きパラメータ）を含むSQLを構築
‘ ※DAOでは名前付きパラメータ（[p_Name]など）を使うのが最も可読性が高い
sqlText = “PARAMETERS [p_Name] Text ( 255 ), [p_Sales] Currency; ” & _
“SELECT 顧客ID, 顧客名, 登録日, 売上金額 ” & _
“FROM T_顧客 ” & _
“WHERE 顧客名 LIKE [p_Name] AND 売上金額 >= [p_Sales] ” & _
“ORDER BY 顧客ID;”
‘ 2. 一時的なQueryDefオブジェクトを作成（名前を空にすると永続保存されない）
Set qdf = db.CreateQueryDef(“”, sqlText)
‘ 3. Parametersコレクションに対して「型を意識した」値を設定
‘ ※ここで明示的に値を渡すことで、型安全性が担保される
qdf.Parameters(“[p_Name]”).Value = “%” & prmName & “%”
qdf.Parameters(“[p_Sales]”).Value = prmSales
‘ 4. パラメータがバインドされた状態でレコードセットを開く
‘ ※OpenRecordsetを実行する前にParametersを設定するのが鉄則
Set GetFilteredCustomers = qdf.OpenRecordset(dbOpenSnapshot)
‘ ※注意: qdfのCloseは不要だが、Recordsetを呼び出し元で閉じた後に
‘ メモリ解放されるライフサイクルを意識すること。
Exit Function
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “システムエラー”
‘ エラー時はNothingを返す（呼び出し元でのIs Nothing判定が必須）
Set GetFilteredCustomers = Nothing
End Function
—
4. チーフアーキテクトが教える実装上の注意点
このコードを実装・運用するにあたり、プロとして知っておくべき極意をいくつか補足しよう。
① パラメータの「型」の宣言を怠るな
SQL文の先頭にある `PARAMETERS [p_Name] Text ( 255 ), [p_Sales] Currency;` の記述に注目してほしい。
これをサボると、DAOは渡された値の型を暗黙的に推論しようとし、予期せぬ型変換エラーやパフォーマンス低下を引き起こす。パラメータの型とサイズは、データベースのフィールド定義と一致させるのがプロの作法だ。
② `OpenRecordset` の引数に `dbOpenSnapshot` を選ぶ理由
UIに表示するだけ、あるいは読み取り専用でデータを回すだけであるなら、デフォルトの `dbOpenDynaset` や `dbOpenTable` を使ってはならない。
`dbOpenSnapshot`（スナップショット）を使うことで、ローカルメモリ上に読み取り専用の軽量なスナップショットを作成し、Jet/ACEエンジンのロック競合や無駄なトラフィックを排除できる。パフォーマンスは劇的に向上する。
③ ライフサイクルの管理とメモリリークの防止
VBAはガベージコレクタを持たない言語だ。`Database`、`QueryDef`、`Recordset` オブジェクトのインスタンスは、スコープを抜ける際に適切に解放（`Set … = Nothing`）される設計を心がけよう。上記の関数では、戻り値として `Recordset` を返しているため、呼び出し元責任で必ず `rs.Close` と `Set rs = Nothing` を行う必要がある。
—
5. まとめ
Access VBAだからといって、セキュリティやパフォーマンスを妥協してよい理由にはならない。
- 文字列連結によるSQL生成は、バグと脆弱性の温床であるため今すぐ廃止する。
- `QueryDef` と `Parameters` コレクションを駆使し、型安全なクエリ構築を徹底する。
- `dbOpenSnapshot` を活用し、データベースの負荷を最小限に抑える。
この極意をマスターしたあなたなら、もはや「動くだけの脆弱なコード」に悩まされることはないはずだ。自信を持って、堅牢で美しい業務システムを作り上げてほしい。
