「FindFirst」を卒業せよ。DAO `Seek` メソッドによる、極限の高速検索アーキテクチャ
開発現場で「動きはするが、データが増えると目に見えて重くなるツール」を量産していないか？
もし君が、レコードの検索に `Recordset.FindFirst` を漫然と使っているとしたら、それは設計者として致命的な慢心だ。小規模なテストデータでは問題なくても、本番環境で数万、数十万件のレコードが流し込まれた瞬間、そのツールはユーザーから「使い物にならない」と切り捨てられるだろう。
我々プロフェッショナルが目指すべきは、単に「動くコード」ではない。データの増大に対して計算量を最小限に抑え、常に一定のパフォーマンスを維持する「堅牢なアーキテクチャ」だ。
本稿では、DAO（Data Access Objects）の真の力を引き出す、インデックス直結型の検索手法 `Seek` メソッド の極意を伝授する。
1. なぜ `FindFirst` は「非効率」なのか
まず、君が書いているコードの「コスト」を理解せよ。
`FindFirst` は、指定した条件に合致するレコードが見つかるまで、レコードセットの先頭から順にレコードをスキャンしていく。これはアルゴリズム論で言えば $O(n)$、つまり線形探索だ。レコード数が10倍になれば、検索にかかる時間も理論上10倍になる。
対して、インデックス（索引）を利用した `Seek` メソッドは、B-Tree構造を辿ることで目的のデータへダイレクトにジャンプする。これは $O(\log n)$ の計算量だ。データが100万件あっても、わずか数十回のステップで目的の場所に到達できる。
この差は、単なる「速度の違い」ではない。「スケーラビリティ（拡張性）の有無」そのものなのだ。
2. `Seek` メソッドを掌握するための「3つの絶対条件」
`Seek` は強力だが、極めて気難しい。`FindFirst` のように「なんとなく」で書くと、エラーを吐くか、あるいはインデックスを無視して低速な動作に陥る。
`Seek` を成功させるには、以下のアーキテクチャ要件を完全に満たさなければならない。
① カーソルタイプとロックタイプの厳格な指定
`Seek` は、`dbOpenTable`（テーブルタイプ）または、インデックスが有効な状態で開かれた `dbOpenDynaset` でのみ真価を発揮する。ADODB（ADO）には存在しない、DAO特有の低レイヤーな操作であることを忘れるな。
② インデックスの明示的な指定
`Recordset.Index` プロパティを使用して、どのインデックス（主キーや作成済みのインデックス名）を使用して検索を行うかを明示する必要がある。
③ 検索キーの整合性
`Seek` に渡す値は、指定したインデックスの構成と完全に一致していなければならない。例えば、複合インデックス（例：`部署ID` + `社員ID`）に対して、片方の値だけで `Seek` しようとすれば、それは失敗する。
3. プロダクションレベルの設計例
では、実務でそのまま使える、堅牢な検索モジュールの設計例を示そう。ここでは、単なる検索だけでなく、エラーハンドリングとオブジェクトのライフサイクル管理を徹底したコードを記述する。
Option Compare Database
Option Explicit
'=======================================================================================
' 概要: 高速インデックス検索モジュール
' 目的: Seekメソッドを用いた、大量データに対する低コストなレコード特定
' 注意: このメソッドはDAO専用であり、インデックスが適切に設定されていることが前提。
'=======================================================================================
Public Sub HighSpeedSearchExample()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim targetID As Long
Dim found As Boolean
' 検索対象のID（実務では引数やUIから取得）
targetID = 1025
found = False
On Error GoTo ErrorHandler
Set db = CurrentDb
' 1. Recordsetのオープン
' Seekを最大限活用するため、dbOpenTable を推奨。
' リンクテーブルの場合でも、ACEエンジンがインデックスを適切にハンドリングする。
Set rs = db.OpenRecordset("T_TransactionHistory", dbOpenTable, dbReadOnly)
' 2. 使用するインデックスの指定
' ここで指定する名前は、テーブル設計時に設定したインデックス名（または主キー名）であること。
rs.Index = "PrimaryKey"
' 3. Seekメソッドによるダイレクトアクセス
' FindFirstとは異なり、インデックスのB-Treeを辿って直接位置を特定する。
' 引数はインデックスの構成要素を順番に渡す。
rs.Seek "=", targetID
' 4. 検索結果の判定
' Seek実行後、NoMatchプロパティでヒットしたかを確認する。
If Not rs.NoMatch Then
found = True
Debug.Print "--- レコード発見 ---"
Debug.Print "ID: " & rs!TransactionID
Debug.Print "日付: " & rs!TransactionDate
Debug.Print "金額: " & rs!Amount
Else
Debug.Print "該当するレコードは見つかりませんでした。"
End If
CleanUp:
' 5. リソースの解放（極めて重要）
' オブジェクトのライフサイクルを適切に管理し、ファイルロックやメモリリークを防ぐ。
On Error Resume Next
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:
' 6. 堅牢なエラーハンドリング
' 実行時エラーが発生した場合、状況をログに出力し、リソースを解放して終了する。
MsgBox "致命的なエラーが発生しました。" & vbCrLf & _
"Error No: " & Err.Number & vbCrLf & _
"Description: " & Err.Description, vbCritical, "Architecture Error"
Resume CleanUp
End Sub4. 実務における「設計の落とし穴」と回避策
アーキテクトとして、君に伝えておくべき注意点が2つある。
リンクテーブル（SQL Server等）との連携
Accessをフロントエンド、SQL Serverをバックエンドとする環境では、`Seek` は強力な武器になる。しかし、リンクテーブルのインデックスが正しく同期されていない（またはAccess側でインデックスとして認識されていない）場合、`Seek` は機能しない。リンクテーブルを更新した際は、必ずインデックスの整合性を確認せよ。
トランザクションとの組み合わせ
検索したレコードを即座に更新する場合、`Seek` で見つけた直後に `BeginTrans` を行い、更新後に `CommitTrans` する設計にせよ。
`Seek` 自体は読み取り専用（`dbReadOnly`）で開くのがパフォーマンス上ベストだが、更新が必要な場合は `dbOptimistic` で開き、検索から更新までの「時間的隙間」を最小限にする設計が求められる。
結論：道具を使い分けるのがプロだ
`FindFirst` は、条件が複雑でインデックスが使えない場合の「最終手段」だ。
`Seek` は、パフォーマンスが要求される大量データ処理における「標準装備」である。
「動けばいい」という思考を捨てろ。
「データが100万件になっても、このコードは今の速度を維持できるか？」
常にこの問いを自分に投げかけ続けろ。それが、一流のエンジニアと、単なる作業者の境界線だ。
以上。
