【Access VBA極限道】一時テーブルの動的生成：DAOで実現する「使い捨て」の極意
業務システムを構築していると、複雑な計算や多段集計に直面し、「この中間データ、どこに置こう？」と悩む瞬間があるはずだ。クエリを何階層もネストしてパフォーマンスをドブに捨てるか、それとも「一時テーブル」という名のゴミをデータベースに溜め込み続けるか。
多くのエンジニアが後者を選び、数ヶ月後には「temp_集計1_旧」「temp_集計1_最新_2」といった無秩序なテーブル群に頭を抱えることになる。
今日は、DAO（Data Access Objects）を駆使し、「処理開始時に生まれ、終了時に跡形もなく消え去る」高潔な一時テーブルの設計パターンを授ける。これは単なるコードのコピペではない。データベースを汚さないという、エンジニアの美学の話だ。
—
1. なぜ「静的テーブル」ではダメなのか？
初心者はよく「tblTemp」のような固定テーブルを作り、`DELETE`文でクリアしてから使う。だが、これは以下の理由で地雷となる。
- 排他制御の競合: 複数ユーザーが同時にそのツールを触った瞬間、データが混ざり合い、集計結果は壊滅する。
- 断片化の蓄積: 頻繁なDELETE/INSERTは、Accessの内部ファイル（.accdb）を物理的に肥大化させ、パフォーマンスを低下させる。
- スキーマの柔軟性欠如: 処理の要件が変わるたび、テーブル定義を手動で修正するのは、保守という名の死を意味する。
真のプロフェッショナルは、実行時にその場限りの名前（GUID等）でテーブルを生成し、処理完了と同時に物理削除する。 これが唯一の解だ。
—
2. 実装の設計指針：DAOによる動的制御
`TableDef`オブジェクトを操作する際、最も重要なのは「エラーハンドリング」と「確実な破棄」だ。処理が途中で落ちた際、一時テーブルが残り続けることを防ぐための`Finally`構造（VBAではラベル制御）が必須となる。
プロダクションコード：`TemporaryTableManager`
以下のコードは、単なる関数ではなく、あなたのライブラリに組み込むべき「設計パターン」だ。
‘ ———————————————————
‘ 一時テーブルを安全に作成・破棄するテンプレート
‘ ———————————————————
Public Sub ExecuteComplexProcess()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim tmpTableName As String
Set db = CurrentDb
‘ ユニークなテーブル名を生成（時刻と乱数で衝突を回避）
tmpTableName = “tmp_” & Format(Now, “yyyymmddhhnnss”) & “_” & Int(Rnd 1000)
On Error GoTo Cleanup
‘ 1. テーブルの定義と作成
Set tdf = db.CreateTableDef(tmpTableName)
With tdf
.Fields.Append .CreateField(“ID”, dbLong)
.Fields.Append .CreateField(“DataValue”, dbDouble)
‘ インデックスを作成すると集計速度が劇的に向上する
.Indexes.Append .CreateIndex(“PrimaryKey”)
.Indexes(“PrimaryKey”).Fields.Append .CreateField(“ID”)
.Indexes(“PrimaryKey”).Primary = True
End With
db.TableDefs.Append tdf
‘ — ここでデータを投入し、計算を行う —
‘ … (処理ロジック) …
Cleanup:
‘ エラーが発生しても、正常終了しても必ずここを通る
If Err.Number <> 0 Then
Debug.Print “処理中にエラー発生: ” & Err.Description
End If
‘ テーブルの削除（存在確認必須）
On Error Resume Next
db.TableDefs.Delete tmpTableName
db.TableDefs.Refresh
Set tdf = Nothing
Set db = Nothing
End Sub
—
3. 実務で勝つための「極限の注意点」
1. `Refresh`を軽視するな
DAOでテーブルを追加・削除した直後、Accessの内部メタデータは即座に反映されない場合がある。`db.TableDefs.Refresh`を適切なタイミングで呼び出すことで、後続のクエリで「テーブルが見つかりません」という幽霊エラーを回避できる。
2. トランザクションの境界
一時テーブルへのデータ投入は、`db.BeginTrans` ～ `db.CommitTrans` で囲むのが鉄則だ。数万件のレコードを処理する場合、トランザクションの有無で速度が数倍〜数十倍変わる。ただし、テーブル作成そのものはトランザクション外で行う必要がある（Accessの制約）。
3. インデックスの戦略的配置
「一時テーブルだからインデックスは不要」という考えは捨てろ。JOINや集計を行うなら、一時テーブルのキーフィールドには必ずインデックスを張れ。メモリとディスクのI/Oバランスを最適化できるのは、インデックスを理解している者だけだ。
—
結びに代えて
一時テーブルを「使い捨てる」という設計は、単なるメモリ節約術ではない。「システムにゴミを残さない」という、持続可能な開発への意志表示だ。
あなたの書くVBAが、数年後の自分やチームメンバーを苦しめないために。このパターンをテンプレート化し、あなたの武器庫に加えてほしい。
Accessは古いプラットフォームではない。それを制御するエンジニアの「設計力」が試される、極めて高度な実験場なのだ。さあ、次はどんな複雑な集計を自動化しようか？
