こんにちは！現場のコードを日々鮮やかに書き換えている、あなたの専属シニアアーキテクトです。
今回は、VB.NETプログラミングにおいて避けて通れない、しかし多くの開発者がなんとなくで見過ごしがちな「ByVal（値渡し）」と「ByRef（参照渡し）」の決定的な違いについてお話しします。
「Excelマクロの記録から抜け出して本格的なVB.NETのアプリを作りたい！」
「なんだか分からないけど、気づいたら変数の値が書き換わってバグが出る……」
そんな悩みを抱えていませんか？大丈夫です。メモリの動きさえイメージできれば、VB.NETの変数なんて怖くありません。ここをクリアすれば、あなたのコーディングスキルは一段上のステージに上がります。さあ、一緒に本質をマスターしましょう！
—
1. メモリの「箱」と「住所」をイメージしよう
VB.NETで変数を使うとき、メモリ上に「データの入れ物（箱）」が作られます。
この箱の扱い方には、大きく分けて2つの流儀があります。それが ByVal と ByRef です。
- ByVal（By Value / 値渡し）
- 意味: データの「コピー」を渡す。
- イメージ: 重要な書類の「コピー」を取って相手に渡す。相手がそのコピーに落書きをしようが、破り捨てようが、手元にある「原本」は一切汚れません。
- ByRef（By Reference / 参照渡し）
- 意味: データの「実家（住所）」を教える。
- イメージ: 自宅の「合鍵」を相手に渡す。相手が勝手に冷蔵庫を開けて中身を書き換えたら、あなたの家の冷蔵庫の中身も変わってしまいますよね。
—
2. VB.NETのデフォルト（既定値）という大きな罠
ここで、VB.NETの歴史的背景と仕様について少し知っておく必要があります。
C#などの近代的な言語では、変数を渡すときは基本的に「コピー（値渡し）」が主流です。しかし、古いVB（Visual Basic 6など）からの互換性を引き継ぐVB.NETでは、プロシージャ（SubやFunction）の引数を省略して書いた場合、`ByRef`（参照渡し）がデフォルトになるという仕様が存在していました（※現在のVB.NETでは省略時はByValが基本ですが、古いコードや仕様の誤解でトラブルが起きやすいポイントです）。
この「意図せず参照渡しになっている」状態こそが、業務アプリで発生する「勝手にデータが書き換わる怪奇現象」の正体です。
—
3. コードで体感する！ByValとByRefの決定的な挙動の違い
百聞は一見にしかず。実際にコードを書いて、この2つの違いを目の当たりにしてみましょう。以下のコードをVB.NETのコンソールアプリなどで試してみてください。
Module Module1
Sub Main()
‘ — 実験1: ByVal（値渡し）の場合 —
Dim originalValue As Integer = 10
Console.WriteLine(“【ByValの実験】”)
Console.WriteLine($”呼び出し前: {originalValue}”)
‘ 変更を試みるプロシージャを呼ぶ
ModifyByVal(originalValue)
‘ 原本はどうなっているか？
Console.WriteLine($”呼び出し後: {originalValue}”) ‘ 結果は 10 のまま！
Console.WriteLine(“———————————–“)
‘ — 実験2: ByRef（参照渡し）の場合 —
Dim targetValue As Integer = 10
Console.WriteLine(“【ByRefの実験】”)
Console.WriteLine($”呼び出し前: {targetValue}”)
‘ 参照渡しをするプロシージャを呼ぶ
ModifyByRef(targetValue)
‘ 原本はどうなっているか？
Console.WriteLine($”呼び出し後: {targetValue}”) ‘ 結果は 99 に書き換わっている！
End Sub
‘ ByVal: コピーを受け取るので、原本は無事
Sub ModifyByVal(ByVal num As Integer)
num = 99
End Sub
‘ ByRef: 変数そのもの（への参照）を受け取るので、原本が書き換わる
Sub ModifyByRef(ByRef num As Integer)
num = 99
End Sub
End Module
実行結果
【ByValの実験】
呼び出し前: 10
呼び出し後: 10
———————————–
【ByRefの実験】
呼び出し前: 10
呼び出し後: 99
お分かりいただけましたか？
`ModifyByRef` を通した方は、呼び出し元の `targetValue` まで問答無用で `99` に書き換えられてしまいました。これがもし、消費税計算や顧客IDといった重要なデータだったら……想像するだけで冷や汗が出ますよね。
—
4. 業務システム開発で陥りやすい「予期せぬ値書き換えバグ」
「じゃあ、全部 `ByVal` にしておけば安全なんですね？」
はい、その通りです！基本的にはすべての引数に明示的に `ByVal` を指定するのが、モダンな業務アプリケーション開発における鉄則であり、バグを防ぐ最強の自衛策です。
特に以下のようなシーンで `ByRef` を安易に使うと、デバッグ地獄に陥ります。
1. ループ処理の中でカウンター変数をサブルーチンに渡すとき
サブルーチン側でうっかりカウンター変数を書き換えてしまい、無限ループや想定外のインデックスエラーが発生する。
2. 複数の画面やクラス間でデータを共有しているとき
「このメソッドに通したら、なぜか親画面のデータまで変わってしまった」という、原因究明が極めて困難な副作用を生む。
💡 例外的に ByRef を使うべきケース
プログラミングにおいて `ByRef` が悪というわけではありません。例えば、VB.NETの標準関数である `Integer.TryParse` のように、「1つのメソッドで複数の結果（成否のBooleanと、変換された数値）を同時に返したい場合」には、今でも `ByRef` が有効に活用されます。
Dim input As String = “123”
Dim result As Integer
‘ TryParseは、第二引数にByRefを使って値を格納する設計になっています
If Integer.TryParse(input, result) Then
Console.WriteLine($”変換成功: {result}”)
End If
—
5. まとめ：今日から使えるコーディングの極意
ここまでのポイントをギュッと凝縮します。
- ByVal（値渡し）は「コピー」を渡す安全設計。原本は絶対に汚れない。
- ByRef（参照渡し）は「合鍵（メモリの住所）」を渡すため、呼び出し元の値まで書き換えてしまう副作用がある。
- 迷ったら必ず `ByVal` を明示する！ これだけで、意図しない値書き換えバグの9割は防げます。
「なんとなく動く」から「仕組みを理解してコントロールできる」へ。
ここをクリアすれば、あなたの書くVB.NETコードは劇的に堅牢で美しいものになります。明日からの開発現場で、ぜひ意識してみてくださいね。あなたなら絶対にバッチリ使いこなせますよ！
