Access VBAで「データ辞書」を自動生成せよ：現場で生き残るためのTableDef制御術
「Accessのテーブル構造がドキュメント化されておらず、修正のたびに冷や汗をかく」――。
これは、開発の現場でよくある悲劇です。仕様書が最新かどうかも怪しい環境で、テーブル構造を頭の中だけで管理するのはプロの仕事ではありません。
今回は、Accessの `DAO (Data Access Objects)` を深淵まで使いこなし、ワンクリックで「データ辞書」をExcelへ出力する堅牢なツールを構築します。単なるコードの羅列ではなく、「なぜその書き方をするのか」というエンジニアの思考プロセスまで含めて伝授します。
—
1. なぜ「手作業」が禁じ手なのか
初心者ほど、フィールド名を手打ちでExcelに書き写します。これは二重の過ちです。
1. ヒューマンエラーの温床: 1文字のタイポが将来的なクエリのバグを生みます。
2. 保守の破綻: 仕様変更のたびにドキュメントを更新するコストが重すぎて、結局誰も管理しなくなります。
我々が目指すべきは、「システムが自身の構造を語る」仕組みです。Accessのエンジンは `TableDef` という形で、テーブルの設計図を自ら保持しています。これを抽出するコードこそが、真の業務効率化です。
—
2. 堅牢な設計の要諦
今回のスクリプトを「プロダクションレベル」にするために、以下の3点を徹底します。
- 型定義の明示: データ型を数値（`dbInteger`など）ではなく、人間が読める文字列（`Text`, `Long`, `Date`など）に変換する関数を分離する。
- Excelの早期バインディング回避: あえてLate Binding（遅延バインディング）を採用し、参照設定のズレによるコンパイルエラーを防ぐ。
- リソースの解放: `DAO`オブジェクトを明示的に `Nothing` にし、メモリリークを許さない。
—
3. 実践：データ辞書自動生成ツール
以下のコードを標準モジュールに貼り付けてください。
Option Compare Database
Option Explicit
‘ テーブル構造をExcelに書き出すメインプロシージャ
Public Sub ExportTableDictionary()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim xlApp As Object, xlBook As Object, xlSheet As Object
Dim r As Long
Set db = CurrentDb
‘ Excelのインスタンス生成（Late Binding）
Set xlApp = CreateObject(“Excel.Application”)
Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Sheets(1)
‘ ヘッダー作成
With xlSheet
.Cells(1, 1).Value = “テーブル名”
.Cells(1, 2).Value = “フィールド名”
.Cells(1, 3).Value = “データ型”
.Cells(1, 4).Value = “サイズ”
.Range(“A1:D1”).Font.Bold = True
End With
r = 2
‘ システムテーブルを除外してループ処理
For Each tdf In db.TableDefs
If Left(tdf.Name, 4) <> “MSys” Then
For Each fld In tdf.Fields
xlSheet.Cells(r, 1).Value = tdf.Name
xlSheet.Cells(r, 2).Value = fld.Name
xlSheet.Cells(r, 3).Value = GetDataTypeName(fld.Type)
xlSheet.Cells(r, 4).Value = fld.Size
r = r + 1
Next fld
End If
Next tdf
xlApp.Visible = True
‘ オブジェクト解放（メモリ管理の基本）
Set xlSheet = Nothing: Set xlBook = Nothing: Set xlApp = Nothing
Set db = Nothing
MsgBox “データ辞書の作成が完了しました。”, vbInformation
End Sub
‘ データ型の数値を読みやすい名称に変換するヘルパー関数
Private Function GetDataTypeName(ByVal fldType As Integer) As String
Select Case fldType
Case 1: GetDataTypeName = “Yes/No”
Case 3: GetDataTypeName = “長整数型”
Case 4: GetDataTypeName = “単精度浮動小数点”
Case 5: GetDataTypeName = “倍精度浮動小数点”
Case 7: GetDataTypeName = “日付/時刻”
Case 10: GetDataTypeName = “テキスト”
Case 12: GetDataTypeName = “メモ”
Case Else: GetDataTypeName = “その他(” & fldType & “)”
End Select
End Function
—
4. プロの視点：コードの解説
なぜ `MSys` を除外するのか？
Accessにはシステム内部で使う隠しテーブル（`MSysObjects`等）が存在します。これらを含めると、開発者が意図しないノイズデータが辞書に混ざります。「システムが管理しているもの」と「自分が作ったもの」を明確に分ける。これがプロの境界線です。
早期バインディング（参照設定）を避ける理由
Excelのライブラリ（Microsoft Excel 16.0 Object Libraryなど）を参照設定すると、環境によってバージョン不整合が発生し、ツールが起動しなくなることがあります。`CreateObject` を使ったLate Bindingなら、環境依存を極限まで減らせます。
—
5. 次のステップへ
この辞書はあくまで「現状の可視化」です。これをさらに進化させるなら、「テーブルのプロパティ（説明フィールド）」を読み取れるように改造してみてください。DAOの `Properties` コレクションを叩けば、フィールドの「説明」に書いた内容まで抽出可能です。
いいですか、自動化とは「楽をするための手段」ではありません。「人間がやるべき価値ある仕事のために、機械的な作業を排除する哲学」です。
さあ、このコードを武器に、あなたのAccess環境を整理し、論理的な設計の土台を築いてください。何かあれば、またいつでも聞きに来なさい。
