Accessの「闇」を可視化せよ：VBAコード動的解析ツールで実現する、負債ゼロの保守体制
Access開発の現場において、最も恐ろしいのは「見えない依存関係」だ。
長年運用されたシステムで、あるクエリのフィールド名を変更した瞬間に、どこか別の場所でコードが死ぬ。そんな経験はないだろうか？
多くの開発者は、IDEの「検索」機能で場当たり的に対応する。だが、プロのアーキテクトは違う。「コードそのものをデータとして扱い、解析する」というアプローチをとるのだ。
今回は、`Application.CurrentProject.AllModules` を駆使し、データベース内の全コードを走査・解析する「保守支援エンジン」の設計思想と実装を伝授する。
—
1. なぜ「静的な検索」では不十分なのか
IDEの検索機能は、あくまで「現在のスナップショット」を見るだけだ。しかし、システムが大規模化すると、以下のような課題が発生する。
- 断片化: 標準モジュール、フォームモジュール、レポートモジュールにコードが散逸している。
- 非効率な追跡: 特定のプロシージャがどこから呼ばれているか、呼び出し階層を追うのに多大な工数がかかる。
- デッドコードの蓄積: 使われているか不明なプロシージャが、肥大化とバグの温床になっている。
我々が作るべきは、「VBAコードという名のテキストデータを、構造化された情報として抽出・管理するツール」である。
—
2. アーキテクチャの要：`Access.AccessObject` と `Module` オブジェクト
Access VBAには、VBAProject自体を操作する強力なAPIが備わっている。
`CurrentProject.AllModules` は、プロジェクト内の全モジュール（フォームやレポートを含む）へのポインタを提供する。
ここで重要なのは、「VBA Extensibility ライブラリ」の参照設定だ。
- VBE（Visual Basic For Applications Extensibility 5.3）
これがないと、コード行単位の走査は不可能だ。
—
3. 実装：コード走査エンジンの核
以下は、全モジュールを走査し、特定のキーワードが含まれる場所を特定するエンジンの雛形だ。これをベースに、ログ出力やDB格納機能を追加してほしい。
‘ 参照設定: Microsoft Visual Basic for Applications Extensibility 5.3
Option Explicit
Public Sub ScanAllVBAProject(ByVal targetKeyword As String)
Dim vbeProject As VBIDE.VBProject
Dim vbeComponent As VBIDE.VBComponent
Dim vbeModule As VBIDE.CodeModule
Dim i As Long
Set vbeProject = Application.VBE.ActiveVBProject
‘ 全コンポーネント（標準モジュール、フォーム等）を走査
For Each vbeComponent In vbeProject.VBComponents
Set vbeModule = vbeComponent.CodeModule
‘ コードの各行をチェック
For i = 1 To vbeModule.CountOfLines
If InStr(1, vbeModule.Lines(i, 1), targetKeyword, vbTextCompare) > 0 Then
‘ 保守ログとして即座に抽出
Debug.Print “発見: ” & vbeComponent.Name & ” (行: ” & i & “)”
Debug.Print ” 内容: ” & Trim(vbeModule.Lines(i, 1))
End If
Next i
Next vbeComponent
MsgBox “解析完了”, vbInformation
End Sub
—
4. 堅牢な保守ツールにするための3つの鉄則
単にコードを走査するだけでは、ただの「スクリプト」だ。プロダクションレベルの「ツール」に昇華させるために、以下の設計指針を守れ。
① 解析結果は必ず「テーブル」に格納せよ
`Debug.Print` で出力して終わるな。解析結果を `tbl_CodeAuditLog` のようなテーブルに保存しろ。
- `ComponentName`（モジュール名）
- `LineNumber`（行数）
- `CodeContent`（コード内容）
- `ScanTimestamp`（解析日時）
これを蓄積することで、「コードが過去数ヶ月でどう変化したか」という時系列解析が可能になる。
② 実行時のパフォーマンスを考慮せよ
`CodeModule.Lines` は、呼び出すたびにVBEのメタデータにアクセスする。大規模なプロジェクトでは非常に低速だ。
解析対象を「特定の接頭辞を持つモジュールのみ」に絞る、あるいは `Application.Echo` をオフにするなど、パフォーマンス対策を怠るな。
③ 「循環参照」と「依存関係」の可視化へ
このツールを拡張し、`Call` されているプロシージャ名を正規表現で抽出し、別のテーブルに「呼び出し元・呼び出し先」のマップを作れ。
これがあれば、「この関数を修正すると、どのフォームに影響が出るか」がクエリ一つで導き出せる。これが真の保守工数削減だ。
—
最後に：エンジニアとしての矜持
Access開発は、しばしば「場当たり的な修正の積み重ね」になりがちだ。しかし、それはツールを使いこなす技術がない者の弁解に過ぎない。
VBAの環境そのものを「解析対象」として掌握した瞬間、君はAccessの「使用者」から「設計者」へと進化する。
このコードを叩き台として、自分だけの「解析ダッシュボード」を構築せよ。それが、長期運用に耐えうる堅牢なシステムを支える、唯一の道だ。
コードを管理するな。コードの「構造」を管理せよ。 それこそが、プロフェッショナルの仕事である。
