【テクニカル・上級編】DAO.QueryDefとADO.Commandの比較：Access内処理と外部DB連携の使い分け基準 – Access VBA解析バイブル

Access VBA

2026.10.20

DAO.QueryDef vs ADO.Command: Access VBAにおけるクエリ処理の最終決断

Access VBAの世界で、動的なSQL生成と実行は避けて通れない課題だ。特に、ユーザーの入力や外部要因によってSQL文が刻々と変化するパラメータークエリの扱いは、システム全体のパフォーマンス、セキュリティ、そして開発・保守コストに直結する。多くのエンジニアがここで迷い、あるいは場当たり的な実装に終始してしまう。

私は長年、Access VBAはもとより、VB6、VB.NET、そして各種API、さらにはレガシーシステムの延命に携わってきた。その経験から断言できるのは、「いつ、どのオブジェクトを使うべきか」という判断基準を明確に持つことこそが、堅牢で効率的なシステムを構築する唯一無二の鍵であるということだ。

本稿では、Access VBAにおける動的SQL処理の二大巨頭、`DAO.QueryDef` と `ADO.Command` に焦点を当てる。それぞれの特性、パフォーマンス、セキュリティ、そして実装コストを徹底的に比較し、あなたが直面するであろうあらゆるシナリオにおける「最善の選択」を導き出す。これは単なるリファレンスの羅列ではない。オブジェクトのライフサイクル、メモリ管理、そしてシステム全体のアーキテクチャ設計という、極限の知見に基づく解説だ。

1. DAO.QueryDef: Accessネイティブの血脈

`DAO.QueryDef` は、Accessデータベースエンジン（Jet/ACE）に深く根ざしたオブジェクトであり、Access VBA環境においては最も自然で、かつ強力な選択肢の一つだ。

1.1. DAO.QueryDefの強み

Accessデータベースエンジンとの親和性:

`DAO.QueryDef` は、Accessのテーブル定義、インデックス、リレーションシップといったメタデータと直接連携できる。これにより、SQL文の構文チェックや、テーブル定義に基づいたフィールド名の補完などが、IDEレベルで強力にサポートされる。

パフォーマンス（ローカルDBの場合）:

Accessファイル（.accdb/.mdb）内に保存されるクエリ定義オブジェクトは、コンパイル済みの状態として扱われ、実行時にはAccessエンジンが最適化を行う。特に、ローカルのAccessデータベースに対するSELECT、INSERT、UPDATE、DELETE処理においては、ADOよりもオーバーヘッドが少なく、高速に動作する傾向がある。

トランザクション管理の容易さ:

`DAO.Database` オブジェクトは、`BeginTrans`、`CommitTrans`、`Rollback` といったメソッドを提供しており、複数操作を原子的に実行するためのトランザクション管理が容易に行える。これは、データの整合性を保証する上で極めて重要だ。

オブジェクトのライフサイクル管理:

`DAO.QueryDef` オブジェクトは、`Database` オブジェクトから生成され、そのスコープ内で管理される。適切に解放（`Set objQueryDef = Nothing`）することで、メモリリークのリスクを最小限に抑えられる。

1.2. DAO.QueryDefの実装例（パラメータークエリ）

‘============================================================
‘ 関数名: ExecuteDynamicQuery_DAO
‘ 概要: DAO.QueryDefを使用して動的なSQL（パラメータークエリ）を実行する
‘ 引数: dbPath (String) : Accessデータベースファイルのパス
‘ queryName(String) : 保存されているクエリ定義名
‘ params (Variant) : パラメーター値の配列 (例: Array(“特定の値”, 100))
‘ action (String) : “SELECT”, “INSERT”, “UPDATE”, “DELETE” など
‘ 戻り値: Variant – SELECTクエリの場合はRecordset、それ以外は実行結果 (Long)
‘============================================================
Function ExecuteDynamicQuery_DAO(dbPath As String, queryName As String, params As Variant, Optional action As String = “SELECT”) As Variant
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
Dim i As Integer

‘ エラーハンドリングの初期化
On Error GoTo ErrorHandler

‘ データベースオブジェクトの取得
‘ 既存のデータベースオブジェクトがあればそれを使用する方が効率的だが、
‘ ここではシンプルにパスから新規に開く例を示す。
Set db = DBEngine.OpenDatabase(dbPath)

‘ QueryDefオブジェクトの取得
‘ データベースに保存されているクエリ定義を直接参照する
Set qdf = db.QueryDefs(queryName)

‘ パラメーターの設定
‘ QueryDefオブジェクトのParametersコレクションを使用して、
‘ クエリ定義に設定されたパラメーターに値を割り当てる。
If qdf.Parameters.Count > 0 Then
If IsArray(params) Then
If UBound(params) – LBound(params) + 1 <> qdf.Parameters.Count Then
Err.Raise 1001, “ExecuteDynamicQuery_DAO”, “パラメーターの数がクエリ定義と一致しません。”
End If
For i = 0 To qdf.Parameters.Count – 1
‘ パラメーターの型を考慮して設定することが重要
‘ 例: DateTime型の場合は #yyyy/mm/dd hh:nn:ss# の形式で渡す
qdf.Parameters(i).Value = params(i)
Next i
Else
Err.Raise 1002, “ExecuteDynamicQuery_DAO”, “パラメーターは配列で指定してください。”
End If
ElseIf Not IsEmpty(params) Then
‘ クエリ定義にパラメーターがないのに値が渡された場合
Debug.Print “警告: クエリ定義 ‘” & queryName & “‘ にパラメーターが定義されていませんが、値が指定されました。”
End If

‘ クエリの実行
Select Case UCase(action)
Case “SELECT”
‘ SELECTクエリの場合、Recordsetとして結果を取得
‘ OpenRecordsetメソッドは、QueryDefオブジェクトを直接渡すことができる
Set rs = qdf.OpenRecordset()
Set ExecuteDynamicQuery_DAO = rs ‘ Recordsetオブジェクトを戻り値とする
Case “INSERT”, “UPDATE”, “DELETE”, “EXECUTE” ‘ SQL ServerのEXECUTEなどにも対応可能
‘ データ操作クエリの場合、Executeメソッドを使用
‘ db.Execute qdf.SQL, dbFailOnError ‘ dbFailOnErrorはエラー発生時に例外をスローする
‘ QueryDefオブジェクトのExecuteメソッドは、トランザクション内で実行される場合、
‘ DatabaseオブジェクトのExecuteよりも直接的で意図が明確になる。
qdf.Execute dbFailOnError
ExecuteDynamicQuery_DAO = 1 ‘ 成功を示す値 (例: 影響を受けたレコード数、または単なる成功フラグ)
Case Else
Err.Raise 1003, “ExecuteDynamicQuery_DAO”, “サポートされていないアクションです: ” & action
End Select

‘ クリーンアップ
GoTo Cleanup

ErrorHandler:
‘ エラー発生時の処理
MsgBox “エラーが発生しました (DAO): ” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“説明: ” & Err.Description & vbCrLf & _
“ソース: ” & Err.Source, vbCritical, “DAOクエリエラー”
‘ エラーが発生した場合、戻り値はNullまたは適切なデフォルト値とする
Set ExecuteDynamicQuery_DAO = Nothing ‘ またはErr.Raise Err

Cleanup:
‘ オブジェクトの解放
‘ 重要なのは、Recordsetオブジェクトは、呼び出し元で明示的にClose/Set Nothingする必要があること。
‘ QueryDefオブジェクトとDatabaseオブジェクトはここで解放する。
If Not rs Is Nothing Then
‘ SELECTクエリでRecordsetが返された場合、呼び出し元でrs.Close / Set rs = Nothing を行う必要がある。
‘ ここでrsを解放してしまうと、呼び出し元でRecordsetが使えなくなる。
‘ そのため、Recordsetは戻り値として返し、呼び出し元に後処理を委ねるのが一般的。
End If
Set qdf = Nothing
If Not db Is Nothing Then
‘ データベースオブジェクトをここでCloseすると、
‘ 実行中のトランザクションが強制的にコミット/ロールバックされる可能性がある。
‘ DBEngine.CloseDatabase db ‘ 不要な場合はCloseしない。OpenDatabaseで開いた場合はCloseすべき。
Set db = Nothing
End If
Set rs = Nothing ‘ Safety first
Set qdf = Nothing ‘ Safety first
End Function

‘ — 使用例 —
Sub TestDAOQuery()
Dim dbPath As String
Dim params() As Variant
Dim rs As DAO.Recordset
Dim result As Variant

‘ 現在開いているデータベースのパスを取得
dbPath = CurrentDb.Name

‘ ===== SELECTクエリのテスト =====
On Error Resume Next
‘ テーブル “T_Products” に “Category” が “Electronics” で “Price” が 1000 以上のレコードを検索するクエリ定義
‘ 事前に “Q_FindProductsByCategoryAndPrice” という名前で、
‘ パラメーター: [EnterCategory] As Text, [EnterMinPrice] As Number
‘ SQL: SELECT FROM T_Products WHERE Category = [EnterCategory] AND Price >= [EnterMinPrice];
‘ というクエリ定義を作成しておく必要があります。

params = Array(“Electronics”, 1000)
result = ExecuteDynamicQuery_DAO(dbPath, “Q_FindProductsByCategoryAndPrice”, params, “SELECT”)

If Not result Is Nothing Then
Set rs = result ‘ 戻り値がRecordsetの場合
If Not rs.EOF Then
Debug.Print “— SELECT 結果 —”
Do While Not rs.EOF
Debug.Print rs!ProductName & “, ” & rs!Price
rs.MoveNext
Loop
Else
Debug.Print “該当するレコードはありませんでした。”
End If
rs.Close ‘ Recordsetを必ず閉じる
Set rs = Nothing
Else
Debug.Print “SELECTクエリの実行に失敗しました。”
End If

‘ ===== UPDATEクエリのテスト =====
‘ テーブル “T_Products” の “ProductID” が 10 のレコードの “Price” を 1200 に更新する
‘ 事前に “Q_UpdateProductPrice” という名前で、
‘ パラメーター: [EnterNewPrice] As Number, [EnterProductID] As Number
‘ SQL: UPDATE T_Products SET Price = [EnterNewPrice] WHERE ProductID = [EnterProductID];
‘ というクエリ定義を作成しておく必要があります。
params = Array(1200, 10) ‘ 新しい価格, ProductID
result = ExecuteDynamicQuery_DAO(dbPath, “Q_UpdateProductPrice”, params, “UPDATE”)

If result = 1 Then ‘ 成功した場合、戻り値は1（または影響レコード数）
Debug.Print “UPDATEクエリが正常に実行されました。”
Else
Debug.Print “UPDATEクエリの実行に失敗しました。”
End If

‘ ===== INSERTクエリのテスト =====
‘ 新しいレコードを T_Products テーブルに追加
‘ 事前に “Q_InsertNewProduct” という名前で、
‘ パラメーター: [EnterProductName] As Text, [EnterCategory] As Text, [EnterPrice] As Number
‘ SQL: INSERT INTO T_Products (ProductName, Category, Price) VALUES ([EnterProductName], [EnterCategory], [EnterPrice]);
‘ というクエリ定義を作成しておく必要があります。
params = Array(“New Gadget”, “Electronics”, 1500)
result = ExecuteDynamicQuery_DAO(dbPath, “Q_InsertNewProduct”, params, “INSERT”)

If result = 1 Then
Debug.Print “INSERTクエリが正常に実行されました。”
Else
Debug.Print “INSERTクエリの実行に失敗しました。”
End If

‘ クリーンアップ
On Error GoTo 0 ‘ エラーハンドリングをリセット
End Sub

【重要】オブジェクトのライフサイクルとメモリ最適化

`DAO.QueryDef` および関連オブジェクト（`DAO.Database`, `DAO.Recordset`）は、COMオブジェクトとして実装されています。これらを適切に解放しないと、メモリリークやリソースの枯渇を引き起こす可能性があります。

`Set obj = Nothing`: 使用が終わったオブジェクト変数は、必ず`Set obj = Nothing`で明示的に解放してください。これにより、オブジェクトが保持していたリソースがシステムに返還されます。
`Recordset`の解放: `OpenRecordset`で取得した`Recordset`オブジェクトは、使い終わったら必ず`rs.Close`し、`Set rs = Nothing`してください。特に、ループ内で何度も`OpenRecordset`を実行する場合、解放を忘れると致命的なメモリリークにつながります。
`Database`オブジェクトの管理: `DBEngine.OpenDatabase`で開いたデータベースオブジェクトは、不要になったら`Close`（または`Set db = Nothing`）するのが基本です。ただし、トランザクションを伴う処理などで、`Database`オブジェクトをスコープ外に持ち出す場合は、そのライフサイクル管理に細心の注意が必要です。
`CurrentDb`の活用: 現在開いているデータベースへの参照を取得するには、`Set db = CurrentDb`を使用します。この場合、`CurrentDb`はAccessアプリケーションによって管理されるため、明示的な`Close`は不要ですが、`db`変数を`Nothing`にするのは同様に推奨されます。

1.3. DAO.QueryDefの限界と注意点

外部データソースへの直接アクセス: `DAO.QueryDef`は、基本的にAccessデータベースエンジンを介して処理を行います。SQL Serverなどの外部データベースに直接接続する場合でも、AccessのODBC接続機能などを介するため、ADOに比べてオーバーヘッドが生じることがあります。
複雑なSQL文やストアドプロシージャ: 非常に複雑なSQL文、あるいは外部データベースのストアドプロシージャを直接実行するようなシナリオでは、ADOの方が柔軟に対応できる場合があります。
VB.NETからの利用: VB.NETからAccessデータベースを操作する場合、`Microsoft.Office.Interop.Access.Dao`ライブラリを参照設定に追加することでDAOを利用できますが、ADO.NET (`System.Data.OleDb` や `System.Data.SqlClient`) の方が .NET 環境との親和性が高く、一般的に推奨されます。

2. ADO.Command: 汎用性と外部DB連携の雄

`ADO.Command` オブジェクトは、ODBCやOLE DBといった汎用データアクセスインターフェースを通じて、様々なデータソースにアクセスするための強力なツールです。Accessデータベースはもちろん、SQL Server、Oracle、MySQLなど、あらゆるデータベースと連携できます。

2.1. ADO.Commandの強み

汎用性: Access DB、SQL Server、Oracle、Excelファイル、テキストファイルなど、OLE DBプロバイダーまたはODBCドライバーが存在するあらゆるデータソースに接続し、操作できます。
パフォーマンス（外部DB連携の場合）: 外部データベースとの直接連携においては、ADOはJet/ACEエンジンを介さないため、オーバーヘッドが少なく、よりネイティブなパフォーマンスを発揮することが期待できます。特に、ネットワーク経由でのデータアクセスや、大量のデータを扱う場合に有利です。
ストアドプロシージャの実行: `ADO.Command`は、ストアドプロシージャの実行に特化した機能（`CommandType = adCmdStoredProc`）を備えています。これにより、データベース側で最適化されたロジックを効率的に呼び出すことができます。
柔軟なパラメーター管理: パラメーターの追加、削除、型指定などが柔軟に行えます。`Parameters`コレクションを通じて、入力パラメーターだけでなく、出力パラメーターや戻り値も扱うことが可能です。
非同期処理: `Execute`メソッドには`adAsyncExecute`オプションがあり、非同期でクエリを実行できます。これにより、UIのフリーズを防ぎ、ユーザーエクスペリエンスを向上させることができます。

2.2. ADO.Commandの実装例（パラメータークエリ）

‘============================================================
‘ 関数名: ExecuteDynamicQuery_ADO
‘ 概要: ADO.Commandを使用して動的なSQL（パラメータークエリ）を実行する
‘ 引数: connectionString (String) : データベース接続文字列
‘ sqlOrProcName (String) : 実行するSQL文またはストアドプロシージャ名
‘ params (Variant) : パラメーター値の配列 (例: Array(“特定の値”, 100))
‘ commandType (Adoenm.AdoCommandTypeEnum) : adCmdText, adCmdStoredProc など
‘ 戻り値: Variant – SELECTクエリの場合はRecordset、それ以外は実行結果 (Long)
‘============================================================
Function ExecuteDynamicQuery_ADO(connectionString As String, sqlOrProcName As String, params As Variant, Optional commandType As Adoenm.AdoCommandTypeEnum = adCmdText) As Variant
Dim cn As ADODB.Connection
Dim cmd As ADODB.Command
Dim rs As ADODB.Recordset
Dim prm As ADODB.Parameter
Dim i As Integer

‘ エラーハンドリングの初期化
On Error GoTo ErrorHandler

‘ Connectionオブジェクトの作成とオープン
Set cn = New ADODB.Connection
cn.ConnectionString = connectionString
‘ Connection TimeoutとCommand Timeoutを設定することを推奨
cn.ConnectionTimeout = 30 ‘ 接続タイムアウト (秒)
cn.CommandTimeout = 60 ‘ コマンド実行タイムアウト (秒)
cn.Open

‘ Commandオブジェクトの作成
Set cmd = New ADODB.Command
Set cmd.ActiveConnection = cn
cmd.CommandText = sqlOrProcName
cmd.CommandType = commandType
‘ CommandTimeoutはCommandオブジェクトで個別に設定することも可能
‘ cmd.CommandTimeout = 60

‘ パラメーターの設定 (adCmdStoredProcの場合に特に重要)
‘ SQL文に直接パラメーターを記述する場合は、ADOが自動的にパラメーターを解釈してくれる場合があるが、
‘ 明示的に設定する方が安全で、型情報なども正確に扱える。
If commandType = adCmdStoredProc Then
‘ ストアドプロシージャの場合、パラメーターの数や順番はプロシージャ定義に依存する。
‘ ここでは、ExecuteDynamicQuery_ADOのparams引数で渡された値の数と、
‘ ストアドプロシージャの定義におけるパラメーターの順番が一致することを前提とする。
‘ より堅牢な実装では、プロシージャ定義からパラメーター情報を取得し、
‘ 順番や型を動的にマッピングする必要がある。
If IsArray(params) Then
For i = LBound(params) To UBound(params)
Set prm = cmd.CreateParameter(“Param” & i, adVarChar, adParamInput, Len(CStr(params(i))), params(i)) ‘ 型は仮定。実際の型に合わせる必要あり。
‘ ※上記は単純な例。実際の型（adInteger, adDouble, adDate, adGUIDなど）や方向（adParamOutput）を
‘ 適切に指定する必要がある。ストアドプロシージャによっては、
‘ Parameters.Refresh メソッドでプロシージャ定義からパラメーターを取得することも可能。
cmd.Parameters.Append prm
Next i
ElseIf Not IsEmpty(params) Then
‘ パラメーターが配列でない場合、単一のパラメーターとして扱うか、エラーとする。
‘ ここではエラーとしておく。
Err.Raise 1001, “ExecuteDynamicQuery_ADO”, “ストアドプロシージャのパラメーターは配列で指定してください。”
End If
ElseIf commandType = adCmdText Then
‘ SQL文の場合、ADOのパラメーターマーカー（?）に対応させる。
‘ ただし、SQL Serverのnamed parameter (@ParamName) もADOはサポートしている。
‘ ここでは、ADOが自動的に ? を ? に置換してくれると仮定する。
‘ params配列は、SQL文中の ? の順番に対応させる。
If IsArray(params) Then
For i = LBound(params) To UBound(params)
‘ ADOは ? を自動的に解釈するが、明示的にパラメータを定義して
‘ cmd.Parameters.Append cmd.CreateParameter(…) する方が
‘ 型安全で、SQLインジェクションのリスクを低減できる。
‘ しかし、ここでは簡潔さのためにADOの自動解釈に依存する例とする。
‘ ※本格的な実装では、SQL文を解析してパラメーターを動的に生成・追加する。
‘ 例: cmd.Parameters.Append cmd.CreateParameter(“p” & i, adVarChar, adParamInput, , params(i))
‘ そして、SQL文中の ? を @p0, @p1, … のような名前に置換する。
Next i
‘ パラメーターを cmd.Parameters に追加しない場合、ADOは CommandText の ? を params 配列の順番で置換しようと試みる。
‘ この挙動は、Provider や SQL Server のバージョンによって若干異なる場合があるため注意が必要。
‘ より確実なのは、CreateParameter を使用すること。
‘ ※ここではADOの自動解釈に依存せず、自前でパラメーターを付与する方式に変更する。
‘ SQL文のパラメーターマーカーを “?” とし、params配列の値を対応させる。
cmd.Parameters.Clear ‘ 念のためクリア
For i = LBound(params) To UBound(params)
‘ パラメーターの型を推測して設定。より厳密には型情報を別途指定する必要がある。
‘ 例: adInteger, adDouble, adDate, adBoolean, adLongVarChar など
‘ ここでは簡潔さのため、可変長文字列として扱う。
Set prm = cmd.CreateParameter(“p” & i, adVarWChar, adParamInput, Len(CStr(params(i))), params(i))
cmd.Parameters.Append prm
Next i
‘ SQL文中の “?” を “@p0”, “@p1”, … のような名前に置換する処理が必要。
‘ この例では、SQL文側で named parameter (@Param1, @Param2) を使用することを想定する。
‘ 例: SQL = “SELECT FROM T_Products WHERE Category = @Param0 AND Price >= @Param1;”
‘ cmd.Parameters.Append cmd.CreateParameter(“@Param0”, adVarWChar, adParamInput, , params(0))
‘ cmd.Parameters.Append cmd.CreateParameter(“@Param1”, adInteger, adParamInput, , params(1))
‘ ※以下は、? を使用する前提で、ADOの自動置換に任せる場合（非推奨）
‘ For i = LBound(params) To UBound(params)
‘ cmd.Parameters.Append cmd.CreateParameter(“”, adVarChar, adParamInput, , params(i)) ‘ 名前は空にする
‘ Next i
ElseIf Not IsEmpty(params) Then
Err.Raise 1002, “ExecuteDynamicQuery_ADO”, “SQL文のパラメーターは配列で指定してください。”
End If
Else
‘ その他のCommandTypeについては、必要に応じて処理を追加
End If

‘ クエリの実行
Select Case cmd.CommandType
Case adCmdText, adCmdStoredProc
‘ SELECTクエリの場合、Recordsetとして結果を取得
If InStr(1, cmd.CommandText, “SELECT”, vbTextCompare) = 1 Or cmd.CommandType = adCmdStoredProc Then ‘ ストアドプロシージャはSELECTを返す場合がある
Set rs = cmd.Execute
Set ExecuteDynamicQuery_ADO = rs ‘ Recordsetオブジェクトを戻り値とする
Else
‘ データ操作クエリ (INSERT, UPDATE, DELETE) の場合
‘ Executeメソッドは、影響を受けたレコード数を戻り値として返す（通常）
‘ NonQueryOperation = True を設定すると、レコードセットを返さないことを明示できる。
‘ cmd.ExecuteOptions = adExecuteNoRecords ‘ レコードセットを返さない
cmd.Execute
ExecuteDynamicQuery_ADO = cmd.RecordsAffected ‘ 影響を受けたレコード数を返す
End If
Case Else
Err.Raise 1003, “ExecuteDynamicQuery_ADO”, “サポートされていないCommandTypeです: ” & cmd.CommandType
End Select

‘ クリーンアップ
GoTo Cleanup

ErrorHandler:
‘ エラー発生時の処理
MsgBox “エラーが発生しました (ADO): ” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“説明: ” & Err.Description & vbCrLf & _
“ソース: ” & Err.Source, vbCritical, “ADOクエリエラー”
‘ エラーが発生した場合、戻り値はNullまたは適切なデフォルト値とする
Set ExecuteDynamicQuery_ADO = Nothing ‘ またはErr.Raise Err

Cleanup:
‘ オブジェクトの解放
‘ Connectionオブジェクトは、Commandオブジェクトの実行後も開いたままにしておくと、
‘ 再利用によるパフォーマンス向上が期待できる。
‘ ただし、メモリリークを防ぐため、最終的な解放は必要。
‘ ここでは、関数終了時にConnectionを閉じる例を示す。
‘ 継続的な接続が必要な場合は、Connectionオブジェクトをモジュールレベルで管理する。
If Not cmd Is Nothing Then
Set cmd = Nothing
End If
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
If Not cn Is Nothing Then
If cn.State = adStateOpen Then cn.Close
Set cn = Nothing
End If
End Function

‘ — 使用例 —
Sub TestADOCommand()
Dim connectionString As String
Dim sql As String
Dim params() As Variant
Dim rs As ADODB.Recordset
Dim result As Variant

‘===== Accessデータベースへの接続例 =====
‘OLE DB Provider for Microsoft Access
‘connectionString = “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=” & CurrentDb.Name & “;”

‘===== SQL Serverへの接続例 =====
‘SQL Server Native Client 11.0 (または適切なバージョン)
connectionString = “Provider=SQLNCLI11;Server=YourServerName;Database=YourDatabaseName;Uid=YourUser;Pwd=YourPassword;”
‘ Windows認証の場合:
‘connectionString = “Provider=SQLNCLI11;Server=YourServerName;Database=YourDatabaseName;Integrated Security=SSPI;”

‘===== SELECTクエリのテスト (SQL Server) =====
‘ SQL Serverのテーブル T_Products から、Category が ‘Electronics’ で Price が 1000 以上のレコードを取得
‘ Named Parameter (@Param0, @Param1) を使用する例
sql = “SELECT ProductID, ProductName, Price FROM T_Products WHERE Category = @Param0 AND Price >= @Param1;”
params = Array(“Electronics”, 1000) ‘ Category, MinPrice
result = ExecuteDynamicQuery_ADO(connectionString, sql, params, adCmdText)

If Not result Is Nothing Then
Set rs = result
If Not rs.EOF Then
Debug.Print “— ADO SELECT 結果 —”
Do While Not rs.EOF
Debug.Print rs!ProductID & “, ” & rs!ProductName & “, ” & rs!Price
rs.MoveNext
Loop
Else
Debug.Print “該当するレコードはありませんでした。”
End If
rs.Close
Set rs = Nothing
Else
Debug.Print “ADO SELECTクエリの実行に失敗しました。”
End If

‘===== UPDATEクエリのテスト (SQL Server) =====
‘ ProductID が 10 のレコードの Price を 1200 に更新
sql = “UPDATE T_Products SET Price = @Param0 WHERE ProductID = @Param1;”
params = Array(1200, 10) ‘ NewPrice, ProductID
result = ExecuteDynamicQuery_ADO(connectionString, sql, params, adCmdText)

If IsNumeric(result) Then
Debug.Print “ADO UPDATEクエリが正常に実行されました。影響レコード数: ” & result
Else
Debug.Print “ADO UPDATEクエリの実行に失敗しました。”
End If

‘===== ストアドプロシージャ実行のテスト (SQL Server) =====
‘ 事前に、以下のようなストアドプロシージャを作成しておく:
‘ CREATE PROCEDURE usp_InsertNewProduct
‘ @ProductName NVARCHAR(100),
‘ @Category NVARCHAR(50),
‘ @Price DECIMAL(10, 2)
‘ AS
‘ BEGIN
‘ INSERT INTO T_Products (ProductName, Category, Price)
‘ VALUES (@ProductName, @Category, @Price);
‘ SELECT SCOPE_IDENTITY() AS NewProductID; — 追加したレコードのIDを返す
‘ END
sql = “usp_InsertNewProduct” ‘ プロシージャ名
params = Array(“Another Gadget”, “Electronics”, 1800) ‘ ProductName, Category, Price
result = ExecuteDynamicQuery_ADO(connectionString, sql, params, adCmdStoredProc)

If Not result Is Nothing Then
Set rs = result
If Not rs.EOF Then
Debug.Print “ストアドプロシージャ ‘usp_InsertNewProduct’ が実行されました。新しく追加されたProductID: ” & rs!NewProductID
Else
Debug.Print “ストアドプロシージャ ‘usp_InsertNewProduct’ は実行されましたが、ProductIDは返されませんでした。”
End If
rs.Close
Set rs = Nothing
Else
Debug.Print “ストアドプロシージャ ‘usp_InsertNewProduct’ の実行に失敗しました。”
End If

‘ クリーンアップ
On Error GoTo 0 ‘ エラーハンドリングをリセット
End Sub

【重要】ADO.NETとの連携とCOMオブジェクトの管理

ADO（ActiveX Data Objects）はCOMコンポーネントです。VBAやVB6では直接利用しますが、VB.NETではADO.NETが推奨されます。もしVB.NETからAccessやSQL Serverに接続する場合、`System.Data.OleDb`（Access用）や`System.Data.SqlClient`（SQL Server用）といった、より.NETネイティブなクラスを使用するべきです。

`ADODB.Connection`, `ADODB.Command`, `ADODB.Recordset`: これらのオブジェクトもCOMオブジェクトです。使用後は `Set obj = Nothing` で明示的に解放することが、リソースリークを防ぐために不可欠です。
`Connection` オブジェクトの再利用: データベースへの接続はコストのかかる処理です。同じデータベースに複数回アクセスする場合は、`Connection` オブジェクトをモジュールレベルなどで保持し、再利用することでパフォーマンスが向上します。ただし、その場合も、アプリケーション終了時など、適切なタイミングで`cn.Close`、`Set cn = Nothing` する必要があります。
タイムアウト設定: ネットワーク遅延やデータベースの応答遅延により、処理が長時間ブロックされる可能性があります。`ConnectionTimeout`（接続確立にかかる時間）と`CommandTimeout`（クエリ実行にかかる時間）を適切に設定することで、予期せぬ長時間実行を防ぎ、ユーザーエクスペリエンスを改善できます。

2.3. ADO.Commandの限界と注意点

SQLインジェクションのリスク: パラメーターを正しく扱わないと、SQLインジェクションの脆弱性を生み出す可能性があります。特に、ユーザーからの入力を直接SQL文字列に埋め込むような実装は絶対に避けるべきです。`Parameters`コレクションを適切に使用し、ADOが提供する型チェックやエスケープ機能に頼ることが重要です。
COMオブジェクトのオーバーヘッド: VBA環境でADOを利用する場合、COMオブジェクトの呼び出しには一定のオーバーヘッドが伴います。単純なローカルAccess DBの操作であれば、DAOの方が効率的な場合があります。
エラーハンドリングの複雑さ: ADOのエラーオブジェクト (`Errors` コレクション) は、複数のエラー情報を持つことがあり、DAOに比べてエラーハンドリングがやや複雑になることがあります。

3. DAO.QueryDef vs ADO.Command: 使い分けの基準

長年の経験に基づき、以下に判断基準を提示する。これは「どちらか一方」という二者択一ではなく、「状況に応じて最適な方を選択する」 という原則に基づく。

3.1. パフォーマンスの観点

ローカルAccess DB (.accdb/.mdb) に対するCRUD操作: DAO.QueryDef が一般的に有利。Accessエンジンとの親和性が高く、オーバーヘッドが少ない。
外部データベース (SQL Server, Oracle, MySQLなど) に対するCRUD操作: ADO.Command が有利。直接的なデータアクセスが可能で、パフォーマンスが期待できる。
大量のデータ操作（バルクインサート、バッチアップデートなど）:
ローカルAccess DB: DAOの`Recordset.UpdateBatch`や`Recordset.Execute`が有効。
外部DB: ADOの`CommandTimeout`を長く設定し、`Execute`メソッドで実行。ストアドプロシージャで一括処理を行うのが最も効率的。
非同期処理が必要な場合: ADO.Command の `adAsyncExecute` オプションが必須。UIの応答性を保つために重要。

3.2. セキュリティの観点

SQLインジェクション対策: どちらのオブジェクトを使用する場合でも、パラメータークエリを正しく使用することが絶対条件。
DAO: `QueryDef`オブジェクトの`Parameters`コレクションを使用。
ADO: `Command`オブジェクトの`Parameters`コレクションを使用。
注意: VBAの文字列連結 (`&`) でSQL文を生成し、ユーザー入力を直接埋め込むのは非常に危険であり、絶対に避けるべき。
外部DBへの接続文字列管理:
DAO: Accessのリンクテーブル機能やODBC接続文字列を介して接続する場合、接続情報はAccessファイル自体やiniファイルなどに保存される。
ADO: 接続文字列をソースコードに直接埋め込むのは避けるべき。設定ファイル（ini, xml, registry）や、よりセキュアな方法（Windows認証、DPAPIによる暗号化など）で管理する。
権限管理: データベース側の権限管理機能（SQL Serverのログイン、ユーザー、ロールなど）に依存する。DAO/ADO自体が直接的な権限管理機能を提供するわけではない。

3.3. 実装コストと保守性の観点

Accessネイティブ機能との連携:
Accessフォーム/レポートのデータソースとして動的SQLを利用する場合: DAO.QueryDef が親和性が高い。
Accessのテーブル/クエリ定義を直接操作する場合: DAO.QueryDef が自然。
外部システムとの連携:
SQL Server、Oracleなどの外部DBに接続する場合: ADO.Command が標準的で、ドキュメントや情報も豊富。
ODBC/OLE DB経由での様々なデータソース（Excel、テキストファイルなど）へのアクセス: ADO.Command が汎用性が高い。
ストアドプロシージャの利用: ADO.Command が得意とする領域。
コードの可読性と保守性:
単純なクエリ: どちらも容易。
複雑なクエリや大量のパラメーター: ADOの方が、パラメーターの型指定や管理が明示的で、コードが整理しやすい場合がある。
レガシー環境の保守: 既存のシステムがDAOを使っているかADOを使っているかを理解し、それに倣うのが基本。どちらかに統一するにしても、影響範囲と移行コストを慎重に評価する必要がある。

3.4. Windows APIとの連携

Windows APIを直接呼び出すような低レベルな処理や、COMオブジェクトのメモリ管理をより細かく制御したい場合、VBAの標準機能だけでは限界がある。

`Declare`ステートメント: API関数を呼び出すために使用。
メモリ管理: `GlobalAlloc`, `GlobalLock`, `GlobalFree` などのAPIを使用して、VBAのヒープとは別のメモリ領域を確保・解放することが可能。これは、大量のデータを扱ったり、特定のAPIが要求するメモリ形式でデータを渡したりする場合に必要となることがある。
COMオブジェクトの解放: VBAの `Set obj = Nothing` は、COMオブジェクトの参照カウントをデクリメントする。しかし、COMオブジェクトの最終的な解放（`Marshal.ReleaseComObject` in .NET, `CoFreeUnusedLibraries` in Windows API）は、VBAのガベージコレクションに依存する部分もある。極限までメモリ使用量を抑えたい場合、API関数を駆使して明示的に解放を試みることもあるが、これは非常に高度でリスクも伴う。

Access VBAの文脈では、APIの直接呼び出しは限定的だが、例えば、ファイル操作（`FindFirstFile`, `FindNextFile`など）、クリップボード操作、あるいはAccessの内部的な動作に影響を与えるような特殊なケースで必要になることがある。`DAO.QueryDef`や`ADO.Command`の実行時にも、バックグラウンドでWindows APIが多数呼び出されていることを理解しておくことが重要だ。

4. まとめ：極限の選択

DAO.QueryDefとADO.Command、どちらが優れているという単純な話ではない。それぞれのオブジェクトは、その設計思想と用途において明確な違いを持つ。

Accessネイティブの堅牢性と効率性を求めるなら、DAO.QueryDef。
汎用性、外部DB連携、そして高度な機能を求めるなら、ADO.Command。

最終的な判断基準は、あなたのシステムが「どこで」「何を」しようとしているのか、そして「どのような制約」の中で動くのか、という具体的な状況に依存する。

レガシーシステムに携わる者として、私は常に「既存資産の尊重」と「将来への拡張性」のバランスを考慮する。もしあなたが新規にAccess VBAシステムを開発するならば、まずはDAOから始めるのが王道だろう。しかし、将来的に外部DBとの連携が必須となる可能性が高いのであれば、ADOの利用も視野に入れるべきだ。

そして何よりも、「オブジェクトのライフサイクル管理」と「SQLインジェクション対策」。この二つは、どのようなオブジェクトを使おうとも、システムを堅牢に保つための揺るぎない原則である。これらを怠る者は、いずれシステム崩壊の淵に立たされることになるだろう。

この解説が、あなたのAccess VBA開発における「最終決断」の一助となれば幸いだ。技術の真髄を追求し、より良いシステムを築き上げてほしい。