Access VBAを掌握する極限の知見：フォーム初期化の深層 — `OnOpen` と `OnLoad` の非対称性を制する者だけがシステムを支配する
長年、エンタープライズの現場でレガシーシステムと格闘してきたエンジニアなら、一度はAccessのフォームが意図せぬタイミングで暴発し、`Run-time error 2450` や `2427`（オブジェクトが見つからない、またはNullの評価エラー）の泥沼にハマった経験があるはずだ。
「なぜ、コントロールに値を代入しようとした瞬間にエラーが出るのか？」
「なぜ、ある環境では動くコードが、別環境やレコードソースの変更時に突然クラッシュするのか？」
その答えは、Accessフォームのライフサイクル、特に `Open` イベント と `Load` イベント の厳密な実行順序と、VBAオブジェクトモデルのメモリ上の挙動を理解しているか否かにかかっている。
今回は、Accessの深部まで知り尽くしたチーフアーキテクトの視点から、この2つのイベントの非対称性を完全に解剖し、破綻のない堅牢な初期化処理のアーキテクチャを提示する。
—
1. フォームライフサイクルの真実：Open と Load の決定的な違い
多くの初学者、あるいは我流でVBAを覚えてきたプログラマーは、「フォームを開くときはとりあえず `OnOpen` に書いておけばいい」と誤解している。これがバグの温床だ。
Accessのフォームが開かれる際、イベントは以下の不可逆な順序で発火する。
1. `Open` イベント (`Form_Open(Cancel As Integer)`)
2. `Load` イベント (`Form_Load()`)
3. `Resize` イベント
4. `Current` イベント (`Form_Current()`)
この連鎖において、それぞれのイベントが担当する「責務」の境界線を明確に引かねばならない。
`Open` イベントの正体：門番とキャンセル権
`Open` イベントは、フォームウィンドウが画面に描画される前、そしてレコードソース（テーブルやクエリ）がバインドされる直前に発生する。
特筆すべきは、このイベントのみが `Cancel As Integer` 引数を持っていることだ。つまり、「このフォームを開くべきか否か」を判断するキャンセル権が与えられている。
- 適した処理:
- 外部パラメータ（`OpenArgs`）の検証と、不正な呼び出しの遮断（`Cancel = True`）
- 権限チェックによるアクセス拒否
- 非バインドフォームにおける初期設定
`Load` イベントの正体：器と中身の同期
`Load` イベントは、フォームとその配下のすべてのコントロール（コントロールオブジェクト）がメモリ上にインスタンス化され、レコードソースへの接続が完了した直後に発生する。ただし、この時点ではまだ最初のレコードの `Current` イベントは発生していない。
- 適した処理:
- コントロールへの初期値設定（非バインドコントロール）
- 動的なレコードソース（`RecordSource`）やコントロールの `RowSource` の書き換え
- API呼び出しや外部リソースとの初期同期
—
2. なぜ `Open` でコントロールをいじると死ぬのか？
現場で最もよく見る悪手は、`Form_Open` の中でテキストボックスやコンボボックスのプロパティ（`Me.MyControl.Value` や `Me.MyControl.RowSource` など）を操作するコードだ。
‘ 【アンチパターン】絶対にやってはいけない例
Private Sub Form_Open(Cancel As Integer)
‘ エラーの原因：この瞬間、コントロールはまだメモリ上に実体を持っていない！
Me.cboCategory.RowSource = “SELECT ID, Name FROM T_Categories”
Me.txtInput.Value = “Default”
End Sub
このコードを実行すると、環境によっては運良く動くように見えることがある。しかし、マルチユーザー環境、データ量が多い状態、あるいはネットワーク経由のA/D環境（Access Runtime等）において、確率でエラー 2450（フォームまたはレポートが見つかりません）やエラー 2470 が発生する。
理由:
`Open` イベントの時点では、Accessの内部エンジンは「フォームという器」の定義を読み込んでいる最中であり、コントロール群のCOMオブジェクトとしてのインスタンス化（実体化）が完了していない。存在しないメモリ領域にアクセスしようとするため、VBAランタイムが悲鳴を上げるのだ。
—
3. 極限のベストプラクティス：安全な初期化処理の設計
真に堅牢なAccessシステムでは、初期化処理を `Open` と `Load` に適切に分散・カプセル化する。さらに、メモリの寿命（ライフサイクル）を意識したオブジェクト解放の作法を徹底する。
以下に、実業務でそのまま使える洗練されたフォームモジュールのテンプレートを示す。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ フォームモジュール: frm_SecureOrderEntry
‘ 概要: ライフサイクルを完全に制御した堅牢な初期化・データバインド処理
‘ ==============================================================================
Private Sub Form_Open(Cancel As Integer)
On Error GoTo ErrorHandler
‘ 1. Openの責務：OpenArgsの検証と不正アクセスの遮断
If Not ValidateOpenArgs(Me.OpenArgs) Then
MsgBox “不正な呼び出しです。処理を中止します。”, vbCritical, “システムエラー”
Cancel = True ‘ フォームの展開を確実にキャンセル
Exit Sub
End If
Exit Sub
ErrorHandler:
Call LogError(Err.Number, Err.Description, “Form_Open”)
Cancel = True
End Sub
Private Sub Form_Load()
On Error GoTo ErrorHandler
‘ 2. Loadの責務：コントロールの動的構築と初期値の設定
‘ この時点ではすべてのコントロール実体がメモリ上に保証されている
‘ コンボボックスのRowSource動的割り当て
Call InitializeComboBoxes
‘ フォームのモードに応じたUI制御
Call ConfigureUIState
Exit Sub
ErrorHandler:
MsgBox “フォームの初期化に失敗しました: ” & Err.Description, vbCritical, “致命的エラー”
‘ Loadイベント内ではCancelプロパティが使えないため、Unloadを誘導するか、
‘ アプリケーションの安全な縮退を考慮する
End Sub
Private Function ValidateOpenArgs(ByVal args As Variant) As Boolean
‘ OpenArgsの型チェックとビジネスロジック検証
If IsNull(args) Or Trim(CStr(args)) = “” Then
ValidateOpenArgs = False
Exit Function
End If
‘ 例: 期待されるプレフィックスが含まれているか
If Left(CStr(args), 4) <> “ORD-” Then
ValidateOpenArgs = False
Exit Function
End If
ValidateOpenArgs = True
End Function
Private Sub InitializeComboBoxes()
Dim db As DAO.Database
Dim rs As DAO.Recordset
On Error GoTo CleanUp
Set db = CurrentDb
‘ 高速化とメモリ最適化のため、必要最小限のクエリを発行
Me.cboClient.RowSource = “SELECT ClientID, ClientName FROM M_Clients WHERE IsActive = True ORDER BY ClientName;”
Me.cboClient.RowSourceType = “Table/Query”
CleanUp:
‘ DAOオブジェクトの明示的解放（メモリリークの根絶）
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
Set db = Nothing
End Sub
Private Sub ConfigureUIState()
‘ ユーザー権限に応じたコントロールの制御
Dim userRole As String
userRole = GetUserRole() ‘ 独自関数
If userRole = “Guest” Then
Me.btnApprove.Enabled = False
Me.txtComments.Locked = True
End If
End Sub
—
4. シニアエンジニアが知るべき「メモリ管理」と「API連携」の罠
Access VBAはガベージコレクタの挙動がブラックボックス化しやすく、不適切なコードを書くと確実にメモリリーク（メモリ肥大化）を引き起こす。特に、フォームのロード・アンロードを頻繁に繰り返す大規模システムでは致命傷となる。
DAO/ADOオブジェクトの「常時明示的解放」の鉄則
先ほどのコードでも示した通り、`CurrentDb` や `DAO.Recordset` を扱う際は、必ずローカル変数に受けて、プロシージャの最後で `Set xxx = Nothing` を明示しなければならない。
特に `CurrentDb` は呼び出すたびに新しいデータベースインスタンスをメモリ上に生成するため、ループ内や頻繁に走るイベント内で安易に `CurrentDb.OpenRecordset` を書くのは、メモリリークの最大の原因となる。
ウィンドウ制御におけるWindows API（User32.dll）の活用
高度な業務システムでは、Access標準のフォームだけでなく、Windows APIを叩いてフォームの振る舞いを制御することが求められる。
例えば、フォームのロード完了時（`Load` または `Current`）に、特定のモーダル制御やウィンドウの最大化制御をAPI経由で行う場合、やはり `Open` 時点ではウィンドウハンドル（`hWnd`）が安定していないため、処理のタイミングは `Load` 以降でなければならない。
‘ 32bit/64bit環境両対応のAPI宣言の極意
If VBA7 Then
Private Declare PtrSafe Function ShowWindow Lib “user32” (ByVal hwnd As LongPtr, ByVal nCmdShow As Long) As Long
Else
Private Declare Function ShowWindow Lib “user32” (ByVal hwnd As Long, ByVal nCmdShow As Long) As Long
If
こうしたAPIを組み込む際も、フォームのコントロールと同様に「対象のオブジェクトが完全にメモリ上に実体化している状態（`Load` イベント以降）」が絶対条件となる。
—
総括
Access VBAは「おもちゃの言語」と揶揄されることがある。しかし、その内部構造（Jet/ACEデータベースエンジン、COMコンポーネントのライフサイクル）の本質を理解したエンジニアが書いたAccessシステムは、堅牢であり、驚異的なまでの高速稼働を実現する。
- 「開くべきか」の判定は `Open` で行い、 `Cancel = True` で門前払いする。
- 「中身の構築・初期化」は、コントロールが実体化した後の `Load` で確実に行う。
- リソースは必ず明示的に解放し、メモリリークを許さない。
この鉄則を死守することで、あなたのAccessアプリケーションは、予期せぬエラーから解放され、エンタープライズの現場に耐えうる「真の基幹システム」へと昇華する。
