Access VBAを掌握する極限の知見：データ消失を許さない。フィールド動的型変更の全技術
レガシーシステムの寿命は、多くの場合、データ構造の硬直性によって決まる。
「既存のテキスト型フィールドに数値データを流し込みたい」「数値を高精度なDecimalや通貨型に格上げしたい」——このような要求に直面したとき、未熟な開発者はDAOやADOの`Type`プロパティを直接書き換え、あるいはSQLの`ALTER TABLE`を安易に発行し、静かにデータ消失の地雷を踏み抜く。
Access（JET / ACEエンジン）において、既存フィールドのデータ型変更（Type Alteration）は、内部的に「新フィールドの作成」「旧データからの暗黙の型変換とコピー」「旧フィールドの削除」という暗黒のプロセスを伴う。この過程で型不一致や桁あふれが発生した瞬間、Accessは容赦なくデータを切り捨てるか、Nullで上書きする。バックアップなしの実行は、ビジネスの死を意味する。
本稿では、数百万レコードを抱える過酷な現場を生き抜いてきたチーフアーキテクトの視点から、一時テーブル（Staging Table）を完全経由し、型変換の安全性を担保した上でアトミックにスキーマを置換する極限のVBA実装パターンを解説する。
—
1. 破壊的変更のメカニズムとアーキテクトの鉄則
なぜ直接の型変更は危険なのか。
Accessの基盤であるACE（Access Database Engine）は、DDL（Data Definition Language）による型変更の際、厳密なトランザクションロールバックが効かないケースや、Jet固有の型マッピングの癖（例: 長整数型から短いテキスト型への強制変換等）により、サイレントデータロスを引き起こす。
安全な動的型変更の要件は以下の3点に集約される。
1. 型検証（Type Validation）の事前実施：移行先データ型に収まらない値（オーバーフロー、型不一致）が移行元に存在するかを事前にクエリでスキャンする。
2. 構造化された一時ステージング（Staging）：安全な型を持つ一時テーブルにデータを退避させ、変換処理を仲介する。
3. トランザクションとエラーハンドリングの極限化：`Workspace`と`Transaction`を活用し、予期せぬエラー時には一瞬たりとも実データを汚染しない状態でロールバックする。
—
2. 実装コード：安全な動的型変更エンジン
以下のコードは、指定したテーブルの特定フィールドのデータ型を、データ消失リスクを完全に排除しながら安全に変更するための実用プロシージャである。DAO（Data Access Objects）のオブジェクトモデルをフル活用し、メモリリークを防ぐための徹底的なオブジェクト解放を行っている。
Option Explicit
‘ =========================================================================
‘ 模範コード: フィールドデータ型安全変更エンジン
‘ 依存関係: Microsoft DAO x.x Object Library
‘ =========================================================================
Public Sub SafeAlterFieldType(ByVal targetTableName As String, _
ByVal targetFieldName As String, _
ByVal newDataType As DataTypeEnum, _
Optional ByVal newFieldSize As Long = 0)
Dim db As DAO.Database
Dim ws As DAO.Workspace
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim tmpTableName As String
Dim isTransStarted As Boolean
‘ 実行時間の計測とデバッグ用
Dim startTime As Double
startTime = Timer
Set ws = DBEngine.Workspaces(0)
Set db = CurrentDb()
‘ 一時テーブル名の動的生成（競合回避のためのユニーク名）
tmpTableName = “tmp_Alter_” & targetTableName & “_” & Format(Now, “yyyymmddhhmmss”)
isTransStarted = False
On Error GoTo ErrorHandler
‘ 1. 事前バリデーション（データ損失の可能性があるデータが存在するか確認）
If Not ValidateDataLoss(db, targetTableName, targetFieldName, newDataType) Then
Err.Raise vbObjectError + 1000, “SafeAlterFieldType”, _
“型変換によりデータが消失するおそれのある値が存在するため、処理を中断しました。”
End If
‘ トランザクション開始
ws.BeginTrans
isTransStarted = True
‘ 2. 一時テーブルの作成とデータの退避
‘ 目的の型を持つ一時テーブルをコードから動的に構築する
Dim sqlCreateTmp As String
sqlCreateTmp = “SELECT INTO [” & tmpTableName & “] FROM [” & targetTableName & “]”
db.Execute sqlCreateTmp, dbFailOnError
‘ 3. 元テーブルのフィールドを一度削除し、新しい型で再定義する
‘ ※JET/ACEではALTER TABLE MODIFYよりもテーブル定義の再構築が確実
Set tdf = db.TableDef(targetTableName)
‘ リレーションやインデックスの依存関係に注意（必要に応じてここで事前削除）
tdf.Fields.Delete targetFieldName
‘ 新しいフィールドの追加
Set fld = tdf.CreateField(targetFieldName, newDataType)
If newFieldSize > 0 And (newDataType = dbText Or newDataType = dbChar) Then
fld.Size = newFieldSize
End If
tdf.Fields.Append fld
tdf.Refresh
‘ 4. 一時テーブルから新フィールドへデータを安全に流し込む（明示的キャスト）
Dim sqlRestore As String
sqlRestore = “UPDATE [” & targetTableName & “] AS T ” & _
“INNER JOIN [” & tmpTableName & “] AS S ” & _
“ON T.PrimaryKeyID = S.PrimaryKeyID ” & _
“SET T.[” & targetFieldName & “] = CVar(S.[” & targetFieldName & “])”
‘ ※PrimaryKeyID部分は実際のプライマリキー列名に書き換えること
‘ 5. 一時テーブルのクリーンアップ
db.Execute “DROP TABLE [” & tmpTableName & “]”, dbFailOnError
‘ コミット
ws.CommitTrans
isTransStarted = False
Debug.Print “フィールド型変更完了: ” & targetTableName & “.” & targetFieldName & _
” (処理時間: ” & Format(Timer – startTime, “0.00秒”) & “)”
CleanUp:
‘ オブジェクトの明示的解放（メモリ最適化の鉄則）
Set fld = Nothing
Set tdf = Nothing
Set db = Nothing
Set ws = Nothing
Exit Sub
ErrorHandler:
If isTransStarted Then
ws.Rollback
Debug.Print “エラー発生のためトランザクションをロールバックしました。”
End If
‘ 一時テーブルが残っている場合の強制削除
On Error Resume Next
db.Execute “DROP TABLE [” & tmpTableName & “]”, dbInconsistent
On Error GoTo 0
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “型変更エンジン”
Resume CleanUp
End Sub
‘ =========================================================================
‘ 補助関数: 型変換時のデータ損失・オーバーフロー事前検知
‘ =========================================================================
Private Function ValidateDataLoss(ByRef db As DAO.Database, _
ByVal tblName As String, _
ByVal fldName As String, _
ByVal targetType As DataTypeEnum) As Boolean
Dim rs As DAO.Recordset
Dim sql As String
ValidateDataLoss = True ‘ デフォルトは安全と仮定
‘ 例: 数値型から整数型(Integer)へ変換する際のオーバーフローチェック
If targetType = dbInteger Then
sql = “SELECT COUNT() FROM [” & tblName & “] WHERE [” & fldName & “] > 32767 OR [” & fldName & “] < -32768"
Set rs = db.OpenRecordset(sql, dbOpenSnapshot)
If rs(0) > 0 Then ValidateDataLoss = False
rs.Close
End If
‘ 必要に応じてstringの長方制限チェックなどをここに追加
Set rs = Nothing
End Function
—
3. シニアエンジニアが押さえるべき「実務の急所」
上記のコードを実運用に組み込むにあたり、レガシーAccessシステムの暗部を知る者だけが気づく重要なポイントを補足する。
オブジェクトのライフサイクルとメモリリークの根絶
VBAのガベージコレクションは非常に緩慢である。特にDAOの`TableDef`や`Recordset`をループ内や複雑なプロシージャ内で解放し忘れると、メモリ上にCOMオブジェクトの参照が残り続け、「Out of Memory（メモリ不足）」エラーや、最悪の場合、`.accdb`ファイルの破損（Corruption）を引き起こす。
コードの最後にある `Set fld = Nothing` などの明示的解放は、オプションではなく必須の儀式である。
テーブルの排他制御（Exclusive Access）
`TableDef.Fields.Delete` や `Append` を実行する瞬間、対象テーブルが他のユーザーやフォーム、レポートによって開かれていると、エラー「3219: 操作が無効です。」が発生する。
実運用環境では、このコードを実行する前に、明示的にマルチユーザー環境をロックアウトするか、アプリケーションを排他モード（Exclusive Mode）で起動しているセッションでのみ実行するガード節を入れるべきだ。
プライマリキー（PK）の依存性
上記のデータ復元クエリ（`UPDATE … INNER JOIN`）では、行を特定するためのユニークなキー（プライマリキー）の存在を前提としている。もし対象テーブルにPKが存在しない場合、どの行がどのデータに対応するのかが保証されず、データがグチャグチャに混ざる（クロスアップデートの発生）。
変更対象のテーブルには必ず単一または複合のプライマリキーが存在するか、あるいは「行ID（AutoNumber）」が担保されていることを前提条件に組むこと。
—
4. 結び：技術の真髄は「守り」にある
動的なスキーマ変更は、システムの進化において不可欠なアプローチだ。しかし、それを「動けばいい」という安易なコードで実装した瞬間、長年積み上げられた顧客のデータ資産は露と消える。
真に優秀なエンジニアとは、華麗なアルゴリズムを書く者ではなく、「最悪の事態（電源断、予期せぬ型不一致、メモリ枯渇）が起きた瞬間に、システムが如何に美しく安全に元の状態へ退避できるか」をデザインできる者である。
ここに示した知見が、あなたの保守現場における強固な盾となることを確信する。
