構造体(Structure)とクラス(Class)の境界線：VB.NETにおけるメモリとGCの調律術
長年、VB6の `Type` 構造体から .NET のメモリ管理モデルまでを渡り歩いてきた者にとって、「なぜここで構造体を使うのか？」という問いへの答えは、単なるプログラミングの好みではない。それは、ガベージコレクション（GC）の暴走を抑え込み、システム全体のスループットを物理的な限界まで引き上げるための「戦術的選択」である。
今回は、業務アプリケーションの根幹を支えるデータ設計において、構造体とクラスをどう使い分けるべきか、その極限の知見を共有する。
—
1. 構造体とクラスの「メモリ的本質」を見極める
VB.NETにおいて、`Structure`（値型）と `Class`（参照型）を混同することは、パフォーマンス上の致命傷となる。
- Structure (値型): スタック領域に配置される。スコープを抜ければ即座に消滅する。ヒープへのメモリ割り当てを伴わないため、GCの負荷を一切かけない。
- Class (参照型): ヒープ領域に配置される。オブジェクトの生存期間はGCに委ねられ、インスタンス生成のたびにメモリの断片化と回収コストが発生する。
構造体を選択すべき絶対的な基準
「100万件のレコードを処理する」ようなループ内で、クラスをインスタンス化していないだろうか？ それこそが、システムのCPU使用率を無駄に押し上げ、GCを頻繁に起動させる原因である。
構造体を使うべき条件：
1. データサイズが小さい（概ね16バイト以下が理想）。
2. インスタンスの寿命が短く、頻繁に生成・破棄される。
3. 継承の必要がない。
4. 他のオブジェクトへの参照を持たない（参照を含めると、構造体自体がヒープ上のオブジェクトを保持することになり、管理コストが逆に増大する）。
—
2. 業務アプリにおける実践的設計：メモリ最適化コード
大量データを扱うシステム連携や、Windows APIを叩く際、スタック領域を意識した設計が重要だ。以下のコードを見てほしい。
‘ 【改善前：クラスで定義】
‘ 大量に生成するとGCが頻発し、メモリ断片化の原因となる
Public Class TransactionData
Public Id As Integer
Public Amount As Decimal
End Class
‘ 【改善後：構造体で定義】
‘ スタックに確保され、GCの負荷をゼロにする
Public Structure TransactionRecord
Public ReadOnly Id As Integer
Public ReadOnly Amount As Decimal
Public Sub New(id As Integer, amount As Decimal)
Me.Id = id
Me.Amount = amount
End Sub
End Structure
Windows API呼び出し時の注意点
Windows APIと連携する場合、`Structure` はメモリ配置が保証されるため、アンマネージド領域との橋渡し（マーシャリング）において不可欠だ。`StructLayout` 属性を使い、メモリ配置を制御することで、C++で書かれたDLLとの高速なデータ交換を実現できる。
Public Structure Win32Point
Public X As Int32
Public Y As Int32
End Structure
—
3. シニアエンジニアが守るべき「GC抑制の鉄則」
1. 「値型のコピー」という罠
構造体は代入時に「値のコピー」が発生する。巨大な構造体を引数で渡すと、スタックを圧迫し、コピーコストが嵩む。構造体はあくまで「小さな塊」として扱い、メソッドに渡す際は `ByRef` を検討することも忘れてはならない。
2. 参照型を構造体内に含めない
構造体の中に `List(Of T)` や `String` などの参照型を含めると、構造体自体はスタックにあっても、その内部データはヒープに残る。結果、構造体の寿命管理とヒープのGC管理が複雑化する。「構造体はプリミティブ型の集合体」として定義せよ。
3. IDisposableの戦略的活用
クラスを避けることができない場合は、必ず `IDisposable` を実装し、`Using` ステートメントで明示的に解放せよ。特に大規模な外部ファイル操作やDBコネクションを保持するクラスでは、GCの「先送り」を許してはならない。
—
結論：システムアーキテクトとしての矜持
優れた設計とは、書いたコードがメモリ上でどう動くかを頭の中で可視化できることである。
- 「何でもクラスにする」のは、楽をしたいだけの怠慢である。
- 「何でも構造体にする」のは、設計を放棄した暴走である。
大量データを扱う業務システムにおいて、我々が目指すべきは「ガベージコレクタが介入する隙を与えないほど、メモリ消費を平滑化すること」だ。
VB.NETは古臭い言語ではない。適切にメモリを制御し、スタックとヒープを使い分ける能力を持つエンジニアにとって、依然として強固な武器となる。あなたの書くコードが、次のGC停止時間を1ミリ秒でも短くすることを願っている。
