メモリの深淵を制御せよ：VB.NETにおける構造体とアンマネージドメモリの極致
VB.NETは、しばしば「レガシーな言語」という誤ったレッテルを貼られる。だが、真のエンジニアは知っている。CLR（Common Language Runtime）の背後に広がるアンマネージドな世界を直接制御できるこの言語が、いかに強力な武器であるかを。
C/C++製のDLL、あるいは低レイヤーのハードウェア・ドライバと対峙する際、我々が扱うのは「オブジェクト」という高尚な抽象ではない。メモリ上の「バイト列」そのものである。本稿では、`StructLayout`と`Marshal`を駆使し、CLRの管理下にあるメモリとアンマネージドメモリの間で、確実かつ高速な相互運用を実現する極意を伝授する。
—
1. 構造体のメモリレイアウトを「固定」する義務
マネージドな環境では、ガベージコレクター（GC）がヒープ上のオブジェクトを自由に移動させる。しかし、外部APIはメモリ上の固定されたアドレスを期待している。ここで `StructLayoutAttribute` が必須となる。
`LayoutKind.Sequential` を指定するだけでは不十分だ。フィールドのパディング（隙間）を制御しなければ、C++側の構造体とズレが生じ、システムは無音のうちにクラッシュする。
Imports System.Runtime.InteropServices
‘ メモリレイアウトをC++の構造体と完全に同期させる
Public Structure NativeData
‘ 4バイト整数
Public Id As Integer
‘ 文字列の扱いには要注意。固定長バッファとして扱うのが鉄則
Public Name As String
‘ 浮動小数点
Public Value As Double
End Structure
極限の知見: `Pack`（アライメント境界）の指定を怠るな。C++のデフォルトである8バイトアライメントと、VB側のデフォルトが一致していないケースは極めて多い。`#pragma pack`の挙動を読み解き、必ず一致させよ。
—
2. Marshalクラス：マネージドとアンマネージドの架け橋
API呼び出しで構造体を渡す際、単に `ByVal` で渡せば良いという単純な話ではない。大量のデータをやり取りする場合、毎回スタックからヒープへコピーを生成していては、パフォーマンスは底を突く。
メモリの「直接確保」と「解放」の責務
アンマネージドメモリを操作するということは、GCの保護を放棄し、自力でメモリ管理を行うということだ。`Marshal.AllocHGlobal` で確保した領域は、必ず `Marshal.FreeHGlobal` で返却せよ。これを忘れることは、シニアエンジニアとして最大の汚点である。
Public Sub ProcessNativeData()
Dim data As New NativeData With {.Id = 1, .Name = “SystemCore”, .Value = 3.14}
‘ 構造体をアンマネージドヒープへコピー
Dim ptr As IntPtr = Marshal.AllocHGlobal(Marshal.SizeOf(data))
Try
‘ マネージドからアンマネージドへ転送
Marshal.StructureToPtr(data, ptr, False)
‘ ここでDLLへポインタを渡す（例：NativeCall(ptr)）
‘ …
Finally
‘ 構造体内部でアロケートされたメモリがある場合は先に解放が必要
Marshal.DestroyStructure(ptr, GetType(NativeData))
‘ メモリを解放（メモリリークの温床を断つ）
Marshal.FreeHGlobal(ptr)
End Try
End Sub
—
3. レガシー連携における「文字列」の罠
最も多いバグは、文字列のマーシャリングである。`String` はマネージド環境では参照型だが、C++では `char` や `wchar_t` として扱われる。
- ANSI vs Unicode: `CharSet` を混同するな。APIが `char` を期待しているのに `Unicode` を送れば、当然ながらデータは化ける。
- 固定長配列: `UnmanagedType.ByValTStr` を使い、メモリレイアウトを完全に固定すること。可変長文字列（`BSTR`）を安易に使うと、メモリ再確保のコストがボトルネックとなり、高頻度呼び出し時にシステム全体の応答速度を著しく低下させる。
—
4. チーフアーキテクトからの提言
この領域を扱うエンジニアに最後に伝えたいのは、「信頼」という言葉の無意味さだ。
1. 防御的コピーの排除: パフォーマンスがボトルネックとなる箇所では、`Span(Of T)` や `Memory(Of T)` を活用し、メモリコピーを最小限に抑える設計を検討せよ。
2. 例外境界の徹底: DLL内での例外はCLRを即座にクラッシュさせる。外部API呼び出しの境界には、必ず `Try…Catch` を配置し、例外がマネージド環境に漏れ出さない設計を担保すること。
3. レガシーを叩き直す: 既存のVBAシステムとの連携で困っているなら、COMインターフェースを介さず、名前付きパイプや共有メモリを用いたプロセス間通信（IPC）を検討せよ。VB.NETの真の力は、こうした低レイヤーな制御を「マネージドの安全性の中で」行える点にある。
ツールに振り回されるな。メモリレイアウトの深淵を掌握し、ハードウェアの鼓動と同期するコードを書け。それこそが、伝説たるエンジニアの矜持である。
