Access開発の聖域：QueryDefと動的SQL、その「境界線」を支配せよ
Access開発において、多くのエンジニアが陥る罠がある。それは「すべてをクエリデザイン画面で作る」か「すべてをSQL文字列としてVBAにハードコードする」という二極化だ。
結論から言おう。この二択はどちらも敗北である。
真のアーキテクトは、GUIが持つ「可視化の恩恵」と、動的SQLが持つ「柔軟な抽象化」を使い分ける。今日は、システムを崩壊させないための「クエリの境界線」と、その先のハイブリッド運用術を授ける。
—
1. 境界線の定義：何をGUIに任せ、何をコードに委ねるか
GUI（クエリデザインビュー）に任せるべきもの
- 定型的な抽出ロジック: 複数テーブルの複雑なJoin構造や、結合条件が固定されているもの。
- データ更新の基盤: `SELECT`クエリをベースにした、ビューとしての活用。
- 理由: Accessのクエリデザインは非常に優秀なSQL生成機だ。複雑なJoinをVBAで文字列結合して書くのは、デバッグの悪夢を招くだけである。
VBA（動的SQL / QueryDef）に任せるべきもの
- ユーザー入力による条件の変化: フィルタ条件が動的に増減する検索画面など。
- 一時的なバッチ処理: 実行時に生成し、用が済んだら破棄すべき一時テーブル操作。
- 理由: 固定クエリを増殖させるのは「保守の墓場」を建設する行為だ。散らばった数百個のクエリを管理するのは不可能に近い。
—
2. 堅牢な設計：QueryDefを動的生成する「型」
動的SQLを作る際、絶対にやってはいけないのが「文字列連結でのクエリ実行」だ。SQLインジェクションのリスクもさることながら、型変換のエラーやクォーテーションのミスに一生悩まされることになる。
「パラメータークエリ」をVBAで生成し、`Parameters`コレクションを介して値を代入する。 これが、プロの現場における「動的SQLの鉄則」である。
実践：保守性の高い動的クエリ実行テンプレート
以下は、安全かつ高速にクエリを実行するための汎用モジュールの一例だ。
‘ ——————————————————————
‘ @brief クエリを動的に生成・実行する汎用プロシージャ
‘ @param strSQL ベースとなるSQL文字列
‘ @param dictParams パラメーター名と値の辞書
‘ ——————————————————————
Public Sub ExecuteDynamicQuery(ByVal strSQL As String, ByVal dictParams As Object)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim prm As DAO.Parameter
Set db = CurrentDb
‘ クエリ定義を一時的に作成（名前を付けずに作成して即時実行）
Set qdf = db.CreateQueryDef(“”, strSQL)
‘ パラメーターの注入
For Each prm In qdf.Parameters
If dictParams.Exists(prm.Name) Then
prm.Value = dictParams(prm.Name)
End If
Next prm
‘ 実行（SELECTクエリの場合はRecordsetとして扱うのが一般的だが、今回は更新系を想定）
qdf.Execute dbFailOnError
‘ クリーンアップ
qdf.Close
Set qdf = Nothing
Set db = Nothing
End Sub
—
3. なぜ「ハイブリッド運用」が最強なのか
開発効率を最大化する鍵は、「保存済みクエリ」を「関数」のように扱うことにある。
1. インフラ層: GUIで作った複雑なJoinクエリを「`qsel_BaseData`」として保存しておく。
2. ロジック層: VBA側では、`SELECT FROM qsel_BaseData WHERE [条件]` と記述する。
これにより、結合ロジックの変更が必要になっても、VBAコードを一行も変えずにデザイン画面で修正を完結できる。これが「疎結合」なアーキテクチャだ。
—
4. エンジニアへの戒め
最後に、これだけは覚えておいてほしい。
- 名前のないクエリ（CreateQueryDef(“”, SQL)）を愛せ: データベースウィンドウをクエリの残骸で埋め尽くすな。不要なオブジェクトはファイルサイズを肥大化させ、検索性を低下させる。
- dbFailOnErrorを省略するな: `qdf.Execute`の際、このフラグを忘れると、トランザクションの失敗がサイレントに無視される。業務システムにおいて「エラーを無視する」ことは最大の罪だ。
Accessは「おもちゃ」ではない。設計思想次第で、巨大なエンタープライズシステムをも制御可能な、極めて強力な開発プラットフォームへと昇華する。
君の作るシステムが、誰かの業務を劇的に改善することを期待している。健闘を祈る。
