VB.NETによる「MemoryMappedFile」：プロセス間通信（IPC）の極限最適化
業務自動化の現場において、プロセス間でのデータ受け渡しに「一時ファイル」や「TCPソケット」を使っているのなら、今すぐその設計を見直すべきだ。ディスクI/Oは遅延の温床であり、ソケット通信はオーバーヘッドと複雑なハンドシェイクを強いる。
我々プロフェッショナルが選ぶのは、MemoryMappedFile（メモリマップトファイル）だ。OSのメモリ管理機構を直接叩き、複数のプロセスが物理メモリ上の同一領域を共有する。このアーキテクチャこそが、現代のWindows開発における最高速の通信手段である。
—
なぜMemoryMappedFileなのか？
一般的なIPC（名前付きパイプやSocket）は、OSのカーネル空間とユーザー空間の間でデータのコピーが発生する。一方、MemoryMappedFileは、ファイルシステム上のデータ（あるいは純粋なメモリ空間）をプロセスの仮想アドレス空間に直接マッピングする。
このアプローチの最大の利点は「ゼロコピー」に近い性能だ。
大容量の構造体データや、数百万行のログデータを一瞬で共有できる。業務自動化ツールが「重い」と感じる原因の大半は、無駄なI/Oにある。ここを削ぎ落とせ。
—
堅牢な設計のための3つの鉄則
MemoryMappedFileを扱う際、初心者は必ず「同期」で躓く。以下の設計指針を脳に刻み込め。
1. 排他制御（Mutex）は必須:
複数のプロセスが同時に同じメモリ領域に書き込めば、データは一瞬で破壊される。`System.Threading.Mutex`を名前付きで作成し、プロセス間で同期せよ。
2. 固定長データ構造の利用:
可変長データはメモリレイアウトを複雑にする。構造体（Structure）を`LayoutKind.Sequential`で定義し、固定長で扱うのが保守性の観点からも最強だ。
3. 例外処理とクリーンアップ:
プロセスがクラッシュしてもメモリが残留しないよう、`IDisposable`を徹底し、finally句での解放を忘れてはならない。
—
【実用コード】超高速メモリ共有の実装例
以下のコードは、あるプロセスから別のプロセスへ、構造化されたデータをノーウェイトで受け渡すための雛形だ。
Imports System.IO.MemoryMappedFiles
Imports System.Runtime.InteropServices
Imports System.Threading
‘ 共有するデータ構造は必ず固定長にする
Public Structure SharedData
Public ID As Integer
End Structure
Public Class MemorySharedBuffer
Private Const MapName As String = “Global\MySharedMemory”
Private Const MutexName As String = “Global\MySharedMutex”
Private Const Capacity As Long = 1024 ‘ 共有メモリサイズ
Public Sub WriteData(data As SharedData)
‘ プロセス間での排他制御
Using mtx As New Mutex(False, MutexName)
mtx.WaitOne()
Try
Using mmf = MemoryMappedFile.CreateOrOpen(MapName, Capacity)
Using accessor = mmf.CreateViewAccessor()
accessor.Write(0, data)
End Using
End Using
Finally
mtx.ReleaseMutex()
End Try
End Using
End Sub
Public Function ReadData() As SharedData
Using mtx As New Mutex(False, MutexName)
mtx.WaitOne()
Try
Using mmf = MemoryMappedFile.OpenExisting(MapName)
Using accessor = mmf.CreateViewAccessor()
Dim data As SharedData
accessor.Read(0, data)
Return data
End Using
End Using
Finally
mtx.ReleaseMutex()
End Try
End Using
End Function
End Class
—
運用時の注意点：データベース連携との境界線
この技術は強力だが、万能ではない。以下の境界線を理解しておくことが「アーキテクト」の務めだ。
- 永続化はDBに任せろ: MemoryMappedFileは「揮発性」の通信手段だ。プロセスが全て終了すればメモリは解放される。長期的なデータ保存や、トランザクションの整合性が求められる場合は、必ずSQL ServerやSQLiteを経由させよ。
- 権限の壁: `Global\`プレフィックスを使用する場合、管理者権限が必要になることがある。アプリケーションのManifestで実行権限を適切に設定せよ。
- デバッグの極意: 共有メモリの中身を直接覗きたい場合は、`WinDbg`等のメモリダンプツールを利用する癖をつけろ。IDEのデバッガで追いかけるのは限界がある。
結びに：エンジニアとしての矜持
「とりあえずファイルに書き込んで受け渡せばいい」という設計は、昨今のビジネススピードには耐えられない。MemoryMappedFileを使いこなすということは、OSのメモリマップを理解し、低レイヤーの挙動まで制御下に置くということだ。
このコードをただのコピペで終わらせるな。なぜこの構造体なのか、なぜMutexが必要なのか。その「理由」を自分なりに噛み砕いた時、君の自動化ツールは一段上のパフォーマンスへと昇華されるはずだ。
次は、君自身がこのアーキテクチャをどう活用するかを見せてもらう。健闘を祈る。
