DoCmd.RunCommandの呪縛を解く：Access標準機能の呼び出しとオブジェクトモデルの深層
レガシーシステムの維持、あるいは高速なプロトタイピングの現場において、Microsoft Accessは依然として強力な牙城である。しかし、GUIの裏側でうごめくAccessオブジェクトモデルの挙動、特にフォームのライフサイクルとデータアクセスのコンテキストを完全に理解しているエンジニアは少ない。
「フォームのレコードを保存したい」「フィルタを安全に解除したい」「新規レコードに移動したい」。
これらをVBAの独自ロジックで実装しようとすると、ダーティバッファの競合、バリデーションイベントの迷走、予期せぬトランザクションのロールバックなど、数々の悪夢に見舞われる。
ここで登場するのが `DoCmd.RunCommand` である。これはAccessの標準メニューやリボンに紐づくコマンドをプログラムから強制発火させるブラックボックスだが、「Accessが本来持っているUIスレッドとデータエンジンの同期機構をそのまま利用できる」という、極めて強力なメリットを持つ。
本稿では、この `DoCmd.RunCommand` の挙動をアーキテクチャの観点から丸裸にし、実務の現場で絶対に破綻しない自動化コードの構築手法を解説する。
—
1. なぜ自前実装をしてはならないのか？：オブジェクトモデルの深層
VBAからフォームを操作する際、多くのプログラマブルなアプローチが存在する。例えば、レコードの保存であれば以下のようなコードが書かれる。
‘ 【アンチパターン】自前でDirtyを落とす危険なアプローチ
If Me.Dirty Then
Me.Dirty = False ‘ ここでバリデーションエラーが発生するとトラップ困難な実行時エラーになる
End If
このコードの何が問題か。`Me.Dirty = False` は、フォームのデータ保存を強制する最も一般的な手法だが、Accessのフォームライフサイクルにおける「エラーハンドリングのコンテキスト」を完全に無視している。
バリデーションルールに違反した場合、エラー番号が返される前にAccess内部のUIがメッセージボックスを表示し、コードの実行が予期せず中断（またはトラップ不能なブレーク）する。
一方、`DoCmd.RunCommand acCmdSaveRecord` は、AccessのUIメッセージループと完全に同期し、標準のエラーハンドリング機構をバイパスせずに安全にトランザクションを完了させる。つまり、「AccessのGUIが持つ堅牢なエラーハンドリングの恩恵をそのままコードに持ち込む」ための唯一のブリッジなのだ。
—
2. 実践：極限まで最適化されたフォーム制御モジュール
実際の業務システムにおいて、エラーハンドリングとオブジェクトのライフサイクル管理は厳格に行われなければならない。以下のコードは、`DoCmd.RunCommand` を活用しつつ、予期せぬエラーやオブジェクトのリークを防ぐための実用的なプロシージャである。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ モジュール名: modFormAutomation
‘ 概要: DoCmd.RunCommandを用いた堅牢なフォーム操作自動化ライブラリ
‘ 執筆者: チーフアーキテクト
‘ =========================================================================
Public Sub ExecuteSafeFormAction(ByRef frm As Access.Form, ByVal targetCommand As AcCommand)
On Error GoTo ErrorHandler
‘ オブジェクトの有効性検証（Null参照例外の防止）
If frm Is Nothing Then
Err.Raise 91, “ExecuteSafeFormAction”, “対象のフォームオブジェクトが参照されていません。”
End If
‘ 該当フォームにフォーカスを強制（RunCommandの前提条件）
‘ ※Accessはアクティブコントロールに対してコマンドを実行するため
If Screen.ActiveForm.Name <> frm.Name Then
frm.SetFocus
End If
‘ コマンドの実行前処理（必要に応じたログ出力やデバッグ）
Debug.Print “Executing Command ID: ” & targetCommand & ” on Form: ” & frm.Name
‘ 標準コマンドの実行
DoCmd.RunCommand targetCommand
Exit Sub
ErrorHandler:
‘ 極限環境におけるエラーハンドリング
‘ acCmd系のエラーはErr.Number 2046（現在利用できないコマンド）などが頻発するため個別に捕捉
Select Case Err.Number
Case 2046
‘ コマンドが現在の状態（未保存、新規行など）で無効な場合
MsgBox “現在の状態ではこの操作を実行できません。” & vbCrLf & _
“詳細: ” & Err.Description, vbExclamation, “システム警告”
Case Else
‘ 予期せぬシステムエラー
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“Error #[ ” & Err.Number & ” ]: ” & Err.Description, vbCritical, “致命的エラー”
End Select
‘ 必要に応じてエラーログをここに記述（Windowsイベントログやテキスト出力）
End Sub
このコードの急所（シニアエンジニアの視点）
1. `Screen.ActiveForm.Name` によるフォーカス検証: `DoCmd.RunCommand` は「今まさにアクティブになっているフォームまたはコントロール」に対して作用する。バックグラウンドにあるフォームに対して呼び出すと致命的な2046番エラーを引き起こすため、事前に `SetFocus` で文脈を強制している。
2. 厳密なエラー分岐: Access特有の「現在実行不可能なコマンド（Err 2046）」を捕捉し、ユーザーフレンドリーかつクラッシュしない構造に昇華させている点に注目してほしい。
—
3. レガシー環境とメモリ最適化：見えないリークを防ぐ
Access VBAを語る上で避けて通れないのが、メモリ管理の闇である。特に古いAccess（Access 2003形式の `.mdb` や、破損しやすい `.accdb`）において、フォームを頻繁に開き閉めしたり、`RunCommand` で大量のレコード操作を行ったりすると、COMコンポーネントの参照カウンタが適切にデクリメントされず、メモリリーク（Bloat現象）を引き起こす。
これを防ぐためには、以下の鉄則を遵守する必要がある。
- オブジェクト変数の局所化と即座の解放:
フォームやレコードセットを操作した後は、必ず `Nothing` を代入してメモリプレッシャーを軽減する。
- カレントデータベースの効率的利用:
`CurrentDb` 関数は呼び出すたびに新しい DAO.Database オブジェクトをメモリ上に生成する。これをループ内で乱用してはならない。
‘ 悪い例：ループ内でCurrentDbを呼び出す（メモリリークの温床）
‘ For i = 1 to 1000
‘ CurrentDb.Execute “…”, dbFailOnError
‘ Next i
‘ 良い例：オブジェクトを変数にキャッシュし、確実に解放する
Public Sub OptimizedBatchProcess()
Dim db As DAO.Database
Set db = CurrentDb ‘ 一度だけ参照を取得
On Error GoTo CleanUp
db.BeginTrans
‘ 処理の実行
db.CommitTrans
CleanUp:
If Err.Number <> 0 Then db.Rollback
‘ 明示的なオブジェクトの解放
If Not db Is Nothing Then
Set db = Nothing
End If
‘ ガベージコレクションの誘発（Access VBAにおける最終防衛ライン）
DBEngine.Idle dbRefreshCache
End Sub
`DoCmd.RunCommand` 自体はAccessの内部エンジン（ACE/Jet）のUIスレッドを叩くため、VBA側でメモリを直接消費しないが、「コマンド実行前後のフォームの状態変化（Dirtyフラグやレコードセットの再クエリ）」がメモリに与える影響は無視できない。定期的な `DBEngine.Idle dbRefreshCache` の呼び出しは、長期間稼働する業務システムにおいて必須のテクニックである。
—
4. システム間連携への応用：APIとの融合
現代のAccessシステムは、孤立した島であってはならない。REST APIとの連携、外部SQL ServerとのODBC接続、あるいはExcel/Outlookとのシームレスなデータ交換が求められる。
ここで `DoCmd.RunCommand` が活きる場面がある。外部APIから非同期でデータを取得し、ローカルのフォームに反映させる際、「データを挿入した直後に、Accessの標準機能を使って画面を強制リフレッシュし、ユーザーが編集可能な状態にロックを解除する」という一連の流れを極めて簡潔に記述できるのだ。
Public Sub SyncExternalDataAndRefresh(ByRef targetForm As Access.Form)
‘ 外部APIからのデータ取得・ローカルテーブルへの書き込みが完了している前提
‘ 1. フォームの再クエリ（最新データの取得）
targetForm.Requery
‘ 2. 標準コマンドで先頭レコードへ移動し、UIを安定化
Call ExecuteSafeFormAction(targetForm, acCmdRecordsGoToFirst)
‘ 3. レコードの保存状態を確定
Call ExecuteSafeFormAction(targetForm, acCmdSaveRecord)
Debug.Print “External sync and UI refresh completed successfully.”
End Sub
API連携のロジック自体はVBAの `MSXML2.DOMDocument` や `WinHttp.WinHttpRequest.5.1` で構築し、「画面の描画とデータの確定」というUIレイヤーの責務のみを `DoCmd.RunCommand` に委譲する。この関心事の分離（Separation of Concerns）こそが、スパゲッティコードと化したレガシーAccessアプリを救う唯一の王道である。
—
総括
`DoCmd.RunCommand` は、単なる「ショートカットキーの代わり」などではない。それは、Microsoft Accessという巨大なデスクトップデータベースエンジンが何十年かけて最適化してきた「UIとデータの同期・整合性維持メカニズム」にアクセスするための、唯一無二の安全弁である。
自前の複雑なコードで車輪の再発明をするのをやめよ。Accessが用意した洗練された標準コマンドを正しく理解し、適切なエラーハンドリングとメモリ管理の元で呼び出すこと。それこそが、モダンな視点を持ったプロフェッショナルなAccessエンジニアの生存戦略である。
