BLOBの深淵を制御せよ：ADOとStreamオブジェクトによる堅牢なバイナリ入出力アーキテクチャ
業務システムを設計していると、避けては通れない壁にぶつかることがある。それは、「画像、PDF、Excelといったバイナリデータ（BLOB）を、いかにしてデータベースとローカル環境の間で、メモリを爆発させることなく、かつ破損させずにやり取りするか」という問題だ。
多くの開発者は、この問題に対して「バイト配列（Byte Array）に一度格納して、ループで回す」といった、素人臭い、そして極めて危険な設計を選択しがちだ。しかし、数MBを超えるファイルが頻発するエンタープライズ環境において、そのような設計は即座に「メモリ不足（Out of Memory）」や「データの破損」という致命的なバグを引き起こす。
今日は、Access VBAをフロントエンドとし、SQL Serverをバックエンドとする構成において、ADODB.Streamを駆使した、プロフェッショナル向けの「極限のBLOBハンドリング」を伝授する。
1. なぜ「バイト配列」ではいけないのか
まず、設計思想の根底にある「なぜ」を理解してほしい。
初心者の書くコードは、以下のようなロジックになりがちだ。
1. SQLでデータを取得する。
2. フィールドの内容を `Variant/Byte()` 型の配列に丸ごとコピーする。
3. その配列をファイルに書き出す。
この手法には、致命的な欠陥が2つある。
致命的な欠陥①：メモリの断片化と枯渇
VBAの `Variant` 型は非常に柔軟だが、その分メモリ管理のオーバーヘッドが巨大だ。10MBのファイルを扱うだけでも、メモリ上にはその数倍の領域を確保しようとする挙動が見られる。複数のユーザーが同時に巨大なファイルをダウンロードするシステムを想像してほしい。サーバーのメモリは一瞬で食いつぶされる。
致命的な欠陥②：ストリーム制御の欠如
バイナリデータは「流れ（Stream）」として扱うべきものだ。ファイルシステムとデータベースの境界を跨ぐ際、データを「塊」としてではなく、「ストリーム」として流し込むことで、メモリ消費を最小限に抑え、かつポインタ操作による高速な転送が可能になる。
これこそが、我々が `ADODB.Stream` を使うべき絶対的な理由だ。
2. アーキテクチャの要諦：ADODB.Streamの役割
`ADODB.Stream` は、メモリ上、あるいはファイル上でのバイナリデータの「流れ」を抽象化するオブジェクトだ。これを用いることで、以下のワークフローが実現する。
- DB → File (Export): Recordsetからバイナリデータをストリームとして吸い出し、直接ファイルへと流し込む。
- File → DB (Import): ファイルをストリームとして開き、その中身をRecordsetのフィールドへ直接流し込む。
このプロセスにおいて、VBAの変数（配列）を経由するステップを極限まで減らすことが、堅牢な設計への第一歩となる。
3. プロダクション・コード：堅牢な実装例
以下に、実務でそのまま利用可能な、エラーハンドリングとリソース解放を徹底したクラスモジュール級のコードを示す。
事前準備
このコードを使用するには、参照設定で “Microsoft ActiveX Data Objects x.x Library” にチェックを入れておく必要がある。
Option Explicit
' ======================================================================================
' Module: modBlobHandler
' Description: ADOとStreamを用いた、堅牢なBLOB入出力モジュール
' Author: Chief Architect
' ======================================================================================
''' <summary>
''' SQL Server上のBLOBデータをローカルファイルとして保存する
''' </summary>
''' <param name="rs">データが含まれるRecordsetオブジェクト (CursorLocationはadUseClient推奨)</param>
''' <param name="fieldName">BLOBデータが格納されているフィールド名</param>
''' <param name="savePath">保存先のフルパス</param>
Public Sub ExportBlobToFile(ByRef rs As ADODB.Recordset, ByVal fieldName As String, ByVal savePath As String)
Dim stream As ADODB.Stream
On Error GoTo ErrorHandler
' 1. Recordsetの状態確認
If rs Is Nothing Then Err.Raise vbObjectError + 1, "modBlobHandler", "RecordsetがNothingです。"
If rs.EOF Then Err.Raise vbObjectError + 2, "modBlobHandler", "レコードが存在しません。"
' 2. Streamオブジェクトの生成
Set stream = New ADODB.Stream
' 3. ストリームの設定
' adTypeBinary: バイナリモードを指定
' adModeWrite: 書き込みモードを指定
stream.Type = adTypeBinary
stream.Mode = adModeWrite
' 4. データの転送
' GetChunkを使用せず、フィールドから直接ストリームへ書き込むアプローチ
' ※ADOの仕様上、フィールドの値を直接Streamに流し込むには
' 一度バイナリ配列として受け取る必要があるが、
' 大規模データの場合はField.GetChunkをループさせる設計がより高度である。
' ここでは実用性と安定性のバランスを取った実装とする。
Dim varData As Variant
varData = rs.Fields(fieldName).Value
If IsNull(varData) Then
Err.Raise vbObjectError + 3, "modBlobHandler", "フィールドの値がNullです。"
End If
' ストリームにデータを書き込み
stream.Write varData
' 5. ファイルへの保存
' SaveToFileの第2引数を adSaveCreateOverWrite にすることで上書きを許可
stream.SaveToFile savePath, adSaveCreateOverWrite
Debug.Print "Export Success: " & savePath
CleanUp:
' リソースの確実な解放
If Not stream Is Nothing Then
If stream.State <> adStateClosed Then stream.Close
Set stream = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox "Export Error: " & Err.Description, vbCritical, "Error"
Resume CleanUp
End Sub
''' <summary>
''' ローカルファイルをSQL Server上のBLOBフィールドにアップロードする
''' </summary>
''' <param name="rs">更新対象のRecordset (LockTypeはadLockOptimistic必須)</param>
''' <param name="fieldName">更新対象のBLOBフィールド名</param>
''' <param name="filePath">読み込むファイルのフルパス</param>
Public Sub ImportFileToBlob(ByRef rs As ADODB.Recordset, ByVal fieldName As String, ByVal filePath As String)
Dim stream As ADODB.Stream
On Error GoTo ErrorHandler
' 1. ファイルの存在確認
If Dir(filePath) = "" Then Err.Raise vbObjectError + 4, "modBlobHandler", "ファイルが見つかりません: " & filePath
' 2. Streamオブジェクトの生成と設定
Set stream = New ADODB.Stream
stream.Type = adTypeBinary
stream.Mode = adModeRead
' 3. ファイルをストリームとして開く
stream.Open
stream.LoadFromFile filePath
' 4. Recordsetへの書き込み
' Streamの内容をバイナリ配列として取得し、フィールドに代入
' 大規模ファイルの場合は、ここを分割処理する設計にする
rs.Fields(fieldName).Value = stream.Read
' 5. 更新の確定（RecordsetのLockTypeが適切であれば自動的に反映される）
' rs.Update は呼び出し元のコンテキストに依存するため、ここでは行わない
Debug.Print "Import Success: " & filePath
CleanUp:
If Not stream Is Nothing Then
If stream.State <> adStateClosed Then stream.Close
Set stream = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox "Import Error: " & Err.Description, vbCritical, "Error"
Resume CleanUp
End Sub4. アーキテクトが教える「落とし穴」と回避策
コードを書くだけでは不十分だ。運用フェーズでシステムを崩壊させないための「知見」を共有しておく。
① CursorLocation の選択
ADOを使用する場合、`Recordset.CursorLocation = adUseClient` を明示的に指定することを強く推奨する。
サーバーサイドカーソル（`adUseServer`）は、バイナリデータの取得においてネットワークトラフィックの制御が難しく、パフォーマンスが不安定になる傾向がある。クライアントサイドカーソルを使うことで、データをローカルメモリに一旦完全に展開してから操作するため、ストリーム操作との相性が極めて良い。
② トランザクションの境界
BLOBの入出力は、ファイル操作とデータベース更新の「二重の作業」だ。
もし、「DBの更新は成功したが、ファイルがディスクフルで保存できなかった」という事態が起きたらどうするか？
- 設計指針: 常に「データベースの更新」を最後に持ってくるか、あるいはファイル操作が完全に成功した後に `rs.Update` を実行する。ファイル操作をトランザクションに含めることはできない（VBAからはファイルシステムへのロールバックは不可能だからだ）という現実を忘れてはならない。
③ 64bit環境への意識
もし将来的に、Accessの64bit版へ移行する場合、バイナリデータの扱いや外部ライブラリの呼び出しには細心の注意が必要だ。今回の `ADODB.Stream` はCOMオブジェクトであるため基本的には透過的に動作するが、配列のインデックス（`Long` vs `LongPtr`）を扱うロジックが混在する場合は、型定義に細心の注意を払え。
結びに代えて
BLOBの扱いは、単なる「データのコピー」ではない。それは、メモリ、ディスク、ネットワーク、そしてデータベースの整合性という、コンピュータサイエンスの基本要素を高度に調和させるプロセスである。
「動けばいい」という思考を捨て、「いかにしてリソースを最小限に抑え、例外からシステムを守るか」というアーキテクトの視点を持て。それが、プロフェッショナルの仕事だ。
