決定論的ID取得の極意：SQL ServerとADOを用いたIDENTITY列の完全掌握
システムの規模が拡大し、単一ユーザーのAccessアプリケーションから、SQL Serverをバックエンドとしたマルチユーザー環境へと移行する際、多くの開発者が「データの整合性」という名の壁に突き当たる。
その中でも、新規レコード追加直後に生成される`IDENTITY`列（自動採番）の取得は、一見単純に見えて、実は極めて設計思想を問われる領域だ。不適切な実装は、トリガーによる予期せぬIDの混入、ネットワークラウンドトリップによるパフォーマンス低下、そしてトランザクションの不整合を引き起こす。
本稿では、中級者レベルの「動けば良い」という実装を脱却し、シニアエンジニアが追求すべき、堅牢かつ高効率なID取得のアーキテクチャについて、その真髄を解説する。
1. 致命的な罠：`@@IDENTITY` vs `SCOPE_IDENTITY()`
まず、歴史的な経緯とアーキテクチャの違いを明確にしておく。これを知らずにコードを書くことは、戦場に地図を持たずに行くに等しい。
`@@IDENTITY` の脆弱性
`@@IDENTITY` は、現在の「セッション」内で最後に生成されたIDENTITY値を取得する。一見便利だが、致命的な欠陥がある。それは、「トリガー」の存在を考慮していない点だ。
もし、対象のテーブルに監査ログを記録するためのトリガーが設定されており、そのトリガーが別のテーブルにレコードを挿入した場合、`@@IDENTITY` は「本来取得したいID」ではなく「トリガーが挿入したログテーブルのID」を返してしまう。これは、データの親子関係を破壊する決定的なバグとなる。
`SCOPE_IDENTITY()` の決定論的性質
対して、`SCOPE_IDENTITY()` は、現在の「スコープ（実行コンテキスト）」内で生成された最新のIDを返す。トリガーによる挿入は別のスコープとして扱われるため、影響を受けない。
実務において、ID取得を求めるなら、`SCOPE_IDENTITY()` を選択することはもはや選択肢ではなく、義務である。
2. パフォーマンスの重み：ラウンドトリップの最小化
多くの開発者は、以下のような2ステップの処理を書きがちだ。
1. `INSERT` 文を実行する。
2. `SELECT SCOPE_IDENTITY()` を実行してIDを取得する。
しかし、これはアーキテクチャとして極めて不格好だ。サーバーへの通信（ネットワークラウンドトリップ）が2回発生するため、高負荷環境下ではレイテンシが蓄積し、システム全体のレスポンスを悪化させる。
プロフェッショナルは、「INSERTとID取得を、単一のSQLステートメントとしてアトミックに実行する」。これにより、通信回数を1回に抑え、かつトランザクションの整合性を極限まで高めることができる。
3. 実装パターン：ADO Commandオブジェクトによる統合実行
Access VBAからSQL Serverを操作する場合、DAOではなくADO（ActiveX Data Objects）を選択するのが定石だ。特に、パラメータ化クエリを用いた`ADODB.Command`オブジェクトの使用は、SQLインジェクション対策だけでなく、実行プランの再利用という観点からも不可欠である。
以下に、実戦でそのまま投入可能な、極めて堅牢な実装パターンを示す。
''' <summary>
''' SQL Serverへレコードを挿入し、生成されたIDENTITY値を安全かつ高速に取得する。
''' </summary>
''' <param name="conn">接続済みのADODB.Connectionオブジェクト</param>
''' <param name="sqlInsert">INSERT文（パラメータを含む）</param>
''' <param name="params">Commandオブジェクトに渡すパラメータの配列（実装に合わせて調整）</param>
''' <returns>生成されたIDENTITY値（Long型）</returns>
Public Function InsertAndGetIdentity(ByRef conn As ADODB.Connection, _
ByVal sqlInsert As String, _
ByRef params As Collection) As Long
Dim cmd As ADODB.Command
Dim rs As ADODB.Recordset
Dim newID As Long
' エラーハンドリングの確立
On Error GoTo ErrorHandler
' 1. Commandオブジェクトの生成
Set cmd = New ADODB.Command
With cmd
.ActiveConnection = conn
' INSERTとSCOPE_IDENTITYの取得を1つのバッチとして結合
' これにより、ネットワークラウンドトリップを1回に集約する
.CommandText = sqlInsert & "; SELECT SCOPE_IDENTITY() AS NewID;"
.CommandType = adCmdText
' 2. パラメータのバインド
' ※実務では、SQLインジェクションを防ぐため必ずパラメータ化を行う
Dim p As Variant
For Each p In params
' p(0): Name, p(1): Type, p(2): Value の構造を想定
.Parameters.Append .CreateParameter(p(0), p(1), adParamInput, , p(2))
Next p
' 3. 実行
' Executeメソッドにより、INSERT実行後、直ちにRecordsetとして結果を受け取る
Set rs = .Execute
End With
' 4. 結果の抽出
If Not rs.EOF Then
' Nullチェックは実務上必須
If Not IsNull(rs.Fields("NewID").Value) Then
newID = CLng(rs.Fields("NewID").Value)
End If
End If
CleanUp:
' 5. オブジェクトのライフサイクル管理（明示的解放）
' メモリリークを防ぎ、COMオブジェクトの参照カウントを適切に制御する
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
If Not cmd Is Nothing Then Set cmd = Nothing
InsertAndGetIdentity = newID
Exit Function
ErrorHandler:
' ログ出力等のエラー処理をここに集約
Debug.Print "Critical Error in InsertAndGetIdentity: " & Err.Description
newID = 0
Resume CleanUp
End Function実装のポイント解説
1. SQLの結合: `.CommandText = sqlInsert & “; SELECT SCOPE_IDENTITY() AS NewID;”`
この一行が、パフォーマンスと整合性の鍵だ。INSERT処理とID取得を同一のバッチとして送信することで、サーバー側では同一コンテキスト内で処理が完結する。
2. オブジェクトの明示的解放: `Set rs = Nothing`
VBAのガベージコレクションは、COMオブジェクトに対して必ずしも即時的・確実ではない。特に大量のデータを扱うループ内や、長時間稼働するAccessアプリケーションにおいて、`Set … = Nothing` を怠ることは、メモリリークと接続リークを招く致命的な瑕疵となる。
3. パラメータ化クエリ:
`cmd.Parameters.Append` を用いることで、データ型を厳密に定義し、SQL Server側での型変換コストを最小化しつつ、セキュリティを担保している。
4. 【極限の知見】SQL Server 2005以降の真の最適解：`OUTPUT` 句
もし、ターゲットとするSQL Serverが2005以降であれば、`SCOPE_IDENTITY()` を使うよりもさらに洗練された手法が存在する。それが `OUTPUT` 句 の利用である。
`INSERT INTO … OUTPUT inserted.ID …` という構文を用いることで、挿入された値を直接結果セットとして返却できる。これは `SCOPE_IDENTITY()` よりもさらに宣言的であり、複数の列を一度に取得したい場合にも極めて強力だ。
-- OUTPUT句を用いたSQLの例
INSERT INTO Employees (EmployeeName, Department)
OUTPUT inserted.EmployeeID
VALUES ('John Doe', 'Engineering');これをADOの `Command.Execute` で呼び出せば、`Recordset` に直接新しいIDが格納される。トリガーの影響を完全に排除し、かつ最も効率的な方法である。
結論：アーキテクトの責務
Access VBAからSQL Serverを操作する際、我々は「クライアント側（Access）の利便性」と「サーバー側（SQL Server）の整合性」の狭間で常に判断を迫られる。
単に「IDが取れた」で満足してはならない。
- それは、トリガーに耐えうる設計か？
- それは、ネットワークのオーバーヘッドを最小化しているか？
- それは、メモリ管理において美しく、決定論的な挙動を示すか？
これらの問いに「Yes」と答えられる実装こそが、レガシーな環境を支え、次世代のシステムへと繋ぐ、真にプロフェッショナルなコードである。
