【実務・中級編】【上級】テーブル定義の変更を検知し、変更箇所をメールで通知する監視ツールの開発 – Access VBA解析バイブル

Accessの「闇」を暴け：テーブル変更監視アーキテクチャの極意

Access開発の現場で最も恐ろしいのは、「いつの間にか誰かがフィールドを削除し、業務システムが沈黙する」という事故だ。GUIで手軽に構造を変えられるAccessの柔軟性は、ガバナンスの観点では諸刃の剣である。

今回は、誰が、いつ、どのテーブルをいじったのかを即座に検知し、管理者に叩きつける「守護神」の設計論を授ける。

1. なぜ「力技」で監視してはいけないのか

初心者は、`CurrentDb.TableDefs`をループさせて全フィールドを比較するようなコードを書きがちだ。しかし、これは非効率の極みである。テーブル数が100を超えた瞬間にパフォーマンスは崩壊する。

真のアーキテクトが目指すべき指針：

• メタデータのキャッシュ化: 現在の構造をローカルの隠しテーブル（監査ログ用DB）にハッシュ化またはシリアライズして保持する。
• イベントドリブンの回避: Accessには「テーブル定義変更イベント」が存在しない。ゆえに、アプリケーション起動時、または管理画面からのチェック実行時に「差分検知」を行う設計にする。
• 差分抽出の最適化: `TableDef`の`LastUpdated`プロパティを信じてはいけない。あれはGUIの変更だけでなく、内部的な最適化でも動くことがある。あくまでフィールド数と属性のシグネチャ（ハッシュ）で比較せよ。

—

2. プロダクションコード：構造比較エンジン

以下のコードは、テーブルのメタデータをJSONライクな文字列に変換し、前回の記録と比較して差分があればメールを飛ばすためのコアロジックだ。

Option Compare Database
Option Explicit

‘ テーブル定義のハッシュ（簡易版）を生成する関数
‘ 実際にはフィールド名＋型＋サイズを連結した文字列をSHA等に通すのが理想
Public Function GetTableSignature(tblName As String) As String
Dim db As DAO.Database: Set db = CurrentDb
Dim td As DAO.TableDef: Set td = db.TableDefs(tblName)
Dim fld As DAO.Field
Dim sig As String

‘ システムテーブルを除外
If (td.Attributes And dbSystemObject) Then Exit Function

‘ フィールド情報を連結してシグネチャを作成
For Each fld In td.Fields
sig = sig & fld.Name & “:” & fld.Type & “:” & fld.Size & “|”
Next fld

GetTableSignature = sig
End Function

‘ 構造変更を監視・通知するメイン処理
Public Sub MonitorTableStructure()
Dim db As DAO.Database: Set db = CurrentDb
Dim td As DAO.TableDef
Dim lastSig As String, currentSig As String

For Each td In db.TableDefs
If Not (td.Attributes And dbSystemObject) Then
currentSig = GetTableSignature(td.Name)
‘ ここで「監査ログテーブル」から前回のシグネチャを取得して比較
lastSig = GetLastRecordedSignature(td.Name)

If lastSig <> currentSig And lastSig <> “” Then
Call SendAlertEmail(td.Name, “構造変更が検知されました。”)
End If

‘ 必要に応じてログを更新
Call UpdateAuditLog(td.Name, currentSig)
End If
Next td
End Sub

—

3. 設計上の注意点：守るべき三つの掟

① 監査ログDBの分離

監視対象のデータベース内にログテーブルを作ってはいけない。監視対象が壊れた際、ログも道連れになるからだ。「監査ログ専用の外部MDB/ACCDB」を用意し、リンクテーブル経由で書き込むこと。これがガバナンスの鉄則だ。

② メール送信の非同期化

AccessからOutlookを直接操作してメールを送る際、エラーで処理が止まるとアプリケーション全体がフリーズする。送信は必ずエラーハンドリングを徹底し、失敗した場合はローカルの「未送信キューテーブル」に格納し、次回起動時にリトライする設計にせよ。

③ セキュリティと権限

そもそも「誰でもデザインビューを開ける」という状況がガバナンスの欠如である。このツールを導入した後は、「運用担当者以外はデザインビューを開けないよう、フロントエンドの配布ファイルから機能を無効化する」という物理的な締め付けを必ずセットで行うこと。

—

最後に：自動化は「抑制」である

エンジニアとして覚えておいてほしい。真に優秀な自動化ツールとは、何かを修正するものではなく、「不正な操作を未然に防ぐための抑止力」として機能するものだ。

この監視システムを導入し、朝一番の起動時に「変更が検知されました」と警告が出る環境を作れば、現場の意識は劇的に変わる。それが、組織全体のリスクをコントロールするということだ。

さあ、退屈な手作業の監視は今日で終わりにしよう。君のコードで、システムに「規律」を刻み込むんだ。