Access VBAを掌握せよ：VBEオブジェクトでコードを解析し、命名規則の崩壊を食い止める
大規模なAccess開発において、最大の敵は「スパゲッティコード」ではなく「統制の取れた規約の欠如」だ。数年経過したプロジェクトで、誰が書いたか不明な`Sub Command1_Click()`が散乱し、リファクタリングもままならない状態に陥っていないか？
本稿では、Accessの心臓部である`VBE`（Visual Basic for Applications Extensibility）ライブラリを直接叩き、プロジェクト内の全プロシージャ名を抽出・監査する「コード品質監査ツール」の極限設計を伝授する。
—
1. なぜ「VBEオブジェクト」を使うべきなのか
多くのエンジニアが、フォームやクエリの情報を取得するために`CurrentProject`や`AllForms`を使うが、コードそのものを解析するとなると途端に手が止まる。
VBAのコードをプログラムから解析するには、`Microsoft Visual Basic for Applications Extensibility 5.3`というライブラリへの参照が必要だ。これを理解しているかどうかで、君が「Accessを操作する人」なのか「Accessのアーキテクチャを掌握するエンジニア」なのかが決まる。
準備：参照設定の壁を越える
VBEを操作するには、VBAエディタで[ツール] > [参照設定]を開き、「Microsoft Visual Basic for Applications Extensibility 5.3」にチェックを入れろ。これがないと、`VBProject`や`CodeModule`といった核心的なオブジェクトにアクセスできない。
—
2. プロダクションコード：命名規則監査ツール
単にプロシージャ名を取るだけなら初学者でもできる。我々が求めるのは、「命名規則から逸脱したモジュールを即座に特定する堅牢な実装」だ。
以下のコードは、プロジェクト内の全プロシージャを走査し、規約（例: `fn_`で始まるべき関数を検知）に違反するものをイミディエイトウィンドウに書き出す。
Option Explicit
‘ 必要な参照設定: Microsoft Visual Basic for Applications Extensibility 5.3
Public Sub AuditProcedureNames()
Dim vbp As VBProject
Dim comp As VBComponent
Dim codeMod As CodeModule
Dim i As Long, lineCount As Long
Dim procName As String, procKind As vbext_ProcKind
Set vbp = Application.VBE.ActiveVBProject
Debug.Print “— 監査開始: ” & Now & ” —”
‘ モジュールを走査
For Each comp In vbp.VBComponents
Set codeMod = comp.CodeModule
lineCount = codeMod.CountOfLines
If lineCount > 0 Then
i = codeMod.CountOfDeclarationLines + 1
Do While i <= lineCount
' プロシージャ名を取得
procName = codeMod.ProcOfLine(i, procKind)
' 重複解析を避けるため、プロシージャの先頭行のみ処理
If i = codeMod.ProcStartLine(procName, procKind) Then
' ここに命名規則のロジックを実装
' 例: Publicな関数は 'fn_' で始まる必要がある
If Left(procName, 3) <> “fn_” Then
Debug.Print “【警告】命名規約違反: [” & comp.Name & “] -> ” & procName
End If
‘ 次のプロシージャへジャンプ
i = i + codeMod.ProcCountLines(procName, procKind)
Else
i = i + 1
End If
Loop
End If
Next comp
Debug.Print “— 監査終了 —”
End Sub
—
3. 実務で勝つための「3つの極意」
① 「行数」でループを回すな
初心者は`Lines`プロパティを使って全行を舐めようとするが、これは非効率だ。`ProcStartLine`と`ProcCountLines`を組み合わせることで、プロシージャの塊を一気にスキップするアルゴリズムを組め。コードベースが数万行を超えた時、この差が処理時間の致命的な差となる。
② 参照設定を動的に行う（上級者向け）
配布ツールにする場合、毎回「参照設定」をさせるのはユーザーフレンドリーではない。`Access.Application`の`References.AddFromGuid`を使用し、ツール実行時にプログラム側からライブラリを読み込む設計にすれば、運用負荷はゼロになる。
③ 「安全な」リファクタリングのために
このツールで抽出したリストを基に、手動で修正するのはナンセンスだ。CSVに出力し、Gitの差分ログと照らし合わせる。自動化とは、単にコードを動かすことではなく、「変更の責任範囲を明確にすること」を指す。
—
最後に：エンジニアとしての矜持
VBEオブジェクトを直接操作するツールを作ることは、自分の書いたコード、あるいはチームのコードを「メタ（俯瞰）」の視点で見つめる行為だ。
もし君が大規模なAccess開発で疲弊しているなら、まずはこのツールで現状の「命名の乱れ」を可視化することから始めろ。真の自動化エンジニアは、ツールを作るだけでなく、そのツールを使って「負債のない文化」を構築する人間だ。
さあ、エディタを開け。君のプロジェクトの「真実」を暴く時が来た。
