【実務・中級編】ADOとSQL Serverのデータ型マッピング：VBAの型とズレが生むパフォーマンス劣化 – Access VBA解析バイブル

Access VBA

2026.10.27

【Access VBA極限性能】SQL ServerとADOの型マッピング最適化：VBAの「なんとなくVariant」がシステムを殺す理由

開発現場でよく見かける光景がある。「とりあえず動けばいい」とすべての変数を `Variant` や `String` で定義し、SQL Serverへデータを流し込むコード。そして、データが増えるにつれて「なぜか処理が遅い」「突然型ミスマッチエラーが起きる」と頭を抱えるエンジニアたち。

プロフェッショナルな業務システム開発において、AccessとSQL ServerをADO（ActiveX Data Objects）で接続する際、データ型のマッピング設計はパフォーマンスと堅牢性を左右する最重要ファクターだ。

今回は、VBAの変数型とSQL Serverのネイティブ型の間に生じる「見えない断層」がなぜパフォーマンスを劣化させるのか、そしてそれをどう極限まで最適化すべきか、アーキテクチャの視点からロジカルかつシャープに解説する。

—

1. なぜ型ズレはパフォーマンスを劣化させるのか？

ADOを経由してSQL Serverと通信する時、VBA側の変数型とSQL Server側のカラム型が一致していないと、COM（Component Object Model）のレイヤーで「暗黙の型変換（Implicit Conversion）」が発生する。

この裏側で何が起きているかを知る者は少ない。

1. CPUコストの増大: バイト配列や数値型を文字列経由で解釈し直すなど、データ転送のたびに無駄なMarshalling（マーシャリング）コストが発生数千・数万件のループ内ではこれが致命傷になる。
2. SQL Server側のインデックス・スキャン: パラメータクエリ（`Command` オブジェクト）を使う際、渡したVBAの型とSQL Serverの定義型が異なると、SQL Server側で最適化プランが再構築（Parameter Sniffingの悪化や暗黙の型変換によるSARGabilityの喪失）され、インデックスが効かなくなる。
3. メモリと精度の損失: `Currency` を使わすべき金銭データを `Double` で受渡し、丸め誤差で監査に引っかかる。あるいは `Variant` のせいでメモリフットプリントが肥大化し、ガベージコレクションやヒープ断片化を誘発する。

「動くコード」と「耐えうるコード」の境界線は、まさにこの型の一致にある。

—

2. 最適な型マッピング早見表

まずは、実務で絶対に押さえておくべきSQL ServerとVBA（ADO）の最適マッピングを定義する。この対応表から外れる設計をしてはならない。

—

3. 【実用コード】型安全かつ高速なパラメータバインドの実装

「文字列結合でSQLを組み立てる」という前時代的な手法は、SQLインジェクションの温床になるだけでなく、ADOの型推論に悪影響を与えるため即座に廃止すべきだ。

ここでは、`Command` オブジェクトと明示的なパラメータ型指定（`Parameter` の追加）を行い、型ズレゼロでSQL Serverから高速にデータを取得・更新するプロダクションコードを提示する。

Option Explicit

‘ =========================================================================
‘ 模範的なADO接続・パラメータ処理クラス/モジュール
‘ =========================================================================
Public Sub ExecuteOptimizedUpdate(ByVal employeeID As Long, ByVal newSalary As Currency, ByVal effectiveDate As Date)
Dim conn As Object
Dim cmd As Object
Dim connString As String

‘ 接続文字列の定義（ODBC Driver 17以上を推奨）
connString = “Driver={ODBC Driver 17 for SQL Server};” & _
“Server=your_server_name;Database=your_db_name;” & _
“Trusted_Connection=yes;”

On Error GoTo ErrorHandler

‘ ADOオブジェクトの明示的な生成
Set conn = CreateObject(“ADODB.Connection”)
conn.CommandTimeout = 30
conn.Open connString

Set cmd = CreateObject(“ADODB.Command”)
Set cmd.ActiveConnection = conn

‘ ストアドプロシージャまたはパラメータ化クエリの指定
cmd.CommandText = “UPDATE Employees SET Salary = ?, EffectiveDate = ? WHERE EmployeeID = ?”
cmd.CommandType = 1 ‘ adCmdText

‘ ———————————————————————
‘ 極限のポイント：型を完全に一致させたパラメータの明示的追加
‘ ———————————————————————
‘ 1. EmployeeID (SQL Server: int -> VBA: Long -> ADO: adInteger)
cmd.Parameters.Append cmd.CreateParameter(“pID”, 3, 1, , employeeID) ‘ 3 = adInteger, 1 = adParamInput

‘ 2. Salary (SQL Server: decimal/money -> VBA: Currency -> ADO: adCurrency)
cmd.Parameters.Append cmd.CreateParameter(“pSal”, 6, 1, , newSalary) ‘ 6 = adCurrency, 1 = adParamInput

‘ 3. EffectiveDate (SQL Server: datetime2 -> VBA: Date -> ADO: adDate)
cmd.Parameters.Append cmd.CreateParameter(“pDate”, 7, 1, , effectiveDate) ‘ 7 = adDate, 1 = adParamInput

‘ 実行（トランザクション制御下での実行を推奨）
conn.BeginTrans
cmd.Execute , , 128 ‘ adExecuteNoRecords (レコードセットを返さない高速実行)
conn.CommitTrans

‘ クリーンアップ
Set cmd = Nothing
conn.Close
Set conn = Nothing
Exit Sub

ErrorHandler:
If Not conn is Nothing Then
If conn.State = 1 Then conn.RollbackTrans
End If
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical, “データベースエラー”

‘ リソースの確実な解放
Set cmd = Nothing
If Not conn is Nothing Then
If conn.State = 1 Then conn.Close
Set conn = Nothing
End If
End Sub

コードのアーキテクチャ解説

1. `CreateParameter` の明示的活用: 変数の型をあらかじめ `Long`, `Currency`, `Date` と厳格に定義し、ADOのパラメータ型（`adInteger`, `adCurrency`, `adDate`）と1対1でバインドしている。これにより、ADO内部での型推論オーバーヘッドが完全に消失する。
2. `adExecuteNoRecords` の活用: 更新系クエリ（UPDATE/INSERT/DELETE）では無駄なRecordsetオブジェクトを生成しないため、ネットワーク帯域とメモリを節約できる。
3. 厳格なトランザクション管理: `BeginTrans` と `RollbackTrans` を組み合わせ、異常系でのデータ破損を防ぐ堅牢な設計にしている。

—

4. 大量データ処理（バルクインサート等）における注意点

もし数万件規模のレコードをAccessからSQL Serverへインサートする場合、上記のような個別パラメータクエリをループさせると、ラウンドトリップ（通信往復）の回数が多すぎて実用に耐えない。

その場合の最適解は以下の通りだ。

ADOのRecordset（`adOpenDynamic`, `adLockOptimistic`）によるバッチ更新、または SQL Server側のTVP（テーブル値パラメータ）、あるいは OLEDBプロバイダ経由の `BulkCopy`（VB.NET等への処理委譲） を検討する。
Access VBA単体で大量データを扱う限界を見極め、重い処理はSQL Server側のストアドプロシージャ（サーバサイド・プログラミング）に任せ、VBAからはそれをキックするだけに留める設計こそが、チーフアーキテクトとしての正しい選択である。

—

総括

「たかが型、されど型」。
VBAとSQL Server間のデータ型マッピングを軽視することは、高性能なスポーツカーに軽自動車のエンジンオイルを入れ続けるようなものだ。

変数の型を正しく選び、ADOのパラメータをコントロール下に対象化せよ。そのひと手間で、あなたの作成する業務システムは見違えるほどのスピードと、揺るぎない安定性を手に入れる。