Access VBAの深淵：DAO.Recordset.FindFirst が「最強の検索エンジン」である理由
Access開発において、クエリを乱造し、`DoCmd.OpenQuery`や`SQL`を都度発行してレコードを絞り込むのは、プロの所作ではない。それは単なる「記述」であり、「設計」ではないからだ。
特に、数万件規模のマスターやトランザクションを扱う際、SQLのパースコストやクエリプランの再構築を繰り返すことは、Accessのデータベースエンジン（ACE/Jet）にとって無駄な負荷でしかない。
真に速く、堅牢な検索エンジンを構築したいのであれば、DAO.Recordsetのメモリ上でのFind操作こそが至高の解となる。
—
1. なぜ「FindFirst」なのか：メモリ空間の支配
SQLによる絞り込みはデータベースエンジンへの問い合わせだが、DAOによる`FindFirst`は、既にメモリへロードされたRecordset内でのポインタ移動だ。
ここでシニアエンジニアが重視すべきは、「カーソル位置をどこに置くか」と「オブジェクトのライフサイクル管理」である。
以下のコードは、単なる検索ロジックではなく、メモリ最適化を考慮した検索エンジンのテンプレートだ。
高速検索エンジンの実装パターン
‘ 検索エンジンのコアロジック
‘ 注意: 第1引数のrsは、必ずdbOpenDynasetまたはdbOpenSnapshotで開くこと
Public Function FindRecordExt(ByRef rs As DAO.Recordset, _
ByVal strCriteria As String) As Boolean
‘ 検索前にブックマークを退避させる必要があればここで行う
‘ 連続検索時のパフォーマンスを考慮し、NoMatchによる早期脱出を徹底する
‘ DAOのFindFirstは高速だが、インデックスが効かない列に対しては
‘ フルテーブルスキャン（相当）が発生するため、スキーマ設計に依存する点に注意せよ
rs.FindFirst strCriteria
‘ NoMatchプロパティの判定は、エラーハンドリングよりも先に評価する
If rs.NoMatch Then
FindRecordExt = False
Else
FindRecordExt = True
End If
End Function
—
2. 伝説的アーキテクトが教える、極限のチューニング手法
① Recordsetの「型」を使い分ける
`dbOpenDynaset`は双方向の更新を可能にするが、オーバーヘッドが大きい。検索目的であれば、可能な限り `dbOpenSnapshot` を用いるべきだ。メモリ使用量を劇的に抑え、かつ検索速度が向上する。
② オブジェクトの明示的解放と「再利用」
VBAにおいて、`Set rs = Nothing` を忘れることはメモリリークを招く。しかし、もっと重要なのは「オブジェクトを使い回す戦略」だ。
‘ レガシー環境でのメモリ管理
Public Sub ProcessSearch()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Set db = CurrentDb
‘ Snapshotで高速化。dbReadOnlyオプションでロック競合を回避する
Set rs = db.OpenRecordset(“SELECT FROM T_Master”, dbOpenSnapshot, dbReadOnly)
If FindRecordExt(rs, “ID = 1001”) Then
Debug.Print rs!Name
End If
‘ 終了処理：必ず順序を守ること
rs.Close
Set rs = Nothing
Set db = Nothing
End Sub
③ 大規模データにおける「Windows API」との協調
検索対象が数百万件に及ぶ場合、AccessのDAOだけでは限界が来ることもある。その際、安易に`.NET`へ逃げるのではなく、`Win32 API`でメモリを直接操作し、バイナリ列としてデータを保持する手法もあるが、保守性を鑑みれば「DAOのFindFirstをインデックス付き列で実行する」のが、最もAccessの思想（Jetエンジンの特性）に適合している。
—
3. レガシー保守への提言：なぜコードは腐るのか
Accessシステムが「遅くなる」最大の理由は、開発者が「検索」と「表示」を密結合させているからだ。
- 検索ロジック：DAO.Recordsetで抽象化し、引数でCriteriaを渡す。
- 表示ロジック：検索結果のブックマークをFormの `RecordsetClone` に同期させる。
この2つを分けるだけで、コードの保守性は劇的に向上する。`FindFirst`を使いこなすことは、単に「速いコードを書く」だけでなく、「データとUIの境界を明確にする」というアーキテクトとしての規律を身につけることと同義である。
—
終わりに
Accessは「オモチャ」ではない。適切に設計されたDAOと、メモリのライフサイクルを意識した検索ロジックを実装すれば、SQL Server等のバックエンドに引けを取らないレスポンスを叩き出すことができる。
君たちが今書いているその`FindFirst`は、ただの検索行ではない。データベースの心臓部に直接触れる、精密な操作なのだ。その重みを理解し、コードの細部まで魂を込めること。
それが、Accessという老兵を、現代のシステム環境でも戦える最強のツールへと昇華させる唯一の道である。
