【テクニカル・上級編】【初心者】DoCmd.RunCommandによる「レコード保存」の強制：バリデーション漏れを防ぐ実務テクニック – Access VBA解析バイブル

レコード保存の強制：DoCmd.RunCommandによるバリデーション漏れ撲滅 – レガシーシステム保守の鉄則

Access VBAの世界において、フォームの入力値をいかに確実に確定させるか、これは一見すると初歩的な課題に見えるかもしれない。しかし、長年レガシーシステム、特にAccess VBAで構築された基幹業務システムと向き合ってきた者であれば、この「確実なレコード保存」がいかに多くのバグの温床となり、システム全体の信頼性を揺るがす諸悪の根源になり得るかを痛感しているはずだ。

本稿では、単なる `DoCmd.RunCommand` の使い方解説に留まらず、その裏に潜むオブジェクトライフサイクル、メモリ管理、そしてWindows APIの深層にまで踏み込み、シニアエンジニアや社内システム管理者、さらには将来のレガシーシステム保守担当者に向けて、バリデーション漏れを未然に防ぐための「レコード保存」強制という、極めて実務的かつ根本的なテクニックを解説する。

なぜ「レコード保存」を強制する必要があるのか？ – フォームのBeforeUpdateイベントの落とし穴

Accessフォームでは、ユーザーがレコードの編集を終え、別のレコードに移動したり、フォームを閉じたりする際に `BeforeUpdate` イベントが発生する。このイベント内で、入力値のバリデーションチェックを行い、不正な値であれば保存をキャンセルする、というのが一般的な実装だ。

Private Sub Form_BeforeUpdate(Cancel As Integer)
‘ ここで入力値のバリデーションチェックを行う
If Not IsValidInput(Me.txtSomeField) Then
MsgBox “不正な入力値です。修正してください。”, vbExclamation
Cancel = True ‘ 保存をキャンセル
End If
End Sub

しかし、この `BeforeUpdate` イベントは、ユーザーの操作に依存する。例えば、以下のようなケースで、期待通りに `BeforeUpdate` が発火しない、あるいは発火してもユーザーが意図せず保存を完了してしまう可能性がある。

レコード移動時の挙動の曖昧さ: ユーザーが意図せず次のレコードに移動してしまい、`BeforeUpdate` のバリデーションがスキップされる。
フォームを閉じる際の挙動: フォームを閉じる際に、保存確認ダイアログで「いいえ」を選択するなど、ユーザーの操作次第で保存されないケース。
プログラムからの操作: `DoCmd.GoToRecord` や `DoCmd.Close` などをプログラムから呼び出した際に、`BeforeUpdate` イベントの挙動が期待通りにならない。
エラーハンドリングの不備: `BeforeUpdate` イベント内で予期せぬエラーが発生し、処理が中断された結果、レコードが保存されてしまう。

これらの状況は、特に複雑な入力フォームや、多数のユーザーが利用する基幹システムにおいては、データ破損や整合性の崩壊に直結する。我々が目指すべきは、いかなる状況下でも、入力されたデータがシステム要件を満たしていることを保証した上で、初めてレコードを確定させるという、絶対的な信頼性だ。

DoCmd.RunCommandによる「レコード保存」強制の真髄

ここで登場するのが `DoCmd.RunCommand` だ。このメソッドは、Accessの組み込みコマンドを実行するための強力なツールであり、その中でも `acCmdSaveRecord` コマンドは、現在のレコードを保存するようAccessに指示する。

DoCmd.RunCommand acCmdSaveRecord

しかし、単にこのコードを置くだけでは、前述の落とし穴を回避することはできない。 `DoCmd.RunCommand acCmdSaveRecord` の真髄は、フォームの `BeforeUpdate` イベントが確実に発火し、その中で定義されたバリデーションチェックが完了した後に、レコード保存の処理を強制的に実行するという点にある。

なぜ `RunCommand acCmdSaveRecord` で `BeforeUpdate` が発火するのか？

Accessの内部的な処理フローを理解することが鍵となる。 `DoCmd.RunCommand acCmdSaveRecord` は、Accessに「現在のレコードを保存せよ」という指示を出す。この指示を受けたAccessは、まず 現在のフォームの `BeforeUpdate` イベントをトリガー し、入力値の検証を試みる。

もし `BeforeUpdate` イベント内で `Cancel` プロパティが `True` に設定され、保存がキャンセルされた場合、 `DoCmd.RunCommand acCmdSaveRecord` の実行はそこで停止する。これは、`BeforeUpdate` イベントがバリデーションの最終防衛線として機能していることを意味する。

逆に、`BeforeUpdate` イベントが正常に完了し、`Cancel` プロパティが `False` のまま（つまり保存が許可された）であれば、Accessはレコードの保存処理を続行する。この一連の流れこそが、我々が求めている「バリデーション漏れを防ぎつつ、レコード保存を強制する」メカニズムなのだ。

実践：バリデーション漏れを防ぐための `RunCommand` 活用パターン

では、具体的にどのように `DoCmd.RunCommand acCmdSaveRecord` を活用すれば、バリデーション漏れを確実に防ぐことができるのか。ここでは、いくつかの実用的なパターンを紹介する。

パターン1: ボタンクリック時にレコード保存を強制する

ユーザーが「保存」ボタンをクリックした際に、明示的にレコード保存を強制する。これは、ユーザーに「保存」というアクションを促しつつ、その前に必ずバリデーションチェックを行わせるための最も基本的な方法だ。

‘ — 標準モジュール —
Public Sub ForceSaveRecord(ByVal frm As Form)
On Error GoTo ErrorHandler

‘ BeforeUpdateイベントを確実に発火させるため、
‘ 一度フォーカスを移動させてから戻す、というテクニックも有効だが、
‘ RunCommand acCmdSaveRecord 自体がBeforeUpdateをトリガーするため、
‘ 基本的には不要。ただし、極めて特殊なケースでは考慮の余地あり。

‘ 現在のレコードを保存するコマンドを実行
‘ これにより、フォームのBeforeUpdateイベントがトリガーされる
DoCmd.RunCommand acCmdSaveRecord

‘ SaveRecordコマンドが成功した場合 (BeforeUpdateでキャンセルされなかった場合)
‘ ここで、さらに追加のビジネスロジックや、
‘ 次の処理（例：別フォームの表示、レポート生成など）を実行できる。
MsgBox “レコードが正常に保存されました。”, vbInformation

Exit Sub

ErrorHandler:
‘ エラーハンドリング
‘ BeforeUpdateでCancel = Trueが設定された場合、
‘ ここには到達しない（RunCommand acCmdSaveRecordが中断されるため）。
‘ ここに到達するのは、RunCommand自体や、その後の処理で発生したエラー。
MsgBox “レコード保存中にエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical
Err.Clear
End Sub

‘ — フォームモジュール —
Private Sub cmdSave_Click()
‘ 標準モジュールに定義した強制保存処理を呼び出す
ForceSaveRecord Me
End Sub

‘ — フォームのBeforeUpdateイベント —
Private Sub Form_BeforeUpdate(Cancel As Integer)
‘ 必須項目のチェック
If IsNull(Me.txtProductName) Or Me.txtProductName = “” Then
MsgBox “商品名は必須入力です。”, vbExclamation
Me.txtProductName.SetFocus ‘ エラー箇所にフォーカスを移動
Cancel = True ‘ 保存をキャンセル
Exit Sub
End If

‘ 数値項目のチェック
If Not IsNumeric(Me.txtQuantity) Then
MsgBox “数量は数値を入力してください。”, vbExclamation
Me.txtQuantity.SetFocus
Cancel = True ‘ 保存をキャンセル
Exit Sub
End If

‘ 複雑なビジネスロジックに基づくバリデーション (例: 在庫確認)
If Me.txtQuantity.Value > GetCurrentStock(Me.txtProductID.Value) Then
MsgBox “在庫が不足しています。”, vbExclamation
Me.txtQuantity.SetFocus
Cancel = True ‘ 保存をキャンセル
Exit Sub
End If

‘ 全てのバリデーションをクリアした場合
‘ CancelはデフォルトでFalseなので、明示的に設定する必要はない
‘ MsgBox “バリデーションチェックを通過しました。”, vbInformation
End Sub

‘ — サンプル関数 (実際にはデータベースから取得) —
Private Function GetCurrentStock(ByVal ProductID As Long) As Long
‘ ここに実際の在庫取得ロジックを実装
‘ 例:
Dim rs As DAO.Recordset
Set rs = CurrentDb.OpenRecordset(“SELECT StockQuantity FROM Products WHERE ProductID = ” & ProductID)
If Not rs.EOF Then
GetCurrentStock = rs!StockQuantity
Else
GetCurrentStock = 0 ‘ 商品が見つからない場合
End If
rs.Close
Set rs = Nothing
End Function

解説:

`ForceSaveRecord` プロシージャを標準モジュールに定義することで、再利用性を高めています。
`DoCmd.RunCommand acCmdSaveRecord` を実行すると、フォームの `BeforeUpdate` イベントがトリガーされます。
`BeforeUpdate` イベント内でバリデーションチェックを行い、問題があれば `Cancel = True` で保存を中断します。
`BeforeUpdate` で問題がなければ、`RunCommand acCmdSaveRecord` はレコードを保存し、その後の処理（この例では成功メッセージの表示）に進みます。
`ErrorHandler` では、`BeforeUpdate` でキャンセルされた場合は到達しません。到達するのは、`RunCommand` 自体や、その後の処理で発生した予期せぬエラーです。

パターン2: フォームを閉じる前にレコード保存を強制する (AfterUpdate/BeforeUpdateとの連携)

ユーザーがフォームを閉じようとした際に、保存されていない変更があれば、それを強制的に保存しようとする。これは、データ損失を防ぐための重要な機能だ。

‘ — フォームモジュール —
Private Sub Form_Close()
‘ フォームが閉じられる際に、変更が保存されているか確認
If Me.Dirty Then ‘ Dirtyプロパティは、レコードに変更があった場合にTrueになる
On Error Resume Next ‘ エラーが発生しても続行

‘ レコード保存を試みる
‘ これにより、BeforeUpdateイベントがトリガーされる
DoCmd.RunCommand acCmdSaveRecord

‘ 保存が成功したかどうかの確認は難しいが、
‘ エラーが発生しなければ、保存は試みられたと判断できる。
‘ もしBeforeUpdateでCancel=Trueになった場合、
‘ acCmdSaveRecordは中断されるが、Form_Closeは続行される。
‘ ここでのエラーハンドリングは、あくまでRunCommand自体のエラーを捕らえるためのもの。

If Err.Number <> 0 Then
‘ acCmdSaveRecord実行中にエラーが発生した場合 (BeforeUpdateでキャンセルされた場合とは異なる)
MsgBox “レコード保存中にエラーが発生したため、フォームを閉じられません。”, vbCritical
‘ ここでフォームを閉じないようにする処理を実装することも可能だが、
‘ ユーザー体験を考慮すると、通常は警告のみとする。
‘ 例: Cancel = True (Form_CloseイベントにはCancelプロパティはないため、別の方法が必要)
End If
On Error GoTo 0 ‘ エラーハンドリングを元に戻す
End If
End Sub

‘ — BeforeUpdateイベントはパターン1と同様 —
Private Sub Form_BeforeUpdate(Cancel As Integer)
‘ … (バリデーションロジック) …
If Not IsValidInput(Me.txtSomeField) Then
MsgBox “不正な入力値です。”, vbExclamation
Me.txtSomeField.SetFocus
Cancel = True
End If
End Sub

解説:

`Form_Close` イベントは、フォームが閉じられる直前に発生します。
`Me.Dirty` プロパティで、レコードに変更があるかどうかを確認します。
変更がある場合、 `DoCmd.RunCommand acCmdSaveRecord` を実行し、 `BeforeUpdate` イベントをトリガーしてバリデーションを実行させます。
`On Error Resume Next` は、`BeforeUpdate` で `Cancel = True` となった場合でも、 `acCmdSaveRecord` が中断されるだけで、 `Form_Close` イベント自体は続行されるため、そこでエラーとして処理されないようにするためです。ただし、 `acCmdSaveRecord` 自体や、その後の処理で発生したエラーは `Err.Number` に捕捉されます。

パターン3: レコード移動前にレコード保存を強制する (GotFocus/BeforeUpdateとの連携)

ユーザーが次のレコードに移動しようとした際に、現在のレコードの変更を強制的に保存させる。

‘ — フォームモジュール —
Private Sub Form_Current()
‘ フォームのCurrentイベントは、レコードが切り替わった後に発生する。
‘ ここで保存処理を直接行うのは、ユーザー体験として好ましくない場合がある。
‘ 通常は、Form_BeforeUpdateやボタンクリックで保存を促す。
End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)
‘ … (バリデーションロジック) …
If Not IsValidInput(Me.txtSomeField) Then
MsgBox “不正な入力値です。”, vbExclamation
Me.txtSomeField.SetFocus
Cancel = True
End If
End Sub

‘ 別のレコードに移動する前に、現在のレコードを保存したい場合。
‘ ただし、これはユーザーの意図しない保存を引き起こす可能性もあるため、
‘ 慎重に実装する必要がある。
‘ 一般的には、Form_BeforeUpdateでCancel=Trueを設定し、
‘ ユーザーに修正を促す方が自然な挙動となる。

‘ もし、どうしてもレコード移動前に保存を強制したい場合は、
‘ 例えば、特定のコントロール（例：非表示のボタン）のGotFocusイベントで
‘ RunCommand acCmdSaveRecordを呼び出す、といったトリッキーな方法も考えられる。
‘ しかし、これは前述のBeforeUpdateイベントの活用で十分カバーできるため、
‘ 通常は推奨しない。

‘ 例：特定のコントロール（例：非表示のテキストボックス）にフォーカスが当たった際に保存を試みる
Private Sub txtHiddenTrigger_GotFocus()
‘ BeforeUpdateイベントが発火し、バリデーションチェックが行われる
DoCmd.RunCommand acCmdSaveRecord
‘ ここでエラーが発生した場合（BeforeUpdateでキャンセルされた場合）は、
‘ txtHiddenTriggerにフォーカスが残る可能性が高い。
End Sub

解説:

`Form_Current` イベントはレコードが切り替わった後に発生するため、このイベントで保存処理を行うのは、ユーザーの意図しない保存につながる可能性があります。

より現実的なのは、ユーザーが「保存」ボタンを押す、またはフォームを閉じる際に保存を強制する方法です。
もし、どうしてもレコード移動前に保存を強制したいという特殊な要件がある場合、非表示のテキストボックスなどにフォーカスが当たった際に `DoCmd.RunCommand acCmdSaveRecord` を実行する、といったトリッキーな実装も考えられます。しかし、これはユーザーにとって予期せぬ挙動となり得るため、 `Form_BeforeUpdate` イベントでのバリデーションと、ユーザー操作（ボタンクリック、フォームクローズ）に紐づいた保存処理の強制が、最も堅牢で推奨されるアプローチです。

Windows API、メモリ最適化、レガシー環境保守の観点から

Windows APIとの連携：COMオブジェクトのライフサイクル管理

Access VBAにおける `CurrentDb` や `Application` オブジェクトは、COM（Component Object Model）オブジェクトです。これらのオブジェクトは、使用後に適切に解放（`Set obj = Nothing`）しないと、メモリリークの原因となります。

`DoCmd.RunCommand` は、Accessの内部的なAPIを呼び出していると考えることができます。 `acCmdSaveRecord` を実行する際にも、Accessは内部的にCOMオブジェクトを操作しています。

‘ データベースオブジェクトを明示的に解放する例
Dim db As DAO.Database
Set db = CurrentDb ‘ CurrentDbはApplicationオブジェクトのプロパティ

‘ … データベース操作 …

‘ 操作完了後、オブジェクトを解放
db.Close ‘ 必要に応じてデータベースを閉じる
Set db = Nothing ‘ COMオブジェクトを解放

`DoCmd.RunCommand` を使用する際も、その前後に `Application` オブジェクトや `CurrentDb` オブジェクトの操作があれば、それらのライフサイクル管理を徹底することが、メモリリークを防ぎ、パフォーマンスを維持するために不可欠です。特に、頻繁に `RunCommand` を実行するようなループ処理などでは、この点が顕著に影響します。

メモリ最適化：オブジェクトの明示的解放の重要性

Access VBAアプリケーション、特に大規模なシステムでは、オブジェクトの生成と解放の管理がパフォーマンスに直結します。

`Set obj = Nothing` の徹底: フォーム、レポート、レコードセット、ADO/DAOオブジェクトなど、使用済みのオブジェクトは、スコープを抜ける前に `Set obj = Nothing` で明示的に解放します。
`With…End With` ステートメントの活用: 複数のプロパティやメソッドを一つのオブジェクトに対して使用する場合、`With…End With` で囲むことで、オブジェクトの参照が効率化され、パフォーマンスが向上します。
不要なオブジェクトの早期解放: プロシージャの途中で不要になったオブジェクトは、すぐに解放することで、メモリ使用量を削減できます。

`DoCmd.RunCommand acCmdSaveRecord` は、AccessのUIイベントを模倣する処理であり、内部的には様々なオブジェクトの状態変化を伴います。この処理を頻繁に行う場合、前述のオブジェクト管理が甘いと、メモリ消費が増大し、アプリケーション全体の応答速度が低下する可能性があります。

レガシー環境の保守：互換性と安定性の確保

長年稼働しているAccess VBAシステムは、WindowsのバージョンアップやOfficeのアップデートによって、予期せぬ互換性の問題に直面することがあります。 `DoCmd.RunCommand` は、Accessの組み込みコマンドであるため、比較的高い互換性が期待できます。しかし、それでも以下のような点に注意が必要です。

Accessのバージョン間の差異: 古いバージョンで作成されたデータベースを新しいバージョンで開いた場合、 `RunCommand` の挙動が微妙に変わる可能性はゼロではありません。
Officeのアップデートによる影響: Microsoftのアップデートによって、COMオブジェクトの挙動が変更されることもあり得ます。
セキュリティ設定: マクロのセキュリティ設定によって、 `DoCmd` を含むVBAコードの実行が制限される場合があります。

レガシーシステムを保守する上で最も重要なのは、「現状を維持し、安定稼働させること」です。 `DoCmd.RunCommand acCmdSaveRecord` は、この目的に沿った、比較的安全で信頼性の高い方法と言えます。新しい技術（例：WPFやWinFormsでのデータ入力フォーム）を導入するよりも、既存のAccess VBA環境で、より堅牢な入力・保存メカニズムを実装することに注力すべき場面も少なくありません。

システム間連携：Access VBAから外部システムへのデータ連携

`DoCmd.RunCommand acCmdSaveRecord` は、Accessデータベース内部のデータ整合性を保つための機能ですが、これをシステム間連携の文脈で捉えることもできます。

例えば、Accessデータベースをバックエンドとし、外部のアプリケーション（VB.NET、C#、Webアプリケーションなど）からデータを受け取るシナリオを考えてみましょう。外部アプリケーションからAccessにデータを書き込む際、Access VBAのコードをトリガーして `DoCmd.RunCommand acCmdSaveRecord` を実行させることで、Access側のバリデーションロジックを確実に適用させることができます。

‘ — VB.NET コード例 —
Public Class AccessDataWriter
Private db As Object ‘ ADODB.Connection または DAO.Database

Public Sub New(connectionString As String)
‘ ADODB.Connection を使用する場合
db = New ADODB.Connection
db.Open connectionString
End Sub

Public Sub SaveRecord(data As Dictionary(Of String, Object))
‘ Access VBAのプロシージャを呼び出す
Dim cmd As ADODB.Command = New ADODB.Command
cmd.ActiveConnection = db
cmd.CommandType = adCmdStoredProc ‘ または adCmdText
cmd.CommandText = “Call VBA_SaveRecordProcedure” ‘ VBAのプロシージャ名を指定

‘ パラメータを設定 (必要に応じて)
‘ cmd.Parameters.Append cmd.CreateParameter(“@Param1”, adVarChar, adParamInput, 50, data(“Field1”))
‘ …

cmd.Execute()
End Sub

‘ Access VBA側 (標準モジュール)
‘ Public Sub VBA_SaveRecordProcedure()
‘ Dim frm As Access.Form
‘ Dim db As DAO.Database
‘
‘ Set db = CurrentDb
‘ ‘ フォームを開き、データを設定する（ここでは簡略化）
‘ ‘ DoCmd.OpenForm “frmInputForm”, acNormal, , , acFormAdd, acDialog
‘ ‘ Set frm = Forms!frmInputForm
‘ ‘ frm.txtField1.Value = …
‘
‘ ‘ レコード保存を強制
‘ DoCmd.RunCommand acCmdSaveRecord
‘
‘ ‘ フォームを閉じる
‘ ‘ DoCmd.Close acForm, “frmInputForm”
‘
‘ Set frm = Nothing
‘ Set db = Nothing
‘ End Sub

End Class

この例では、VB.NETからAccess VBAのプロシージャを呼び出し、その中で `DoCmd.RunCommand acCmdSaveRecord` を実行しています。これにより、外部から渡されたデータが、Access VBAの `BeforeUpdate` イベントで定義されたバリデーションを通過することを保証できます。これは、データの一貫性を保つ上で非常に強力な手段となります。

まとめ：確実なデータ保存はシステム信頼性の礎

`DoCmd.RunCommand acCmdSaveRecord` によるレコード保存の強制は、Access VBAにおけるバリデーション漏れを防ぐための、シンプルでありながら極めて強力なテクニックです。このテクニックの真髄は、Accessの内部的なイベント処理フローを理解し、 `BeforeUpdate` イベントを確実にトリガーさせ、そこで定義されたバリデーションロジックを強制的に実行させることにあります。

長年Access VBAシステムやレガシーアーキテクチャの最前線に立ってきた者であれば、この「確実なデータ保存」がいかにシステム全体の信頼性を支える礎となるかを深く理解しているはずです。本稿で解説した内容が、皆様のシステム開発、保守、そして将来にわたる安定稼働の一助となれば幸いです。技術の真髄は、細部に宿る。そして、その細部を極めることこそが、我々エンジニアの責務なのです。