Access VBAを掌握する極限の知見：SQLの255文字制限を粉砕する「一時テーブル×分割実行」のアーキテクチャ
レガシーシステムの寿命は、往々にして設計時の「見えない壁」によって突然断ち切られる。
その代表格が、Access SQLにおける「IN句の255文字制限（あるいはSQL文字列全体の長大化によるJET/ACEエンジンのパース限界）」である。
リストボックスでユーザーが多量のレコードを選択した瞬間、`IN (‘ID001’, ‘ID002’, …)` の文字数が限界を超え、おなじみの実行時エラーがシステムを沈黙させる。「数件なら動くのに、全選択すると落ちる」という問い合わせは、現場のエンジニアにとって悪夢以外の何物でもない。
今回は、この制約を根本から打破し、数千件規模の条件であっても秒速で処理しきるための「動的一時テーブル戦略による分割実行ロジック」を、プロダクション環境のクオリティで公開する。
—
1. なぜ「IN句の文字数制限」でシステムが崩壊するのか
初学者は「SQL文をスマートに組み立てればいい」と考えがちだが、Access（Microsoft Jet / ACE データベースエンジン）の仕様の本質を理解していないと、パフォーマンスと安定性の両方を失う。
255文字の壁と、文字列連結の罠
SQL文の中に直接 `IN (‘A001’, ‘A002’, …)` と値を埋め込んでいく手法は、文字数が255文字（あるいは長大すぎるクエリ文字列）に達した時点でパースエラーを引き起こす。さらに、VBAで文字列を何重にも連結する処理は、BSTR（COMの文字列型）のメモリ再割り当てを頻発させ、メモリ断片化（ヒープフラグメンテーション）の温床となる。
クエリキャッシュの汚染（プランキャッシュの肥大化）
動的に毎回異なる `IN (…)` を含んだSQLを `CurrentDb.OpenRecordset` や `QueryDef.SQL` に流し込むと、Accessエンジンはそれらを「すべて異なるSQL」と認識し、実行計画（Query Plan）のキャッシュを無駄に消費し続ける。結果として、メモリリークに近い状況を引き起こし、アプリケーション全体のレスポンスが劣化する。
—
2. 解決策：ローカル一時テーブルを用いた「セット指向アプローチ」
この問題をエレガントに解決する唯一の解法は、「条件値を一度ローカル一時テーブルにバルクインサートし、本丸のクエリ側でJOINまたはサブクエリ（`IN (SELECT …)`）として結合する」ことだ。
リレーショナルデータベースの本質は「セット指向（集合演算）」にある。文字列をこねくり回すのではなく、データを物理的な集合（テーブル）に落とし込んでから処理する。このアプローチにより、SQLの文字数制限は完全に無力化される。
アーキテクチャの全体像
1. 一時テーブルの動的生成: 処理セッションごとにユニークな名前のテンポラリテーブルを作成する。
2. トランザクション内での高速バルクインサート: DAOの `Recordset` を用いて、メモリ上で高速にデータを流し込む。
3. セット指向クエリの実行: 本体のクエリから一時テーブルを内部結合（INNER JOIN）またはサブクエリで参照する。
4. 確実なクリーンアップ: 例外が発生しようとも、オブジェクトと一時テーブルを確実に破棄し、MDB/ACCDBの肥大化（Bloat）を防ぐ。
—
3. 実装コード：限界を突破するモジュール
以下のコードは、エラーハンドリング、トランザクション、メモリ管理、オブジェクトの明示的解放（ライフサイクル管理）のベストプラクティスを網羅した実用コードである。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 処理名: 巨大IN句回避型 抽出実行エンジン
‘ 概要 : リストボックス等の多量選択IDを一時テーブル経由で安全に処理する
‘ ==============================================================================
Public Sub ExecuteBulkInQuery(ByVal lstTarget As ListBox)
Dim db As DAO.Database
Dim rsTemp As DAO.Recordset
Dim qdf As DAO.QueryDef
Dim varItem As Variant
Dim tempTableName As String
Dim isTableCreated As Boolean
Set db = CurrentDb()
isTableCreated = False
‘ セッションごとにユニークな一時テーブル名を生成（競合防止）
tempTableName = “tmp_Criteria_” & Format(Now, “yyyymmddhhnnss”) & “_” & Int(Rnd 1000)
On Error GoTo ErrorHandler
‘ 1. リストボックスの選択チェック
If lstTarget.ItemsSelected.Count = 0 Then
MsgBox “抽出対象が選択されていません。”, vbExclamation, “制御アラート”
Exit Sub
End If
‘ 2. 一時テーブルの動的作成（高速化のためインデックスはあえて張らない、または主キーのみ）
‘ ※ 本番環境では、DELETE文で使い回す常設の「作業用テーブル」を推奨するが、
// 今回は動的生成のパターンを示す。
db.Execute “CREATE TABLE ” & tempTableName & ” (ItemID TEXT(50));”, dbFailOnError
isTableCreated = True
‘ 3. トランザクションとDAOレコードセットによる高速バルクインサート
‘ (Executeをループさせるよりも、Addnewの方が圧倒的にオーバヘッドが少ない)
db.BeginTrans
Set rsTemp = db.OpenRecordset(“SELECT FROM ” & tempTableName, dbOpenDynaset, dbAppendOnly)
For Each varItem In lstTarget.ItemsSelected
rsTemp.AddNew
‘ リストボックスのバウンド列（例: 0列目）の値を取得
rsTemp!ItemID = CStr(lstTarget.ItemData(varItem))
rsTemp.Update
Next varItem
rsTemp.Close
Set rsTemp = Nothing
db.CommitTrans
‘ 4. 動的クエリの生成・実行（またはフォームへのバインド）
‘ 一時テーブルとマスタテーブルをJOINすることで、IN句の文字数制限を完全に回避
Dim sqlText As String
sqlText = “SELECT M. FROM T_MasterTable AS M ” & _
“INNER JOIN ” & tempTableName & ” AS T ” & _
“ON M.ID = T.ItemID;”
‘ デバッグ用出力（イミディエイトウィンドウ）
Debug.Print “Generated SQL: ” & sqlText
‘ 例：結果をフォームのレコードソースに設定する場合
‘ Forms!YourForm.RecordSource = sqlText
‘ 例：レコードセットとして処理する場合
Dim rsResult As DAO.Recordset
Set rsResult = db.OpenRecordset(sqlText, dbOpenSnapshot)
MsgBox “抽出完了: ” & rsResult.RecordCount & ” 件のレコードをヒットさせました。”, vbInformation, “完了”
‘ 後始末
rsResult.Close
Set rsResult = Nothing
CleanUp:
‘ 5. 一時テーブルの確実な破棄（ゴミを残さない）
On Error Resume Next
If isTableCreated Then
db.Execute “DROP TABLE ” & tempTableName & “;”, dbFailOnError
End If
On Error GoTo 0
‘ オブジェクトの明示的解放（メモリリークの根絶）
Set qdf = Nothing
Set db = Nothing
Exit Sub
ErrorHandler:
‘ トランザクション中のエラーであればロールバック
If db.Transactions > 0 Then
db.Rollback
End If
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“Error No: ” & Err.Number & vbCrLf & _
“Description: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanUp
End Sub
—
4. チーフアーキテクトが指摘する「実装上の急所」
上記のコードは単に動くだけではない。シニアエンジニアとして押さえておくべき「裏の仕様と最適化の哲学」を解説する。
① DAO `dbAppendOnly` オプションの魔力
レコードセットを開く際に指定している `dbAppendOnly` は極めて重要だ。既存データの読み込みを行わず、新規追加（Append）専用のストリームとして開くため、Jet/ACEエンジンは余計なロックやページ読み込みを行わない。これにより、数千件のインサートであっても一瞬で完了する。
② セッション競合を防ぐテーブル名命名規則
マルチユーザー環境のAccess（バックエンド共有型）において、固定名の一時テーブル（例: `tmp_Filter`）を複数のクライアントが同時に作成・削除しようとすれば、間違いなく「テーブルが排他ロックされています」という致命的な競合エラーを引き起こす。
今回のコードでは、タイムスタンプと乱数を組み合わせた一意のテーブル名 (`tmp_Criteria_YYYYMMDDHHNNSS_XXX`) を動的生成することで、完全なスレッドセーフ（セッション分離）を実現している。
③ MDB/ACCDBの肥大化（Bloat）対策
Accessにおける `CREATE TABLE` と `DROP TABLE` の乱用は、内部のシステムテーブル（MSysObjects等）にゴミを残し、ファイルサイズが異常肥大化する原因となる。
もしこの処理が極めて高頻度で実行されるシステムであるならば、動的作成ではなく、あらかじめ固定の作業用テーブルを用意し、`DELETE FROM ワークテーブル` でデータをクリア・再利用する設計へ昇華させるべきだ。
—
5. まとめ
Access VBAというレガシーなフレームワークであっても、データベースの理論（セット指向、トランザクション制御、リソースのライフサイクル管理）に則ったコードを書けば、モダンなシステムに匹敵する堅牢性とパフォーマンスを引き出すことが可能だ。
「文字数制限」という表層的なエラーに怯えるのではなく、背後にあるストレージエンジンとメモリの挙動を支配すること。それこそが、真のプロフェッショナルエンジニアの仕事である。
