【実務・中級編】フォームのOnOpenとOnLoadの実行順序を完全理解：初期化処理の配置場所によるエラー回避 – Access VBA解析バイブル

Access VBAを掌握する極限の知見：OnOpenとOnLoadの「本当の実行順序」と、バグを根絶する初期化配置の極意

こんにちは。開発プロジェクトの現場において、数々のAccess巨大システムをリファクタリングしてきたチーフアーキテクトの私だ。

Accessで開発をしていて、最も頻繁に遭遇する不可解なバグの一つが、フォームのオープン時に発生する実行時エラー、あるいは「コントロールに値を入れたはずなのに消える・反映されない」という怪現象だ。その多くは、`OnOpen` と `OnLoad` という2つのイベントのライフサイクルの違いを理解していないことに起因している。

「なんとなく動くから」と、コントロールの初期化処理を `OnOpen` に書き散らし、データ操作を `OnLoad` に混ぜ返す……。そんな場当たり的な設計は、システムが大規模化・複雑化した瞬間に破綻する。

今回は、Accessのオブジェクトモデルの深層に踏み込み、これら2つのイベントの決定的な違いと、プロとして絶対に守るべき初期化配置の鉄則をロジカルかつシャープに伝授しよう。

—

1. ライフサイクルの真実：OnOpen と OnLoad は何が違うのか？

まず、フォームが開く瞬間にAccessの内部エンジンで何が起きているのか、そのタイムラインを正確に把握してほしい。

イベントの発生順序は厳密にこうだ。

1. `OnOpen` （データ未ロード・コントロール未バインド）
2. レコードソースの読み込み（データがフォームにバインドされる）
3. `OnLoad` （コントロール生成完了・データ配置完了）
4. `OnResize` / `OnActivate`

この順序を見ただけで、プロなら直感的に「どちらに何を書くべきか」が分かるはずだ。

`OnOpen` の本質：フォームの「門番」

`OnOpen` は、フォームが画面に描画される前、そしてデータベースからレコードソース（テーブルやクエリ）が読み込まれる前に発生する。
ここでの最大の武器は、イベントプロシージャ内で `Cancel = True` を指定することで、フォームのオープン自体をキャンセルできるという点だ。

`OnLoad` の本質：UIとデータの「調停者」

`OnLoad` は、レコードソースが読み込まれ、すべてのコントロール（テキストボックス、コンボボックス等）がメモリ上に実体化し、データがバインドされた直後に発生する。
ここでは既にコントロールが生きており、データも流し込まれているため、UIの初期状態の構築や動的な書式設定を行うのに最適なタイミングとなる。

—

2. なぜそのエラーは起きるのか？「やってはいけない」アンチパターン

現場でよく見かける悪手を見てみよう。

• アンチパターンA：`OnOpen` でコントロールの値を操作する
• `Me.txtUserName = “管理者”` と `OnOpen` に書く。
• 結果： コントロールがまだ完全に初期化されていない、あるいはレコードソースのバインド前であるため、予期せぬエラー（実行時エラー 2448: 「このオブジェクトに値を代入することはできません」など）が発生するか、後からバインドされたレコードデータの値で上書きされて消滅する。
• アンチパターンB：`OnOpen` で処理をキャンセルしたいのに `OnLoad` で書く
• 条件不一致でフォームを開きたくないのに、`OnLoad` で `DoCmd.Close` を実行する。
• 結果： 一瞬フォームが画面に表示されてから閉じるという、極めてユーザビリティの低い挙動（画面のちらつき）を引き起こす。

—

3. 【プロダクションコード】バグを根絶するイベント配備の設計

では、実務でそのまま使える堅牢なコードパターンを提示しよう。
ここでは、「親フォームから渡された引数（OpenArgs）を検証して不正なら開きをキャンセル（OnOpen）」し、「画面上のコントロールの動的な初期化とユーザー権限に応じた制御（OnLoad）」を行う実例だ。

Option Compare Database
Option Explicit

‘ ==============================================================================
‘ イベント名 : Form_Open
‘ 目的 : フォーム起動の可否判定（キャンセル制御）とグローバル変数の初期受渡
‘ 実行タイミング: レコードソースが読み込まれる前（コントロールはまだ触れない）
‘ ==============================================================================
Private Sub Form_Open(Cancel As Integer)
On Error GoTo ErrorHandler

Dim strParam As String
strParam = Nz(Me.OpenArgs, “”)

‘ 1. セキュリティ/前提条件チェック：引数が空なら起動を阻止
If strParam = “” Then
MsgBox “不正な呼び出しです。このフォームは直接開けません。”, vbCritical, “システムエラー”
Cancel = True ‘ フォームのオープンを完全にキャンセル
Exit Sub
End If

‘ 2. 検索条件の動的変更（レコードソースを変更する場合の布石）
‘ ※注意: ここではSQLの書き換えやFilterプロパティのベース設定を行う
Me.Filter = “DepartmentCode = ‘” & strParam & “‘”
Me.FilterOn = True

Exit Sub

ErrorHandler:
MsgBox “Form_Openで予期せぬエラーが発生しました: ” & Err.Description, vbCritical
Cancel = True
End Sub

‘ ==============================================================================
‘ イベント名 : Form_Load
‘ 目的 : コントロールの初期値設定、UIの動的制御、外観の構築
‘ 実行タイミング: データがバインドされ、コントロールが完全に実体化した後
‘ ==============================================================================
Private Sub Form_Load()
On Error GoType ErrorHandler

‘ 1. コントロールへの初期値代入（安全にバインド済みコントロールを操作）
Me.txtDisplayInfo.Value = “現在選択中の部門データ”

‘ 2. ユーザー権限に応じたUIのロック制御（実務で頻出）
Call ApplyUserPermissions

‘ 3. コンボボックスのリスト初期選択など
If Me.cmbStatus.ListCount > 0 Then
Me.cmbStatus.Value = Me.cmbStatus.ItemData(0)
End If

Exit Sub

ErrorHandler:
MsgBox “Form_Loadで予期せぬエラーが発生しました: ” & Err.Description, vbCritical
End Sub

‘ ==============================================================================
‘ 内部プロシージャ : 権限に応じたUI制御
‘ ==============================================================================
Private Sub ApplyUserPermissions()
‘ 例：一般権限なら一部ボタンを無効化
If Not CurrentUserHasAdminRight() Then
Me.cmdDeleteRecord.Enabled = False
Me.cmdDeleteRecord.ForeColor = RGB(180, 180, 180)
End If
End Sub

Private Function CurrentUserHasAdminRight() As Boolean
‘ ダミーの権限判定関数（実際は環境に合わせて実装）
CurrentUserHasAdminRight = False
End Function

この設計が堅牢である理由

1. 責務の完全な分離：`OnOpen` は「門番（ガード句とデータ構造の準備）」、`OnLoad` は「インテリアデザイナー（UIの構築とデータ反映後の見栄え調整）」と役割が明確化されている。
2. 無駄な描画とエラーの排除：不正なアクセスは画面を描画する前に `OnOpen` の `Cancel = True` で弾くため、画面のチラつきや不要なクエリ発行コストが発生しない。
3. 保守性の高さ：後からメンテナンスする開発者が「コントロールを触るのは Load、フォーム自体の起動制御は Open」という共通認識を持てるため、属人性を排除できる。

—

4. チーフアーキテクトからの最終提言

Access VBAの開発現場において、「動けばいいや」というコードは、数ヶ月後に必ず自分（あるいは後任のエンジニア）の首を絞めること偶発的なモンスターと化す。

フォームのライフサイクル、特に `OnOpen` と `OnLoad` の境界線を制する者は、Accessフォームの挙動を制する。次に新しいフォームを作る時は、指先を止めてこう自問してほしい。

「今書こうとしているその処理は、データを読み込む前（Open）にやるべきか？ それとも、コントロールが顕現した後（Load）にやるべきか？」

この問いに対するロジカルな選択こそが、プロとアマを分かつ最大の境界線である。あなたの作る業務システムが、堅牢で美しいアーキテクチャに満たされることを期待している。