Access VBAの限界を突破せよ：OpenArgsをJSON化して「画面間連携」を掌握する
Access開発の現場で、画面（フォーム）間のパラメータ受け渡しに頭を抱えたことはないだろうか。
「IDだけ渡せばいいと思っていたら、検索条件も必要になった」
「モーダル画面で選択した値を呼び出し元に戻すために、複雑なグローバル変数を使っている」
もしあなたが`OpenArgs`を単なる「文字列の運び屋」としか見ていないなら、それは大きな損失だ。Access VBAにおいて、フォーム間の密結合は保守性を破壊する最大の癌である。今回は、`OpenArgs`をJSON文字列として拡張し、堅牢で拡張性の高い画面設計を実現する「アーキテクトの定石」を授けよう。
—
1. なぜ「カンマ区切り」のOpenArgsは死ぬのか？
多くの現場で散見されるのが、`”ID=1,Mode=Edit,Filter=Active”`のようなカンマ区切りの文字列だ。
これには致命的な欠陥がある。
- 構造化できない： 階層データ（配列やオブジェクト）を扱えない。
- パースが脆弱： インデックスが変わるだけで動かなくなる。「何番目が何のデータか」をコード内で記憶するのは人間には不可能だ。
- 拡張の恐怖： 引数を一つ増やすたびに、全ての呼び出し箇所を修正する羽目になる。
プロは「構造」を渡す。 JSON形式を採用することで、パラメータの追加・削除はコードの可読性を損なうことなく行えるようになる。
—
2. 実装の要：JSONパースの壁をどう超えるか
VBAには標準のJSONパーサーが存在しない。そのため、外部ライブラリ（[VBA-JSON](https://github.com/VBA-tools/VBA-JSON)など）を導入するのが定石だが、ここでは「あえて何も入れずに、軽量に解決する」ための設計思想を示す。
※大規模開発ではVBA-JSONの利用を強く推奨するが、今回はシンプルに`ScriptControl`（あるいは`JSONConverter`ライクな思想）を前提としたスマートな設計を紹介する。
JSON生成・解析のユーティリティ（クラスモジュール案）
まず、JSON文字列を読み解くための「仲介役」を作成する。
‘ クラス名: JsonHelper
‘ 軽量なJSONパースをサポートするラッパー
Option Explicit
‘ 簡単なプロパティ取得（実務では正規表現やSplitで簡易実装するか、VBA-JSONを導入すること）
Public Function GetValue(jsonStr As String, key As String) As String
‘ 正規表現を使って “key”: “value” を抽出するロジック
‘ ここでは設計の骨子を示すため簡略化している
Dim pattern As String
pattern = “””” & key & “””\s:\s””?([^””,}]+)””?”
‘ …（正規表現によるマッチング処理）…
GetValue = “抽出された値”
End Function
—
3. 現場で使えるプロダクションコード：フォーム呼び出しのスマート化
呼び出し元（親フォーム）
パラメータを構造化してJSON文字列として送る。
Sub OpenDetailForm()
Dim jsonParams As String
‘ JSON文字列を構築（本来はDictionaryオブジェクトから生成するのがベスト）
jsonParams = “{“”ID””: 1024, “”Mode””: “”Edit””, “”ReadOnly””: true}”
‘ OpenArgsにJSONを載せてフォームを開く
DoCmd.OpenForm “frmDetail”, , , , , acDialog, jsonParams
End Sub
呼び出し先（子フォーム）の設計
`Form_Load`で受け取ったJSONを解釈し、状態を確定させる。
Private Sub Form_Load()
Dim rawJson As String
Dim mode As String
rawJson = Me.OpenArgs
If Len(rawJson) > 0 Then
‘ JSONを解析して設定を適用
mode = JsonHelper.GetValue(rawJson, “Mode”)
If mode = “Edit” Then
Me.AllowEdits = True
Else
Me.AllowEdits = False
End If
Debug.Print “ID: ” & JsonHelper.GetValue(rawJson, “ID”)
End If
End Sub
—
4. アーキテクトからの忠告：設計上の注意点
この手法を取り入れる上で、以下の3点を必ず守れ。
1. バリデーションを忘れるな：
`OpenArgs`は万能ではない。空文字の判定や、JSON形式が崩れていた場合のフォールバック（デフォルト値の適用）を必ず入れろ。エラーハンドリングなき自動化は、ただの「壊れる爆弾」だ。
2. 機密情報を渡すな：
`OpenArgs`はフォームのプロパティとしてメモリ上に残る。パスワードやセッションキーなど、セキュリティ上クリティカルな情報を安易に載せてはならない。
3. グローバル変数への逃避を断て：
「JSON化が面倒だから」といってPublic変数に逃げるな。その場しのぎのグローバル変数は、半年後の君自身を苦しめることになる。画面間の疎結合を保つためにこそ、この手間をかけるのだ。
結論：コードの品格を上げろ
Access開発が「レガシーな泥沼」になるか、「モダンなシステム」になるかは、こうした小さな設計の積み重ねで決まる。
`OpenArgs`をJSONで拡張する。これは単なる技術的な工夫ではない。「画面の状態をデータとして定義する」という、疎結合アーキテクチャへの第一歩なのだ。
さあ、今すぐあなたのAccessプロジェクトの「カンマ区切りの惨状」をリファクタリングしよう。コードが整理されるとき、あなたの開発スピードもまた一段階上の次元へ到達するはずだ。
