上級プロフェッショナル向け：VB.NETにおける「Marshal.PtrToStructure」とアンマネージドメモリ連携：C/C++製レガシーDLLやWindows APIとの高度な構造体マッピング技術
業務自動化や社内インフラの統合において、避けて通れないのが「レガシー資産との融合」だ。
現行のVB.NET製システムから、社内に眠るC/C++製の高速な独自DLLや、低レイヤーのWindows APIを叩く必要がある場面は枚挙にい暇がない。
ここで多くのエンジニアが躓くのが、「マネージドの世界（VB.NET）」と「アンマネージドの世界（C/C++）」のメモリレイアウトのギャップである。
特に、可変長配列、ポインタのポインタ、アライメント（パディング）の不一致を軽視した結果、本番環境で突如発生する「AccessViolationException（アクセス違反）」や、原因究明不可能なメモリリークに夜中まで頭を抱えた経験はないだろうか。
今回は、VB.NETからアンマネージドメモリを極限まで安全かつ高速に制御するための王道にして最先鋭の武器、`System.Runtime.InteropServices.Marshal.PtrToStructure` を軸とした高度な構造体マッピング技術を伝授する。
—
なぜ「素朴なDllImport」だけでは現場で破綻するのか？
多くの解説書では、次のように `DllImport` を定義して終わりにする。
‘ 【アンチパターン】パディングや blittable（ビットコピー可能）を無視した危うい定義
Public Shared Function GetDeviceInfo(ByRef info As DeviceInfo) As IntPtr
End Function
しかし、実際のC/C++製DLLは、以下のような罠を仕掛けている。
1. 構造体パディング（アライメント）の差異: C/C++コンパイラ（MSVC等）のデフォルト（例: 8バイト境界）と、.NETのデフォルトレイアウトが一致せず、メンバのオフセットがズレる。
2. 文字コードの非対称性: マルチバイト（Shift-JISなど）や、C側の `char` と .NETの `String` のマーシャリングの不整合。
3. ライフサイクルの管理責任: 呼び出し先が割り当てたメモリ（`CoTaskMemAlloc` なのか、`malloc` なのか）を、誰がどのタイミングで解放すべきかという所有権（Ownership）の曖昧さ。
これらを完全制圧するのが、明示的なメモリ位置（`IntPtr`）の受領と、`Marshal.PtrToStructure` による安全なデシリアライゼーション（逆直列化）である。
—
プロダクション品質：堅牢な構造体マッピングの実装パターン
ここでは、C/C++側から「デバイス情報（文字列、数値、および内部アンマネージドバッファへのポインタ）」を返すレガシーDLLを想定し、VB.NET側で完全に安全に受け取るコードを示す。
1. 構造体の厳密なレイアウト定義 (`StructLayout`)
メモリレイアウトの主導権をVB.NET側に完全に握らせるため、`StructLayout` と `FieldOffset`（または `Sequential`）を明示する。ここではアライメントをC/C++側に合わせた `Pack` を指定するのが極意だ。
Imports System.Runtime.InteropServices
Imports System.Text
Namespace LegacyIntegration
‘ 1. C/C++の #pragma pack(1) もしくはデフォルトアライメントに合わせる
Public Structure NativeDeviceInfo
Public DeviceName As String
Public FirmwareVersion As UInteger
‘ アンマネージド側の内部バッファを指すポインタ
Public ExtendedDataPtr As IntPtr
End Structure
‘ 2. マネージド側で扱いやすく整形したクリーンな構造体
Public Class DeviceInfoModel
Public Property DeviceName As String
Public Property FirmwareVersion As UInteger
Public Property ExtendedData() As Byte()
End Class
End Namespace
2. `Marshal.PtrToStructure` を駆使した安全なラッパー実装
ポインタの有効性を検証し、メモリコピー、さらにはアンマネージド領域の確実な解放までをカプセル化したプロフェッショナルなクラスを構築する。
Imports System.Runtime.InteropServices
Imports System.Text
Namespace LegacyIntegration
Public NotInheritable Class LegacyDllWrapper
Implements IDisposable
‘ 外部DLLのインポート（Cdecl規約、文字コードAnsi）
Private Shared Function GetNativeDevicePtr(ByRef bufferSize As Integer) As IntPtr
End Function
Private Shared Function FreeNativeDevicePtr(ByVal nativePtr As IntPtr) As Boolean
End Function
Private _disposed As Boolean = VersionCheckAndDispose() ‘ ダミー初期化（Disposeパターン用）
”’
”’
Public Function FetchDeviceInfo() As DeviceInfoModel
Dim bufferSize As Integer = 0
Dim nativePtr As IntPtr = IntPtr.Zero
Try
‘ 1. DLLからアンマネージドメモリ上のポインタを取得
nativePtr = GetNativeDevicePtr(bufferSize)
If nativePtr = IntPtr.Zero Then
Throw New InvalidOperationException(“レガシーDLLからのポインタ取得に失敗しました。”)
End If
‘ 2. PtrToStructure を使ってアンマネージドメモリをマネージド構造体に一括マッピング
‘ ※ 第2引数に既存の構造体インスタンスを指定するオーバーロードはGC負荷軽減に効果的
Dim nativeStruct As NativeDeviceInfo =
DirectCast(Marshal.PtrToStructure(nativePtr, GetType(NativeDeviceInfo)), NativeDeviceInfo)
‘ 3. 構造体内のポインタ（ExtendedDataPtr）が指す先から、追加データを安全に読み取る
Dim extendedDataBytes(127) As Byte ‘ 例: 128バイトの拡張データと仮定
If nativeStruct.ExtendedDataPtr <> IntPtr.Zero Then
Marshal.Copy(nativeStruct.ExtendedDataPtr, extendedDataBytes, 0, extendedDataBytes.Length)
End If
‘ 4. アプリケーション層のモデルへ変換
Return New DeviceInfoModelWithExtension() With {
.DeviceName = nativeStruct.DeviceName.Trim(Chr(0)),
.FirmwareVersion = nativeStruct.FirmwareVersion,
.ExtendedData = extendedDataBytes
}
Catch ex As Exception
‘ ログ出力基盤へスルー、またはラップして上位へ通知
Throw New ApplicationException($”アンマネージド連携エラー: {ex.Message}”, ex)
Finally
‘ 【最重要】アンマネージドメモリのリークを防ぐため、DLL側が用意した解放関数を必ず呼ぶ
If nativePtr <> IntPtr.Zero Then
Dim released As Boolean = FreeNativeDevicePtr(nativePtr)
If Not released > 0 Then
‘ 解放失敗時のフォールバック（Marshal.FreeHGlobalはmalloc由来なら使うべきではない）
System.Diagnostics.Trace.WriteLine(“警告: ネイティブメモリの解放に失敗しました。”)
End If
End If
End Try
End Function
Region “IDisposable Support”
Private disposedValue As Boolean
Protected Sub Dispose(disposing As Boolean)
If Not disposedValue Then
If disposing Then
‘ マネージド資源の解放
End If
‘ アンマネージド資源の解放（必要に応じて）
disposedValue = True
End If
End Sub
Public Sub Dispose() Implements IDisposable.Dispose
Dispose(True)
GC.SuppressFinalize(Me)
End Sub
End Region
End Class
End Namespace
—
アーキテクトが教える：実務で絶対に外せない3つの鉄則
① 「Blittable（ビットコピー可能）」な型設計を意識せよ
構造体のメンバに `String` や `Boolean`（4バイトのWin32 BOOL型など）を雑に混ぜると、マーシャラーが裏側でメモリの割り当てとコピー（Alloc & Copy）を頻発させ、パフォーマンスが劇的に低下する。
高速性が求められるループ内等では、基本データ型（`Integer`, `UInteger`, `Byte`の配列など）で固めた「Blittable構造体」を定義し、ポインタから一撃で引き抜く設計がプロフェッショナルだ。
② 文字コード（Ansi / Unicode / Utf8）の罠を見極めよ
レガシーC/C++ DLLの大部分は `char`（マルチバイト/Shift-JIS または UTF-8）を返してくる。
VB.NETのデフォルト文字列はUTF-16であるため、`CharSet:=CharSet.Ansi` や `UnmanagedType.LPStr` を適切に指定しないと、文字化けやバッファオーバーランを引き起こす。必要に応じて `Marshal.PtrToStringAnsi(ptr)` を手動で呼び出すアプローチも選択肢に入れよ。
③ メモリの「所有権（Ownership）」を死守せよ
「誰がメモリを確保し、誰が解放するのか」はアンマネージド連携の永遠のテーマだ。
- DLL側が確保 (`malloc` 等) ➔ DLL側が用意した解放関数（`free` や専用の `FreeXXX`）を必ず呼ぶ。`Marshal.FreeHGlobal` で解放しようものなら、ヒープ壊れ（Heap Corruption）を起こして即座にプロセスが異常終了する。
- VB側が確保 (`Marshal.AllocHGlobal` 等) ➔ `Marshal.FreeHGlobal` で確実に解放する。
—
結び
VB.NETは「レガシーな言語」などではない。.NETの深淵なメモリ管理機構とAPIを正しく理解したエンジニアの手にかかれば、C/C++に匹敵するパフォーマンスと堅牢性を兼ね備えた、極めて強力な業務自動化・インフラ統合の武器となる。
`Marshal.PtrToStructure` を手なづけ、アンマネージドの荒波を完全にコントロールした時、あなたの書くコードはワンランク上の「プロフェッショナル・アーキテクチャ」へと昇華するだろう。
