文字列連結の最適化：`&`演算子と`Join`関数のパフォーマンス比較と実務での使い分け
VBA（Visual Basic for Applications）の現場において、文字列の連結は最も頻繁に発生する処理の一つである。しかし、数千行から数万行に及ぶログの生成、外部APIへのリクエストペイロードの組み立て、あるいは巨大なCSVのエクスポート処理において、無頓着な文字列操作は瞬く間にVBAのランタイムを窒息させる。
シニアエンジニアであれば、VBAの裏側で何が起きているかを知っているはずだ。
今回は、`&`演算子と`Join`関数のパフォーマンス特性を極限まで暴き、メモリ管理の観点から実務における正しい使い分けを定義する。
—
1. 文字列連結の裏側：なぜ「愚直なループ」は破滅を招くのか
VBA（内部的にはCOMのBSTR：Basic String）において、文字列はイミュータブル（不変）なデータ構造として扱われる。
ループ内で以下のようなコードを書いたとき、何が起きているか。
‘ 悪夢のアンチパターン
Dim result As String
Dim i As Long
For i = 1 to 100000
result = result & “Data:” & i & vbCrLf
Next i
初心者は「変数を結合して更新している」と勘違いするが、実際に行われているのは以下のメモリ破壊的オペレーションである。
1. 新しい文字列長分のメモリ領域をOS/ランタイムに要求する。
2. 既存の`result`の文字列データを、新しく確保した領域の先頭にコピーする。
3. 追加する文字列（`”Data:” & i & vbCrLf`）をその後方にコピーする。
4. 古い`result`が占有していたメモリ領域を解放する。
これを10万回繰り返す。計算量は $O(N^2)$ となり、後半に進むにつれてアロケーションとメモリコピーのコストが爆発的に増加する。これが、VBAの処理が突然フリーズしたように重くなる真の原因である。
—
2. `Join`関数による配列バッファリングの優位性
このメモリ再割り当ての呪縛から逃れる唯一の王道が、「配列をバッファとして使い、最後に一度だけ結合する（`Join`）」アプローチである。
配列のサイズをあらかじめ（あるいは適切にチャンク単位で）確保しておけば、メモリの再割り当てコストは最小限に抑えられる。BSTRの構築は最後の`Join`実行時に一度だけ行われるため、計算量は $O(N)$ へと劇的に改善される。
ベンチマーク検証：`&` vs `Join`
以下の検証コードを用いて、10万回の結合処理におけるパフォーマンス差を体感してほしい。
Option Explicit
‘ 高精度タイマー用API（Win32 API）
If VBA7 Then
Private Declare PtrSafe Function QueryPerformanceCounter Lib “kernel32” (ByRef lpPerformanceCount As Currency) As Long
Private Declare PtrSafe Function QueryPerformanceFrequency Lib “kernel32” (ByRef lpFrequency As Currency) As Long
Else
Private Declare Function QueryPerformanceCounter Lib “kernel32” (ByRef lpPerformanceCount As Currency) As Long
Private Declare Function QueryPerformanceFrequency Lib “kernel32” (ByRef lpFrequency As Currency) As Long
End If
Public Sub BenchmarkStringConcat()
Const LOOP_COUNT As Long = 50000
Dim t1 As Currency, t2 As Currency, freq As Currency
Dim i As Long
QueryPerformanceFrequency freq
‘ — 1. & 演算子による逐次結合 —
QueryPerformanceCounter t1
Dim badResult As String
For i = 1 To LOOP_COUNT
badResult = badResult & “Index:” & CStr(i) & vbTab & “Value” & vbCrLf
Next i
QueryPerformanceCounter t2
Debug.Print “Operator (&) Elapsed: ” & Format((t2 – t1) / freq, “0.0000”) & ” sec”
‘ — 2. Join関数によるバッファリング結合 —
QueryPerformanceCounter t1
Dim buf() As String
ReDim buf(1 To LOOP_COUNT)
For i = 1 To LOOP_COUNT
buf(i) = “Index:” & CStr(i) & vbTab & “Value” & vbCrLf
Next i
Dim goodResult As String
goodResult = Join(buf, “”)
QueryPerformanceCounter t2
Debug.Print “Join Function Elapsed: ” & Format((t2 – t1) / freq, “0.0000”) & ” sec”
End Sub
実行結果の傾向（目安）
- `&` 演算子によるループ: 数秒〜数十秒（ループ回数が増えると指数関数的に悪化）
- `Join` 関数: 0.05秒以下（圧倒的な速度差）
規模が大きくなればなるほど、この差はシステム全体の生死を分けるポイントとなる。
—
3. 実務での使い分け：すべての場面で `Join` を使うべきか？
チーフアーキテクトとして断言する。「あらゆる文字列結合を `Join` に置き換える必要はない」。
エンジニアリングとはトレードオフの最適化である。以下の基準でコードベースを設計せよ。
A. `&` 演算子を使うべきケース
- 結合回数が固定かつ少数（数回〜数十回程度）
- 例：SQL文の構築、ファイルパスの生成、ログメッセージの基本フォーマット。
- コードの可読性が圧倒的に高く、VBAの最適化エンジンでも十分に高速に処理されるため、無理に配列化する必要はない。
- 短命な文字列の直感的結合
- 可読性を犠牲にしてまでパフォーマンスを追求するフェーズではない領域。
B. `Join` 関数（または独自コレクションクラス）を使うべきケース
- ループ内で動的に文字列を追加・構築する処理
- 例：CSV/TSVのエクスポート、巨大なJSON/XMLのシリアライズ、DBからのフェッチデータの整形。
- データ件数が数千件を超えるバッチ処理
- メモリリークや「メモリ不足（Error 7）」を回避するための防衛的プログラミングとして必須。
—
4. 極限のメモリ最適化：巨大データ処理におけるさらなる知見
実務において、数百万件のレコードを扱う場合、静的な`ReDim buf(1 To 1000000)`すらもメモリプレッシャー（大量の連続メモリ確保によるフラグメンテーション）を引き起こすリスクがある。
このような極限環境では、「チャンク方式（動的配列の拡張）」を採用する。
‘ チャンク単位でメモリを再割り当てする高度なバッファクラス的実装の断片
Private Sub AppendWithChunk(ByRef buf() As String, ByRef currentCount As Long, ByVal addStr As String)
Const CHUNK_SIZE As Long = 10000
If currentCount > UBound(buf) Then
‘ 領域が足りなくなったら、一気にチャンクサイズ分を拡張する
ReDim Preserve buf(1 To UBound(buf) + CHUNK_SIZE)
End If
currentCount = currentCount + 1
buf(currentCount) = addStr
End Sub
また、処理が終わった巨大な文字列変数や配列は、スコープを抜ける前に明示的に初期化（`StringVal = vbNullString` や `Erase buf`）し、VBAランタイムのガベージコレクション（正確にはCOMの参照カウントとBSTRマネージャー）へ速やかにメモリを返還する意識を持つことが、安定稼働するエンタープライズVBAシステムの必須条件である。
—
総括
VBAはレガシーな言語と揶揄されることが多い。しかし、その内部構造（BSTRの仕様やメモリ管理）を深く理解した上でコードを書くならば、C#やPythonの処理系に匹敵する堅牢かつ高速なデータ処理パイプラインを構築することが可能だ。
「なぜその書き方をするのか」――その問いにメモリレベルの根拠を持って答えられるエンジニアであれ。コードの細部に宿る執念こそが、システムを神域へと引き上げる。
