【テクニカル・上級編】動的SQL生成時の「引用符（’）」エスケープ処理を自動化する汎用関数 – Access VBA解析バイブル

SQLインジェクションと構文エラーの終焉：VBAにおける動的SQLエスケープの極限解

Access VBAを用いた開発において、`QueryDef`を用いた動的SQLの生成と実行は、避けて通れないアーキテクチャの中核だ。しかし、現場のエンジニアリングにおいて、もっとも根深く、そしてもっとも初歩的なバグの温床となるのが「シングルクォーテーション（ `’` ）のエスケープ処理」である。

ユーザー入力値に「O’Brien」のような文字が含まれていた瞬間、SQL文は無残に構文エラーを吐き出し、あるいは最悪の場合、脆弱性を孕んだシステムへと変貌する。

本稿では、レガシーな文字列連結の呪縛からシステムを解放し、完全無欠な動的SQLエスケープを実現する汎用ユーティリティ関数の設計思想と、Access VBAの内部挙動を踏まえた実践的コードを提示する。

—

1. なぜ「`Replace関数`の二重化」では不十分なのか

多くの初級〜中級プログラマは、SQL文を組み立てる際に以下のようなコードを書く。

‘ 悪夢の始まり：場当たり的な置換処理
Dim safeValue As String
safeValue = Replace(userInput, “‘”, “””)
Dim sql As String
sql = “SELECT FROM T_Clients WHERE ClientName = ‘” & safeValue & “‘;”

確かに、シングルクォーテーションを2つ重ねる（`”`）ことでSQLの構文エラーは回避できる。しかし、このアプローチには致命的な欠陥がある。

1. コンテキストの欠如: SQLのWHERE句、LIKE演算子、IN句、あるいはパススルークォーテーションなど、挿入される文脈によって必要なエスケープルールは微妙に異なる。
2. 多重エスケープの弊害: 既にエスケープ済みの文字列が再度渡された場合、データが破損する。
3. NULL値とゼロレングス文字列（ZLS）の混同: VBAの `Null` と空文字列 `””` の扱いの不整合が、SQL実行時に予期せぬ型ミスマッチを引き起こす。

我々が目指すべきは、あらゆる入力値（`Null`、制御文字、特殊記号）を安全に包摂し、SQLの構文木を破壊しない「絶対的な堅牢性を持つサニタイズ関数」の構築である。

—

2. 実装：極限まで最適化されたエスケープ・ユーティリティ

以下に提示するのは、実務の最前線で酷使されるシステム耐性を備えた汎用関数だ。オブジェクトのライフサイクルとVBAのデータ型特性を熟知したアーキテクチャで設計されている。

Option Compare Database
Option Explicit

‘ =========================================================================
‘ módulo: M_SqlUtility
‘ 概要: 動的SQL生成における文字列エスケープおよび型安全化の極限実装
‘ =========================================================================

/

• 任意の値りを受け取り、SQL文の構築に適した安全な文字列に変換する
• @param ByVal vValue As Variant 処理対象の値（Null許容）
• @param ByVal bIsLike As Boolean LIKE検索用のワイルドカードをエスケープするかどうか
• @return String SQLのクォーテーションで囲むためのエスケープ済み文字列

/
Public Function f_GetSafeSqlString(ByVal vValue As Variant, Optional ByVal bIsLike As Boolean = False) As String

‘ 1. Null値の厳格なハンドリング
‘ SQLでは Null は “NULL” というキーワードとして扱うべきであり、空文字列とは明確に区別する
If IsNull(vValue) Then
f_GetSafeSqlString = “NULL”
Exit Function
End If

Dim strVal As String
strVal = CStr(vValue)

‘ 2. 制御文字や危険なエスケープシーケンスの排除（必要に応じて拡張）
‘ Null文字やCR/LF混入によるSQLインジェクション/構文破壊を防ぐ
strVal = Replace(strVal, vbNullChar, “”)

‘ 3. LIKE検索特有のエスケープ処理
‘ Wildcard文字（%, _, [, ]）をエスケープする必要がある場合の処理系
If bIsLike Then
‘ Accessの標準SQL（Jet/ACE）におけるLIKE演算子のエスケープ
‘ [%] -> [[] などだが、実務上はプレースホルダーの利用を推奨
strVal = Replace(strVal, “[“, “[[]”)
strVal = Replace(strVal, “%”, “[%]”)
strVal = Replace(strVal, “_”, “[_]”)
End If

‘ 4. 基本的なシングルクォーテーションのエスケープ
‘ SQLの基本ルール：単一の引用符は二重の引用符に置換する
strVal = Replace(strVal, “‘”, “””)

‘ 5. 最終的なSQLリテラル形式へのラップ
f_GetSafeSqlString = “‘” & strVal & “‘”

End Function

—

3. シニアアーキテクチャ：QueryDefとの融合によるパフォーマンス最大化

この関数単体では、単なる文字列置換の域を出ない。真価を発揮するのは、Accessの基盤である`QueryDef`オブジェクトと組み合わせ、コンパイル済みの実行計画を最大限に利用するアプローチだ。

動的SQLを毎回文字列として実行するのではなく、パラメーター化されたクエリを動的に構築・破棄、あるいは永続的QueryDefのパラメータを書き換える手法が、パフォーマンスのボトルネックを粉砕する。

以下は、安全にエスケープされた値を用いて、安全かつ高速にクエリを実行する実践的なプロシージャである。

Public Sub S_ExecuteDynamicQuery(ByVal targetClientId As Long, ByVal searchName As String)

Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rst As DAO.Recordset

On Error GoTo ErrorHandler

‘ カレントデータベースの参照を取得（オーバーヘッドを最小化）
Set db = CurrentDb()

‘ 一時的なQueryDefとして動的SQLを構築
‘ 毎回SQLパース走査を行わせず、QueryDefオブジェクトのライフサイクルを厳密に管理する
Set qdf = db.CreateQueryDef(“”, “PARAMETERS p_Id Long, p_Name Text(255); ” & _
“SELECT FROM T_Clients ” & _
“WHERE ClientID = p_Id ” & _
“AND ClientName LIKE p_Name;”)

‘ パラメーターのバインド（DAOの強みである型安全な代入）
qdf.Parameters(“p_Id”) = targetClientId

‘ 万全を期すためにエスケープ関数を通す（LIKE句のパターンマッチング用）
qdf.Parameters(“p_Name”) = “%” & searchName & “%”

‘ レコードセットのオープン（ForwardOnly/ReadOnlyにより極限の速度を引き出す）
Set rst = qdf.OpenRecordset(dbOpenSnapshot, dbForwardOnly)

Do Until rst.EOF
‘ 処理ロジック
Debug.Print rst!ClientName
rst.MoveNext
Loop

CleanUp:
‘ オブジェクトの明示的解放（メモリリークの完全防止）
If Not rst Is Nothing Then rst.Close: Set rst = Nothing
If Not qdf Is Nothing Then
‘ 一時QueryDefはCloseメソッドを持たないが、コレクションから削除するか
‘ 変数のスコープアウトにより破棄される。ここでは参照を切る。
Set qdf = Nothing
End If
Set db = Nothing
Exit Sub

ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub

—

4. チーフアーキテクトからの提言：レガシーの呪縛を超えて

Access VBA開発において、コードの簡便さに逃げて「文字列の直接連結」を放置することは、将来のシステム障害という負債を複利で積み上げることに他ならない。

1. 文字列連結によるSQL生成は、極力排除せよ。 代わりにDAOの `Parameter` コレクションを活用し、Jet/ACEエンジンに型の解釈を委ねよ。
2. やむを得ず動的SQL文字列を構築する場面（動的なIN句の展開など）においては、今回提示した `f_GetSafeSqlString` のような厳格なサニタイズ境界を設けよ。
3. すべてのデータベースオブジェクト（`Database`, `QueryDef`, `Recordset`）は、使用後に必ず `Nothing` を代入し、VBAのガベージコレクション頼みではなく、決定論的なメモリ解放を徹底せよ。

コードの美しさは、そのままシステムの堅牢性と実行速度に直結する。妥協なき設計こそが、プロフェッショナルなエンジニアリングの証明である。