VB.NETを掌握する極限の知見：StringBuilderによるアロケーション削減の極意
VBAからVB.NETへの移行期、あるいはレガシーなVB6の作法を引きずったままのコードベースで、いまだに見かける光景がある。数万行に及ぶCSV出力、あるいは巨大なログファイルの生成ループの中で、平然と`&`演算子や`String.Concat`を叩いているコードだ。
「動いているからいい」ではない。
ガベージコレクタ（GC）の挙動、そしてLOH（Large Object Heap）の断片化を知るシニアエンジニアの視点から見れば、それはメモリ空間に対する暴力であり、システムのスケーラビリティをドブに捨てる行為に他ならない。
今回は、VB.NET環境における`System.Text.StringBuilder`のパフォーマンス最適化、特に「初期容量（Capacity）の事前計算と確保」に焦点を当て、アロケーションを極限まで削減する実務的ノウハウを叩き込む。
—
1. なぜ `&` 演算子とデフォルトの `StringBuilder` は悪なのか
文字列型（`System.String`）は.NETにおいてイミュータブル（不変）である。
つまり、一度生成された文字列の内容は変更できない。`&` 演算子を使って文字列を結合するということは、以下の一連の処理を裏で強制していることになる。
1. 結合後の文字列長に見合った新しいメモリ領域をヒープ上に確保する。
2. 既存の文字列の内容を、新しいメモリ領域にコピーする。
3. 古い文字列はGCの回収対象（ガベージ）となる。
これを数万回ループさせればどうなるか。
世代別ガベージコレクション（Generation 0, 1, 2）の負荷が跳ね上がり、アプリケーションの応答性が一瞬フリーズしたような挙動を示すようになる。さらに、結合後のサイズが85,000バイトを超える瞬間、オブジェクトはLOH（Large Object Heap）に直接割り当てられ、メモリの断片化（メモリフラグメンテーション）を引き起こす。
デフォルトコンストラクタの罠
では、`Dim sb As New StringBuilder()` と書けば救われるのか？
答えは「半分ノー」だ。
引数なしのコンストラクタを使用した場合、`StringBuilder`内部のバッファ初期容量は16文字に設定される。
文字数が16を超えた瞬間、内部で何が起きるか。
1. 現在の容量の2倍（32文字 -> 64文字 -> 128文字…）の新しい配列がヒープ上に再割り当てされる。
2. 古い配列から新しい配列へ文字がコピーされる。
3. 古い配列は捨てられる。
数万行を処理する場合、この「配列の再割り当てとメモリコピー」が何十回も無駄に発生している。これでは `&` 演算子と大差ない。
—
2. アロケーションゼロへのアプローチ：初期容量の事前計算
真にパフォーマンスを追求するアーキテクトであれば、「必要な最大容量を事前に計算し、コンストラクタで一発確保する」。これが鉄則である。
以下の実務コードを見てほしい。数万件のデータベースレコード（またはファイル行）から、巨大なCSV文字列をノーアロケーションに近い状態で生成するサンプルだ。
Imports System.Text
Public Class CsvExporter
”’
”’
Public Function GenerateLargeCsv(ByVal records As List(Of ExportRecord)) As String
‘ 1レコードあたりの平均文字数を仮定（例: 1行あたり平均150文字）
‘ マジックナンバーを避け、ドメイン知識に基づいた係数を使用する
Const EstimatedCharsPerRecord As Integer = 150
‘ 【極意】あらかじめ必要な容量を計算し、バッファを拡張させない
Dim initialCapacity As Integer = records.Count EstimatedCharsPerRecord
‘ 初期容量を指定してStringBuilderをインスタンス化
Dim sb As New StringBuilder(initialCapacity)
‘ ヘッダー行の追加
sb.AppendLine(“ID,Code,Name,CreatedAt,Status”)
‘ ループ処理
For Each record As ExportRecord In records
‘ AppendFormatはボックス化（Boxing）が発生するため、
‘ 極限のパフォーマンスを求める場合はスニペットのようにAppendをチェインさせるか、
‘ Span
sb.Append(record.Id)
sb.Append(“,”c)
sb.Append(EscapeCsv(record.Code))
sb.Append(“,”c)
sb.Append(EscapeCsv(record.Name))
sb.Append(“,”c)
sb.Append(record.CreatedAt.ToString(“yyyy-MM-dd HH:mm:ss”))
sb.Append(“,”c)
sb.AppendLine(record.Status)
Next
‘ ToString()の1回のみで最終的なStringオブジェクトを生成
Return sb.ToString()
End Function
Private Function EscapeCsv(ByVal input As String) As String
If String.IsNullOrEmpty(input) Then
Return String.Empty
End If
‘ 簡易エスケープ処理（実際の実装ではダブルクォーテーション等の処理を入れる）
If input.Contains(“,”) OrElse input.Contains(“”””) Then
Return “””” & input.Replace(“”””, “”””””) & “”””
End If
Return input
End Function
End Class
Public Class ExportRecord
Public Property Id As Long
Public Property Code As String
Public Property Name As String
Public Property CreatedAs As DateTime
Public Property Status As String
End Class
このコードのアーキテクチャ的解説
1. バッファの事前確保: `New StringBuilder(initialCapacity)` により、内部の `char[]` 配列が最初に一発で確保される。ループ中のリサイズ（再アロケーション）とガベージの発生が完全にゼロになる。
2. 文字リテラルの活用: `”,”c` のように文字リテラル（Char型）としてAppendしている点に注目せよ。文字列（String型）として渡すと、内部でオーバーロードの解決や余計な処理を挟む要因になるが、Char型であればダイレクトに内部バッファへ書き込まれる。
3. `AppendFormat` の排除: 可読性は上がるが `AppendFormat` は引数のオブジェクト化（Boxing）および書式解析コストが発生する。ミリ秒単位を争うバッチ処理では、地道な `Append` のチェインこそが正義である。
—
3. レガシー環境・長時間稼働プロセスにおけるメモリ管理の極意
エンタープライズ領域のVB.NETデスクトップアプリや、Windowsサービスとして常駐するバッチ処理において、`StringBuilder` を多用する際の落とし穴がある。
それは、「一度大きく拡張されたStringBuilderの内部バッファは、縮小しない」という仕様だ。
例えば、あるタイミングで100MB分の文字列を処理するために `StringBuilder` の容量が100MB分に拡張されたとする。その後、別のタイミングで数KBの短い文字列を処理するために同じインスタンス（あるいは使い回されたインスタンス）を使い続けると、使われていない99.9MBのメモリがヒープに居座り続けることになる。これがメモリリークの温床、あるいはメモリ肥大化（Bloat）の正体だ。
対策：インスタンスのスコープ限定と `EnsureCapacity` / `Clear` の使い分け
1. 基本方針：メソッドローカルで使い捨てる
`StringBuilder` は極力メソッドのスコープ内で生成し、メソッド終了とともにGCの第0世代として速やかに回収させるのが最も安全である。マネージドヒープの世代別GCは、短命なオブジェクトの回収に対して驚異的なパフォーマンスを発揮する。
2. インスタンスをキャッシュ・再利用する場合の注意
オブジェクトプール等で `StringBuilder` を使い回す設計にする場合は、使い終わった後に `sb.Clear()` を呼ぶこと。`Clear()` は内部の長さを0にするが、allocated な配列バッファ自体は保持するため、次回のアロケーションコストをゼロにできる。ただし、最大バッファサイズが異常に膨らんでいないかを監視するガードロジックが必要だ。
—
4. Windows API連携やシステム間連携における実務知見
製造業のプラント制御や、古い基幹システムとの連携において、VB.NETから `DllImport` を介してネイティブの Windows API（C++製のDLLなど）を叩くケースはまだ根強い。
このとき、非管理,メモリ（Unmanaged Memory）と `StringBuilder` の挙動でハマるエンジニアが後を絶たない。
APIへバッファを渡して文字列を書き込んでもらう場合、`StringBuilder` の初期容量が不足していると、ネイティブ側でバッファオーバーランを引き起こし、致命的なクラッシュ（Access Violation）を招く。
Imports System.Runtime.InteropServices
Imports System.Text
Public Class NativeInterop
‘ 外部のWin32 APIやレガシーDLLのインポート例
Private Shared Function GetPrivateProfileString(
ByVal lpAppName As String,
ByVal lpKeyName As String,
ByVal lpDefault As String,
ByVal lpReturnedString As StringBuilder,
ByVal nSize As Integer,
ByVal lpFileName As String) As UInteger
End Function
Public Shared Function ReadIniFile(ByVal iniPath As String, ByVal section As String, ByVal key As String) As String
‘ 【重要】ネイティブ側が書き込む最大サイズをあらかじめ担保する
Dim sb As New StringBuilder(256)
Dim result As UInteger = GetPrivateProfileString(section, key, “”, sb, sb.Capacity, iniPath)
Return sb.ToString()
End Function
End Class
API連携において `StringBuilder` を使う際は、「ネイティブ側が書き込む可能性のある最大長」を `Capacity` に明示して初期化することが、セキュアかつ堅牢なシステムを構築するための絶対条件である。
—
5. 結言
VB.NETは「レガシーな言語」などではない。.NET Runtime（CLR）の進化とともに、その下回り（基盤）は常に最先端の最適化恩恵を受けている。
しかし、どれほどCLRが優秀であれ、コードを書く人間のアーキテクチャに対する理解が甘ければ、システムは重くなり、やがて破綻する。
`&` 演算子を安易にループ内で使い捨てる悪癖を断ち切り、`StringBuilder` の容量設計とメモリライフサイクルを掌握すること。それこそが、現場を支えるシニアエンジニア、そして真の業務自動化エンジニアのプライドである。
コードの1行、メモリの1バイトに魂を込めよ。勝負は常に細部に宿る。
