Access VBAを掌握する極限の知見：入力規則のVBA一括制御でデータ品質を極限まで担保する
業務システムの成否は、突き詰めれば「入力データの信頼性」の担保に他ならない。
どれほど美しいフォームを作り、どれほど高度な集計クエリを組もうとも、肝心のテーブルにゴミデータが紛れ込んでいれば、出力される結果の価値はゼロになる。
Accessで開発をしていると、こんな壁にぶつからないだろうか。
- 「テーブル設計書をもとに、数十個あるテーブルのフィールド一つひとつにGUIで入力規則を設定していく……手が痛いし、ミスも起きる」
- 「後から要件定義が変わり、『すべての金額フィールドは0以上にする』というルールを全テーブルに追加することになった」
GUI（画面）をポチポチと手作業で操作して設定する時代は、今日で終わりだ。
今回は、`TableDef` と `Field` オブジェクトをVBAで自在に操り、入力規則を一括適用してデータ入力を完全に標準化する堅牢なアーキテクチャを伝授する。
単なる「コードのコピペ集」ではない。実務の現場でバグを踏まないためのプロの知見を、余すところなく公開しよう。
—
1. なぜGUIではなく「VBAコードによる定義」なのか？
初心者層の多くは、「テーブルの設計は画面を開いて手動でするもの」という固定観念にとらわれている。しかし、プロの現場において、手動設定は「最大のバグ温床」だ。
手動設定が抱える3つの致命的リスク
1. ヒューマンエラー（設定漏れ・タイポ）: 30テーブル、合計300フィールドに対して手動で入力規則を入れるとき、ミスを100%防げる人間はいない。
2. 保守性の欠如: 仕様変更が入った際、どこを修正したか追跡できなくなる（ドキュメントと実態の乖離）。
3. 環境移行のコスト: 別データベースへスキーマを移行する際、手作業を再度繰り返す必要がある。
VBAでコード化するということは、「テーブル定義をソースコードとしてバージョン管理し、何度でも再現可能な状態にする」ということだ。これこそが、プログラマが手動作業から脱却すべき最大の理由である。
—
2. アーキテクチャの全体像とDAOのライフサイクル
Accessのテーブル構造をコードから操作する場合、ADOではなくDAO（Data Access Objects）を使用するのがセオリーであり、唯一の正解だ。
DAOはAccessのデータベースエンジン（ACE/Jet）とダイレクトに通信するため、テーブル定義やインデックス、リレーションシップの操作において圧倒的なパフォーマンスと安定性を誇る。
ここで意識すべきは、オブジェクトの「解放（リソース管理）」の作法だ。
VBAでは、インスタンス化した `Database` や `TableDef` を放置すると、メモリリークやファイルロックの原因になる。極限までクリーンなコードを書くためには、生成と逆の順序で確実に `Nothing` を代入するプロ意識を持たなければならない。
—
3. 【実践】入力規則を一括設定するプロダクションコード
以下のコードは、実務の現場ですぐに投入できるよう、エラーハンドリングとトランザクション（概念）を考慮した堅牢なモジュールである。
このコードでは、指定したプレフィックスを持つテーブル、または全テーブルを走査し、特定のフィールド名に対して標準的な「入力規則（ValidationRule）」と「入力規則違反時のメッセージ（ValidationText）」を一括で流し込む。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 処理名 : BatchSetValidationRules
‘ 概要 : 指定したデータベース内のテーブル群に対し、特定のフィールドの
‘ 入力規則とエラーメッセージをプログラムから一括設定する
‘ 著者 : チーフアーキテクト
‘ =========================================================================
Public Sub BatchSetValidationRules()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim targetTableCount As Long
Dim updatedFieldCount As Long
On Error GoTo ErrorHandler
‘ カレントデータベースの参照を取得
Set db = CurrentDb()
targetTableCount = 0
updatedFieldCount = 0
‘ データベース内のすべてのテーブル定義を走査
For Each tdf In db.TableDefs
‘ システムテーブル（MSysで始まるもの）や一時テーブルを除外
If Left(tdf.Name, 4) <> “MSys” And Left(tdf.Name, 1) <> “~” Then
‘ — パターンA: フィールド名で一括制御する場合のロジック —
For Each fld In tdf.Fields
‘ 例: 「単価」または「価格」という名前のフィールドすべてに 0以上 の規則を強制
If fld.Name = “単価” Or fld.Name = “価格” Or fld.Name = “quantity” Then
‘ 既存のプロパティを上書き設定
fld.ValidationRule = “>= 0”
fld.ValidationText = “価格または単価には0以上の数値を入力してください。”
updatedFieldCount = updatedFieldCount + 1
End If
‘ 例: 「メールアドレス」フィールドに対して簡易的な形式チェックを強制
If fld.Name = “メールアドレス” Then
fld.ValidationRule = “Like ‘@.'”
fld.ValidationText = “有効なメールアドレスの形式で入力してください。”
updatedFieldCount = updatedFieldCount + 1
End If
Next fld
targetTableCount = targetTableCount + 1
End If
Next tdf
‘ 成功ログの出力
MsgBox “入力規則の一括設定が完了しました。” & vbCrLf & _
“処理対象テーブル数: ” & targetTableCount & vbCrLf & _
“更新されたフィールド数: ” & updatedFieldCount, vbInformation, “処理成功”
CleanExit:
‘ 对象的ライフサイクルの適切な終端処理（メモリリーク防止）
On Error Resume Next
Set fld = Nothing
Set tdf = Nothing
Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“Error No: ” & Err.Number & vbCrLf & _
“Description: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanExit
End Sub
—
4. 現場で絶対に踏んではいけない「罠」と注意点
このコードを実務で動かすにあたり、プロのエンジニアとして知っておくべき「罠」がいくつか存在する。ここを理解していないと、稼働後にシステムがクラッシュする原因になる。
① 既存データとのコンフリクト（整合性エラー）
すでに大量のレコードが存在するテーブルに対して、後から `fld.ValidationRule = “>= 0″` のような厳しい規則を適用しようとしたとき、もしテーブル内に「-100」という負の値がすでに含まれていた場合、VBAは容赦なく実行時エラー（エラー3295等）を吐いて停止する。
- 対策: ルールを適用する前に、クエリ等を使って既存データが新しい規則に違反していないかを事前にスクリーニング（クレンジング）する工程を必ず挟むこと。
② 排他制御（マルチユーザー環境の罠）
他のユーザーがデザインビューで該当テーブルを開いている、あるいはフォームで編集中である場合、`TableDef` のプロパティ書き換えはロックされ失敗する。
- 対策: テーブル定義の変更を行うスクリプトは、必ず「誰もアクセスしていないメンテナンス時間帯」に、排他モードで開いたデータベースに対して実行すること。
③ プロパティの型（データ型）のミスマッチ
数値型（IntegerやDoubleなど）のフィールドに対して、テキスト用の規則（`Like`演算子など）を設定すると、当然エラーになる。フィールドの `Type` プロパティ（`dbLong`, `dbText` など）を条件に含めて、型安全な分岐を行うのがベストプラクティスだ。
—
5. さらなる高みへ：外部定義ファイル（JSON/CSV）からの動的マッピング
もし君が真に洗練されたシステムアーキテクチャを目指すなら、上記コードのようにVBAの中に「条件（単価、メールアドレスなど）」をハードコーディングすべきではない。
保守性の極限を追求するならば、「どのフィールドに、どんな入力規則を入れるか」の定義を外部のCSVファイルや別テーブルに持たせ、VBA側はそれを読み込んで動的にリフレクション（反映）させるエンジンを作るべきだ。
これによって、要件定義が変わった際も、VBAのソースコードを一行も書き換えることなく、設定データの差し替えだけでシステムの仕様変更に追随できるようになる。
—
総括
Access VBAにおけるテーブル定義のコード制御は、単なる手抜きのためのツールではない。「システムの品質を人の手から解放し、数学的・機械的な確実性によって担保する」ためのエンジニアリングである。
GUIの呪縛から脱却し、コードでデータベースを支配せよ。あなたの開発する業務システムは、そこから一段上のステージへと進化するはずだ。
