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

VB.NETにおけるByValとByRefの決定的な違い：メモリ挙動から紐解く予期せぬバグの全貌

レガシーなVB6の時代から、現代の.NET 8に至るまで、我々Windows業務アプリケーション開発者が直面し続ける永遠の課題がある。それがパラメータの渡し方、すなわち `ByVal`（値渡し）と `ByRef`（参照渡し） の選択だ。

特にVB.NETにおいて、この仕様を曖昧に理解したままコードを書くことは、時限爆弾を抱えてシステムを稼働させるに等しい。
今回は、マネージドヒープとスタックのメモリ挙動、そしてWindows API（P/Invoke）連携や巨大なデータ構造を扱う現場において、なぜこの基本が死活問題になるのかを、チーフアーキテクトの視点から徹底的に解き明かす。

—

1. 脳裏に焼き付けるべきメモリの物理挙動

まずは、CPUとメモリのレイヤーで何が起きているのかを正確に把握しよう。ここを理解していれば、デバッガーに頼るまでもなくバグの原因が透けて見えるようになる。

• `ByVal`（値渡し）:

変数が持つ「値そのもの」、あるいはオブジェクト変数の場合は「マネージドヒープ上のメモリアドレス（ポインタの値）」のコピーをスタック領域に積んで渡す。呼び出し元の変数は、渡した先で何をされようとも絶対に保護される。

• `ByRef`（参照渡し）:

変数そのものの「メモリ上のアドレス（ポインタへのポインタ）」を渡す。呼び出し先で引数に値を代入するということは、呼び出し元の変数領域のビット列を直接書き換えると同義である。

VBの「歴史的呪縛」：デフォルトの罠

C#やJavaなどのモダン言語では、原則として値渡し（C#の `ref` や `out` は明示的な指定が必要）が基本である。しかし、VB（VB.NET）の言語仕様はレガシーなVB6の互換性を引き継いでおり、修飾子を省略した場合のデフォルトが `ByRef` になる（※プロジェクト設定や一部コンテキストによるが、基本構文として `ByRef` が暗黙的に適用されやすい、あるいはVB6からの移行組が誤解しやすい）という極めて危険な特性を持っている。

この「暗黙の `ByRef`」が、大規模な業務システムで血を吐くようなデバッグ工数を生み出してきた元凶なのだ。

—

2. 業務アプリで頻発する「予期せぬ値書き換え」の構造

次のコードを見てほしい。一見すると何気ないユーティリティメソッドだが、`ByRef` の怖さが凝縮されている。

Module MemoryHazardSample

Sub Main()
Dim baseTaxRate As Decimal = 0.1D
Console.WriteLine($”[Main初期] 税率: {baseTaxRate}”)

‘ メソッドを呼び出す
CalculateEffectiveRate(baseTaxRate)

‘ ここで意図せず値が書き換わっている！
Console.WriteLine($”[Main事後] 税率: {baseTaxRate}”)
‘ 出力結果: 0.15 に化けている
End Sub

‘ 意図せず ByRef になっている（あるいは古いコードからのコピペ）
Sub CalculateEffectiveRate(ByRef taxRate As Decimal)
‘ 内部でロジックの都合上、一時的に変数の値を書き換えてしまった
taxRate = 0.15D
‘ …後続の処理
End Sub

End Module

なぜこれが問題なのか？

`CalculateEffectiveRate` は「税率を計算する」ための関数であって、「基準の税率そのものを改変する」意図は微塵もないはずだ。しかし、`ByRef` で渡してしまったがために、メソッド内の副作用（Side Effect）が呼び出し元の変数を直接汚染してしまった。

これが数百行に及ぶスパゲッティな業務ロジック、あるいはマルチスレッド環境下で発生したと想像してほしい。原因特定は極めて困難を極める。

—

3. 参照型（Class）と値型（Structure）におけるByValの決定的な違い

ここで多くの開発者が混乱するポイントがある。「オブジェクト（Class）を `ByVal` で渡しているんだから、中身を変えても安全ですよね？」という誤解だ。

メモリの図式を思い出してほしい。クラスのインスタンスはマネージドヒープに存在し、変数にはその「住所（参照）」が入っている。

Public Class Order
Public Property Amount As Decimal
End Class

Module ObjectReferenceSample

Sub Main()
Dim myOrder As New Order()
myOrder.Amount = 1000D

ProcessOrder(myOrder)

‘ Q: myOrder.Amount はいくつになっているか？
Console.WriteLine(myOrder.Amount) ‘ -> 5000D に変わっている！
Sub Main

‘ ByVal で渡しているが…
Sub ProcessOrder(ByVal order As As Order)
‘ アドレスの「コピー」が渡されているが、指し示しているヒープ上の実体は同じ！
order.Amount = 5000D
End Sub

End Module

構造体（Structure）の場合

これが `Structure`（値型）であれば、`ByVal` で渡すと実体そのものがコピーされるため、呼び出し先の変更は呼び出し元に波及しない。
しかし、`Class`（参照型）を `ByVal` で渡した場合、「変数（ポインタ）の値のコピー」が渡るため、インスタンスのプロパティを書き換えると呼び出し元にも影響が及ぶ。

• 値型 (`Structure`): `ByVal` なら完全安全（コピーされる）。`ByRef` なら書き換わる。
• 参照型 (`Class`): `ByVal` でもプロパティの書き換えは伝播する（インスタンスの参照先が同じなため）。ただし、`ByRef` にすると変数自体に別のインスタンスを代入して差し替えることすら可能になる。

—

4. Windows API 呼び出し（P/Invoke）における死活問題

極限のパフォーマンスや、.NET標準ライブラリではカバーできないOSネイティブ機能にアクセスする際、Windows API（`DllImport`）の直接叩きは避けられない。ここで `ByRef` と `ByVal` の選択を誤ると、一発でメモリ破壊を起こし、アプリケーションが強制終了（クラッシュ）する。

特に、C/C++側のポインタや構造体の仕様と、VB.NET側の marshaling（マーシャリング）の挙動を完全に一致させなければならない。

Imports System.Runtime.InteropServices

Module NativeApiSample

‘ Windows API の例：GetSystemTime
‘ C言語側: VOID GetSystemTime(LPSYSTEMTIME lpSystemTime);
‘PSYSTEMTIME は構造体へのポインタ（すなわち書き換え可能な参照）を要求する

Public 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

Sub Main()
Dim sysTime As New SYSTEMTIME()

‘ APIに ByRef で渡すことで、アンマネージド領域から
‘ 構造体のメモリに直接現在時刻が書き込まれる
GetSystemTime(sysTime)

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

End Module

もしここで、誤って `ByVal sysTime As SYSTEMTIME` なんぞと書こうものなら、API側はポインタを期待しているのに値そのものがスタックに積まれてしまい、アクセス違反（Access Violation）による致命的なクラッシュを引き起こす。
API連携において、`ByRef` は「OSにメモリを書き込んでもらうためのパスポート」なのだ。

—

5. シニアエンジニアが実践すべき設計指針とベストプラクティス

レガシーシステムの保守や、新規のエンタープライズ開発において、不具合をゼロにするための鉄則を提示する。

① 原則としてすべての引数に `ByVal` を明示する

言語のデフォルトに頼るな。チームのコーディング規約として、引数には必ず `ByVal` を明示することを強制せよ。これにより、「うっかり参照渡しになっていた」というヒューマンエラーをコンパイル段階で完全に封殺できる。

‘ 良い例：意図が明確
Public Sub ProcessData(ByVal inputData As String, ByVal config As AppConfig)
‘ …
End Sub

② `ByRef` を使うのは「明確な理由」がある場合のみに限定する

`ByRef` を許可していいのは、以下の2点に合致する場合のみである。
1. 複数の戻り値を返したい場合（パフォーマンスクリティカルなループ内で `Tuple` や `ValueTuple` のインスタンス生成コストを極限まで削りたい時など。ただし現代の.NETでは原則 `ValueTuple` や `out` 相当の設計を推奨）。
2. Windows API（P/Invoke）の仕様でポインタのポインタ、または構造体の書き換えが必須な場合。

③ イミュータブル（不変）設計の徹底

クラスや構造体を作る際、極力プロパティを `ReadOnly` にし、インスタンス生成後に対象の状態を変えられない設計（Immutable）を心がけよう。
状態が変化しないのであれば、仮に `ByRef` で渡されようとも、内部の値を書き換えられるリスクはゼロになる。

‘ 不変オブジェクトの例
Public NotInheritable Class ReadOnlyContext
Public ReadOnly Property ConnectionString As String

Public Sub New(ByVal connStr As String)
Me.ConnectionString = connStr
End Sub
End Class

—

結言

`ByVal` と `ByRef` は、単なる構文の選択肢ではない。それは「メモリの所有権とスコープの境界線」を定義する極めて重要なアーキテクチャ上の意思決定である。

「動けばいい」という妥協を捨て、背後にあるメモリの挙動を支配した者だけが、予期せぬバグの恐怖から解放された堅牢なシステムを構築できる。
プロフェッショナルたるもの、コードの1文字、修飾子の1つにまで魂とエンジニアリングの哲学を宿せ。