【Access VBA】DoCmd.TransferSpreadsheetの暗黒面：インポートエラーテーブルを完全自動監視・浄化するアーキテクチャ
こんにちは。チーフアーキテクトの私だ。
現場で日々、Accessの巨大なレガシーシステムや、野良マクロと格闘している開発者なら一度は絶望したことがあるはずだ。
「外部のエンドユーザーが勝手にヘッダー行を変更しやがった」
「数値フィールドに文字列が混入し、インポートが沈黙した」
`DoCmd.TransferSpreadsheet` は、ExcelデータをAccessに取り込むための最も手軽なメソッドだ。しかし、実務においてこのメソッドを「エラーハンドリングなしで」ベタ書きすることは、夜の高速道路を無灯火で逆走するようなものだ。
今回は、インポート失敗時にAccessが裏でこっそり生成する「インポートエラーテーブル（ImportErrors）」の正体を暴き、それをVBAで完全自動監視・例外処理・ログ出力するプロダクションコードを授けよう。
—
1. なぜ「インポートエラー」は見落とされるのか？
`DoCmd.TransferSpreadsheet` を実行した際、データ型の不一致やバリデーション違反が発生すると、Accessは容赦なくデータを切り捨てるか、処理をスキップする。そして、バックグラウンドでしれっと 「[テーブル名] エラー」 という名前のテーブルを生成する。
アマチュアのコード（最悪のパターン）
‘ ❌ やってはいけない実装
Sub BadImport()
‘ エラーが起きようがテーブルが生成されようが、VBA側は「成功した」と勘違いする
DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12Xml, “T_Master”, “C:\Data\input.xlsx”, True
MsgBox “インポート完了しました！”, vbInformation
End Sub
このコードの何がクソなのか？
ユーザーは「完了した」と信じ込んで業務を進めるが、肝心のデータはごっそり抜け落ちている。これがデータ不整合グエスカ・シンドロームの正体だ。
—
2. 堅牢なインポート・アーキテクチャの設計思想
プロのエンジニアリングにおいて、例外は「発生するもの」として設計に組み込む必要がある。今回の自動監視メカニズムの要件は以下の通りだ。
1. 事前クリーンアップ: 処理開始前に、前回の残骸であるエラーテーブルを確実に抹殺する。
2. 実行と検知: インポート実行後、システムカタログ（`MSysObjects` 等）を走査してエラーテーブルが生成されたかを機械的に判定する。
3. 構造化ログ出力: エラー内容（行番号、フィールド名、エラー理由）を抽出し、ユーザーが直感的に修正できるログテーブルへ昇華させる。
4. トランザクション的思考: 致命的な不整合がある場合は、ロールバックまたは処理中断のシグナルを上げる。
—
3. 【実装】インポートエラー完全自動監視・浄化エンジン
以下のコードを、あなたのプロジェクトの標準モジュールにそのまま実装してほしい。実務の現場でそのまま使える、極限まで最適化されたプロダクションコードだ。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 模範的なスプレッドシート・インポート・エンジン
‘ =========================================================================
Public Sub ExecuteRobustImport()
Dim strFilePath As String
Dim strTargetTable As String
Dim strErrorTableName As String
strFilePath = “C:\Data\SalesData.xlsx”
strTargetTable = “T_Sales_Actual”
strErrorTableName = strTargetTable & ” エラー” ‘ Accessが自動生成するエラーテーブル名
On Error GoTo ErrorHandler
‘ —————————————————————–
‘ Step 1: 過去の亡霊（前回生成されたエラーテーブル）の確実な抹殺
‘ —————————————————————–
Call DropTableIfExists(strErrorTableName)
‘ —————————————————————–
‘ Step 2: データのインポート実行
‘ —————————————————————–
‘ ※ここでデータ型の不一致等があると、Accessは裏で「strErrorTableName」を作る
DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12Xml, _
strTargetTable, strFilePath, True
‘ —————————————————————–
‘ Step 3: エラーテーブルの存在確認（自動監視）
‘ —————————————————————–
If CheckTableExists(strErrorTableName) Then
‘ エラー検知！ 例外処理ルーチンへジャンプ
GoTo ImportExceptionDetected
End If
‘ —————————————————————–
‘ Step 4: 正常終了
‘ —————————————————————–
MsgBox “インポートが正常に完了しました。”, vbInformation, “処理成功”
Exit Sub
ImportExceptionDetected:
‘ —————————————————————–
‘ Step 5: 例外の自動解析とユーザーフレンドリーな通知
‘ —————————————————————–
Call HandleImportErrors(strErrorTableName)
Exit Sub
ErrorHandler:
‘ VBA自体のランタイムエラー（ファイルが存在しない、排他制御がかかっている等）
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “システムエラー”
End Sub
‘ =========================================================================
‘ 補助関数群：アーキテクチャの堅牢性を支えるパーツ
‘ =========================================================================
‘ テーブルの存在確認（CurrentDbのTableDefsコレクションを使用）
Private Function CheckTableExists(ByVal tableName As String) As Boolean
Dim tdf As TableDef
Dim exists As Boolean
exists = False
For Each tdf In CurrentDb.TableDefs
If tdf.Name = tableName Then
exists = True
Exit For
End If
Next tdf
CheckTableExists = exists
End Function
‘ テーブルの安全な削除（存在する場合のみドロップ）
Private Function DropTableIfExists(ByVal tableName As String) As Boolean
On Error GoTo DropError
If CheckTableExists(tableName) Then
DoCmd.SetWarnings False
DoCmd.RunSQL “DROP TABLE [” & tableName & “];”
DoCmd.SetWarnings True
End If
DropTableIfExists = True
Exit Function
DropError:
DoCmd.SetWarnings True
DropTableIfExists = False
End Function
‘ エラーテーブルの内容を解析し、実用的なログとして整形するプロシージャ
Private Function HandleImportErrors(ByVal errorTableName As String) As दस्तावेजों
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strMsg As String
Dim errorCount As Long
Set db = CurrentDb
Set rs = db.OpenRecordset(“SELECT FROM [” & errorTableName & “]”, dbOpenSnapshot)
‘ レコード数（エラー件数）の取得
If Not (rs.BOF And rs.EOF) Then
rs.MoveLast
errorCount = rs.RecordCount
Else
errorCount = 0
End If
strMsg = “【警告】Excelデータのインポート中に ” & errorCount & ” 件のエラーが発生しました。” & vbCrLf & _
“データ型が違う、または許容文字数を超えている可能性があります。” & vbCrLf & vbCrLf & _
“生成されたエラーテーブル [” & errorTableName & “] を確認し、データを修正してください。”
‘ 必要であればここでエラーテーブルの内容を専用のログテーブル（T_SystemLog等）に転記する処理を実装する
rs.Close
Set rs = Nothing
Set db = Nothing
‘ ユーザーへ警告ダイアログを表示
MsgBox strMsg, vbExclamation, “インポート例外発生”
End Function
—
4. チーフアーキテクトからの実践的アドバイス
1. 「`DoCmd.SetWarnings False`」の多用に溺れるな
エラーメッセージを出さないために思考停止で警告を消す開発者がいるが、これは悪手だ。エラーテーブルの生成自体は防げないため、今回のように「検知してハンドリングする」ロジックこそが正解である。
2. エラーテーブルのスキーマ構造を理解せよ
Accessが自動生成するエラーテーブルには、通常 `転送エラー`、`行`、`フィールド名`、`テキスト` などのフィールドが格納される。大規模運用では、これらを監視用ログテーブルに自動吸い上げ、誰がいつどんな不備のあるファイルをアップロードしたかまでトレーサビリティを確保すると、システム評価が爆上がりする。
総括
システムのエレガンスは、「正常系」の美しさではなく、「異常系」に対する気配りの深さで決まる。
今回の自動監視・浄化アーキテクチャを導入すれば、「なんかデータが足りないんだけど！」というエンドユーザーからの不毛な問い合わせをゼロにできる。
プロフェッショナルとして、コードの隅々にまで「守りの美学」を宿してほしい。
