Access VBAを掌握する極限の知見：OpenArgsとJSONによる画面間パラメータ制御の極意
レガシーシステムの寿命を延ばし、その限界領域を突破し続けること――それが我々シニアエンジニアの責務だ。
Microsoft Accessは、適切に飼い慣らせば今なお中小規模の業務システムにおいて最強のラピッド開発プラットフォームであり続ける。しかし、そのアーキテクチャの古さは隠せない。特にフォーム間でパラメータを受け渡す際、`DoCmd.OpenForm`の`OpenArgs`引数は、長年「ただ一つの文字列しか渡せない」という致命的な制約を抱えてきた。
複数の条件、モード、親フォームの参照IDなどを渡したいがために、グローバル変数に依存したり、フォームのコントロールに値を隠蔽したりといった、スパゲッティコードの温床を作ってはいないか？
今回は、`OpenArgs`にJSON文字列を流し込み、画面間の複雑なパラメータ制御を一括管理する極限のテクニックを授ける。さらに、Access標準機能の限界を超えるためのメモリ管理や、外部パーサに頼らない堅牢な実装の神髄を解説する。
—
1. なぜ「OpenArgs × JSON」なのか？
`OpenArgs`のデータ型は `Variant (String)` である。これは「文字列であれば何でも詰め込める」という巨大なポテンシャルを秘めている。
従来、複数のパラメータを渡すためにカンマ区切りやパイプ区切り（`ID=1|Mode=Edit|Parent=frmMain`）が使われてきたが、これらは拡張性に乏しく、エスケープ処理や順序依存のバグを生みやすい。
ここにJSON（JavaScript Object Notation）を導入する。キー・バリューのペア構造、ネスト、配列をそのまま文字列化して放り込み、受け手側でデシリアライズする。これにより、インターフェースの契約（Contract）が劇的にクリーンになる。
しかし、VBAには標準でJSONパーサが存在しない。ここで外部の巨大なライブラリを持ち込むのは、配布や保守の観点からAccessの機動性をスポイルする。求めるべきは、「VBA単体で完結し、かつメモリリークを起こさない軽量・堅牢な構造」である。
—
2. 実装アーキテクチャ：JSONパーサと基底クラスの設計
まずは、複雑なJSONをVBAの`Scripting.Dictionary`に変換するエンジン、およびそれを安全にハンドリングするフォームのライフサイクル設計を示す。
2.1 堅牢なJSONパース（簡易VBA実装）
実務上、すべての環境に外部DLLやCOMコンポーネントが導入できるわけではない。ここでは正規表現（VBScript.RegExp）を利用した、実用的な軽量パーサのコアスニペットを示す。
‘ Option Explicit は絶対の掟
Option Explicit
‘ 依存関係: Microsoft Scripting Runtime
‘ 依存関係: Microsoft VBScript Regular Expressions 5.5
Public Function ParseJsonToDictionary(ByVal jsonStr As String) As Scripting.Dictionary
Dim dict As New Scripting.Dictionary
Dim regEx As New VBScript.RegExp
Dim matches As VBScript.MatchCollection
Dim match As VBScript.Match
‘ 空文字列のガード
If Trim(jsonStr) = “” Then
Set ParseJsonToDictionary = dict
Exit Function
End If
‘ キーと値（文字列または数値）を抽出する正規表現パターン
‘ ※極限までシンプル化された実用パターン
regEx.Pattern = “””([^””]+)””:\s(“”([^””])””|([0-9\.\-]+|true|false|null))”
regEx.Global = True
regEx.IgnoreCase = True
Set matches = regEx.Execute(jsonStr)
For Each match In matches
Dim key As String
Dim val As String
key = match.SubMatches(0)
If match.SubMatches(2) <> “” Then
‘ 文字列値の場合
val = match.SubMatches(2)
Else
‘ 数値・ブール値の場合
val = match.SubMatches(3)
End If
If Not dict.Exists(key) Then
dict.Add key, val
End If
Next match
Set ParseJsonToDictionary = dict
End Function
—
3. 呼び出し元（Caller）のデザイン
フォームを呼び出す側では、パラメータを匿名オブジェクト（風の文字列）として構築し、`OpenArgs`に載せる。
‘ 顧客詳細フォームを編集モードで呼び出すサンプル
Public Sub OpenCustomerEditForm(ByVal customerID As Long, ByVal editMode As String)
Dim jsonArgs As String
‘ JSON文字列の手動構築（エスケープ考慮）
jsonArgs = “{” & _
“””Action””: “”Edit””,” & _
“””CustomerID””:” & customerID & “,” & _
“””CallerForm””: “”” & Me.Name & “””,” & _
“””AccessLevel””: 2″ & _
“}”
‘ DoCmdによるフォームオープン
DoCmd.OpenForm _
FormName:=”frmCustomerDetail”, _
View:=acNormal, _
WindowMode:=acWindowNormal, _
OpenArgs:=jsonArgs
End Sub
ここで重要なのは、呼び出し元が「相手がどう初期化されるか」を知る必要がないという点だ。すべては受け取る側のフォーム内で完結する。
—
4. 受け手（Receiver）での一括パラメータ制御とライフサイクル
ここからが本題だ。Accessのフォームイベントにおいて、`OpenArgs`を解析し、コントロールの初期化を行う最適なタイミングはどこか？
答えは `Form_Open` イベント である。`Form_Load` ではすでにレコードソースの評価が始まっており、パラメータに基づいたクエリの動的変更やキャンセル（`Cancel = True`）を行うには遅すぎる。
以下のコードは、受け側フォームにおける極限まで最適化された初期化ルーチンの実装例である。
Option Explicit
‘ フォーム全体で保持するパラメータ用Dictionary
Private m_Params As Scripting.Dictionary
Private Sub Form_Open(Cancel As Integer)
On Error GoTo ErrorHandler
‘ 1. OpenArgsの存在確認とパース
If IsNull(Me.OpenArgs) Or Len(Me.OpenArgs) = 0 Then
‘ パラメータなしで開かれた場合のデフォルト挙動
Set m_Params = New Scripting.Dictionary
m_Params.Add “Action”, “New”
Else
‘ 抽出・パース実行
Set m_Params = ParseJsonToDictionary(CStr(Me.OpenArgs))
End If
‘ 2. パラメータに基づいた一括制御の執行
ExecuteParameterInitialization
Exit Sub
ErrorHandler:
MsgBox “フォームの初期化に失敗しました: ” & Err.Description, vbCritical, “システムエラー”
Cancel = True ‘ 不正な引数の場合はフォームのオープン自体をキャンセル
End Sub
Private Sub ExecuteParameterInitialization()
Dim action As String
If m_Params.Exists(“Action”) Then
action = m_Params(“Action”)
Else
action = “New”
End If
Select Case action
Case “Edit”
If m_Params.Exists(“CustomerID”) Then
‘ レコードの絞り込み（RecordSourceの動的変更）
Me.RecordSource = “SELECT FROM T_Customers WHERE CustomerID = ” & CLng(m_Params(“CustomerID”))
End If
Me.AllowAdditions = False
Me.Caption = “顧客情報 編集モード”
Case “New”
Me.RecordSource = “SELECT FROM T_Customers WHERE 1=0” ‘ 空のレコードセット
Me.AllowAdditions = True
Me.Caption = “顧客情報 新規登録”
Case Else
Err.Raise 9999, , “未定義のアクションが指定されました: ” & action
End Select
‘ 権限や呼び出し元に応じた追加制御
If m_Params.Exists(“AccessLevel”) Then
If CInt(m_Params(“AccessLevel”)) < 2 Then
Me.AllowDeletions = False
Me.cmdDelete.Visible = False
End If
End If
End Sub
---
5. メモリ最適化とオブジェクトの明示的解放（The Architecture of Garbage）
VBAはCOMベースの参照カウント方式（Reference Counting）を採用しているが、循環参照やローカルでないオブジェクトの放置は、長期間稼働するAccessランタイムにおいて致命的なメモリリーク（Memory Leak）を引き起こす。特にフォームのライフサイクルが終わる際、保持したオブジェクトは確実に破棄しなければならない。
Private Sub Form_Unload(Cancel As Integer)
‘ フォーム閉鎖時の厳格なメモリ解放
If Not m_Params Is Nothing Then
m_Params.RemoveAll
Set m_Params = Nothing
End If
‘ アクセスVBA特有のガベージシュリンクを促すためのロギングや処理（必要に応じて）
End Sub
プロフェッショナルであれば、`Form_Open` で生成したインスタンスは、必ず `Form_Unload`（または `Form_Close`）の対となるライフサイクルで `Nothing` を代入するコードを義務づけるべきだ。この規律の欠如が、数日稼働しただけでメモリを食いつぶす「愚かなシステム」を生む原因となる。
—
総括：レガシーの殻を破るエンジニアリング
Access VBAという枯れた技術であっても、アーキテクチャの設計思想次第でモダンなアプリケーションに匹敵する堅牢性と拡張性を手に入れることができる。
`OpenArgs` にJSONを詰め込み、パラメータ制御を中央集権化するこの手法は、コードの重複を排除し、画面間の結合度を劇的に下げる。
場当たり的な修正で延命されたシステムに別れを告げよ。真のエンジニアリングとは、制約の中で最大限の合理性と美しさを追求することに他ならない。あなたの手元にあるそのAccessアプリも、適切な設計のメスを入れれば、まだ何年もの間、現場を支え続ける強力なエンジンになり得るのだ。
