【テクニカル・上級編】DAOのFindFirstとADOのFilter：検索速度を比較し最適なメソッドを選択する – Access VBA解析バイブル

検索の深淵：DAO `FindFirst` と ADO `Filter` のアーキテクチャ的境界線

システムの規模が拡大し、データレコード数が数万、数十万の境界を超えたとき、プログラマは「動くコード」から「効率的なアーキテクチャ」への転換を迫られる。

Access VBAの世界において、検索処理のパフォーマンス差を生む最大の要因は、単なる構文の書き方ではない。それは、背後で動くデータエンジンへの命令の抽象度と、メモリ空間におけるオブジェクトのライフサイクルの理解に集約される。

本稿では、DAO（Data Access Objects）の `FindFirst` と、ADO（ActiveX Data Objects）の `Filter` プロパティ。この二つのメソッドが、内部的にどのようにエンジンへ命令を下し、どのようなコストを支払っているのかを解剖する。

1. DAO `FindFirst`：Jet/ACEエンジンへの直撃

DAOは、Accessの心臓部であるJet（またはACE）エンジンに特化した、いわば「ネイティブな言語」である。

内部メカニウム：インデックスの活用

DAOの `FindFirst` メソッドの本質は、「カーソルを移動させる命令」である。
検索条件がインデックス（B-Tree構造）に存在する場合、エンジンはテーブル全体をスキャンすることなく、インデックス・ツリーを辿って目的のレコードポインタを即座に特定する。これは、物理的なデータ読み込みを最小限に抑え、CPUサイクルを極限まで節約する極めて低レイヤーな操作だ。

ライフサイクルとメモリ

DAOのオブジェクトは、エンジンとの密結合が強いため、明示的な解放が極めて重要である。特に、ループ内で `Recordset` を生成する場合、`Set rs = Nothing` を怠れば、メモリリークが累積し、最終的にAccessのプロセス全体が不安定化する。

' --- DAOによる高速検索の極致 ---
Public Sub ExecuteDAOFindFirst(ByVal targetID As Long)
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim strSQL As String

    On Error GoTo ErrorHandler

    Set db = CurrentDb
    ' インデックスが効く条件で開くことが大前提
    Set rs = db.OpenRecordset("T_TransactionData", dbOpenDynaset)

    ' FindFirstは「現在のレコードセット内でのポインタ移動」
    ' インデックスが貼られているフィールドであれば、O(log n)の計算量で済む
    rs.FindFirst "TransactionID = " & targetID

    If Not rs.NoMatch Then
        Debug.Print "Found: " & rs.Fields("Amount").Value
    Else
        Debug.Print "Record not found."
    End If

ExitProcedure:
    ' オブジェクトの明示的解放：これは作法ではなく、生存戦略である
    If Not rs Is Nothing Then
        rs.Close
        Set rs = Nothing
    End If
    If Not db Is Nothing Then
        Set db = Nothing
    End If
    Exit Sub

ErrorHandler:
    MsgBox "Critical Error: " & Err.Description, vbCritical
    Resume ExitProcedure
End Sub

2. ADO `Filter`：抽象化レイヤーによる論理的フィルタリング

一方で、ADOはOLE DBを介してあらゆるデータソースにアクセスするための、汎用的な「抽象化レイヤー」である。

内部メカニウム：論理ビューの生成

ADOの `Filter` プロパティは、`FindFirst` とは根本的に思想が異なる。
`Filter` を適用した瞬間、ADOは既存のレコードセットに対して「論理的なサブセット（仮想的なビュー）」を構築する。これは、元のデータセットに対して述語（Predicate）を適用し、条件に合致するものだけを「見せている」状態である。

このプロセスには、条件判定のためのオーバーヘッドが発生する。たとえクライアントサイドカーソル（`adUseClient`）を使用していたとしても、条件に合致するレコードをメモリ上で再スキャンし、論理的なポインタを再構成するコストを支払わなければならない。

接続設定の罠：CursorLocation

ADOを扱うシニアエンジニアが最も注視すべきは `CursorLocation` である。

• `adUseServer`: サーバー側で処理を行うが、Accessのようなファイルベースのエンジンでは、ネットワーク遅延やロック競合の温床となる。
• `adUseClient`: 全データをクライアントメモリに展開する。`Filter` はこのメモリ上のデータに対して高速に動作するが、データ量が増大すると、メモリ消費量が指数関数的に増大し、スワップが発生してシステムが死に至る。

' --- ADOによるフィルタリングの実装 ---
Public Sub ExecuteADOFilter(ByVal categoryName As String)
    Dim conn As ADO.Connection
    Dim rs As ADO.Recordset
    Dim strConn As String

    On Error GoTo ErrorHandler

    ' 接続文字列の構築（環境に応じた最適化が必要）
    strConn = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & CurrentProject.FullName & ";"

    Set conn = New ADO.Connection
    conn.Open strConn
    
    ' クライアントサイドカーソルを指定。Filterを最大限活用するための定石
    conn.CursorLocation = adUseClient

    Set rs = New ADO.Recordset
    rs.Open "SELECT * FROM T_TransactionData", conn, adOpenStatic, adLockOptimistic

    ' Filterプロパティによる論理的な絞り込み
    ' 注意：これは新しいレコードセットを作るのではなく、表示条件を書き換えている
    rs.Filter = "CategoryName = '" & Replace(categoryName, "'", "''") & "'"

    If Not rs.EOF Then
        Debug.Print "Filtered Record Count: " & rs.RecordCount
        Debug.Print "First Filtered Amount: " & rs.Fields("Amount").Value
    End If

ExitProcedure:
    ' ADOの解放プロセスはDAOよりも複雑。接続(Connection)の管理も徹底せよ
    If Not rs Is Nothing Then
        If rs.State = adStateOpen Then rs.Close
        Set rs = Nothing
    End If
    If Not conn Is Nothing Then
        If conn.State = adStateOpen Then conn.Close
        Set conn = Nothing
    End If
    Exit Sub

ErrorHandler:
    MsgBox "ADO Error: " & Err.Description, vbCritical
    Resume ExitProcedure
End Sub

3. 究極の選択基準：どちらを実装すべきか

現場のエンジニアが直面する「どちらを使うべきか」という問いに対し、私は以下のマトリクスを提示する。

アーキテクトの判断基準

1. 「特定のIDを持つ1件を探したい」場合
迷わず DAOの `FindFirst` を選択せよ。インデックスを最大限に活用し、エンジンに最小限の負荷で答えを出させるのが、プロフェッショナルの選択だ。

2. 「特定の条件に合致するレコード群を、UI（ListBoxやComboBox）に表示したい」場合
ADOの `Filter`、あるいは最初から SQLの `WHERE` 句 を用いた再クエリを検討せよ。ただし、メモリ消費を考慮し、クライアントサイドカーソルを使用する場合は、取得件数の上限を設計段階で定義しておくこと。

3. システム間連携（SQL Server等への移行を見据える場合）
ADO を一貫して使用する構成にせよ。ロジックの抽象度を保つことで、将来的なデータベース・マイグレーション時のコード修正コストを最小化できる。

結言

技術の選択に「絶対的な正解」はない。しかし、「なぜそれを選ぶのか」という論理的な根拠は必ず存在する。
`FindFirst` が持つ「ポインタの移動」という物理的な感覚と、`Filter` が持つ「論理的なビューの構築」という抽象的な感覚。この違いを理解して初めて、君たちのコードは「単なる命令の羅列」から「堅牢なアーキテクチャ」へと昇華されるのだ。