Access VBAで「クエリの乱造」を卒業せよ：DAO.RecordsetとFindFirstによる高速検索エンジンの構築術
現場でAccessを触っていると、要件が増えるたびに「検索用クエリ」を量産してしまうエンジニアをよく見かける。クエリを増やすことは、データベースの管理コストを爆発的に増大させ、パフォーマンスを劣化させる悪手だ。
真の業務自動化エンジニアは、メモリ上のレコードセットを操作する。今回は、DAO.Recordsetの`FindFirst`メソッドを駆使し、堅牢かつ爆速なデータ検索エンジンを構築する作法を伝授する。
—
1. なぜ「クエリ作成」が敗北への入り口なのか
Accessで検索のたびに `DoCmd.OpenQuery` やSQLを動的に書き換えるアプローチは、以下の理由で「開発の負債」となる。
- コンパイルコスト: クエリを実行するたびに、Accessのクエリオプティマイザが実行計画を再計算する。
- 名前空間の汚染: クエリが増えるほど、データベースウィンドウがカオス化し、修正時の影響範囲が特定困難になる。
- 排他制御の脆弱性: 複数のユーザーが同時にクエリを動かした場合、リソースの競合を招きやすい。
これに対し、DAO.Recordsetをメモリにロードし、FindFirstでポインタを制御する手法は、データアクセスをアプリケーションのメモリ層で完結させるため、非常に軽量で予測可能な挙動を示す。
—
2. 堅牢な検索エンジン実装：プロフェッショナル・コード
以下に、実務でそのまま利用できる、エラーハンドリングを備えた汎用的な検索関数を示す。このコードのポイントは、「DAOの明示的な型指定」と「NoMatchによる確実な分岐」だ。
‘ 必要なライブラリ: Microsoft Office 16.0 Access database engine Object Library
‘ 参照設定で DAO を有効にすること
Public Function FindRecord(ByVal strTableName As String, _
ByVal strCriteria As String) As Variant
Dim db As DAO.Database
Dim rs As DAO.Recordset
‘ エラーハンドリングの要：メモリリークを防ぐための後始末
On Error GoTo ErrorHandler
Set db = CurrentDb
‘ dbOpenDynaset: 読み書き可能かつインデックスを利用できる高速なモード
Set rs = db.OpenRecordset(strTableName, dbOpenDynaset)
‘ 検索実行
rs.FindFirst strCriteria
‘ NoMatchプロパティによる判定
If rs.NoMatch Then
‘ 見つからなかった場合の処理
FindRecord = Null
Else
‘ 見つかった場合、キーとなる値を返す（例: IDなど）
FindRecord = rs!ID
End If
ExitRoutine:
‘ オブジェクトの明示的な解放（必須）
If Not rs Is Nothing Then rs.Close: Set rs = Nothing
Set db = Nothing
Exit Function
ErrorHandler:
MsgBox “検索エンジンでエラーが発生しました: ” & Err.Description, vbCritical
Resume ExitRoutine
End Function
この設計のポイント
1. dbOpenDynasetの選択: `FindFirst`を高速に機能させるには、対象テーブルにインデックスが貼られていることが前提だ。`dbOpenDynaset`はインデックスを最大限活用する。
2. 徹底したオブジェクト解放: `Set rs = Nothing` を忘れるのは、メモリという資産を垂れ流す行為だ。`ExitRoutine`へのジャンプ構造を徹底せよ。
3. NoMatchによる分岐: `If rs.EOF` ではなく `rs.NoMatch` を使うのがDAO流の作法だ。FindFirstの直後に評価することで、検索の成否を明示的に処理できる。
—
3. 実務で「殺す」ための注意点
このコードを現場で運用する際、以下の3点を意識しなければ、どれだけコードが美しくてもシステムは崩壊する。
① 検索対象のインデックス化
`FindFirst` は強力だが、魔法ではない。検索対象となるフィールド（例: `EmployeeID` や `CustomerCode`）にインデックスが設定されていない場合、全件走査（テーブルスキャン）が発生する。数万件を超えた瞬間にツールはフリーズする。「検索に使う列には必ずインデックスを貼る」。これは鉄則だ。
② 大規模データに対する「OpenRecordset」の慎重さ
もし対象テーブルが数百万件クラスなら、テーブル全件をメモリに乗せるのは悪手だ。その場合は、`WHERE`句を含んだSQLを `db.OpenRecordset` に渡すことで、最初から絞り込んだ状態でロードせよ。
‘ 大規模データの場合はSQLで絞り込んでからロードする
Set rs = db.OpenRecordset(“SELECT FROM T_Sales WHERE SalesDate >= #2023/01/01#”, dbOpenDynaset)
③ トランザクションとの共存
このコードを更新処理（`rs.Edit` / `rs.Update`）と組み合わせる場合は、必ずトランザクション（`dbBeginTrans`）で囲むこと。検索中に他ユーザーからデータが変更されるリスクを管理するのは、エンジニアとしての責務だ。
—
結論：コードは「資産」か「負債」か
クエリを増やすだけのエンジニアは、行き当たりばったりのコードを積み上げ、いずれ「修正が怖い」という領域に足を踏み入れる。
一方で、DAOのライフサイクルを理解し、メモリ上でスマートにデータを操るエンジニアは、堅牢で拡張性の高いシステムを構築できる。今回紹介した `FindFirst` と `NoMatch` の組み合わせは、Access VBAにおける「最適解」の一つだ。
さあ、今すぐあなたのプロジェクト内の「死にかけのクエリ」を整理し、このコードでリプレイスせよ。技術は、正しく使えば必ずあなたの時間を守る盾となる。
