【Access VBA極限解説】フォームの `OnCurrent` イベントで実現する、ミリ秒単位の動的UI制御とメモリ最適化の極意
レガシーシステムと呼ばれる領域であっても、そこで稼働する業務アプリケーションのUX（ユーザーエクスペリエンス）が妥協される理由にはならない。特にMicrosoft Accessを用いた基幹システムにおいて、オペレーターが一日中向き合う入力フォームの応答速度と視認性は、業務のスループットを左右する生命線である。
レコードごとに「編集可能・不可能」が動的に切り替わり、ステータスに応じて背景色が瞬時に変化する――。この要件を最も美しく、かつパフォーマンスを犠牲にせずに実装する鍵が、フォームの `OnCurrent`（カレント時）イベント である。
本稿では、単なる基本構文の解説にとどまらない。オブジェクトモデルの挙動、VBAのメモリ管理の闇、そして描画のオーバーヘッドを極限まで削ぎ落とした、シニアエンジニアのための実践的アーキテクチャを提示する。
—
1. `OnCurrent` イベントの本質とオブジェクトモデルの罠
`OnCurrent` イベントは、フォームで表示されているレコードが移動するたびに、すなわちレコードのコンテキストが切り替わる瞬間に発火する。ここで重要なのは、「画面上のすべてのコントロールの状態は、レコードが変わるたびに再評価されなければならない」という事実だ。
しかし、愚直なコードはAccessのパフォーマンスを容易に殺す。以下のアンチパターンを見てほしい。
‘ 【アンチパターン】これでは描画負荷とメモリリークの温床になる
Private Sub Form_Current()
If Me.Status = “完了” Then
Me.FieldA.Locked = True
Me.FieldA.BackColor = RGB(220, 220, 220)
Else
Me.FieldA.Locked = False
Me.FieldA.BackColor = RGB(255, 255, 255)
End If
End Sub
このコードの何が問題か。
1. プロパティ変更の連鎖による描画（Repaint）の頻発: コントロールの `Locked` や `BackColor` を変更するたびに、Access内部でレイアウト計算と再描画が走り、画面のちらつき（フリッカー）や速度低下を引き起こす。
2. `Me` プレフィックスの過剰な評価: フォームモジュール内での暗黙的な参照解決は、大規模なフォームになるとわずかながらオーバーヘッドとなる。
プロフェッショナルは、描画の抑制とオブジェクトのライフサイクル管理を徹底的にコントロールする。
—
2. 実装アーキテクチャ：高速化と保守性を両立する動的UI制御
レコードごとの状態判定を高速化するため、条件分岐を簡素化し、コントロール群へのアクセスを最適化したプロダクションレベルのコードを示す。
ここでは、`Echo` メソッドを用いて画面描画を一時停止させ、一括してプロパティを変更する手法をとる。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ フォーム名: frmOrderEntry
‘ 概要: カレントレコードのステータスに応じた動的UI制御と視覚フィードバック
‘ ==============================================================================
Private Sub Form_Current()
‘ エラーハンドリングの徹底
On Error GoTo ErrorHandler
‘ 1. 描画を一時停止し、レイアウト計算のオーバーヘッドを排除する
Application.Echo False
‘ 2. カレントレコードのデータを評価
Dim isLocked As Boolean
Dim targetColor As Long
‘ 例：ステータスが「承認済」または「処理完了」の場合はロックする
Select Case Nz(Me.txtStatus.Value, “”)
Case “承認済”, “処理完了”
isLocked = True
targetColor = RGB(240, 240, 240) ‘ グレーアウト（読取専用）
Case Else
isLocked = False
targetColor = RGB(255, 255, 255) ‘ ホワイト（編集可能）
End Select
‘ 3. コントロール群の状態を一括設定
Call ApplyControlState(isLocked, targetColor)
ErrorHandler_Exit:
‘ 4. 必ず描画を復元する（これを怠ると画面が真っ白でフリーズしたようになる）
Application.Echo True
Exit Sub
ErrorHandler:
MsgBox “UI制御中に予期せぬエラーが発生しました。” & vbCrLf & _
“Error: ” & Err.Description, vbCritical, “システムエラー”
Resume ErrorHandler_Exit
End Sub
‘ ——————————————————————————
‘ 補助プロシージャ: コントロール群へのプロパティ適用
‘ ——————————————————————————
Private Sub ApplyControlState(ByVal pLocked As Boolean, ByVal pBackColor As Long)
‘ フォーム上の特定の入力フィールド群を一括制御
With Me.txtCustomerName
.Locked = pLocked
.BackColor = pBackColor
End With
With Me.txtOrderAmount
.Locked = pLocked
.BackColor = pBackColor
End With
With Me.cmbCategory
.Locked = pLocked
.BackColor = pBackColor
End With
‘ 主キーや管理番号など、常にロックすべきフィールドの担保
Me.txtOrderID.Locked = True
Me.txtOrderID.BackColor = RGB(230, 230, 230)
End Sub
—
3. チーフアーキテクトの知見：メモリ最適化とレガシー環境の罠
ここからが本題だ。Access VBAを極限まで使い倒すエンジニアは、VBAの裏側にあるCOM（Component Object Model）のライフサイクルを意識している。
① `CurrentDb` の濫用と暗黙のインスタンス化
多くの解説書では `CurrentDb.OpenRecordset` が平然と使われている。しかし、`CurrentDb` は呼び出すたびに新しいデータベースオブジェクトのインスタンスをメモリ上に生成し、ポインタを返す。
`OnCurrent` はレコード移動のたびに高頻度で実行されるため、ここで `CurrentDb` を安易に使うと、ガベージコレクションが追いつかずにメモリリークやパフォーマンス劣化を引き起こす。
もし `OnCurrent` 内でレコードセットを引く必要がある場合は、フォームのモジュールレベル変数としてデータベースおよびレコードセットを保持し、フォームのオープン時に一度だけバインドするか、DAOの参照を適切に解放（`Set db = Nothing`）しなければならない。
② 条件付き書式（Conditional Formatting）との使い分け
「セルの背景色を変える」という要件であれば、Access標準の「条件付き書式」機能を使う方がVBAを書かずに済むため、一見するとスマートに見える。
しかし、シニアエンジニアとして言いたい。複雑な業務ロジック（他フィールドの値に依存する、外部APIの戻り値を参照するなど）が絡む制御において、条件付き書式はデバッグの困難なブラックボックスと化す。
VBAの `OnCurrent` でコントロールのプロパティを直接制御する手法は、コードの追跡性が高く、保守フェーズにおいて圧倒的な優位性を持つ。
③ Windows APIとの連携によるさらなるUIの極限化
さらに踏み込んだ最適化として、レコードの切り替え時にWindows API（`SendMessage` など）を叩き、IMEのモードを自動制御したり、ウィンドウの再描画メッセージ（`WM_SETREDRAW`）を完全に制御してちらつきをゼロにするアプローチも存在する。
社内システムであっても、Webアプリケーションに劣らない「サクサク動くUI」は、ユーザーの入力ストレスを劇的に軽減する。
—
まとめ
Access VBAにおけるUI制御は、単に「動けばいい」というフェーズをとうに過ぎている。
`OnCurrent` イベントの特性を理解し、描画の制御（`Application.Echo`）、適切なスコープ管理、そしてメモリのライフサイクルを意識したコードを書くことによってのみ、レガシーの殻を破る最高峰のデスクトップアプリケーションが構築できる。
コードは嘘をつかない。細部に宿るアーキテクトのこだわりこそが、システム自体の寿命を延ばすのだ。
