Access VBAを掌握する極限の知見：`Application.Echo`を支配せよ――エラー耐性を持つ画面描画制御クラスの設計
レガシーシステムの最前線に立つ我々にとって、Access VBAは単なる簡易言語ではない。適切に御すれば、堅牢なエンタープライズ・クライアントアプリケーションの心臓部となり得る強力なツールだ。
しかし、その圧倒的な柔軟性の裏には、幾多の「地雷」が埋まっている。その一つが、大量データ処理時のパフォーマンス改善に欠かせない `Application.Echo False` による画面描画の抑制だ。
プロシージャの途中で予期せぬ実行時エラーが発生し、`Echo True` に復帰することなく処理が中断されたとき、何が起きるか？
ユーザーの目の前には、完全に凍結したかのような画面が残り、Accessは操作を受け付けなくなる。タスクマネージャーから強制終了する以外の選択肢を奪われたユーザーの冷ややかな視線を、幾度浴びたことか。
今回は、この古典的かつ致命的な問題に対し、VBAのクラスモジュールが持つ「オブジェクトのライフサイクル（Terminateイベント）」を極限まで利用した、絶対に破綻しない汎用画面制御アーキテクチャを提示する。
—
1. なぜ「オンエアー・ハンドリング」では不十分なのか
多くの開発者は、エラーハンドリングといえば `On Error GoTo ErrorHandler` を思い浮かべる。次のようなコードを書いたことがあるはずだ。
Public Sub BadExample()
On Error GoTo ErrorHandler
Application.Echo False
‘ 膨大なレコード処理や外部連携…
Err.Raise 1000, , “予期せぬエラー” ‘ テスト用の意図的エラー
Application.Echo True
Exit Sub
ErrorHandler:
MsgBox “エラー発生: ” & Err.Description, vbCritical
Application.Echo True ‘ ここで復帰させる設計
Resume Next
End Sub
このコードは、正常系と明確にキャッチできる異常系では機能する。だが、以下のシナリオでは完全に無力だ。
1. VBAの実行時エラー（トラップ不能な致命的エラーやスタックオーバーフロー）
2. 開発者による `Ctrl + Break` による強制中断
3. エラーハンドラー内でのさらなる予期せぬエラー（二重障害）
これらが発生した瞬間、エラーハンドラーはバイパスされ、`Echo False` の状態が永続化する。Accessのプロセスが生きていれば、画面は真っ白か直前の描画のまま固まる。
プロセスの安全性担保において、「エラーが起きたら元に戻す」というリアクティブなアプローチは破綻している。我々が求めるべきは、「スコープを抜けた（あるいは消滅した）時点で、物理法則のように確実に状態を復元する」プロアクティブな仕組みだ。
—
2. クラスのライフサイクル（Terminate）をフェイルセーフの盾にする
VBAのクラスモジュールは、インスタンスが生成されたときに `Class_Initialize` が走り、スコープから外れるか `Nothing` が代入されてメモリから解放される瞬間に `Class_Terminate` が走る。
この言語仕様は、RAII（Resource Acquisition Is Initialization：リソース獲得は初期化時）イディオムそのものである。エラーが発生しようが、コードが途中で強制終了されようが、VBAのランタイムはスコープ変数やオブジェクトの参照破棄を確実に実行し、その過程で必ず `Terminate` イベントを通過させる。
これを利用しない手はない。
究極の画面制御クラス：`clsScreenGuard`
以下のコードを、プロジェクト内にクラスモジュールとして作成し、名前を `clsScreenGuard` とせよ。
‘ ==============================================================================
‘ クラス名: clsScreenGuard
‘ 概要: Application.Echoおよびマウスカーソル、画面再描画を確実に管理するRAIIラッパー
‘ ==============================================================================
Option Explicit
Private m_EchoState As Boolean
Private m_CursorState As Integer
Private m_PaintingState As Boolean
Private m_IsDisposed As Boolean
Private Sub Class_Initialize()
‘ 現在の状態を退避（多重ネストや外部状態の変化に対応）
m_IsDisposed = False
‘ 画面描画の抑制
On Error Resume Next
m_EchoState = True ‘ Accessの仕様上、Echoの現在値直接取得は不可のためTrueをデフォルト
Application.Echo False
‘ 砂時計カーソルへ変更（ユーザーへの視覚的フィードバック）
m_CursorState = Screen.MousePointer
Screen.MousePointer = 11 ‘ acHourglass
‘ フォームの再描画を停止（フォームが開いている場合）
‘ ※CurrentDb周辺のオブジェクトモデルと組み合わせることで整合性を担保
Application.Echo False
On Error GoTo 0
End Sub
Private Sub Class_Terminate()
‘ デストラクター：いかなる理由であれ、インスタンスが消滅する瞬間に必ず実行される
Me.Release
End Sub
‘ Explicitな解放メソッド（usingステートメント的な使い方も可能にする）
Public Sub Release()
If m_IsDisposed Then Exit Sub
On Error Resume Next
‘ 画面描画の復帰
Application.Echo True
‘ カーソルをデフォルトに戻す
Screen.MousePointer = m_CursorState
‘ 変更フラグを立てて二重実行を防止
m_IsDisposed = True
On Error GoTo 0
End Sub
—
3. 実戦投入：極限までシンプルかつ安全なプロシージャ記述
このクラスを実装したことにより、実際のビジネスロジックを書くプロシージャ側から、エラーハンドリングにおける「状態復元の呪縛」が完全に消え去る。
以下が、実際の業務システムにおける実装例だ。
Public Sub ExecuteHeavyBatchProcess()
‘ ガードクラスのインスタンスをローカル変数として生成
‘ この瞬間に Echo False と 砂時計カーソル化が発動する
Dim screenGuard As clsScreenGuard
Set screenGuard = New clsScreenGuard
On Error GoTo ErrorHandler
‘ —————————————————-
‘ ここから先は、画面描画やカーソルの復元を一切気にする必要がない
‘ —————————————————-
‘ 1. 一時テーブルのクリアとデータ構築
CurrentDb.Execute “DELETE FROM T_TempWork;”, dbFailOnError
Dim i As Long
For i = 1 to 10000
‘ 負荷の高い処理のシミュレーション
CurrentDb.Execute “INSERT INTO T_TempWork (ProcessNo) VALUES (” & i & “);”, dbFailOnError
‘ 意図的なエラーテスト（コメントアウトを外して挙動を確認せよ）
‘ If i = 500 Then Err.Raise 9999, , “想定外のバグ発生”
Next i
‘ 2. 外部API連携やレポート出力のモック
Call DoSomethingComplexBusinessLogic()
‘ 正常終了時は明示的に解放しても良い（しなくてもスコープアウトで自動実行される）
Set screenGuard = Nothing
MsgBox “バッチ処理が正常に完了しました。”, vbInformation
Exit Sub
ErrorHandler:
‘ 業務エラーのログ出力や通知のみに集中できる
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
‘ エラーハンドラー内でさらにエラーが起きようとも、
‘ この後プロシージャを抜けて screenGuard が破滅（Terminate）する際に
‘ 必ず Echo True とカーソル復元が保証される。
Set screenGuard = Nothing
End Sub
Private Sub DoSomethingComplexBusinessLogic()
‘ さらに下位の処理…
End Sub
—
4. シニアアーキテクトが解説するアーキテクチャの優位性
なぜこの設計が、レガシーAccess開発において「至高」なのか。その理由はメモリ管理と実行コンテキストの厳格な分離にある。
1. スコープバインドによる確実性
VBAのガベージコレクションは参照カウンタ方式（COMベース）である。プロシージャが異常終了（スタックのアンワインド）を起こした際、ローカルスコープに存在するオブジェクト変数は必ず破棄される。つまり、`Terminate` イベントの確実性は、VBAランタイムの最も低レイヤーな機構によって保証されている。
2. 「状態の汚染」からの解放
もし複数のサブルーチンが入れ子構造で `Echo False` を呼び出した場合、単純な `Echo True` では「親の処理の途中で画面が勝手に描画されてしまう」というバグを生む（カウンター方式でEcho深度を管理する高度なクラスに拡張することも容易だ）。今回は単一プロシージャスコープにおける極限の簡潔さに特化させたが、クラス化することで将来的な拡張（ログ出力の統合、トランザクションの強制ロールバック連動など）への耐性が圧倒的に高まる。
3. ユーザビリティとパフォーマンスの両立
数万件のレコードをDAOやADOで処理する際、画面描画（Repaint）が走るか否かで処理時間は文字通り「10倍以上」変わる。このクラスを使えば、パフォーマンスチューニングの恩恵を安全に、かつ「戻し忘れによるハングアップリスク」を完全にゼロにして享受できる。
—
結び
Access VBAにおいて、コードの美しさはそのままシステムの堅牢性に直結する。
「エラーが起きても確実に元に戻る」という当たり前のようで最も実装が漏れやすい要件を、言語仕様（オブジェクトのライフサイクル）の背後に隠蔽すること。これこそが、散らかったレガシーコードをエンタープライズレベルへと昇華させるシニアエンジニアの技法である。
明日からの開発で、あなたのプロジェクトから「画面が固まったまま動かないAccess」を根絶せよ。
