DAOからADOへ：既存システムを壊さずに「進化」させるためのリファクタリング戦略
こんにちは。業務自動化の世界へようこそ。
マクロの記録から一歩踏み出し、VBAという「魔法の杖」を手に取ろうとしているあなた。素晴らしい決断です。
今日は、少しだけ踏み込んだ、しかしエンジニアとして避けては通れない「データの扱い方（アーキテクチャ）」の話をしましょう。
もしあなたが、長年動いているAccessシステムを引き継いだり、あるいは「もっと大規模なデータベース（SQL Serverなど）に繋げたい」と考えているなら、必ず「DAO」と「ADO」という言葉に出会うはずです。
「どっちを使えばいいの？」「書き方が違うみたいだけど、どうやって書き換えたらいいの？」
そんな不安を抱えているあなたのために、今日は「既存の仕組みを壊さずに、スマートにADOへ移行するための設計図」を伝授します。ここをクリアすれば、あなたのVBAスキルは「単なるツール作成者」から「システム設計者」へと進化しますよ。
1. そもそも、DAOとADOは何が違うのか？
まず、敵（違い）を知ることから始めましょう。
例え話で説明しますね。
- DAO (Data Access Objects) は、「Access専用の、超優秀な専属シェフ」です。
Accessというキッチン（環境）の中での動きに特化しており、Access内のテーブルを操作するのがめちゃくちゃ速いです。しかし、キッチンの外（他のデータベース）にある食材を扱うのは少し苦手です。
- ADO (ActiveX Data Objects) は、「世界中の食材を扱える、超一流の物流マネージャー」です。
Accessの中だけでなく、SQL Server、Oracle、あるいはWeb上のデータなど、どこにデータがあっても、共通の作法でスマートに運び出してくれます。
なぜ今、ADOへの移行を検討するのか？
今のシステムがAccessだけで完結しているなら、無理にADOに変える必要はありません。DAOは非常に高速だからです。
しかし、将来的に「データをSQL Serverに移したい」「他のアプリケーションからもデータにアクセスさせたい」という要望が出た瞬間、DAOの限界がやってきます。その時に「ADO」という共通言語を知っていれば、システムを根本から作り直すことなく、スムーズに拡張できるのです。
2. 移行前の「判断基準」チェックリスト
いきなりコードを書き換えるのは、設計図なしにビルを建てるようなものです。まずは以下のチェックリストを確認してください。
- [ ] データの所在はどこか？
- Access内のみ $\rightarrow$ DAOのままでもOK（無理に移行しない勇気も大切です）。
- 外部DB（SQL Server等）への移行予定あり $\rightarrow$ ADOへの移行を推奨。
- [ ] レコードセットの操作内容は？
- 単なるデータの読み込み $\rightarrow$ ADOが非常に扱いやすい。
- 複雑なローカルインデックス操作 $\rightarrow$ DAOの方が得意な場合がある。
- [ ] トランザクション（一括処理）が必要か？
- 複数のテーブルを同時に更新し、失敗したら全部戻したい $\rightarrow$ ADOの接続管理（Connectionオブジェクト）をマスターする必要があります。
3. 実践リファクタリング：DAOからADOへの書き換え
では、具体的なコードを見ていきましょう。
「DAOで書いていたコード」を、どのように「ADO」へ昇華させるか。そのエッセンスを詰め込みました。
【Before】従来のDAOによる書き方
Access専用の書き方です。`CurrentDb` という魔法の言葉で、現在のデータベースに直接アクセスします。
' --- DAOによる標準的な書き方 ---
Sub Sample_DAO()
Dim db As DAO.Database
Dim rs As DAO.Recordset
' 現在のデータベースを取得
Set db = CurrentDb
' テーブルを開く
Set rs = db.OpenRecordset("T_社員マスタ", dbOpenDynaset)
' データの読み取り
If Not rs.EOF Then
Debug.Print rs!社員名
End If
' 後片付け（これを忘れるとメモリを食いつぶします！）
rs.Close
Set rs = Nothing
Set db = Nothing
End Sub【After】洗練されたADOによる書き方
ADOでは、「Connection（接続）」と「Recordset（データ集合）」を分けて考えます。これがプロの作法です。
' --- ADOによるリファクタリング後の書き方 ---
' ※参照設定で "Microsoft ActiveX Data Objects x.x Library" にチェックを入れてください
Sub Sample_ADO()
Dim conn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim strSQL As String
' 1. Connectionオブジェクトの生成
Set conn = New ADODB.Connection
' 2. 接続文字列の設定（ここを変えるだけでSQL Server等にも繋がる！）
' 現在のAccessに繋ぐ場合の例
conn.Open "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & CurrentProject.FullName & ";"
' 3. Recordsetオブジェクトの生成
Set rs = New ADODB.Recordset
strSQL = "SELECT 社員名 FROM T_社員マスタ"
' 4. レコードセットを開く
' CursorType: データの動かし方（adOpenStaticは静的な読み取りに強い）
' LockType: データのロック（adLockOptimisticは変更を許可する設定）
rs.Open strSQL, conn, adOpenStatic, adLockOptimistic
' 5. データの読み取り
If Not rs.EOF Then
Debug.Print rs.Fields("社員名").Value
End If
' 6. 後片付け（ライフサイクル管理の徹底）
' 接続を閉じる前に、レコードセットを先に閉じるのが鉄則です
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
If conn.State = adStateOpen Then conn.Close
Set conn = Nothing
Debug.Print "移行成功：ADOによるデータアクセスが完了しました。"
End Sub4. 陥りやすいエラーと、エンジニアの「守り」の知恵
移行作業中、あなたは必ず壁にぶつかります。特に以下の2点は、ベテランでもうっかりミスをするポイントです。
① 「CursorType（カーソルタイプ）」の罠
DAOでは意識しなくても動いていたものが、ADOでは「データの動かし方」を明示しないとエラーになることがあります。
- `adOpenForwardOnly`: 前に進むだけ。一番速いけれど、戻れない。
- `adOpenStatic`: 自由に動ける。読み取り専用に近い用途に最適。
- `adOpenDynamic`: リアルタイムの変更も反映されるが、重い。
アドバイス: 基本は `adOpenStatic` を選んでおけば、大抵の業務アプリケーションでは安全に動作しますよ。
② トランザクション処理の重要性
「データを更新したけれど、途中でエラーが起きて半分だけ書き換わってしまった！」
これは業務システムにおいて致命的な事故です。ADOでは `conn.BeginTrans` を使って、「全部成功するか、全部なかったことにするか」を制御できます。
On Error GoTo ErrorHandler
conn.BeginTrans ' トランザクション開始！
' --- ここに更新処理を書く ---
rs.Update
conn.CommitTrans ' 全て成功したら確定！
Exit Sub
ErrorHandler:
conn.RollbackTrans ' エラーが起きたら、すべてを「開始前」の状態に巻き戻す！
MsgBox "エラーが発生したため、処理をロールバックしました。"
End Sub最後に：一歩ずつ、着実に
いかがでしたか？
DAOからADOへの移行は、単なる「書き換え」ではありません。それは、あなたのシステムに「拡張性」と「堅牢性」という翼を与える作業です。
いきなり全てのコードを書き換える必要はありません。
「新しい機能を作る時だけ、ADOを使ってみる」
「特定の複雑なクエリだけ、ADOに切り替えてみる」
そんなスモールステップから始めてみてください。
一つ一つのエラーを乗り越えるたびに、あなたは確実に、世界を変える自動化エンジニアへと近づいています。
応援していますよ。さあ、コードを書き始めましょう！
