【テクニカル・上級編】実務中級者向け：VB.NETにおけるByValとByRefの決定的な違い：参照渡しと値渡しのメモリ挙動を理解して意図しないバグを防ぐ – Visual Basic (VB / VB.NET)解析バイブル

VB.NETにおけるByValとByRefの決定的な違い：メモリ挙動から紐解く堅牢なメソッド設計

長年、VBA（Visual Basic for Applications）の巨大利便性とカオスに翻弄され、そしてVB.NETへの移行期を生き抜いてきた開発者であれば、「なぜか予期せぬタイミングで変数の値が書き換わっている」という悪夢のようなバグに一度は直面したことがあるはずだ。

VB.NETのデフォルトである `ByVal`（値渡し）と、明示的に指定する `ByRef`（参照渡し）。この2つの挙動を「なんとなく」でコードを書いているうちは、シニアエンジニアとは言えない。

今回は、マネージドヒープとスタックのメモリ挙動レベルまで踏み込み、VB.NETのメソッド設計における「参照と値の真実」を徹底的に解き明かす。

—

1. パラメータ渡しの基礎：スタックとヒープの物理的挙動

まず、VB.NETが裏側でどのようにメモリを管理しているかを定義する。ここを理解していないと、パフォーマンスチューニングもバグ解析も机上の空論に終わる。

• 値型 (Value Types): `Integer`, `Boolean`, `DateTime`, 構造体 (`Structure`) など。データそのものがスタック領域に格納される。
• 参照型 (Reference Types): `String`, `Class` のインスタンス、配列など。実データは「マネージドヒープ」に存在し、スタックにはそのヒープ上のメモリアドレス（ポインタ）が格納される。

デフォルトである ByVal の正体

VB.NETでは、何も指定しない場合、すべての引数は `ByVal`（値渡し） として扱われる（C#のデフォルトとはここが異なる。C#は参照型であっても参照「の値」を値渡しするが、VB.NETの歴史的背景を含めた仕様の妙と言える）。

`ByVal` で渡された場合、何が起きるか？

• 値型の場合: スタック上の数値そのものが複製され、メソッド側に渡される。呼び出し元の変数は微動だにしない。
• 参照型の場合: ヒープ上の実体への「アドレスのコピー」がメソッド側に渡される。

> ⚠️ ここが最大の罠：
> 「参照型を `ByVal` で渡したのだから、呼び出し元の変数は安全だ」という誤解が数々のバグを生む。アドレスのコピーであっても、同じヒープ領域（実体）を指し示しているため、メソッド内でプロパティを書き換えれば、呼び出し元のオブジェクトも当然書き換わる。

—

2. 徹底比較：コードで見るメモリと挙動の差異

百聞は一見にしかず。以下のコードを見てほしい。構造体（値型）とクラス（参照型）において、`ByVal` と `ByRef` がメモリ上でどのような振る舞いをするのかを証明する実用的なコードだ。

Module MemoryBehaviorDemo

‘ 1. 値型の構造体
Public Structure PointStruct
Public X As Integer
Public Y As Integer
End Structure

‘ 2. 参照型のクラス
Public Class PointClass
Public X As Integer
Public Y As Integer
End Class

Sub Main()
Console.WriteLine(“=== 1. 構造体 (Value Type) の実験 ===”)
Dim ptVal As New PointStruct With {.X = 10, {.Y = 20}}

ModifyStructByVal(ptVal)
Console.WriteLine($”ByVal後: X={ptVal.X}, Y={ptVal.Y}”) ‘ 出力: 10, 20 (書き換わらない)

ModifyStructByRef(ptVal)
Console.WriteLine($”ByRef後: X={ptVal.X}, Y={ptVal.Y}”) ‘ 出力: 99, 99 (書き換わる)

Console.WriteLine(vbCrLf & “=== 2. クラス (Reference Type) の実験 ===”)
Dim ptRef As New PointClass With {.X = 10, .Y = 20}

‘ ByValであっても参照型ならプロパティは書き換わる！
ModifyClassPropertiesByVal(ptRef)
Console.WriteLine($”ByVal(プロパティ変更)後: X={ptRef.X}, Y={ptRef.Y}”) ‘ 出力: 50, 50

‘ ByRefの場合、オブジェクト自体のすげ替え（インスタンスの再生成）が可能になる
ModifyClassReferenceByRef(ptRef)
Console.WriteLine($”ByRef(インスタンスすげ替え)後: X={ptRef.X}, Y={ptRef.Y}”) ‘ 出力: 999, 999 (※メソッド内でNewされた新しいインスタンスを指す)

Console.ReadLine()
End Sub

‘ — メソッド定義群 —

Private Sub ModifyStructByVal(ByVal p As PointStruct)
p.X = 99
p.Y = 99 ‘ 複製されたスタック上の領域が書き換わるだけ
End Sub

Private Sub ModifyStructByRef(ByRef p As PointStruct)
p.X = 99
p.Y = 99 ‘ 呼び出し元のスタック上の実体が直接書き換わる
End Sub

Private Sub ModifyClassPropertiesByVal(ByVal p As PointClass)
‘ アドレスのコピーだが、同じヒープインスタンスを指しているため実体が書き換わる
p.X = 50
p.Y = 50
End Sub

Private Sub ModifyClassReferenceByRef(ByRef p As PointClass)
‘ ByRefにより、ポインタ変数そのものの参照を書き換える（新しいインスタンスを割り当てる）
p = New PointClass()
p.X = 999
p.Y = 999
End Sub

End Module

このコードの挙動を完全に脳内でトレースできるか？これができれば、VB.NETのメモリモデルをマスターしていると言っていい。

—

3. レガシー・Windows API連携におけるByRefの絶対的役割

現代の.NET開発ではあまり意識しないが、VB.NETが真価を発揮する現場、すなわちレガシーシステム保守、COMコンポーネント連携、そしてP/Invoke（Windows API呼び出し）においては、`ByRef` は命綱となる。

C/C++のポインタや `pointer-to-a-pointer` (`LPVOID` や `HANDLE`) を受け取るAPIを叩く場合、VB.NET側で `ByRef` を正しく指定しなければ、メモリ違反（Access Violation）による致命的なクラッシュを引き起こす。

実践：Windows API (Kernel32) 呼び出しにおけるByRefの活用

ハンドルや構造体の状態をAPI側で書き換えてもらう必要がある場合、`ByRef` は必須である。

Imports System.Runtime.InteropServices

Public Class NativeApiInterop

‘ Windows API の宣言例 (System Timeの取得)

Public Shared Sub GetSystemTime(ByRef lpSystemTime As SYSTEMTIME)
End Sub

Public Structure SYSTEMTIME
Public wYear As UShort
Public wMonth As UShort
Public wDayOfWeek As UShort
Public wDay As UShort
Public wHour As UShort
Public wMinute As UShort
Public wSecond As UShort
Public wMilliseconds As UShort
End Structure

Public Sub CheckSystemTime()
Dim sysTime As New SYSTEMTIME()

‘ API内でメモリを書き換えてもらうため、必ず ByRef で渡す必要がある
GetSystemTime(sysTime)

Console.WriteLine($”Current UTC Year: {sysTime.wYear}”)
End Sub

End Class

もしここで `ByVal` を指定してしまったらどうなるか？ APIには `sysTime` の「コピー」が渡され、API側がどれだけ構造体を書き換えても、呼び出し元の `sysTime` は空っぽ（初期値のままである 0）のまま放置される。最悪の場合、アンマネージド領域とのメモリ不整合を起こす。

—

4. 堅牢なメソッド設計のためのアーキテクチャ指針

シニアエンジニアとして、チームメンバーが書くコードの品質を担保し、「意図しないバグ」を根絶するためには、以下の設計原則をコードレビューで徹底させるべきだ。

① 原則として `ByVal` を使用せよ（イミュータブルの思想）

VB.NETのデフォルトが `ByVal` であることは理にかなっている。メソッド内で意図せず引数の値が変わってしまう副作用（Side Effect）を防ぐため、特別な理由がない限り `ByRef` は使ってはならない。

② 巨大な構造体（Value Type）を渡す場合のパフォーマンス考慮

もし数百バイトを超えるような巨大な `Structure` を頻繁にメソッド間で受け渡す場合、`ByVal` だとスタック領域への「値のコピー」が発生し、パフォーマンスが劣化する。

• 対策: 構造体をクラス（`Class`）に変更して参照渡しにするか、どうしても構造体にこだわる必要があるかつ極限のパフォーマンスが求められる場合にのみ、意図的に `ByRef` を選択する（※ただし、読み取り専用であることが明確な場合は `ReadOnly` 修飾子や `In` キーワード（C#由来だが概念として重要）の活用を検討する）。

③ アウトパラメータの代替としての `ByRef`

メソッドから複数の値を戻したい場合（TryParseパターンなど）、VB.NETでは `ByRef` を使用する。

Public Function TryParseData(rawInput As String, ByRef resultValue As Integer) As Boolean
If Integer.TryParse(rawInput, resultValue) Then
Return True
End If
resultValue = 0
Return False
End Function

このパターンはVB.NETでは伝統的かつ有効だが、C# 7.0以降のタプルやout変数のインライン宣言に比べると冗長になりがちである。モダンな設計を目指すなら、戻り値としてカスタム構造体やタプルを返す設計へのリファクタリングも視野に入れよう。

—

5. チーフアーキテクトからの提言

Visual Basicという言語は、その歴史の長さゆえに「誰でも動くコードが書ける」という美点を持つ一方で、メモリの概念をブラックボックス化したまま高度なシステム構築に挑むと、突如として牙をむく。

`ByVal` と `ByRef` の違いは、単なる文法の優劣ではない。
「今、このデータはメモリのどこに存在し、誰がそのライフサイクルを所有しているのか」というエンジニアリングの根幹そのものだ。

レガシーシステムの保守であれ、新規のエンタープライズ開発であれ、メモリの挙動を支配する者だけが、バグのない堅牢なアーキテクチャを構築できる。今日のビルドから、あなたのメソッドシグネチャに対する意識が変わることを期待する。