【Access VBA極限講座】テーブルの「説明」プロパティを完全制御せよ！コードで築く生きたデータベース設計
こんにちは。チーフアーキテクトの私だ。
現場で数々のAccess案件を見渡していて、最もフラストレーションが溜まる瞬間は何だと思うかね？
それは、「このテーブル、いったい何の目的で作られて、どの処理から参照されているんだ？」という疑問に直面した時だ。
設計書は半年前に古び、Excelのデータ定義書はどこにいったか分からない。結局、VBAのソースコードを全検索して、恐る恐る中身を解読する……。そんな不毛な残業を、君のチームにまだ強いているのかね？
今回は、外部のドキュメントファイルに頼るのをやめ、データベースそのものを自ら語る「生きたドキュメント」へと変貌させる極限のテクニックを授けよう。
ターゲットは、テーブルの「説明（Description）」プロパティだ。ここをVBAで完全に支配し、保守性の高いメタデータ駆動型の開発環境を構築する。
—
なぜ「説明」プロパティをVBAで制御すべきなのか？
初心者によくある間違いは、AccessのGUI（画面）をポチポチと手動で操作して、各テーブルのプロパティに説明文を入力していくことだ。
断言しよう。手動によるドキュメント化は、100%破綻する。
テーブルが50個を超えたあたりで更新漏れが発生し、半年後には「嘘の書かれたゴミ箱」に成り下がる。
真にプロフェッショナルなエンジニアは、「DB構造の変更と同時に、ドキュメントも自動で更新される（あるいはスクリプトで一括流し込みできる）仕組み」をコードで担保する。
DAO（Data Access Objects）を正しく叩き、`Properties` コレクションの挙動とライフサイクルを理解していれば、これは驚くほど堅牢かつ簡単に行えるのだ。
—
現場で即死するアンチパターンを知る
まずは、初心者がやりがちな「動かない・エラーになる」典型的なコードを見てみよう。
‘ 【× 悪い例】存在しないプロパティに直接アクセスして爆死するパターン
Sub BadCode_SetDescription()
Dim db As DAO.Database
Set db = CurrentDb
‘ テーブルが存在するか、プロパティが既に存在するかを無視している
db.TableDefs(“T_受注明細”).Properties(“Description”) = “日別の受注明細を保持するマスター”
Set db = Nothing
End Sub
このコードの何が問題か？
1. `Properties` コレクションの仕様： Accessのオブジェクトにおいて、`Description` などの拡張プロパティは、「まだ一度も値が設定されていない状態では、コレクションに存在しない」という残酷な仕様がある。存在しないキーに直接アクセスすれば、当然 `Runtime Error 3270: プロパティが見つかりませんでした。` が発生して即死する。
2. エラーハンドリングの欠如： 指定したテーブル名が存在しなかった場合の考慮がない。
プロのエンジニアであれば、この「プロパティが存在しないかもしれない」という非対称性を美しく吸収するコードを書かなければならない。
—
【プロダクションコード】堅牢性極まる「説明」一括設定モジュール
ここからが本題だ。
DAOの作法を厳密に守り、プロパティの有無を動的に判定・生成（Append）する、実務投入レベルのサブルーチンを公開しよう。
このプロシージャをプロジェクトに組み込んでおけば、マスターデータ定義用の配列から、一瞬にしてデータベース全体をドキュメント化できる。
Option Compare Database
Option Explicit
‘ =================================================================================
‘ 概要: 指定したテーブルの「説明」プロパティを安全に設定・更新する
‘ 引数: tableName – 対象テーブル名
‘ descriptionText – 設定する説明文
‘ =================================================================================
Public Sub SetTableDescription(ByVal tableName As String, ByVal descriptionText As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim prp As DAO.Property
Const PROP_NAME As String = “Description”
Const ERR_PROPERTY_NOT_FOUND As Long = 3270
Set db = CurrentDb
On Error GoTo ErrorHandler
‘ テーブル定義を取得（存在しない場合はトラップされる）
Set tdf = db.TableDefs(tableName)
‘ プロパティが存在するかどうかを試行錯誤せず、エラー番号でハンドリングするスマートな実装
tdf.Properties(PROP_NAME).Value = descriptionText
‘ 正常終了時はクリーンアップへ
GoTo Finally
ErrorHandler:
If Err.Number = ERR_PROPERTY_NOT_FOUND Then
‘ プロパティがまだ一度も作成されていない場合は新規作成して追加する
‘ 第2引数: DB_TEXT (10) -> 文字列型を示すDAOの定数
Set prp = tdf.CreateProperty(PROP_NAME, dbText, descriptionText)
tdf.Properties.Append prp
Resume Next ‘ 追加処理が終わったら元の行へ復帰
Else
‘ その他の予期せぬエラー
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
Resume Finally
End If
Finally:
‘ オブジェクトの解放（メモリリークの完全防止）
Set prp = Nothing
Set tdf = Nothing
Set db = Nothing
End Sub
コードのキモ：なぜこの実装が「神」なのか
1. DAOのライフサイクル管理の徹底： `CurrentDb` は関数が呼ばれるたびに新しいインスタンスを返す。これをローカル変数 `db` で受けて適切に解放することで、Access特有のメモリリークや内部キャッシュの肥大化を防いでいる。
2. `CreateProperty` の正しい作法： プロパティが存在しないエラー（#3270）を検知した瞬間のみ、`CreateProperty` で型（`dbText`）を指定して生成し、`Append` する。このイディオムは、テーブルだけでなくクエリやフィールド（Field）のプロパティ操作にも完全に応用できる。
—
実践：システム全体のテーブル定義をコードで一元管理する
さて、上記の関数が手に入った。これをどう業務に活かすか？
例えば、以下のような初期セットアップ用プロシージャを用意し、開発環境のデプロイ時に実行するのだ。
‘ =================================================================================
‘ 概要: システム内の主要テーブルへ一括で説明文を流し込む（ドキュメント同期）
‘ =================================================================================
Public Sub SyncDatabaseDocumentation()
‘ トランザクション的な処理の前兆として画面描画を停止すると高速化する
Echo False
On Error GoTo SafeExit
‘ ここに設計書となるメタデータを記述していく
Call SetTableDescription(“T_M_Staff”, “社員マスタ：権限管理および担当者別の集計に使用”)
Call SetTableDescription(“T_T_OrderHeader”, “受注ヘッダー：外部受発注システムからのCSVインポート先”)
Call SetTableDescription(“T_T_OrderDetail”, “受注明細：ヘッダーとリレーション（1対多・カスケード削除無）”)
MsgBox “データベースのドキュメント同期が正常に完了しました。”, vbInformation, “完了”
SafeExit:
Echo True
If Err.Number <> 0 Then
MsgBox “同期処理中にエラーが発生しました: ” & Err.Description, vbExclamation
End If
End Sub
これを実行すれば、Accessのナビゲーションウインドウ、あるいは外部のデータベースドキュメント出力ツールから、いつでも正確で最新の定義を参照できるようになる。
—
アーキテクトからの最後のアドバイス
「たかが説明文のプロパティ」と侮るなかれ。
優れたシステムとは、コードが綺麗であるだけでなく、「次に触る人間（それが未来の自分であれ、他のメンバーであれ）に対する配慮」がシステム構造の内部にまで染み出しているものだ。
VBAを使ってメタデータを制圧する。このアプローチをマスターした君なら、もうスパゲッティ・アクセスに頭を悩ませることは二度とないはずだ。
さあ、今すぐエディタを開き、君のデータベースに「言葉」を与えてやりたまえ。
