動的SQLのデバッグを極限まで加速する：「SQL出力ログ」自動生成アーキテクチャ
レガシーなAccessデータベースの運用において、最も開発者の精神力を削る瞬間はどれか。
それは、画面上のフォームから入力された幾多の条件を組み合わせ、VBAの裏側で組み立てられた「巨大な動的SQL」が、実行時エラーや意図しないゼロ件ヒットを引き起こした瞬間だ。
`CurrentDb.OpenRecordset` や `QueryDef.SQL` の代入の直前で、文字列結合の迷宮に迷い込んだSQL文を出力するために `Debug.Print` を仕込む――そんな泥臭いデバッグにいつまで時間を費やすつもりか。
シニアエンジニアに必要なのは、場当たり的なデバッグコードではない。「実行される直前の完全なSQL文を、一そだての人手も介さずに自動キャプチャし、イミディエイトウィンドウと外部ログへシームレスに吐き出す基盤」である。
今回は、Access VBAのオブジェクトライフサイクルとメモリ管理の深層を理解した者だけが実装できる、極限まで洗練された「SQL出力ログ自動生成ツール」のアーキテクチャを解説する。
—
1. 動的SQLデバッグにおける「アクセスの罠」
動的SQLの生成において、Access VBAエンジニアが直面する最大の壁は以下の3点だ。
1. シングルクォーテーションと日付リテラルのエスケープ地獄
2. パラメータの型不一致（特に `Null` 値の混入による構文崩壊）
3. QueryDefオブジェクトのキャッシュ汚染とメモリリーク
特に、ADO/DAOを介したクエリ実行時に、Jet/ACEエンジンが解釈する直前のSQL文は、VBA側で組み立てた文字列と微妙に異なる場合がある。ここで真に必要なのは、「VBAが生成した文字列」と「実際にデータベースエンジンに投げられたSQL」の乖離をゼロにする仕組みだ。
—
2. 設計思想：ロギングクラスの分離とインターフェース
汚染されたグローバル標準モジュールに `Sub Log()` を適当に生やすような設計は、プロフェッショナルのそれではない。
ログ出力処理は、単一責任の原則（SRP）に基づき、専用のクラスモジュールとしてカプセル化すべきである。これにより、将来的なログ出力先の変更（テキストファイルからWindowsイベントログ、あるいは外部APIへの非同期送信など）にも耐えうる。
コアコンポーネントの全体像
- `clsSqlLogger`（クラスモジュール）: SQLの整形、イミディエイト出力、ファイル出力の責務を持つ。
- 標準モジュール / ラッパー関数: アプリケーション全体からワンライナーで呼び出せるインターフェース。
—.
3. 実装コード：極限まで最適化された `clsSqlLogger`
以下のコードは、オブジェクトの明示的解放、エラーハンドリング、そしてファイルI/Oのパフォーマンスを考慮して構築された実用コードである。開発環境にそのままインポートして使用してほしい。
クラスモジュール：`clsSqlLogger`
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ クラス名: clsSqlLogger
‘ 概要: 動的SQLの生成・実行直前のログを自動出力し、デバッグを極限まで効率化する
‘ ==============================================================================
Private m_EnableFileLog As Boolean
Private m_LogFilePath As String
‘ イニシャライザー
Private Sub Class_Initialize()
‘ デフォルトではファイル出力は有効、パスはカレントディレクトリの Logs フォルダ
m_EnableFileLog = True
m_LogFilePath = CurrentProject.Path & “\SqlDebug.log”
End Sub
‘ プロパティ設定: ファイル出力の有効/無効
Public Property Let EnableFileLog(ByVal Val As Boolean)
m_EnableFileLog = Val
End Property
‘ プロパティ設定: ログファイルの保存先変更
Public Property Let LogFilePath(ByVal Val As String)
m_LogFilePath = Val
End Property
‘ ==============================================================================
‘ メソッド名: WriteLog
‘ 概要: SQL文をフォーマットし、イミディエイトおよびファイルへ出力する
‘ ==============================================================================
Public Sub WriteLog(ByVal SqlText As String, Optional ByVal CallerName As String = “Unknown”)
On Error GoTo ErrorHandler
Dim FileNum As Integer
Dim FormattedSql As String
Dim Timestamp As String
Timestamp = Format$(Now, “yyyy-mm-dd hh:nn:ss.nn”)
‘ SQL内の連続する改行やタブを整え、可読性を最大化する
FormattedSql = CleanSql(SqlText)
‘ 1. イミディエイトウィンドウへの出力（開発時の即時確認用）
Debug.Print “————————————————–”
Debug.Print “[” & Timestamp & “] Caller: ” & CallerName
Debug.Print FormattedSql
Debug.Print “————————————————–”
‘ 2. ファイル出力（永続的な証跡・検証用）
If m_EnableFileLog Then
FileNum = FreeFile
Open m_LogFilePath For Append As #FileNum
Print #FileNum, “==================================================”
Print #FileNum, “Timestamp: ” & Timestamp & ” | Caller: ” & CallerName
Print #FileNum, FormattedSql
Print #FileNum, “==================================================”
Close #FileNum
End If
Exit Sub
ErrorHandler:
‘ ロギング自体のエラーでメイン処理を止めないための安全弁
If FileNum > 0 Then Close #FileNum
Debug.Print “[SqlLogger Error] Failed to write log: ” & Err.Description
End Sub
‘ ==============================================================================
‘ 内部メソッド: SQLの整形（改行・余分なスペースの削除）
‘ ==============================================================================
Private Function CleanSql(ByVal Sql As String) As String
Dim Result As String
Result = Sql
‘ 制御文字をスペースに置換
Result = Replace(Result, vbCrLf, ” “)
Result = Replace(Result, vbCr, ” “)
Result = Replace(Result, vbLf, ” “)
‘ 連続するスペースを単一化（簡易的）
Do While InStr(Result, ” “) > 0
Result = Replace(Result, ” “, ” “)
Loop
CleanSql = Trim$(Result)
End Function
—
4. 実戦投入：QueryDefおよびRecordsetとの統合パターン
このロガーを実際の業務システム（動的クエリ生成ロジック）に組み込む方法を示す。
ポイントは、「SQLを実行、あるいはQueryDefへ割り当てるその瞬間」にロガーを挟むことだ。
標準モジュールでの活用例
Option Compare Database
Option Explicit
Public Sub ExecuteDynamicQuerySample()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rst As DAO.Recordset
Dim logger As clsSqlLogger
Dim strSql As String
Dim customerId As Long
‘ オブジェクトのインスタンス化
Set logger = New clsSqlLogger
Set db = CurrentDb
customerId = 1050
‘ — 動的SQLの組み立て —
strSql = “SELECT C.CustomerID, C.CustomerName, O.OrderDate, O.TotalAmount ” & _
“FROM Customers AS C ” & _
“INNER JOIN Orders AS O ON C.CustomerID = O.CustomerID ” & _
“WHERE C.CustomerID = ” & customerId & ” ” & _
“ORDER BY O.OrderDate DESC;”
‘ 【核心】実行直前のSQLを完全キャプチャ（呼び出し元関数名も明記）
logger.WriteLog strSql, “ExecuteDynamicQuerySample”
‘ — クエリの実行とメモリ管理 —
On Error GoTo ErrorHandler
‘ 一時的なQueryDefとして実行する場合、あるいは既存クエリを動的書き換えする場合
Set qdf = db.CreateQueryDef(“”, strSql)
Set rst = qdf.OpenRecordset(dbOpenSnapshot)
‘ データ処理のシミュレーション
Do Until rst.EOF
‘ Debug.Print rst!CustomerName
rst.MoveNext
Loop
CleanUp:
‘ ==========================================================================
‘ シニアエンジニアの流儀：オブジェクトの明示的かつ逆順の解放
‘ アクセスのメモリリークを防ぐための鉄則
‘ ==========================================================================
If Not rst Is Nothing Then rst.Close: Set rst = Nothing
If Not qdf Is Nothing Then
‘ 永続クエリでない場合（名前が空の場合）、自動破棄されるが明示的に参照を切る
Set qdf = Nothing
End If
Set db = Nothing
Set logger = Nothing
Exit Sub
ErrorHandler:
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
—
5. チーフアーキテクトからの提言：レガシー環境におけるパフォーマンスと堅牢性
長年運用されてきたAccessシステムでは、コードの量が増えるにつれて「メモリリーク」と「クエリキャッシュの肥大化」がサイレントキラーとなる。
1. ファイルI/Oの競合回避（多重起動対策）
複数ユーザーが同時にネットワーク共有フォルダ上のAccess（スプリット構成のフロントエンド）から同一のログファイルに書き込もうとすると、ファイルロック競合エラー（Error 70: 書き込みできません）が発生する。
本番環境の共有サーバー等でファイルログを有効にする場合は、エラーハンドラーで無視させる（あるいは環境変数やローカルPCの `Environ$(“TEMP”)` 配下にログを吐き出す）設計が不可欠である。上記のサンプルコードでは、`ErrorHandler` によるフォールバックを実装しているため、ログ出力の失敗が業務処理本体をクラッシュさせることは絶対にない。
2. QueryDefの動的生成における注意点
`db.CreateQueryDef(“”, strSql)` のように名前を空文字 `””` にして作成する一時クエリ（Anonymous QueryDef）は、レコードセットを閉じると同時にメモリから解放される。しかし、これを名前付きで次々と `db.QueryDefs` に追加・削除を繰り返すと、Accessの内部システムテーブル（MSysObjects）にゴミが残り、データベースファイルが肥大化する原因となる。動的SQLの実行には必ず「名前なしQueryDef」または `CurrentDb.OpenRecordset(strSql)` を選択すべきである。
—
結び
「動的SQLのデバッグが面倒だからAccessは嫌いだ」――そんな弱音は、アーキテクチャの力で完全に封じ込めることができる。
今回紹介した「SQL出力ログ自動生成ツール」を導入すれば、SQLの構文エラーやパラメータの不整合は、実行した瞬間にイミディエイトウィンドウとログファイルで明白になる。
デバッグに費やしていた無駄な時間を排除し、より本質的なビジネスロジックの構築にリソースを集中させよ。これこそが、レガシーを掌握するプロフェッショナルの仕事である。
