【テクニカル・上級編】ADOのFieldsコレクションを動的に操作する：汎用的なデータインポートツールの作り方 – Access VBA解析バイブル

Access VBA

2026.10.31

抽象化の極致：ADO Fieldsコレクションによる動的データインジェクション・エンジンの構築

抽象化の極致：ADO Fieldsコレクションによる動的データインジェクション・エンジンの構築

業務システムにおける「データ移行」や「外部ファイルからのインポート」は、往々にして泥臭いコードの集積体になりがちだ。多くの開発者は、テーブルのフィールド名が分かっていることを前提に、`rs.Fields(“UserID”).Value = …` といったハードコーディングを繰り返す。

しかし、それは設計思想の敗北である。

真のアーキテクトが構築すべきは、スキーマ（構造）に依存しない「データパイプライン」だ。ソースとなるデータの構造がどうあれ、ターゲットとなるテーブルの定義に基づいて、動的にマッピングを解決し、アトミック（不可分）にデータを流し込む。

本稿では、ADO（ActiveX Data Objects）の `Fields` コレクションを極限まで活用し、型定義と構造の変更に耐えうる「汎用データインポート・エンジン」の設計と実装について詳述する。

1. アーキテクチャの分水嶺：DAOとADOの使い分け

Access開発において、DAO（Data Access Objects）とADOの選択は、単なる好みの問題ではない。

DAO は、ACE/Jetエンジンに対して最適化された、いわば「ネイティブ言語」である。ローカルのAccessテーブルに対する高速な操作、特にリレーションシップを維持した操作においては、DAOのパフォーマンスに分がある。
ADO は、OLE DBを介した「抽象化レイヤー」である。SQL Server、Oracle、あるいはExcelやCSVといった、異なるデータソースを同一のインターフェースで扱うための武器だ。

汎用インポートツールにおいてADOを選択する理由は、「ソースとターゲットの抽象化」にある。ソースがExcelであり、ターゲットがAccessであったとしても、ADOの `Recordset` オブジェクトであれば、どちらも「Fieldsコレクションを持つオブジェクト」として等価に扱えるからだ。

2. 動的マッピングのロジック：Fieldsコレクションの掌握

汎用的なインポートを実現するためには、ソースとターゲットのフィールド名を動的に照合し、インデックスではなく「名前」に基づいて値を転送するロジックが必要となる。

ここで重要になるのが、`Fields` コレクションの反復処理だ。特定のフィールド名を指定するのではなく、ターゲット側のフィールドをループさせ、その名前がソース側に存在するかを判定する。これにより、ソース側に余計な列（メタデータ等）が含まれていても、ターゲットの構造を破壊することなく安全にインポートが可能になる。

3. 実装：高信頼性インポート・エンジン

以下に、実戦投入レベルの汎用インポートプロシージャを示す。単なるインポートではない。「トランザクション制御」「エラーハンドリング」「メモリ解放」の三原則を遵守した設計である。

Option Explicit

''' <summary>
''' 汎用データインポートエンジン
''' ソースRecordsetからターゲットRecordsetへ、フィールド名に基づきデータを転送する。
''' </summary>
''' <param name="srcRS">ソースとなるRecordset (Excel, CSV, SQL Server等)</param>
''' <param name="tgtRS">書き込み先となるRecordset (Accessテーブル等)</param>
Public Sub ExecuteGenericImport(ByRef srcRS As ADODB.Recordset, ByRef tgtRS As ADODB.Recordset)
    Dim i As Long
    Dim fldName As String
    Dim targetConn As ADODB.Connection
    
    ' 1. 事前検証: Recordsetの状態確認
    If srcRS Is Nothing Or tgtRS Is Nothing Then
        Err.Raise vbObjectError + 513, "ExecuteGenericImport", "RecordsetオブジェクトがNothingです。"
    End If
    
    If srcRS.EOF And srcRS.BOF Then
        Debug.Print "Source Recordset is empty. Skipping."
        Exit Sub
    End If

    ' 2. トランザクションの開始
    ' ターゲットの接続オブジェクトを取得し、アトミックな処理を保証する
    Set targetConn = tgtRS.ActiveConnection
    targetConn.BeginTrans
    
    On Error GoTo ErrorHandler

    ' 3. データ転送ループ
    ' ソースのレコードを走査
    Do Until srcRS.EOF
        tgtRS.AddNew
        
        ' ターゲット側のフィールドを基準にループ（スキーマ依存の排除）
        For i = 0 To tgtRS.Fields.Count - 1
            fldName = tgtRS.Fields(i).Name
            
            ' ソース側に同名のフィールドが存在するかを動的に判定
            ' ※パフォーマンスを考慮し、大規模データではソース側のフィールド名をDictionaryにキャッシュすることを推奨
            On Error Resume Next
            Dim srcValue As Variant
            srcValue = srcRS.Fields(fldName).Value
            
            If Err.Number = 0 Then
                ' 型の不一致を避けるため、Null判定と代入を行う
                If IsNull(srcValue) Then
                    tgtRS.Fields(i).Value = Null
                Else
                    tgtRS.Fields(i).Value = srcValue
                End If
            Else
                ' フィールド名が一致しない場合はスキップ（エラーをクリアして次へ）
                Err.Clear
            End If
            On Error GoTo ErrorHandler
        Next i
        
        tgtRS.Update
        srcRS.MoveNext
    Loop

    ' 4. コミット
    targetConn.CommitTrans
    Debug.Print "Import completed successfully."

CleanUp:
    ' 5. オブジェクトの明示的解放 (メモリリーク防止)
    ' VBAのガベージコレクションに頼らず、ライフサイクルを制御する
    Set targetConn = Nothing
    Exit Sub

ErrorHandler:
    ' 6. ロールバック
    ' 途中でエラーが発生した場合、データの整合性を守るために全件破棄する
    If Not targetConn Is Nothing Then
        targetConn.RollbackTrans
    End If
    
    MsgBox "Critical Error during import: " & Err.Description, vbCritical, "Transaction Rolled Back"
    Resume CleanUp
End Sub

4. 極限の知見：プロフェッショナルが留意すべき細部

このコードを実運用に載せる際、シニアエンジニアが直視すべき「重み」がいくつかある。

4.1 メモリ管理とオブジェクトのライフサイクル

VBAにおいて、`Recordset` や `Connection` オブジェクトは、スコープを抜けただけではメモリ上に残り続けることが多々ある。特にループ内で大量のオブジェクトを生成する場合、メモリの断片化（Fragmentation）を引き起こし、システムの不安定化を招く。必ず `Set obj = Nothing` による明示的な解放を行うこと。これは「作法」ではなく「生存戦略」だ。

4.2 トランザクションの重み

`BeginTrans` と `CommitTrans` は強力な武器だが、諸刃の剣だ。
大量のデータを一度にトランザクションに詰め込みすぎると、ログファイル（LDF等）の肥大化や、データベースのロック競合を引き起こす。数万件規模のインポートを行う場合は、例えば「1,000件ごとにコミットする」といったバッチ処理の実装を検討せよ。

4.3 データ型の不一致（Type Mismatch）への対処

上記のコードでは `On Error Resume Next` を用いてフィールドの有無を判定しているが、実務では「名前は一致するが型が異なる」という事態が頻発する。

ソースが `String` で、ターゲットが `Integer`
ソースが `Double` で、ターゲットが `Decimal`

これらを解決するには、`tgtRS.Fields(i).Type` を参照し、`CInt`, `CDbl`, `CStr` などの明示的型変換関数を動的に呼び出す、あるいは `Variant` を介した緩やかな型変換を設計に組み込む必要がある。

結言

汎用的なツールを作るということは、単に「動くもの」を作ることではない。「変化」を許容できる構造を作ることだ。

`Fields` コレクションを使いこなし、スキーマの変更をロジックから切り離したとき、君の書いたコードは単なるスクリプトから、堅牢な「システム」へと昇華する。レガシーな環境であっても、このアーキテクチャの原則は変わらない。

常に、オブジェクトのライフサイクルと、データの原子性に目を光らせておけ。