Access VBAを掌握する極限の知見：Unicode圧縮プロパティの完全制御によるDB最適化の極意
こんにちは。開発プロジェクトの現場で数々のAccess地獄を見てきたチーフアーキテクトだ。
お前たちは、Accessデータベースが日々肥大化し、2GBの壁に怯えながら「なぜこんなに容量が大きいんだ？」と頭を抱えた経験はないか？
その原因の多くは、テーブル設計の怠慢、そして「Unicode圧縮（UnicodeCompression）」プロパティの放置にある。
今回は、テキストやメモフィールドが持つこのプロパティをVBAで一括制御し、データベースのフットプリントを劇的に削減するための実践的な知見を授けよう。ネットの適当なサンプルをコピペして動くだけのコードとは違う。実務の現場で耐えうる、堅牢でミスの起きないプロダクションコードを解説する。
—
1. なぜ「Unicode圧縮」の制御が必要なのか？
Access（JET / ACEエンジン）のテキスト型（Short Text）およびメモ型（Long Text）フィールドは、内部的にUTF-16（1文字につき2バイト）で文字列を保持している。
ここで問題になるのが、「英数字や半角記号しか保存していないにもかかわらず、2バイト消費している」という無駄だ。
「Unicode圧縮」を有効（`True`）にすると、ASCII文字（コードが0〜128の範囲の文字）の先頭バイトに `0x00` が並ぶ特性を利用し、これを1バイトに圧縮して保存してくれる。
実務において、社内ニッポン系のシステムであっても、コード値、ステータス、メールアドレス、IDなど、格納データの大部分が半角英数字であるケースは非常に多い。 ここを最適化するだけで、テーブルサイズが数分の一に激減するケースも珍しくないのだ。
非効率なアプローチの罠
GUIから手動でポチポチ設定変更？ 5つや10のフィールドならいいだろう。しかし、50テーブル、300フィールドを超えるような実務システムでそれをやるのか？ 人間はミスをする。だからこそVBAによる完全自動化が必須となる。
—
2. 設計上の注意点とVBA制御のダークマター
コードを書く前に、DAO（Data Access Objects）におけるオブジェクトのライフサイクルと、Access特有の「罠」を理解しておかなければならない。
1. すべてのフィールドが対象になるわけではない
`Text`（短いテキスト）型や `Memo`（長いテキスト）型であっても、データ型によっては `UnicodeCompression` プロパティ自体が存在しない（例：数値型、日付時刻型など）。存在しないプロパティにアクセスしようとすると、容赦なく実行時エラー（エラー3270: プロパティが見つかりません）が飛んでくる。
2. トランザクションと排他制御
テーブル構造を変更（Alter）するため、対象テーブルが他のユーザーやフォームで開かれているとロック競合を起こす。実行時は必ず排他モード、あるいは適切なエラーハンドリングが必須だ。
3. プロパティの動的追加
DAOの `Field` オブジェクトにおいて、`UnicodeCompression` プロパティはデフォルトで存在しない場合がある。そのため、「存在しなければ新規作成して追加する」という防御的コードが必要になる。
—
3. 【プロダクションコード】全テーブル・全テキストフィールド一括最適化モジュール
以下のコードは、カレントデータベース内のすべてのユーザーテーブルを走査し、テキスト系フィールドの `UnicodeCompression` プロパティを強制的に `True` に設定するプロシージャだ。
エラーハンドリング、トランザクション、プロパティの動的生成を網羅した、現場でそのまま使える実用コードである。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ ódulo名: modDatabaseOptimizer
‘ 概要 : データベース内の全テキストフィールドのUnicode圧縮を有効化する
‘ 著者 : チーフアーキテクト
‘ =========================================================================
Public Sub OptimizeUnicodeCompression()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Dim prp As DAO.Property
Dim targetCount As Long
Dim modifiedCount As Long
Set db = CurrentDb
targetCount = 0
modifiedCount = 0
‘ 画面描画と警告を停止してパフォーマンスを最大化
Echo False
DoCmd.Hourglass True
On Error GoTo ErrorHandler
Debug.Print “=== Unicode圧縮の最適化処理を開始します ===”
For Each tdf In db.TableDefs
‘ システムテーブル（MSysで始まるもの）およびリンクテーブルは除外
If (tdf.Attributes & dbSystemObject) = 0 And (tdf.Attributes & dbAttachedTable) = 0 Then
For Each fld In tdf.Fields
‘ Text型 (dbText) または Memo型 (dbMemo) のみをターゲットとする
If fld.Type = dbText Or fld.Type = dbMemo Then
targetCount = targetCount + 1
‘ プロパティが存在するか確認し、なければ安全に追加する
Set prp = Nothing
On Error Resume Next
Set prp = fld.Properties(“UnicodeCompression”)
On Error GoTo ErrorHandler
If prp Is Nothing Then
‘ プロパティが存在しない場合は新規作成（Boolean型は 1）
Set prp = fld.CreateProperty(“UnicodeCompression”, dbBoolean, True)
fld.Properties.Append prp
modifiedCount = modifiedCount + 1
Debug.Print ” [追加・設定] テーブル: ” & tdf.Name & ” / フィールド: ” & fld.Name
Else
‘ 既に存在する場合は強制的に True に設定
If prp.Value = False Then
prp.Value = True
modifiedCount = modifiedCount + 1
Debug.Print ” [更新] テーブル: ” & tdf.Name & ” / フィールド: ” & fld.Name
End If
End If
End If
Next fld
End If
Next tdf
MsgBox “最適化が完了しました。” & vbCrLf & _
“対象テキストフィールド数: ” & targetCount & vbCrLf & _
“変更/適用数: ” & modifiedCount, vbInformation, “処理成功”
CleanUp:
‘ 資源の解放
Set prp = Nothing
Set fld = Nothing
Set tdf = Nothing
Set db = Nothing
Echo True
DoCmd.Hourglass False
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanUp
End Sub
—
4. このコードのアーキテクチャ上の優位性
1. システムテーブル・リンクテーブルの完全排除
`dbSystemObject` や `dbAttachedTable` のビット演算による判定を行っているため、外部のSQL ServerデータベースへのリンクテーブルやAccess内部のシステムカタログを破壊するリスクを完全に排除している。
2. 遅延バインディングとプロパティのフォールバック
DAOの仕様上、フィールド作成直後などは `UnicodeCompression` プロパティがインスタンス化されていないことがある。`On Error Resume Next` を挟んだ安全な存在チェックと `CreateProperty` による動的追加により、「プロパティが見つかりません」エラーを華麗に回避している。
3. UIのロックによる高速化
`Echo False` と `DoCmd.Hourglass` により、大量のテーブル走査中におけるAccessの無駄な画面再描画を抑制し、処理速度を極限まで高めている。
—
5. 運用上の重要アドバイス：実行後の「儀式」を忘れるな
勘の良いエンジニアなら気づいているはずだが、VBAでテーブル構造を変更（プロパティの追加・変更）し、データを大量に書き換えただけでは、Accessの物理ファイルサイズ（mdb/accdb）は小さくならない。
Accessのストレージエンジンは、データを削除・圧縮しても、ファイル内部の空き領域（デフラグ前スペース）を保持し続ける仕様だからだ。
このバッチを実行した後は、必ず以下の手順を踏むこと。
1. データベースを排他モードで開く。
2. 「データベースの最適化と修復（Compact and Repair Database）」を実行する。
この「最適化と修復」を実行して初めて、Unicode圧縮の恩恵によるファイルサイズの劇的な縮小が物理的に現れる。夜間バッチやリリース前のメンテナンス手順に、今回のVBAコードと「最適化と修復」をセットで組み込んでおくのが、プロフェッショナルなアーキテクトのやり方だ。
現場のパフォーマンスに責任を持つ者なら、今すぐこのコードを導入し、無駄な肥大化からデータベースを解放してやりたまえ。
