Access VBAを掌握する極限の知見：VBEオブジェクトによるメタプログラミングとコード自動生成の全貌
レガシーシステムの最前線に立ち続ける我々にとって、Accessは単なる簡易データベースではない。適切なアーキテクチャと極限の最適化を施せば、それは強靭なローコード・ラピッド開発プラットフォームへと変貌する。
だが、システムの寿命が延び、管理すべきクエリ、フォーム、そしてモジュールの数が数千規模に達したとき、手動によるコードのメンテナンスは破綻する。ここで必要となるのが、VBA自身にVBAを書かせる「メタプログラミング」である。
今回は、`Application.VBE`（Visual Basic for Applications Environment）オブジェクトを直接叩き、モジュールの動的生成、プロシージャの注入、そしてコードの自動修正を実現する極限の知見を公開する。
—
1. VBE操作の前提条件：セキュリティホールと参照設定の罠
VBAからVBEを操作し、コードコンポーネント（VBComponent）を読み書きするためには、Accessのセキュリティ設定およびCOMコンポーネントの参照設定において、厳格なハードルを越えなければならない。
必須の事前設定
1. 「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する」の有効化
- Accessのオプション（またはレジストリ）から、プログラムによるVBEへのアクセスを許可する必要がある。これを怠ると、`Automation Error` が発生し、一切のコード操作が拒絶される。
2. 「Microsoft Visual Basic for Applications Extensibility 5.3」の参照設定
- 早期バインディング（Early Binding）による型安全性を確保するため、VBE関連のオブジェクトライブラリをプロジェクトに追加する。
‘ 【早期バインディング用コードの前提】
‘ ツール -> 参照設定 -> 「Microsoft Visual Basic for Applications Extensibility 5.3」にチェックを入れること。
—
2. メモリの深淵：COMオブジェクトのライフサイクルと解放の鉄則
VBEオブジェクトモデルを操作する際、最も恐れなければならないのはメモリリークとCOM参照の残骸（ゾンビプロセス・ポインタの残留）である。
`Application.VBE` や `VBProject`、`VBComponent` は、VBAの通常の変数とは異なるCOMのライフサイクルを持つ。適切に参照を解放しないと、Accessの強制終了や、最悪の場合プロジェクトファイルの破損（Corruption）を招く。
以下のコードは、動的に標準モジュールを生成し、そこにプロシージャを注入したのち、確実にメモリを解放するシニアのイディオムである。
‘ ==============================================================================
‘ 概要: 指定した名前の標準モジュールを動的に生成し、任意のプロシージャを注入する
‘ ==============================================================================
Public Sub InjectDynamicModule(ByVal moduleName As String, ByVal codeBody As String)
‘ 早期バインディングによるオブジェクト変数宣言
Dim vbProj As VBIDE.VBProject
Dim vbComp As VBIDE.VBComponent
Dim codeMod As VBIDE.CodeModule
Dim targetLine As Long
Dim isModuleExists As Boolean
On Error GoTo ErrorHandler
‘ 現在のデータベースのVBProjectを取得
Set vbProj = Application.VBE.ActiveVBProject
‘ 既存モジュールの有無をチェックし、存在する場合は削除または流用
isModuleExists = False
For Each vbComp In vbProj.VBComponents
If vbComp.Name = moduleName Then
isModuleExists = True
Exit For
End If
Next vbComp
If isModuleExists Then
‘ 既存モジュールが存在する場合は一旦削除してクリーンな状態にする
vbProj.VBComponents.Remove vbComp
End If
‘ 新規標準モジュールの作成
Set vbComp = vbProj.VBComponents.Add(vbext_ct_StdModule)
vbComp.Name = moduleName
‘ コードモジュールインターフェースを取得
Set codeMod = vbComp.CodeModule
‘ プロシージャのコードを流し込む
‘ CodeModule.AddFromString は複数行の文字列を一括でコンパイル対象として書き込む
codeMod.AddFromString codeBody
MsgBox “モジュール [” & moduleName & “] の動的生成に成功しました。”, vbInformation, “メタプログラミング完了”
CleanUp:
‘ 【極めて重要】COMオブジェクトの参照を逆順かつ明示的に解放
‘ これを怠るとVBEの内部キャッシュが破損し、Access不安定化の原因となる
Set codeMod = Nothing
Set vbComp = Nothing
Set vbProj = Nothing
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “VBE操作エラー”
Resume CleanUp
End Sub
—
3. 実務応用：システム間連携コードの自動生成エンジン
では、このメタプログラミングを実際の業務でどう活かすのか。
例えば、外部の巨大なREST APIや、数千に及ぶレガシーテーブル定義が頻繁に変更されるシステムを想像してほしい。スキーマが変わるたびに、対応するCRUD（Create, Read, Update, Delete）のVBAコードを手動で書き換えるのは、エンジニアの労力の無駄遣いである。
以下は、「データベースのテーブル定義をメタデータとして読み込み、それに対応するデータ操作モジュールをプログラム自身が自動生成・上書きする」アーキテクチャの実装例である。
‘ ==============================================================================
‘ 概要: テーブル定義からデータアクセスのボイラープレートコードを動的生成する
‘ ==============================================================================
Public Sub GenerateDataAccessCodeForTable(ByVal tableName As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim sb As Object ‘ StringBuilderの代替としてのString結合（メモリ効率考慮）
Dim codeTemplate As String
Dim pkName As String
Set db = CurrentDb
Set tdf = db.TableDefs(tableName)
‘ 主キーの特定（簡易的に最初に見つかったインデックスを使用）
pkName = “ID” ‘ デフォルト
On Error Resume Next
Dim idx As DAO.Index
For Each idx In tdf.Indexes
If idx.Primary Then
pkName = idx.Fields(0).Name
Exit For
End If
Next idx
On Error GoTo 0
‘ コードの動的構築
Set sb = CreateObject(“Scripting.Dictionary”) ‘ 簡易バッファ
codeTemplate = “‘ ————————————————–” & vbCrLf & _
“‘ 自動生成されたデータアクセスモジュール: ” & tableName & vbCrLf & _
“‘ 生成日時: ” & Now & vbCrLf & _
“‘ ————————————————–” & vbCrLf & _
“Public Function GetRecord_” & tableName & “(ByVal ” & pkName & ” As Long) As DAO.Recordset” & vbCrLf & _
” Dim sql As String” & vbCrLf & _
” sql = \”SELECT FROM ” & tableName & ” WHERE ” & pkName & ” = \” & ” & pkName & “” & vbCrLf & _
” Set GetRecord_” & tableName & ” = CurrentDb.OpenRecordset(sql, dbOpenSnapshot)” & vbCrLf & _
“End Function” & vbCrLf
‘ 先ほど定義した動的モジュール注入ルーチンを呼び出す
Call InjectDynamicModule(“Mod_Gen_” & tableName, codeTemplate)
Set tdf = Nothing
Set db = Nothing
End Sub
このアプローチにより、外部インターフェースの仕様変更（JSONスキーマの変更やSQL Serverのビュー変更など）が発生した際、データ同期バッチが走った瞬間にVBAコード自体が自己書き換え（セルフ・モディフィケーション）を行い、常に最新のAPI/DB仕様に適応し続けるシステム構築が可能となる。
—
4. チーフアーキテクトからの警句：動的コード生成の光と影
VBEオブジェクトを用いたメタプログラミングは、レガシーAccessシステムの保守性を劇的に飛躍させる「諸刃の剣」である。
1. コンパイルエラーの隠蔽リスク
- 動的に生成されたコードに構文エラーがある場合、実行時（Run-time）になるまで検知できない。必ず `Compile` メソッド（`Application.VBE.ActiveVBProject.VBComponents…` のコンパイル確認）を挟むか、生成後にエラーハンドリングを徹底すること。
2. セキュリティソフトの誤検知
- 高度なEDR（Endpoint Detection and Response）やウイルス対策ソフトの中には、VBAからVBEを操作してコードを書き換える挙動を「マクロウイルス（自己書き換え型マルウェア）」の挙動と酷似していると判断し、検疫・ブロックするものがある。導入する環境のセキュリティポリシーを事前に精査すること。
コードを書くコードを書く。このパラダイムをモノにした瞬間、あなたのAccess開発能力は、単なる「マクロ作成者」から「システム・アーキテクト」へと完全に昇華する。制約の多いレガシー環境こそ、知略と極限のコードでねじ伏せろ。
