墓場まで持っていくVBAの鉄則：文字列連結の「真実」とパフォーマンスの最適化
VBAの現場で、未だに `s = s & “text”` というコードを無自覚にループ内で書いている者はいないだろうか。もし君がそうなら、今すぐその指を止めろ。
小規模なデータなら問題はない。だが、10万行のCSVを生成する、あるいは巨大なJSON文字列をAPIに投げる際、その記述はシステムを「沈黙」させる毒になる。今日は、メモリとプロセッサの挙動を知り尽くした者だけが知る、文字列連結の最適解を紐解く。
—
1. なぜ `&` 演算子の多用は「罪」なのか
VBAの文字列型（BSTR）は、COMの仕様に基づき、不変（イミュータブル）なメモリ領域を確保する。
`s = s & “data”` と記述した瞬間、VBAは以下のプロセスを強制される。
1. 現在の `s` のサイズ + `”data”` のサイズ分をヒープ上に再確保する。
2. 古い `s` の内容と `”data”` を新しい領域にコピーする。
3. 古い `s` のメモリ領域を解放する。
これをループ内で繰り返せばどうなるか。メモリ断片化（フラグメンテーション）の加速と、ガベージコレクション（あるいはメモリの再確保）によるオーバーヘッドが指数関数的に増大する。これが、VBAの処理速度が終盤にかけて急激に低下する根本原因だ。
—
2. 極限の最適解：Join関数による「バッファリング戦略」
大量の文字列を扱う場合、我々アーキテクトが取るべき唯一の正解は「配列に格納し、最後にJoinで一括結合する」ことだ。
配列への格納は、メモリの再確保が最小限で済む（あるいは動的配列の `ReDim Preserve` を適切に制御することで制御可能）。文字列連結のコストを `O(n^2)` から `O(n)` へと劇的に引き下げる。
実装サンプル：ハイパフォーマンス・文字列連結
‘ 大量データ処理用の最適化関数
Public Function BuildLargeString(ByRef dataArray() As String) As String
‘ 配列の要素数が決まっている場合は、ReDimで最初から領域を確保せよ
‘ 頻繁なReDim Preserveは避けるのが鉄則
‘ Join関数は内部的にバッファを一括計算してメモリを確保するため、
‘ & 演算子を繰り返すよりも圧倒的に高速である
BuildLargeString = Join(dataArray, vbCrLf)
End Function
—
3. メモリ管理の深淵：Windows APIの活用と解放の義務
VBAは自動メモリ管理言語だが、外部APIや巨大オブジェクトを扱う際、その「甘え」は命取りになる。特にレガシーなシステム連携を行う際は、以下の原則を徹底せよ。
- オブジェクトの明示的破棄: `Set obj = Nothing` はおまじないではない。オブジェクトのライフサイクルを強制終了させる、エンジニアの意志だ。
- API呼び出し時のバッファ管理: `SysAllocString` 等のWindows APIを直接叩く領域に足を踏み入れるなら、メモリリークを避けるため `SysFreeString` の呼び出しを `Error Handling`（On Error GoTo）で確実に保証すること。
現場で使える「安全性と速度」を両立するパターン
Public Sub HighSpeedProcess()
Dim i As Long
Dim buffer() As String
ReDim buffer(0 To 9999) ‘ 事前に領域を確保（パフォーマンスの要）
On Error GoTo Cleanup
For i = 0 To 9999
buffer(i) = “Record_” & i
Next i
‘ 結合処理
Dim result As String
result = Join(buffer, “,”)
‘ ここでAPI呼び出しやファイル出力を行う
Cleanup:
‘ 異常終了時も必ずメモリを解放する構造にする
Erase buffer
If Err.Number <> 0 Then MsgBox “Error: ” & Err.Description
End Sub
—
4. 伝説のエンジニアへのアドバイス：計測なき最適化は無意味である
この記事で教えた手法は強力だが、「計測（プロファイリング）」を忘れてはならない。
VBAの `Timer` 関数を用いて、処理開始前と後のミリ秒を計測する癖をつけろ。
- `&` 演算子で1万回結合した場合の実行速度
- `Join` 関数で1万回結合した場合の実行速度
この二つを比較すれば、君のシステムでどちらを採用すべきか、論理的な答えが出るはずだ。
VBAは古い言語ではない。「いかにハードウェアのリソースを制約の中で使い切るか」という、エンジニアの真髄を問うための最高の試練の場だ。小手先のテクニックに溺れず、メモリの挙動を支配せよ。それこそが、伝説のアーキテクトへの第一歩である。
