Access VBAの「OpenArgs」を使い倒せ：JSONによる構造化パラメータ設計の極意
Access開発で避けて通れない「画面遷移」。多くの開発者が、特定のIDを渡すために`OpenArgs`を使い、フラグが増えるたびに「第二引数、第三引数…」と関数を拡張して自爆していく。
断言しよう。`DoCmd.OpenForm`の引数で拡張性を担保しようとするのは悪手だ。VBAの引数はあくまでシンプルに保つべきであり、「複数の設定値」は「一つの構造化された文字列」に封じ込めるのが、スケーラブルなシステムの鉄則である。
今回は、Accessの`OpenArgs`にJSONを流し込み、複雑な画面状態を完全に制御する「プロフェッショナルな設計術」を伝授する。
—
1. なぜ「単一の引数」にこだわるべきか
Accessの画面遷移において、OpenArgsは唯一の「呼び出し元から子画面への通信路」だ。ここに「ID=123, Mode=Edit, Theme=Blue」といった情報を羅列して`”123;Edit;Blue”`のように渡すのは、保守の地獄への入り口である。
- 順序依存の脆弱性: 途中でパラメータが増えると、既存の呼び出し元コードがすべて破壊される。
- パースの複雑化: `Split`関数で切り出してインデックスでアクセスするコードは、読み解くのに脳のリソースを浪費する。
JSONを採用すれば、キーと値のペアで管理できるため、「必要なパラメータだけを渡す」という疎結合な設計が実現できる。
—
2. 実装の要：JSONパースの戦略
Accessには標準でJSONパーサーが存在しない。ここで「自作のパース関数」に時間をかけるのはナンセンスだ。VBAの世界では、Windows標準の`ScriptControl`（※32bit版）や、より現代的なアプローチとして`VBA-JSON`ライブラリを推奨する。
今回は、標準機能のみで完結させたいという現場の要望に応え、シンプルかつ堅牢な「JSON風オブジェクト管理」の実装例を示す。
呼び出し側：パラメータをJSON化して渡す
‘ 呼び出し側：フォームを開く前にJSON文字列を生成
Public Sub OpenDetailForm(ByVal lngID As Long, ByVal strMode As String)
Dim jsonParams As String
‘ JSON文字列を構築（シンプルに置換で行う例）
‘ 実務では専用のJSON生成クラスを使うのがベスト
jsonParams = “{“”ID””:” & lngID & “,””Mode””:””” & strMode & “””,””ReadOnly””:true}”
DoCmd.OpenForm “frmDetail”, , , , , , jsonParams
End Sub
受け取り側：フォームのOpenイベントで解釈する
‘ 子画面側：Form_Openイベント
Private Sub Form_Open(Cancel As Integer)
Dim rawJson As String
rawJson = Me.OpenArgs
If Len(rawJson) > 0 Then
‘ パラメータをパースしてフォームの状態を制御
Call ApplyJsonParams(rawJson)
End If
End Sub
Private Sub ApplyJsonParams(ByVal json As String)
‘ 簡易パーサーまたはライブラリを使用して値を抽出
‘ ここではデバッグ用にイミディエイトウィンドウへ出力
Debug.Print “Mode: ” & ExtractValue(json, “Mode”)
‘ フォームの制御ロジック
If ExtractValue(json, “ReadOnly”) = “true” Then
Me.AllowEdits = False
End If
End Sub
—
3. 設計を堅牢にするための3つの鉄則
1. バリデーションは「受け取り口」に集約せよ
JSONが壊れている可能性は常に考慮すべきだ。`OpenArgs`が空ではないか、必要なキーが含まれているかを検証するラッパー関数を必ず経由させろ。ここで例外処理を入れておけば、画面がクラッシュするリスクを劇的に減らせる。
2. 型安全性（Type Safety）を意識せよ
JSONはすべて文字列として渡される。数値やブール値として扱う際は、必ず`CLng()`や`CBool()`で明示的に変換すること。ここを怠ると、Accessの曖昧な型推論により、後々不可解なバグに悩まされることになる。
3. データベース連携は「IDのみ」が基本
JSONで巨大なレコードセットの全情報を渡そうとしてはならない。渡すのは「キー（ID）」と「表示状態（フラグ）」のみに留め、データ本体は子画面側で`CurrentDb`から取得する。これがメモリを圧迫させない、Accessアプリのパフォーマンスを維持する秘訣だ。
—
結論：プロのコードは「読みやすさ」を捨てない
複雑な画面制御をif文の迷宮に落とし込むのは、アマチュアのやり方だ。JSONという「構造化された言語」を間に挟むことで、呼び出し元と受け取り側の依存関係を分離し、将来的な機能拡張に耐えうる柔軟なアーキテクチャを構築せよ。
Accessは古いプラットフォームかもしれないが、設計思想まで古くある必要はない。このJSON駆動の設計を導入した瞬間から、君のコードは保守の苦しみから解放され、より本質的なビジネスロジックの開発に集中できるはずだ。
次は、このJSONパラメータをさらに拡張して、「画面の動的レイアウト変更」まで実装してみるといい。Accessの限界は、常に設計者の想像力によって更新されるのだから。
