はじめに：なぜ「空文字」はAccessの癌なのか
業務システムの現場において、Access（ACEエンジン）ほど「悪気のない仕様のゆがみ」に苦しめられるRDBMSはない。その最たるものが、「長さ0の文字列（空文字 `””`）」と「NULL（`Null`）」の混同だ。
画面フォームからの入力漏れや、Excelからのいい加減なインポートにより、テキスト型フィールドには `””` が蔓延し、数値型や日付型への変換エラー、集計クエリのカウント漏れ、そして何よりSQLの結合条件崩壊を引き起こす。
「クエリで `NZ(FieldName, ”)` と書けばいいじゃないか」——それは対症療法に過ぎない。データナレッジの根本的な衛生管理を怠ったエンジニアが直面するのは、数ヶ月後に爆発する「原因不明の集計ズレ」という名の技術負債だ。
今回は、Accessのメタデータ（`TableDef` と `Field`）を直接叩き、テーブル構造を完全自律走査して、全テキストフィールドの空文字を問答無用で `Null` へ置換するプロダクション・クリーンアップツールの全貌を伝授する。
—
1. 堅牢な設計思想：なぜ全件UPDATEではダメなのか？
素人プログラマブルな発想だと、全テーブルに対して以下のようなSQLを流し込みたくなる。
— 愚かなアプローチ
UPDATE T_Sample SET Field1 = Null WHERE Field1 = “”;
しかし、これを数十のフィールドを持つ巨大テーブル群に対して手動、あるいはハードコーディングされたSQLで実行するのは、保守性の観点から自殺行為だ。テーブル仕様変更（フィールドの追加・削除）のたびにVBAの修正が必要になるからだ。
プロフェッショナルのアプローチ：メタデータ駆動型動的SQL
今回のツールは、以下のステップで完全に自動化する。
1. `CurrentDb.TableDefs` を走査し、システムテーブル（`MSys` で始まるもの）やリンクテーブルを除外する。
2. 各テーブルの `Fields` コレクションを舐め、データ型が「テキスト型（`dbText` / `dbMemo`）」であるものだけを抽出する。
3. 該当フィールドに対し、「空文字（`””`）」のみを「NULL」に置換するトランザクション配下のUPDATEクエリを動的に生成・実行する。
これにより、テーブル構造がどう変わろうとも、スクリプトは常に最新のスキーマに完全適応する。
—
2. 【コピペ即実戦】極限まで最適化されたクリーンアップコード
以下のモジュールを、Accessの標準モジュールにそのまま貼り付けてほしい。エラーハンドリング、トランザクション、イミディエイトウィンドウへの詳細なログ出力まで完備した、現場でそのまま使える実用コードだ。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 処理名: データベース全テーブル空文字クリーンアップツール
‘ 概要: 全ローカルテーブルのテキスト型フィールドを走査し、”” を Null に置換する
‘ 備考: トランザクション制御により、予期せぬ中断時のデータ破損を防止
‘ =========================================================================
Public Sub ExecuteDataCleanup()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim sql As String
Dim updateCount As Long
Dim startTime As Double
startTime = Timer
Set db = CurrentDb()
‘ トランザクション開始（整合性の担保）
db.BeginTrans
On Error GoTo ErrorHandler
Debug.Print “==================================================”
Debug.Print ” データクリーンアップ処理を開始します…”
Debug.Print “==================================================”
updateCount = 0
‘ テーブル定義を走査
For Each tdf In db.TableDefs
‘ システムテーブルおよびリンクテーブルはスキップ
If (tdf.Attributes & dbSystemObject) = 0 And (tdf.Attributes & dbAttachedTable) = 0 And (tdf.Attributes & dbAttachedODBC) = 0 Then
‘ フィールド定義を走査
For Each fld In tdf.Fields
‘ 対象はテキスト型 (dbText) およびメモ型 (dbMemo) のみ
If fld.Type = dbText Or fld.Type = dbMemo Then
‘ プレースホルダーを用いた動的SQLの構築
‘ ※識別子（テーブル名・フィールド名）は角括弧でエスケープし、予約語やスペース衝突を防御
sql = “UPDATE [” & tdf.Name & “]” & vbCrLf & _
“SET [” & fld.Name & “] = Null” & vbCrLf & _
“WHERE [” & fld.Name & “] = “”””;”
‘ 実行
db.Execute sql, dbFailOnError
‘ 変更があったレコード数を加算
If db.RecordsAffected > 0 Then
Debug.Print ” [修正] テーブル: ” & tdf.Name & ” | フィールド: ” & fld.Name & ” (” & db.RecordsAffected & “件)”
updateCount = updateCount + db.RecordsAffected
End If
End If
Next fld
End If
Next tdf
‘ コミット
db.CommitTrans
Debug.Print “==================================================”
Debug.Print ” 処理完了: 累計 ” & updateCount & ” 箇所の空文字をNullに置換しました。”
Debug.Print ” 実行時間: ” & Format(Timer – startTime, “0.00秒”)
Debug.Print “==================================================”
Exit Sub
ErrorHandler:
‘ 異常発生時はロールバック
db.Rollback
MsgBox “データクリーンアップ中に致命的なエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical, “処理中断”
Debug.Print “【ERROR】トランザクションをロールバックしました。 Err: ” & Err.Description
End Sub
—
3. チーフアーキテクトが教える実装上の急所（罠と対策）
このコードをただ動かすだけなら誰でもできる。プロたる者、以下の「裏の仕様」を抑えておかなければならない。
① なぜ `dbFailOnError` を指定するのか？
DAOの `db.Execute` メソッドでこれを省くのは素人の証だ。指定しない場合、途中でインデックス違反や型不整合などのサイレントエラーが発生しても処理が続行され、データベースが中途半端な状態で破壊される。エラー時には確実にロールバックさせるための必須オプションである。
② テーブル属性（`Attributes`）のフィルタリング
Accessには、フォーム用のシステムテーブルや、別DBへのリンクテーブルが無数に存在する。これらを判定せずに `UPDATE` をかけようとすると、「更新可能なクエリメンバではありません」というエラーで沈没する。
`dbSystemObject` や `dbAttachedTable` のビット演算による除外処理は、実務用スクリプトの絶対条件だ。
③ インデックスとパフォーマンスのトレードオフ
空文字から `Null` への一括置換は、対象フィールドにインデックスが貼られている場合、一時的にインデックスの再構築が発生するため若干のオーバーヘッドがある。
しかし、大規模データ（数十万レコード以上）を扱う場合は、あらかじめインデックスを一時削除するのではなく、トランザクションを張ることでディスクI/Oのフラッシュを最適化し、一括処理する方が安全かつ高速である。
—
おわりに：メンテナンスフリーの基盤へ
「データが汚いから動かない」と嘆くフェーズは、今日で終わりにしよう。
今回紹介したメタデータ駆動型のクリーンアップツールを、例えばアプリケーション起動時のイニシャライザ（自動実行マクロやメインフォームの `Open` イベント）に組み込む、あるいは週次バッチとして組み込むことで、「人間の手が入ることで必ず汚染される」というRDBMSの宿命を完全にハックできる。
コードをコピペして終わりにするな。その背後にある「メタデータを支配者が如く自在に操る」というアーキテクチャの思想を、あなたの引き出しに深く刻み込んでほしい。
