【極限のVBA】DAO.RecordsetのFindFirstを「検索エンジン」として昇華させる技術
Accessのパフォーマンスを語る際、多くの初学者は「クエリが遅い」と嘆き、クエリを分割して逃げる。しかし、真のアーキテクトは知っている。データセットに対するランダムアクセスをDAOのレイヤーでどう制御するか。
今回は、単なる「検索処理」を、数百万件のレコードに対してもミリ秒単位で応答する「検索エンジン」へと昇華させるための、極限のDAO活用術を伝授する。
—
1. なぜ「SQL」ではなく「DAO.FindFirst」なのか
大規模データにおいて、`DoCmd.OpenForm` の `WhereCondition` や、都度 `CurrentDb.OpenRecordset` を発行するSQLの手法は、オーバーヘッドが大きすぎる。
真の高速化とは、「一度開いたメモリ上のオブジェクトを、いかにインデックスを跨いで使い回すか」に集約される。`FindFirst` は、適切にインデックスが貼られたテーブルに対して実行すれば、バイナリツリー検索（B-Tree）を直接叩くのと同等の速度を叩き出す。
2. 「検索エンジン」の最適化実装
以下に、メモリ効率と実行速度を極限まで高めた実装を示す。ポイントは「再利用可能なRecordsetのキャッシュ」と「NoMatchの厳密なハンドリング」だ。
‘ 検索エンジンクラス（必要に応じて標準モジュールへ書き換え可）
Option Compare Database
Option Explicit
‘ 検索用Recordsetを保持し、メモリを制御する
Private m_rsEngine As DAO.Recordset
Public Function InitializeSearchEngine(ByVal strTableName As String) As Boolean
‘ 既に開いている場合は閉じて解放（メモリリーク防止）
If Not m_rsEngine Is Nothing Then TerminateSearchEngine
‘ DBエンジン最適化: Type:=dbOpenDynaset または dbOpenTable（テーブル直ならTableが最速）
Set m_rsEngine = CurrentDb.OpenRecordset(strTableName, dbOpenTable)
‘ インデックスを指定することで、FindFirstはバイナリ検索へ切り替わる
‘ ※テーブルデザイン側でインデックスを貼っておくことが前提（必須）
m_rsEngine.Index = “PrimaryKey”
InitializeSearchEngine = True
End Function
Public Function FindRecord(ByVal vSearchValue As Variant) As Boolean
If m_rsEngine Is Nothing Then Exit Function
‘ FindFirstを実行
m_rsEngine.FindFirst “ID = ” & vSearchValue
‘ NoMatch判定の直後に戻り値を確定させるのが鉄則
‘ キャストのオーバーヘッドを避けるためブール値を直接返す
FindRecord = Not m_rsEngine.NoMatch
End Function
Public Sub TerminateSearchEngine()
‘ オブジェクトの明示的解放はVBAにおける礼儀
If Not m_rsEngine Is Nothing Then
m_rsEngine.Close
Set m_rsEngine = Nothing
End If
End Sub
3. シニアエンジニアが押さえるべき「3つの深淵」
① インデックスの「恩恵」を最大化する
`FindFirst` が遅いと感じる場合、それは `FindFirst` が悪いのではない。対象フィールドにインデックスが貼られていないか、複合インデックスの順序が間違っているのだ。`m_rsEngine.Index` を適切に設定しなければ、DAOはテーブル全体を全走査（Table Scan）する。これは自殺行為に等しい。
② Windows APIとの共存：メモリ監視
もしあなたが巨大なレコードセットを扱うなら、`GlobalMemoryStatusEx` APIを呼び出し、物理メモリの空き容量を監視せよ。Accessはガベージコレクションが甘い。特に `Recordset` を開いたままループ処理を行う際、メモリが枯渇し始めたら強制的に `Close` して再起動するフックを仕込むのが、伝説的なエンジニアの流儀だ。
③ ネットワーク越しのボトルネック
AccessのバックエンドがSQL Server等のRDBMSである場合、`DAO.Recordset` はパススルーの制約を受ける。その際は `dbOpenDynaset` のオプションで `dbSeeChanges` を付与し、非同期のカーソル管理を行う必要がある。ネットワークの往復回数（ラウンドトリップ）を減らすため、検索条件は可能な限りプリコンパイルされたクエリを通すべきだ。
—
結び：コードは芸術である
Access VBAはレガシーではない。メモリ管理とオブジェクトライフサイクルさえ掌握すれば、現代のWebフロントエンドよりも遥かに高速な「データの肉食獣」を作り上げることができる。
「動けばいい」という考えは捨てろ。`NoMatch` の判定一つ、オブジェクトの解放一つに、あなたのプロとしての矜持を宿せ。それが、10年後も生き残るシステムを構築する唯一の道だ。
質問があればいつでも来い。次の技術的深淵へ案内しよう。
