【実務・中級編】初心者必見：Visual Basic (VB.NET)で初学者が陥る「ByRefとByVal」の誤解と、意図しない値書き換えバグを防ぐ参照渡しの正しい設計 – Visual Basic (VB / VB.NET)解析バイブル

構文の先へ：ByRef/ByValの罠を回避し、堅牢なVB.NETシステムを構築するための設計思想

業務自動化ツールの開発において、最も恐ろしいのは「コンパイルエラー」ではない。「エラーは出ないが、意図しない値に書き換わっている」というサイレント・バグだ。

現場で動くツールを作る際、多くの初学者は「動けばいい」という思考に陥る。しかし、我々プロフェッショナルが目指すべきは、単に動くコードではない。「誰が、どこで、どう触っても壊れない」堅牢な設計である。

その設計思想の根幹に関わるのが、メソッド引数における `ByVal`（値渡し）と `ByRef`（参照渡し）の制御だ。今日は、この二つの違いを単なる文法知識としてではなく、「副作用（Side Effect）を制御するための武器」として捉え直すための講義を行おう。

1. なぜあなたのコードは「壊れる」のか：副作用の正体

VB.NETにおいて、メソッドに引数を渡す際、デフォルトの挙動や安易な `ByRef` の使用は、呼び出し元の変数を「勝手に書き換える」リスクを孕んでいる。

ByVal（値渡し）の論理

`ByVal` は、渡されたデータの「コピー」を作成する。メソッド内でその値をどう弄り回そうが、呼び出し元のオリジナルの変数には一切影響を与えない。これは「データの独立性」を保証する、最も安全な選択だ。

ByRef（参照渡し）の論理

`ByRef` は、データの「メモリ上の住所（ポインタ）」を直接渡す。メソッド内での変更は、呼び出し元の変数そのものを書き換える。これは「データの共有」を意味する。

「複数の値を一度に返したいから `ByRef` を使う」――もし君がそう考えているなら、今すぐその設計を捨てろ。それは、コードの予測可能性を著しく低下させ、デバッグを地獄に変える「設計の敗北」だ。

2. 【実例】初学者が陥る「意図しない書き換え」の罠

Windows Formsアプリケーションで、ユーザー設定を管理する簡単なツールを想定しよう。以下のコードを見て、何が問題か理解できるだろうか。

❌ 避けるべきアンチパターン

“`vb.net
Public Class UserSettings
Public Property UserName As String
Public Property IsAdmin As Boolean
End Class

Module SettingsManager
‘ ❌ 非常に危険な設計：ByRef を使って、メソッド内で意図せず元のオブジェクトを操作してしまう
Public Sub UpdateUserStatus(ByRef settings As UserSettings)
‘ 何らかのロジック（例：一時的な検証用）
‘ 本来は検証したいだけなのに、ByRef なので元のオブジェクトに影響が出る可能性がある
settings.UserName = “Guest_” & settings.UserName
settings.IsAdmin = False
End Sub
End Module

‘ — 呼び出し側 (Form1.vb 等) —
Dim currentSettings As New UserSettings With {.UserName = “Taro”, .IsAdmin = True}

‘ 設定を検証したいだけなのに…
SettingsManager.UpdateUserStatus(currentSettings)

‘ 😱 結果：currentSettings.UserName は “Guest_Taro” になり、IsAdmin も False に書き換わっている！
‘ ユーザーは「検証しただけ」のつもりなのに、システム上の権限が剥奪された。

このコードの致命的な点は、「メソッドを呼び出しただけで、呼び出し元の状態が変わってしまう（副作用がある）」ことだ。大規模なシステムになれば、この「どこで値が変わったのか？」を探す作業だけで、エンジニアの数時間が溶けていくことになる。

3. プロフェッショナルの設計：副作用を封じ込める3つの鉄則

では、どう設計すべきか。我々アーキテクトが現場で徹底している規約を伝授する。

鉄則1：原則 `ByVal` をデフォルトとする
引数はすべて `ByVal` で渡す。これが基本だ。もし、オブジェクトのプロパティが書き換わるのが怖いなら、それは「オブジェクトの設計（カプセル化）」に問題がある。

鉄則2：複数の値を返したいなら「結果オブジェクト」を作る
`ByRef` を使って複数の値を返そうとするのは、古い時代の書き方だ。現代的な設計では、結果を格納するための専用の `Structure` や `Class`、あるいは `Tuple` を返却する。

鉄則3：不変性（Immutability）を意識する
可能であれば、渡されたデータを書き換えるのではなく、「新しいデータを作成して返す」設計にする。これが、最もバグの入り込みにくいクリーンなコードだ。

4. 【実践】堅牢なプロダクションコード・テンプレート

これまでの教訓をすべて詰め込んだ、実務でそのまま使える「堅牢な設計」の例を示そう。ここでは、データベースやファイル連携を想定した、ユーザー情報の更新処理を記述する。

vb.net
”’

Public Class UpdateResult
Public Property IsSuccess As Boolean
Public Property NewSettings As UserSettings ‘ 更新後の新しい状態
Public Property Message As String ‘ ログやエラーメッセージ
End Class

Public Class UserSettings
‘ プロパティは読み取り専用に近い運用を推奨（必要に応じて Setter を制御）
Public Property UserName As String
Public Property IsAdmin As Boolean

”’

Public Function CloneWithNewName(newName As String, isAdmin As Boolean) As UserSettings
Return New UserSettings With {
.UserName = newName,
.IsAdmin = isAdmin
}
End Function
End Class

Module UserProcessor
”’

”’ 元の設定（ByVal で保護） ”’ 更新結果を格納したオブジェクト
Public Function ProcessUserUpdate(ByVal originalSettings As UserSettings) As UpdateResult
Try
‘ 1. 入力値の検証（元の originalSettings は絶対に書き換えない）
If String.IsNullOrWhiteSpace(originalSettings.UserName) Then
Return New UpdateResult With {.IsSuccess = False, .Message = “ユーザー名が空です。”}
End If

‘ 2. ビジネスロジックの実行
‘ 元のオブジェクトを改造するのではなく、新しい状態を計算して生成する
Dim updatedName As String = “Updated_” & originalSettings.UserName
Dim updatedAdminStatus As Boolean = False ‘ 規約により、一般ユーザーへ降格させるロジックと仮定

‘ 新しいインスタンスを生成（これが「非破壊的変更」）
Dim nextSettings = originalSettings.CloneWithNewName(updatedName, updatedAdminStatus)

‘ 3. ここでデータベースやファイルへの保存処理を行う（擬似コード）
‘ SaveToDatabase(nextSettings)

‘ 4. 成功結果を返す
Return New UpdateResult With {
.IsSuccess = True,
.NewSettings = nextSettings,
.Message = “更新に成功しました。”
}

Catch ex As Exception
‘ エラー発生時も、元のデータには影響を与えず、エラー情報を返す
Return New UpdateResult With {
.IsSuccess = False,
.Message = $”予期せぬエラーが発生しました: {ex.Message}”
}
End Try
End Function
End Module

‘ — 呼び出し側 (Form1.vb 等) —
‘ 実装例
Public Sub ExecuteUpdate()
Dim currentSettings As New UserSettings With {.UserName = “Taro”, .IsAdmin = True}

‘ メソッドを呼び出す。currentSettings 自体は破壊されない。
Dim result As UpdateResult = UserProcessor.ProcessUserUpdate(currentSettings)

If result.IsSuccess Then
‘ 成功した場合のみ、新しい設定を適用する
currentSettings = result.NewSettings
MessageBox.Show($”{result.Message} 新しい名前: {currentSettings.UserName}”)
Else
‘ 失敗した場合、currentSettings は元のまま保持されている（安全！）
MessageBox.Show($”失敗: {result.Message}”)
End If
End Sub
“`

まとめ：エンジニアとしての矜持

`ByRef` は、メモリを節約したい極限のパフォーマンス追求が必要な場面（大規模な配列の操作など）を除き、「ビジネスロジックの伝播」においては避けるべき劇薬だ。

君が書くべきは、呼び出し側が「何が起こるか」を完全に予測できるコードである。

1. `ByVal` を愛せ。
2. 副作用を恐れ、データの不変性を守れ。
3. 複数の戻り値が必要なら、構造化されたオブジェクトを返せ。

この原則を守るだけで、君の作成する業務自動化ツールは、単なる「動くスクリプト」から、プロフェッショナルが信頼を寄せる「堅牢なシステム」へと昇華する。

次にコードを書くとき、その引数は本当に `ByRef` である必要があるか、自らに問いかけよ。