DAO.RecordsetのBatchUpdateを自作する：トランザクション管理による一括更新の極限高速化
Access VBAにおける最大のアンチパターンのひとつが、「フォームやループ内での1レコードずつの`.Edit` / `.Update`（または`CurrentDb.Execute`の乱用）」である。
Jet/ACEデータベースエンジンは非常に優れたコストパフォーマンスを持つが、暗黙のトランザクション、ディスクI/Oの同期、そしてオブジェクト生成・破棄のオーバヘッドに無頓着なコードを走らせた瞬間、アプリケーションは途方もない遅延の泥沼に沈む。特に数万件規模のレコード処理において、この非効率なアプローチは致命傷となる。
ADOの`BatchUpdate`メソッドのような一括処理機能がDAO標準では直接提供されていないため、多くの開発者はここで絶望し、処理の遅さに頭を抱える。
しかし、DAOのトランザクション（`BeginTrans` / `CommitTrans`）と、メモリ上に展開された非連結・あるいは最適化されたローカルRecordsetを組み合わせることで、極限のパフォーマンスを引き出す「自作BatchUpdate」を実装することは完全に可能である。
本稿では、レガシー環境の限界を突破し、システム間連携や大量データ処理を秒速で完遂するためのアーキテクチャを詳解する。
—
1. なぜ「1件ずつ更新」は遅いのか？（アーキテクチャの真実）
Access（Jet/ACE）が背後で行っている処理を直視しなければならない。
1. 暗黙のトランザクションとディスクI/O
トランザクションを明示的に囲まない場合、DAOは`Update`メソッドが実行されるたびにトランザクションログをディスクに書き込み、インデックスの整合性を検証する。数千回のディスクシークが発生するため、CPUではなくストレージのI/Oがボトルネックになる。
2. COMオブジェクトのマーシャリング・オーバヘッド
VBAからAccessのオブジェクトモデル（`CurrentDb`等）へアクセスするたびに、COMのインターフェースを介したコンテキストスイッチが発生する。
これに対する解決策はただ一つ。「トランザクションのスコープを最小限のI/O回数に圧縮し、メモリ上のRecordset操作で完結させる」ことだ。
—
2. 実装：トランザクション制御による自作BatchUpdate
以下に、大量データを一括処理するための高効率なVBAモジュールを示す。
このコードは、トランザクションの明示的制御、エラーハンドリングによるロールバック、そしてオブジェクトの厳格な解放（メモリリークの完全排除）を網羅したプロダクション品質のコードである。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 処理名: 巨大データ一括更新エンジン (BatchUpdate実証コード)
‘ 概要 : トランザクションを明示的に制御し、DAO Recordsetの更新を高速化する
‘ ==============================================================================
Public Sub ExecuteHighSpeedBatchUpdate()
Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim lngCounter As Long
Dim dblStartTime As Double
dblStartTime = Timer
‘ デフォルトワークスペースの取得（トランザクション制御に必須）
Set ws = DBEngine.Workspaces(0)
Set db = CurrentDb
‘ パフォーマンス最適化のため、TableTypeまたはSnapshot/Dynasetを適切に選択
‘ 大量一括更新には、余計なオーバヘッドを排除したダイナセット（悲観的ロック回避）を使用
Set rs = db.OpenRecordset(“T_TargetTable”, dbOpenDynaset, dbDenyWrite)
‘ トランザクションの開始
ws.BeginTrans
On Error GoTo ErrorHandler
lngCounter = 0
With rs
If Not (.BOF And .EOF) Then
.MoveFirst
Do While Not .EOF
‘ — 実際の業務ロジック（例：特定の条件に基づく値の書き換え） —
.Edit
!ProcessedFlag = True
!UpdatedAt = Now()
‘ 複雑な計算や文字列操作もここでメモリ上のみで完結させる
!Description = “BatchProcessed: ” & CStr(!ID)
.Update
lngCounter = lngCounter + 1
‘ 進捗確認やメモリ解放のポイント（必要に応じてバッチサイズでコミットを分割する場合）
‘ ※今回は一括コミットの極限を試すため、ループ外で最終コミットする
.MoveNext
Loop
End If
End With
‘ トランザクションの確定（一括書き込み）
ws.CommitTrans
MsgBox “一括更新が完了しました。” & vbCrLf & _
“処理件数: ” & lngCounter & ” 件” & vbCrLf & _
“処理時間: ” & Format(Timer – dblStartTime, “0.00秒”), _
vbInformation, “極限最適化バッチ”
CleanUp:
‘ 厳格なオブジェクトの解放（メモリリークの撲滅）
On Error Resume Next
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
Set db = Nothing
Set ws = Nothing
Exit Sub
ErrorHandler:
‘ 障害発生時は即座にロールバックし、データベースの整合性を担保する
ws.Rollback
MsgBox “エラーが発生したため、処理をロールバックしました。” & vbCrLf & _
“Error ” & Err.Number & “: ” & Err.Description, _
vbCritical, “トランザクション異常終了”
Resume CleanUp
End Sub
—
3. シニアエンジニアが押さえるべき「極限の知見」とチューニング
上記のコードをさらに実務の現場で極限まで活かすための、アーキテクト視点の知見を共有する。
① `CurrentDb` の乱用を断つ
多くの初心者は、ループの内部や頻繁に呼び出される関数内で `CurrentDb.Execute` や `CurrentDb.OpenRecordset` を実行する。
`CurrentDb` は呼び出されるたびに新しいデータベースオブジェクトのインスタンスをメモリ上に生成し、既存のキャッシュを破棄するため、パフォーマンスが劇的に低下する。
データベース参照は必ずローカル変数（`Dim db As DAO.Database`）に一度だけ格納し、それを使い回せ。
② メモリリーク（COM参照の残骸）の完全撲滅
Access VBAにおいて、オブジェクト変数を `Set rs = Nothing` で解放するだけでは不十分な場合がある。特にモジュールレベル変数や、予期せぬエラーハンドリングのバイパスによって、Accessのプロセス（MSACCESS.EXE）がメモリ上に居座り続ける現象（ゾンビプロセス）が発生する。
トランザクション内でエラーが起きた際、`Rollback` を忘れるとロックが維持され、他のユーザーやシステム連携バッチを完全にブロックする。必ず `On Error GoTo` とクリーンアップブロックをセットで実装せよ。
③ 巨大データにおける「チャンク（分割）トランザクション」の概念
数百万件規模のレコードを単一の `BeginTrans` ～ `CommitTrans` で囲むと、Jet/ACEのトランザクションログ（`.ldb` / `.laccdb`）がパンクし、ディスク容量の枯渇や「システムリソースが不足しています」というエラーを引き起こす。
このような極限環境では、一定件数（例：5,000件ごと）に達した時点で一度 `CommitTrans` し、直ぐに次の `BeginTrans` を張る「チャンク分割パターン」を実装する必要がある。これにより、メモリとログの消費量を一定に保ちつつ、高速性を維持できる。
—
4. システム間連携への応用：外乱に強い堅牢な設計
この自作BatchUpdateパターンは、外部システム（SQL ServerやCSV、Web API等）からインポートした一時テーブルのデータを、本番テーブルへ高速にマージ・更新する際にも極めて有効である。
DAOの限界を知り、リソースのライフサイクルを完全に支配下に置いたコードだけが、レガシーとモダンが混交する現場において「止まらないシステム」を実現できる。
感覚的なコーディングを捨て去り、データベースエンジンの物理挙動に基づいた設計を徹底してほしい。
