【VBA極限術】ReDim Preserveの「コスト」を理解し、メモリを制する動的配列の実装論
業務自動化の現場で、初心者が陥る最大にして最初の罠。それが「データ件数が不明な状態での配列操作」です。
「とりあえずデータがあるだけ `ReDim Preserve` を繰り返せばいいんでしょ？」
もしあなたがそう考えているなら、今すぐその思考を捨ててください。`ReDim Preserve` は、魔法の杖ではありません。メモリの断片化を招き、大規模データ処理においてツールを鈍足化させる「諸刃の剣」です。
今日は、メモリ効率を極限まで高め、堅牢なプロダクションコードを書くための作法を伝授します。
—
1. なぜ「毎回のReDim」は罪なのか
`ReDim Preserve` を実行するたび、VBAは以下の処理を水面下で行います。
1. 新しいメモリ領域の確保: 現在の配列より大きいメモリブロックをヒープ領域から確保。
2. データのコピー: 旧配列の全データを、新しいメモリ領域へ物理的にコピー。
3. 旧領域の解放: 古いメモリ領域を破棄。
つまり、ループのたびに「メモリの確保とコピー」という重い負荷が発生します。要素数が数千件程度なら誤差ですが、数万件規模のCSVやDB連携を行うと、実行時間は指数関数的に増大します。
「倍々拡張」のアルゴリズム
メモリ消費を抑えつつ処理速度を落とさない唯一の正解は、「必要に応じて、余裕を持って拡張する」ことです。限界に達した時だけ拡張を行い、拡張時には現在のサイズを倍にする。これが計算量を最適化するプロの常識です。
—
2. 実践：高効率・動的配列クラスの設計
実務でそのまま使える、堅牢な配列管理のコード例を提示します。
‘ @description: メモリ効率を意識した動的配列管理のテンプレート
‘ @author: Automation Architect
Public Sub ProcessLargeData()
Dim dataArray() As Variant
Dim currentIdx As Long
Dim maxIdx As Long
Dim i As Long
‘ 初期化：まずは少量のメモリを確保（例：100件）
maxIdx = 100
ReDim dataArray(1 To maxIdx)
currentIdx = 0
‘ データソースからループ処理
For i = 1 To 10000 ‘ 仮に1万件のデータがあると想定
‘ 限界に達したら配列を拡張（倍々に拡張してコピー回数を激減させる）
If currentIdx >= maxIdx Then
maxIdx = maxIdx 2
ReDim Preserve dataArray(1 To maxIdx)
End If
currentIdx = currentIdx + 1
dataArray(currentIdx) = “Data_” & i
Next i
‘ 最後に、実際に使ったサイズまで切り詰める（不要なメモリを解放）
If currentIdx > 0 Then
ReDim Preserve dataArray(1 To currentIdx)
End If
Debug.Print “処理完了: ” & UBound(dataArray) & ” 件のデータを格納しました。”
End Sub
このコードのポイント
- 倍々拡張（Doubling Strategy）: 拡張の頻度を劇的に減らしています。これにより、コピーのオーバーヘッドを最小化します。
- 最終的な切り詰め: 最後に `ReDim Preserve` を1回だけ行い、余分に確保したメモリを解放します。これが「メモリリークを防ぎつつ最適化する」プロの流儀です。
—
3. 現場で「死なない」ための3つの鉄則
① 配列の次元は「1次元」を貫け
多次元配列（`data(100, 100)`など）の `ReDim Preserve` は、最後の次元しか拡張できません。これは仕様上の制約であり、設計ミスを誘発します。2次元以上のデータが必要なら、1次元配列にクラスオブジェクトを格納する「配列の配列」構造を検討してください。
② エラーハンドリングは必須
外部ファイルやAPIからデータを取得する場合、想定外の空データや型の不一致で `ReDim` が失敗することがあります。必ず `On Error GoTo` を活用し、どの段階でメモリ確保に失敗したのかをログに吐く設計にしてください。
③ 巨大データなら「Collection」や「Dictionary」も検討せよ
もし、「そもそも件数が全く予測不能」かつ「データ検索も頻繁に行う」のであれば、配列へのこだわりを捨て、`Scripting.Dictionary` を使うべきです。VBAの配列は「連続したメモリ領域」を占有するため、断片化に弱いです。用途に合わせて「データ構造」を選択する力が、エンジニアの差となります。
—
最後に：効率化は「可読性」の上に成り立つ
どんなにメモリ効率が良くても、メンテナンス不可能な複雑すぎるコードは「技術的負債」です。
今回紹介した「倍々拡張」のロジックは、汎用的なモジュールに切り出して再利用してください。「どう書くか」よりも「どうシステムを設計するか」。その視点を持つだけで、あなたの書くVBAは、単なるマクロから「堅牢な業務アプリケーション」へと昇華されます。
さあ、コードを書き換えましょう。あなたの手元で、ツールが軽快に動き出すはずです。
