【VB.NET極限最適化】構造体(Structure) vs クラス(Class)：大量データを扱う業務アプリのメモリ戦略
開発現場でよくある光景だ。
「動くには動くが、数万件のデータを処理し始めると突然画面がカクつく」「タスクマネージャーを見るとメモリ使用量が右肩上がりに増え、数分おきにGC（ガベージコレクション）が走って処理がストップする」。
原因の多くは、「とりあえず何でもClassで定義する」という悪癖にある。
VB.NETにおいて、`Structure`（値型）と`Class`（参照型）の選択は、単なるシンタックスの好みではない。CPUキャッシュのヒット率、ヒープ領域の断片化、そしてGCの負荷を左右する極めて重要なアーキテクチャ上の決断だ。
今回は、数万件の座標データや高頻度な設定値を扱う業務アプリケーションにおいて、両者をどう使い分けるべきか。その「メモリの真実」とプロダクションコードで使える実践的な設計指針を授けよう。
—
1. スタックとヒープ：なぜ「何でもクラス」は罪なのか？
まず、メモリ上の振る舞いの違いを正確に把握してほしい。
- Structure（構造体 / 値型）:
データそのものが「スタック領域」（またはそれが含まれるオブジェクトのインライン）に配置される。生成・破棄のオーバーヘッドがほぼゼロであり、スコープを抜ければ一瞬で消え去る。GCの管理外であるため、GCストールの原因にならない。
- Class（クラス / 参照型）:
データ本体は「マネージド・ヒープ」に生成され、変数にはその「参照（ポインタ）」のみが格納される。インスタンスが破棄された後も、メモリは即座に解放されず、将来のGC実行時に回収されるのを待つことになる。
業務アプリにおける「GCの恐怖」
1件あたりわずか64バイトのオブジェクトを100万件生成・破棄したとする。クラスを使えば、約64MBのゴミがヒープに散乱する。
これが毎秒数回繰り返されるループ処理の中にあったとしたらどうなるか？ 頻繁なGCの発生によりCPU使用率が跳ね上がり、UIスレッドがフリーズする。「最近のPCはメモリ潤沢だから大丈夫」という甘い認識は、過酷な業務現場では通用しない。
—
2. 構造体とクラスの「厳格な」使い分け基準
チーフアーキテクトとして、チームメンバーには以下の基準を徹底させている。
【Structure（構造体）を採用すべき条件】
1. 論理的な単一の値を表す（例：X/Y座標、RGBカラー、複素数、小さなDTO）。
2. インスタンスのサイズが小さい（目安として16バイト〜最大でも64バイト以下）。
3. 不変（Immutable）である（値の変更ができない、または値渡しであることが望ましい）。
4. ボックス化（Boxing）の頻度が低い（`Object`型やインターフェース型へのキャストが起きない）。
【Class（クラス）を採用すべき条件】
1. サイズが大きい、または可変長である。
2. 参照の同一性が重要である（インスタンスが「誰のものか」を追跡する必要がある）。
3. 継承（Inheritance）やポリモーフィズムを利用する。
4. 状態を持ち、内部の値が頻繁に変更される。
> ⚠️ 痛い教訓：巨大な構造体は諸刃の剣
> 「構造体は速い」と誤解し、数十個のプロパティを持つ巨大な構造体を作ってはならない。構造体は値渡し（コピー）が基本であるため、メソッドの引数に渡すたびにメモリ全体のコピーが発生し、かえってパフォーマンスが急落する。
—
3. 実践：大量座標データを極限まで高速処理する設計
ここからは、実務で使えるプロダクションコードを示す。
地図上の位置情報や、CAD・図面データの処理を想定し、「数万件の座標データを扱い、ミリ秒単位で一括計算を行うモジュール」を構築する。
メモリ効率を最大化するため、座標データには構造体を採用し、さらに`ReadOnly`や配列を駆使してGCの発生を完全にゼロ（ゼロアロケーション）に近づける。
Imports System.Runtime.InteropServices
Namespace BusinessApp.Geometry
‘ 【超重要】メモリレイアウトを明示的に制御し、CPUキャッシュ効率を極限まで高める
Public Structure Point2D
‘ 読み取り専用（Immutable）にすることで、予期せぬ値書き換えバグを防ぎ、スレッドセーフにする
Public ReadOnly X As Double
Public ReadOnly Y As Double
‘ コンストラクタ
Public Sub New(x As Double, y As Double)
Me.X = x
Me.Y = y
End Sub
‘ 距離計算（インスタンス生成を伴わないため、GC負荷ゼロ）
Public Function DistanceTo(ByRef other As Point2D) As Double
Dim dx As Double = Me.X – other.X
Dim dy As Double = Me.Y – other.Y
Return Math.Sqrt(dx dx + dy dy)
End Function
‘ 演算子のオーバーロード（値型ならではの直感的な記述）
Public Shared Operator +(ByVal p1 As Point2D, ByVal p2 As Point2D) As Point2D
Return New Point2D(p1.X + p2.X, p1.Y + p2.Y)
End Operator
End Structure
‘ 座標群を管理する高パフォーマンス・プロセッサ
Public NotInheritable Class CoordinateProcessor
‘ オブジェクトの乱立を防ぐため、Array（配列）で一括管理する
‘ List(Of T)は要素追加時に内部配列の再割り当て（リサイズ）が発生し、ヒープを汚染するため極力避ける
Private ReadOnly _points() As Point2D
Public Sub New(points() As Point2D)
If points Is Nothing Then Throw New ArgumentNullException(NameOf(points))
_points = points
End Sub
”’
”’
Public Function FilterWithinRadius(ByRef center As Point2D, radius As Double) As Point2D()
‘ 事前にサイズがわかっている場合はリストを使わず、処理後に必要な分だけ配列化する
‘ ここでは簡略化のため、LINQではなくプリミティブなForループで極限の速度を担保する
Dim threshold As Double = radius radius
Dim tempResults(_points.Length – 1) As Point2D
Dim matchCount As Integer = 0
For i As Integer = 0 To _points.Length – 1
‘ 参照渡し（ByRef）を活用し、構造体のコピーコストを完全に排除
Dim p As Point2D = _points(i)
Dim dx As Double = p.X – center.X
Dim dy As Double = p.Y – center.Y
‘ 平方根の計算コスト（Math.Sqrt）を避けるため、二乗値で比較するプログラミングの鉄則
If (dx dx + dy dy) <= threshold Then
tempResults(matchCount) = p
matchCount += 1
End If
Next
' 結果を切り詰める
Dim finalResults(matchCount - 1) As Point2D
Array.Copy(tempResults, finalResults, matchCount)
Return finalResults
End Function
End Class
End Namespace
このコードのアーキテクチャ上の美しさ
1. `
2. `ByRef` による構造体渡し: 構造体は値型ゆえに引数に渡すとコピーが発生するが、`ByRef`にすることでポインタ（参照）のみを渡し、巨大な配列の走査時でもCPUサイクルを無駄に消費させない。
3. 平方根（`Math.Sqrt`）の排除: 距離比較において `Sqrt` は重い演算であるため、「二乗した値同士で比較する」という数学的アプローチで処理速度を数倍に跳ね上げている。
—
4. ファイル・データベース連携における「落とし穴」
構造体をDBやCSVファイル、あるいはネットワーク通信（API）と連携させる際、以下の罠にハマるジュニアプログラマーが後を絶たない。
- ORM（Entity Framework等）やDapperとの相性:
データベースのテーブル設計をそのまま構造体マッピングしようとしてはならない。ほとんどのORMはインスタンスの参照トラッキングや遅延ロードのためにクラス（Class）を前提としている。無理に構造体をDBエンティティに使うと、「ボックス化（Boxing）」の嵐となり、パフォーマンスが逆に悪化する。
- 指針: データベース層やUIバインディング層（`DataGridView`など）にはClass（DTO）を使い、高頻度なインメモリ計算エンジンの中核でのみStructure（値型）に変換（シリアライズ/マッピング）する二段構えの設計にせよ。
—
5. まとめ：プロフェッショナルとしての設計判断
VB.NETにおける `Structure` と `Class` の選択は、単なるコーディング規約のチェック項目ではない。
- データが小さく、計算のパーツであるなら `Structure` でメモリを直結し、GCをハメ殺せ。
- 状態を持ち、ライフサイクルが長く、複雑な関連性を持つなら `Class` で安全に管理せよ。
「なぜその型を選んだのか？」をコードレビューで論理的に説明できないうちは、まだ真にVB.NETを掌握したとは言えない。
メモリの動きを支配し、ユーザーを待たせない極限の業務アプリケーションを構築してほしい。健闘を祈る。
