【Access VBA極限optimization】RecordsetCloneでフォーム操作を爆速化せよ！UIとデータの完全分離設計
こんにちは。チーフアーキテクトの私だ。
日々、現場から「Accessのフォームが重い」「検索処理のたびに画面がチラつく、あるいはフリーズする」という悲鳴交わりの相談が後を絶たない。
君たちはフォーム上のコントロール（テキストボックスやコンボボックス）の値や、フォーム自体の `Me.Recordset` を直接ゴリゴリと操作していないだろうか？
もし、画面に描画されているレコードソースを直接ループさせたり、非効率な `Requery` を連発しているなら、今すぐその手を止めてほしい。それはAccessアプリの寿命を縮める「アンチパターン」の極みだ。
今回は、DAOの真骨頂である `RecordsetClone` を用い、UI（ユーザーインターフェース）の描画コストを極限まで削ぎ落とし、安全かつ爆速でデータを制御する極意を伝授しよう。
—
なぜ生のフォーム操作は遅いのか？（アーキテクチャの視点）
Accessフォームは、UIの描画エンジンと背後のデータ（Recordset）が密結合している。
フォーム上でレコードを移動させたり、検索を行ったりすると、Accessは以下の重い処理を同時に実行する。
1. カレントレコードの移動に伴う画面の再描画（Paintイベントの発生）
2. コントロールの書式設定や連動するサブフォームの同期
3. Jet/ACEエンジンと画面バッファ間の無駄な往復
数千件程度のレコードであればごまかせても、データが膨れ上がり、複雑なクエリが絡み合う現場のシステムでは、これらが致命的なパフォーマンス低下を招く。
解決策：RecordsetCloneという「影武者」の活用
`RecordsetClone` メソッドは、現在フォームが開いているレコードソースのクローン（複製）をメモリ上に生成する。
重要なのは、「このクローンはフォームの画面（UI）とカレントレコードを共有していない」という点だ。
つまり、メモリ上でどれだけ高速にレコードを走査しようが、フィルタリングしようが、画面は一切再描画されない。目的のレコードを見つけたら、フォーム側の `Bookmark` プロパティにそのクローンの位置を転写するだけ。
これこそが、UIとデータを完全に分離し、モダンで堅牢なフォーム操作を実現する唯一無二の設計アプローチである。
—
プロダクションコード：爆速・安全な検索・同期ルーチン
現場でそのまま使える、堅牢なエラーハンドリング済みの実装例を提示する。
これは、特定の管理番号（ID）をテキストボックスに入力してエンターを押した際、画面をチラつかせずに該当レコードへ一瞬でジャンプし、さらにヒットしなかった場合のロールバックまで考慮したプロ仕様のコードだ。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 担当者コード: 001
‘ 概要: RecordsetCloneを用いた高速レコード検索・ジャンプ処理
‘ 特徴: 画面の再描画を抑制し、例外発生時もブックマークの整合性を担保する
‘ ==============================================================================
Private Sub txtSearchID_AfterUpdate()
Dim rsClone As DAO.Recordset
Dim lngTargetID As Long
‘ 入力値のバリデーション
If IsNull(Me.txtSearchID) Then Exit Sub
If Not IsNumeric(Me.txtSearchID) Then
MsgBox “有効な数値IDを入力してください。”, vbExclamation, “入力エラー”
Me.txtSearchID.Undo
Exit Sub
End If
lngTargetID = Me.txtSearchID.Value
‘ エラーハンドリングの開始（UIの凍結解除を確実に保証するため）
On Error GoTo ErrorHandler
‘ 画面描画の完全停止（パフォーマンス劇的改善のキモ）
Me.Application.Echo False
‘ フォームのRecordsetCloneを取得
Set rsClone = Me.RecordsetClone
If rsClone.RecordCount = 0 Then
MsgBox “テーブルにデータが存在しません。”, vbInformation, “通知”
GoTo CleanUp
End If
‘ 【重要】クローン側で高速検索を実行（インデックスが効くフィールドであることが前提）
‘ ※IDが数値型の場合の構文。文字列型の場合は “ID = ‘” & strTarget & “‘” とする
rsClone.FindFirst “ID = ” & lngTargetID
If rsClone.NoMatch Then
MsgBox “該当するレコードが見つかりません。”, vbExclamation, “検索結果”
‘ 見つからない場合は元の位置を維持するため、あえて何もしない
Else
‘ フォームのBookmarkにクローンのBookmarkを渡し、一瞬でジャンプ
Me.Bookmark = rsClone.Bookmark
End If
CleanUp:
‘ オブジェクトの解放と描画の復元
If Not rsClone Is Nothing Then
rsClone.Close
Set rsClone = Nothing
End If
Me.Application.Echo True
Exit Sub
ErrorHandler:
‘ 予期せぬエラー発生時も画面が固まったままになるのを防ぐ
Me.Application.Echo True
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical, “システムエラー”
Resume CleanUp
End Sub
—
現場で絶対に守るべき「3つの鉄則」
このアーキテクチャを導入するにあたり、プロのエンジニアとして知っておくべき極意を授けておく。
1. `Me.Application.Echo False` との合わせ技
`RecordsetClone` 自体はメモリ上の操作のため高速だが、フォームの `Bookmark` を書き換えた瞬間に画面が再描画される。これを防ぐために `Echo False` を挟むのがプロの定石だ。ただし、エラー時も含めて確実に `Echo True` に戻す構造（上のコードの `CleanUp` ラベルのような設計）にしないと、最悪の場合Access画面が操作不能になるので細心の注意を払うこと。
2. 検索対象フィールドには必ずインデックスを貼る
`rsClone.FindFirst` は非常に強力だが、裏側でJet/ACEエンジンが動いている。検索対象のフィールド（今回の例では `ID`）にインデックス（歯車マーク）が設定されていない場合、テーブル全体のフルスキャン（逐次検索）が発生し、データ量が増えると一気に遅くなる。DAOを極める者は、必ずバックエンドのインデックス設計まで統括する。
3. RecordsetCloneオブジェクトは「生成したら閉じる（Close）」
`Me.RecordsetClone` で取得したオブジェクトは、参照を切り離すために明示的な `Close` と `Set rsClone = Nothing` が必要だ。これを怠ると、VBAのメモリリークを引き起こし、長時間の稼働でAccessが不安定になる原因となる。
—
まとめ：アーキテクチャの美しさが業務を救う
コードを書くということは、単に動くものを作ることではない。
「なぜその書き方が最速で、なぜ安全なのか」をロジカルに説明できること、それがプロのエンジニアの条件だ。
今回紹介した `RecordsetClone` を用いたUIとデータの分離設計は、Accessアプリのパフォーマンスを別次元へと引き上げる。
君たちの開発するシステムにこの知見を組み込み、ユーザーに「ストレスフリーで爆速な業務アプリ」を届けてほしい。健闘を祈る。
