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

VB.NETにおけるByValとByRefの決定的な違い：メモリ挙動を制して予期せぬバグを駆逐する

開発現場において、若手プログラマからベテランまでが最もハマりやすい罠の一つが、メソッド引数の指定方法、すなわち `ByVal` と `ByRef` の違い です。

特にVB.NETの言語仕様において、何も指定しない場合のデフォルト（省略時）が `ByVal` なのか `ByRef` なのか、そしてそれがメモリ上でどのような振る舞いをするのかを正確に理解していないがために、「画面を切り替えたらデータが勝手に書き換わっていた」「DB登録直前の値がどこかで変質している」といった、原因究明に何時間も費やす不気味なバグを生み出す原因となります。

今回は、CLR（共通言語ランタイム）のメモリモデルの観点から、この2つの挙動の決定的な違いを解き明かし、業務システムで絶対に破綻しない堅牢なコードの書き方を伝授します。

—

1. 結論：VB.NETのデフォルト仕様とメモリの真実

まず、大前提として知っておくべき仕様があります。

VB.NETのデフォルトは `ByVal`（値渡し） です。
ただし、C#やJavaなどのモダンな言語の感覚からすると、VB.NETの歴史的背景（VB6等の名残）から、うっかり仕様を見誤りやすいポイントが潜んでいます。

メモリの観点から両者の違いをスパッと定義しましょう。

| 区分 | キーワード | 意味 | メモリ上の挙動 |
| :— | :— | :— | :— |
| 値渡し | `ByVal` (By Value) | 変数のコピーを渡す | 呼び出し元の変数とは別のメモリ領域に値がコピーされる。メソッド内で値を書き換えても呼び出し元には影響しない。 |
| 参照渡し | `ByRef` (By Reference) | 変数そのもののアドレス（参照）を渡す | 呼び出し元の変数と同じメモリ領域を指す。メソッド内で値を書き換えると、呼び出し元の値も即座に書き換わる。 |

「なんだ、じゃあ `ByRef` を使えば複数変数を返せるから便利じゃないか」と思ったそこのあなた。その油断が、保守性最悪のスパゲッティコードを生み出す最大のトリガーです。

—

2. なぜ `ByRef` は業務アプリの敵になり得のか？（メモリと参照の罠）

特に注意しなければならないのは、「値型（Integer, Boolean, Date, 構造体など）」と「参照型（String, Object, クラス, DataTableなど）」を `ByRef` で扱ったときの挙動の違いです。

参照型（Class等）を `ByVal` で渡した場合でも、渡されるのは「ヒープ領域にある実体へのアドレス（ポインタのコピー）」です。そのため、メソッド内でオブジェクトのプロパティ（例: `user.Name = “変更”`）を書き換えれば、呼び出し元でもその変更は反映されます。

しかし、`ByRef` を使った場合、変数そのものの参照（ポインタの変数自体の住所）が渡されます。これにより何が起きるか？

‘ 【アンチパターン：ByRefによる予期せぬインスタンスすり替え】
Sub ProcessData(ByRef targetList As List(Of String))
‘ 処理の途中でうっかり新しいインスタンスを代入してしまった場合…
targetList = New List(Of String)
targetList.Add(“新規データ”)
‘ これにより、呼び出し元のリスト自体がまるっと別物にすり替わる！
End Sub

このコードの恐ろしいところは、呼び出し元が意図していたデータが、メソッド内の不適切な `ByRef` のせいで跡形もなく消え去り、コンパイルエラーにもならずに静かにバグが潜む点です。業務アプリにおいて「データが勝手に消失・すり替わる」のは致命傷です。

—

3. 【プロダクションコード】堅牢性を極めたデータ処理の実装例

実務でファイル読み込みやデータベース連携を行う際、どのようにメソッドを設計すべきか。
「副作用（Side Effect）を排除した、保守性の高いコード」の模範解答を提示します。

このコードは、引数を原則 `ByVal` で固定し、戻り値や関数型のアプローチを用いてデータの不変性を保つ実用的なサンプルです。

Option Strict On
Option Explicit On

Imports System.IO
Imports System.Data.SqlClient

Namespace Enterprise.Utilities

”’

”’ 堅牢なデータ処理を提供するユーティリティクラス
”’

Public NotInheritable Class DataProcessor

‘ インスタンス化させない静的クラスとしての設計
Private Sub New()
End Sub

”’

”’ CSVファイルを安全に読み込み、加工済みデータを返す（ByValの徹底）
”’

”’ 読み込み元ファイルのパス ”’ 処理結果の文字列リスト（新規インスタンス）
Public Shared Function LoadAndProcessCsv(ByVal filePath As String) As List(Of String)

‘ ガード節：引数の事前検証
If String.IsNullOrWhiteSpace(filePath) Then
Throw New ArgumentException(“ファイルパスが不正です。”, NameOf(filePath))
End If

If Not File.Exists(filePath) Then
Throw New FileNotFoundException(“指定されたファイルが見つかりません。”, filePath)
End If

Dim processedRecords As New List(Of String)()

‘ Using文によるリソースの確実な解放（メモリリーク防止）
Using reader As New StreamReader(filePath, System.Text.Encoding.UTF8)
While Not reader.EndOfStream
Dim line As String = reader.ReadLine()

‘ データのバリデーションと加工（副作用なし）
If IsValidRecord(line) Then
Dim cleanedLine As String = SanitizeData(line)
processedRecords.Add(cleanedLine)
End If
End While
End Using

‘ 処理済みの新しいリストを返す（呼び出し元の変数を破壊しない）
Return processedRecords
End Function

”’

”’ レコードの妥当性検証（純粋関数としての設計）
”’

Private Shared Function IsValidRecord(ByVal record As String) As Boolean
‘ Nullまたは空行は除外
If String.IsNullOrWhiteSpace(record) Then Return False

‘ コメント行を除外
If record.TrimStart().StartsWith(“#”) Then Return False

Return True
End Function

”’

”’ データのサニタイジング（ByValにより入力値が破壊されないことを保証）
”’

Private Shared Function SanitizeData(ByVal rawData As String) As String
‘ 前後の空白除去および特殊文字の置換
Dim sanitized As String = rawData.Trim()

‘ 実際の業務ロジックに応じた置換処理
sanitized = sanitized.Replace(ControlChars.Tab, ” “)

Return sanitized
End Function

End Class

End Namespace

この設計が優れている理由

1. 完全な `ByVal` の徹底: すべての引数に `ByVal`（または省略による `ByVal`）を明示し、メソッド内部で入力値が勝手に書き換わる余地を完全に排除しています。
2. 関数の純粋性: メソッドは入力（引数）を受け取り、副作用を起こさずに新しい出力（戻り値）を返します。これにより、単体テスト（Unit Test）が極めて容易になります。
3. リソース管理の厳格化: `Using` ステートメントにより、ファイルストリームなどの非管理リソースのリークを確実に防ぎます。

—

4. チーフアーキテクトからの提言：いつ `ByRef` を使うべきか？

「じゃあ `ByRef` は一切使わないほうがいいのか？」という疑問がわくでしょう。

答えは 「NO。ただし極めて限定的なケースを除いて封印せよ」 です。

実務において `ByRef` の使用が許容される、あるいは強制されるのは以下の2ケースのみです。

1. VB.NETの言語仕様上、`ByRef` が必須である場合

代表例：`Integer.TryParse(inputString, ByRef resultValue)`
この手のメソッドは、パース成功時は値を詰め、失敗時は0を返すという「成否と値の両方」を効率よく返すために設計されています（※モダンなC#では `out` パラメータに相当）。

2. 極限のパフォーマンスチューニング（高頻度で巨大な構造体を往復させる場合）

数万回のループ内で巨大な構造体を値渡しすると、メモリのコピーコスト（スタック領域の消費）が無視できなくなります。ただし、これはプロファイラで明確なボトルネックが検出された場合のみの例外措置です。業務アプリの一般的な画面・バッチ処理において、これが原因になることはまずありません。

—

まとめ

基本はすべて `ByVal`：データの安全性を担保するため、変数のコピーを渡す意識を持つ。
`ByRef` は「呼び出し元の変数を意図して書き換える」明確な意思がある時以外は使わない。
副作用を排した「入出力が明確なコード」を書くことが、保守フェーズで泣かないための唯一にして最大の防衛策である。

メモリの挙動を支配する者が、コードを支配する。明日の開発から、あなたのコードの `ByRef` を見直し、堅牢で美しいプロダクションコードへと昇華させてください。