Accessの「クエリ定義」をメタデータ化せよ：QueryDefの隠された力を引き出す設計術
Access開発の現場で、名前だけで中身が判断できないクエリが乱立し、メンテナンス不能な「ゴミ屋敷」と化したデータベースを数多く見てきた。`Query1`, `Query2`…といった命名規則の果てに、誰も修正を恐れて触れないSQL文の墓場。
君たちが目指すべきは、そんな場当たり的な実装ではない。「クエリ自体に自己説明能力を持たせる」というアーキテクチャだ。今回は、Accessの`QueryDef`が持つ「隠し属性」を活用し、システム管理を一段上のレベルへ引き上げる極意を授ける。
—
なぜ「Descriptionプロパティ」が最強の武器なのか
Accessのクエリには、実は`Properties`コレクションが存在する。ここには標準的な名前やSQLだけでなく、ユーザーが自由に定義できるメタデータ領域がある。
特に有用なのが`Description`プロパティだ。これはクエリのプロパティシートで見える「説明」欄に対応している。ここに「何のためのクエリか」「誰が作成したか」「どの外部システムと連携しているか」をJSONや特定のタグ形式で埋め込むことで、VBAからメタデータを読み取り、動的な制御が可能になる。
非効率な管理からの脱却
多くの開発者は、クエリの用途をExcelの台帳に記録する。だが、その台帳は開発者との乖離が早晩始まる。クエリそのものにメタデータを埋め込めば、「データベース自身が自身の仕様書になる」のだ。
—
実装：メタデータ駆動型のクエリ管理
以下のコードは、指定したクエリにメタデータを書き込み、実行時にそれを検証する仕組みの雛形だ。
1. メタデータの書き込み（設定）
開発時に一度だけ実行するユーティリティ関数である。
‘ @brief クエリに説明(Description)を設定する
Public Sub SetQueryMetadata(queryName As String, descriptionText As String)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Set db = CurrentDb
Set qdf = db.QueryDefs(queryName)
‘ Descriptionプロパティが存在しない場合は作成して追加する
On Error Resume Next
qdf.Properties(“Description”) = descriptionText
If Err.Number = 3270 Then ‘ プロパティが見つからないエラー
qdf.Properties.Append qdf.CreateProperty(“Description”, dbText, descriptionText)
End If
On Error GoTo 0
Debug.Print “メタデータ更新成功: ” & queryName
End Sub
2. メタデータの読み取りと堅牢な実行
動的SQLを生成する前に、クエリの属性を確認するガード節を設ける。これにより「誤ったクエリを誤ったタイミングで実行する」事故を未然に防ぐ。
‘ @brief メタデータを検証してからクエリを実行する
Public Sub ExecuteManagedQuery(queryName As String, paramValue As Variant)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim meta As String
Set db = CurrentDb
Set qdf = db.QueryDefs(queryName)
‘ Descriptionからメタデータを取得（例: “TYPE:REPORT_DATA” のようなタグを埋め込んでおく）
meta = qdf.Properties(“Description”).Value
‘ ここでメタデータによるガードを実施
If InStr(meta, “TYPE:REPORT_DATA”) = 0 Then
Err.Raise vbObjectError + 1000, , “このクエリは実行許可されていません。”
End If
‘ パラメータクエリの動的制御
qdf.Parameters(0).Value = paramValue
qdf.Execute dbFailOnError
Set qdf = Nothing
End Sub
—
現場で差がつく3つの運用ルール
単にプロパティをいじるだけでは片手落ちだ。現場を統制するための「アーキテクトとしての作法」を伝授する。
1. メタデータは「構造化」せよ
`Description`には単純なテキストではなく、`”ID:001; OWNER:SYSTEM; REQ:DB_SYNC”`のように、セミコロン区切りのタグ形式、あるいはJSON形式で埋め込むこと。これにより、将来的な自動解析ツールへの拡張が容易になる。
2. 実行時は「dbFailOnError」を徹底せよ
`qdf.Execute`を実行する際、`dbFailOnError`オプションを忘れるな。これを指定しなければ、SQLが途中で死んでもAccessは「成功した」と勘違いして処理を続行する。君のコードは、失敗した時に即座に止まるべきだ。
3. 隠し属性の整合性はコードで保証する
手動でプロパティを書き換えるのは禁止だ。必ず専用の管理用モジュールを通すこと。そうすれば、いつ、誰が、どのクエリの属性を変えたのかをログに残すことも可能になる。
—
まとめ：エンジニアの誇りをコードに宿せ
Access VBAは、往々にして「とりあえず動くもの」が量産されがちだ。しかし、真のエンジニアは、その「とりあえず」の裏側に強固な規律を敷く。
`QueryDef`のメタデータ管理は、地味だが非常に強力な武器になる。データベースという閉じた世界の中で、クエリを単なるSQLの集まりから、仕様と実体が一体化した「自律的なコンポーネント」へと昇華させてほしい。
それができる者だけが、Accessという巨大なレガシーを、真の意味で掌握できるのだ。さあ、今すぐ君のデータベースにあるクエリの「説明欄」を覗いてみるといい。そこには、君のシステムの未来が書き込まれるのを待っているはずだ。
