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

Access VBAを掌握する極限の知見：フォームのOnOpenとOnLoadの実行順序がもたらす破滅と、それを回避する設計論

レガシーシステムの最前線に立ち続ける我々にとって、Accessは時として狂気を孕んだ巨大なブラックボックスとなる。その最たるものが、フォームのライフサイクル、特に `OnOpen` と `OnLoad` の微細な挙動の差が生むエラーの連鎖だ。

「なぜこの初期化コードは、ある環境では動き、別の環境では `エラー 2450: 指定したフォームが開いていません` を吐くのか？」
「なぜレコードソースの動的書き換えが、時としてコントロールのイベントを暴走させるのか？」

表面的なリファレンスをなぞるだけの知識は、現場の泥臭いマルチユーザー環境や、肥大化したMDB/ACCDBの前では無力に等しい。本稿では、Accessオブジェクトモデルの深層に踏込み、イベントのライフサイクルとメモリ管理、そして実務で生き残るための「真の初期化配置論」をコードとともに叩き込む。

—

1. イベントのライフサイクル：OpenとLoadの不可逆的な境界

フォームが画面に描画されるまでのプロセスにおいて、Accessエンジン（ACE）内部では厳密な順序でイベントが発火する。この順序を誤認することは、時限爆弾を抱えてコードを書くことに等しい。

正確な実行順序と内部状態

1. `OnOpen` (開く時)

• 状態: ウィンドウハンドル（hWnd）はまだ生成されていない。レコードソース（テーブルやクエリ）のバインドも完了していない。
• キャンセル性: 唯一、`Cancel = True` を使ってフォームのオープン自体を中止できるイベント。
• 主な用途: ユーザー権限のチェック、グローバル変数に基づく条件分岐、オープン引数 (`OpenArgs`) の検証と初期ガード。

2. `OnLoad` (読み込み時)

• 状態: レコードソースのバインドが完了し、各コントロールのインスタンスがメモリ上に展開されている。しかし、画面上の描画（Paint）はまだ行われていない。
• キャンセル性: なし（ここでの `Cancel` は無効、またはエラーになる）。
• 主な用途: コントロールのプロパティ動的変更、コンボボックスの行ソース（RowSource）の動的生成、子フォーム（サブフォーム）との同期。

3. `OnResize` / `OnCurrent`

• 状態: 画面描画が始まり、最初のレコードにフォーカスが当たった状態。

> チーフアーキテクトの警告:
> 「まだ実体化していないコントロール（テキストボックスやサブフォーム）のプロパティやメソッドに `OnOpen` 内でアクセスしてはならない」。これがAccess開発における第一の戒律である。

—

2. 現場で頻発するアンチパターンとクラッシュのメカニズム

多くの開発者が陥る罠は、「フォームを開くのだから、その中の部品もすべて存在しているはずだ」という素朴な誤解だ。

典型的な破滅コード

‘ 【アンチパターン】OnOpenイベントでのコントロール操作
Private Sub Form_Open(Cancel As Integer)
‘ ❌ 致命傷：OnOpen時点では、txtUserBoxはまだメモリ上に正しくインスタンス化されていない
‘ ここでアクセスすると、実行時エラーまたは不定な挙動を引き起こす
Me.txtUserBox = Environ(“USERNAME”)

‘ ❌ 致命傷：サブフォームのコントロールを操作しようとする試み
Me.subForm.Form.RecordSource = “SELECT FROM T_Log WHERE…”
End Sub

このコードが孕むリスクは単なるエラーに留まらない。最悪の場合、Accessの内部メモリ構造（COMコンポーネントの参照カウンタ）に矛盾が生じ、`.accdb` 自体の破損（Corruption）を引き起こすトリガーとなる。

—

3. 極限の最適化：役割を厳密に分離した安全な設計コード

では、実務において `OnOpen` と `OnLoad` をどのように使い分けるべきか。正解は、「フォーム自体の制御は `Open`、内部のデータとコントロールの制御は `Load`」という明確な分離にある。

以下の実装パターンは、数百万レコードを抱える基幹システムでもビクともしない、極めて堅牢な初期化ルーチンのテンプレートである。

Option Compare Database
Option Explicit

‘ =========================================================================
‘ フォーム名: frm_SecureOrderEntry
‘ 概要: 堅牢なライフサイクル管理による受注入力フォーム
‘ =========================================================================

Private Sub Form_Open(Cancel As Integer)
On Error GoTo ErrorHandler

‘ 【指針1】Openイベントは「ガード条件の検証」と「大域的設定」に限定する

‘ 例1: OpenArgsによる不正な直接起動の防止
If IsNull(Me.OpenArgs) Then
MsgBox “不正なアクセスです。メインメニューから起動してください。”, vbCritical, “システムエラー”
Cancel = True ‘ フォームのオープンを確実にキャンセル
Exit Sub
End If

‘ 例2: セキュリティ権限チェック（API等を用いた高度な検証もここに置く）
If Not HasExecuteAuthority(CInt(Me.OpenArgs)) Then
MsgBox “この機能を実行する権限がありません。”, vbExclamation, “アクセス拒否”
Cancel = True
Exit Sub
End If

Exit Sub

ErrorHandler:
Call LogSystemError(“Form_Open”, Err.Number, Err.Description)
Cancel = True
End Sub

Private Sub Form_Load()
On Error GoTo ErrorHandler

‘ 【指針2】Loadイベントは「コントロールの初期化」と「データソースの構築」を行う
‘ この時点では、すべてのコントロールがメモリ上に存在することが保証されている。

‘ 例1: コントロールの初期値設定
Me.txtUserBox = Environ(“USERNAME”)
Me.txtLoginTime = Now()

‘ 例2: コンボボックスの動的RowSource設定（パフォーマンス最適化）
Call InitializeComboBoxes

‘ 例3: サブフォームの動的連携
Me.subDetail.Form.RecordSource = “SELECT FROM T_OrderDetail WHERE OrderID = ” & Me.txtOrderID.Value
Me.subDetail.Form.Requery

Exit Sub

ErrorHandler:
Call LogSystemError(“Form_Load”, Err.Number, Err.Description)
MsgBox “フォームの初期化中に致命的なエラーが発生しました。” & vbCrLf & Err.Description, vbCritical
End Sub

‘ — ヘルパープロシージャ群 —

Private Function HasExecuteAuthority(ByVal permissionLevel As Integer) As Boolean
‘ ダミーの権限チェックロジック（実際にはDBやActiveDirectoryを叩く）
HasExecuteAuthority = (permissionLevel >= 2)
End Function

Private Sub InitializeComboBoxes()
Dim strSQL As String
strSQL = “SELECT MasterID, DisplayName FROM M_Category WHERE Active = True ORDER BY SortOrder;”

With Me.cmbCategory
.RowSourceType = “Table/Query”
.RowSource = strSQL
.Requery
End Sub
End Sub

Private Sub LogSystemError(ByVal procName As String, ByVal errNum As String, ByVal errDesc As String)
‘ 堅牢なエラーロジック（ファイル出力やシステムログテーブルへの書き込み）
Debug.Print “[” & Now() & “] Error in ” & procName & “: ” & errNum & ” – ” & errDesc
End Sub

—

4. チーフアーキテクトからの提言：メモリ管理とオブジェクトの明示的解放

Access VBAのガベージコレクションは完全ではない。特にDAOやADOを用いたレコードセットの操作、あるいは外部COMオブジェクト（ExcelやOutlookなど）の操作をフォームの初期化時に行う場合、参照の解放漏れがメモリリークを引き起こし、最終的にAccessのプロセスをクラッシュさせる。

もし `OnOpen` や `OnLoad` の中でクエリやレコードセットを扱う場合は、必ず以下のイディオムを遵守せよ。

Private Sub SafeRecordsetInitialization()
Dim db As DAO.Database
Dim rs As DAO.Recordset

On Error GoTo CleanUp

Set db = CurrentDb ‘ CurrentDbは呼び出すたびに新規インスタンスを生成するため変数に保持する
Set rs = db.OpenRecordset(“T_MasterConfig”, dbOpenSnapshot)

If Not rs.EOF Then
Me.txtConfigValue.Value = rs!ConfigValue.Value
End If

CleanUp:
‘ 逆順での明示的なオブジェクト解放
If Not rs is Nothing Then
rs.Close
Set rs = Nothing
End If

‘ DAO.DatabaseのCurrentDbラッパーは明示的Close不要だが、変数の破棄は行う
Set db = Nothing

If Err.Number <> 0 Then
Err.Raise Err.Number, , Err.Description
End If
End Sub

`CurrentDb` をプロシージャ内で何度も呼び出す愚を犯してはならない。それはヒープメモリを圧迫し、パフォーマンスを著しく低下させる悪臭（Bad Smell）そのものだ。

—

5. 総括

フォームの `OnOpen` と `OnLoad` の違いは、単なる「タイミングの差」ではない。それは「実体化の前と後」という、Accessオブジェクトモデルにおける厳然たる境界線である。

• `OnOpen`：門番の領域。通すか、追い返すか（Cancel）。
• `OnLoad`：構築士の領域。家具を配置し、配線を繋ぐ（コントロール・データの初期化）。

この責務分離を徹底し、メモリのライフサイクルに敬意を払ったコードを書く者だけが、Accessという暴れ馬を完全に手懐けることができる。プロフェッショナルであれば、感覚的なコーディングを捨て去り、アーキテクチャの理に従った堅牢なシステムを構築し続けなければならない。