【実務・中級編】プロシージャの引数におけるByValとByRefの「意図しない変更」を防ぐ防御的プログラミング – Excel VBA解析バイブル

【VBA極限知見】デフォルトの罠に嵌まるな。ByVal（値渡し）による防御的プログラミングでサイレント・バグを根絶する

Excel VBAで数千行、数万行に及ぶ業務自動化ツールを開発していると、「昨日まで動いていたのに、なぜか時々計算結果がおかしくなる」「特定のデータパターンを通ったときだけ、関係のない変数の値が書き換わっている」といった、再現性の低い怪奇現象（バグ）に遭遇したことはないでしょうか。

その原因の9割は、VBAの言語仕様における最大の罠、「デフォルトの参照渡し（ByRef）」が引き起こす副作用（サイレント・データ破壊）にあります。

多くの入門書やネットの解説記事では、「引数にはByValとByRefがある」程度で片付けられていますが、エンタープライズ（実務）の現場で耐えうる堅牢なシステムを構築するためには、この挙動をミリ秒・1ビット単位で制御する「防御的プログラミング」の思想が不可欠です。

今回は、開発プロジェクトリーダーの視点から、なぜあなたのコードでバグが発生するのかをロジカルに解明し、極めて堅牢なVBAコードを設計するための実践アプローチを伝授します。

—

1. 悲劇の始まり：なぜデフォルトが「ByRef」なのか？

VBAにおいて、引数の前に何も明示しない場合、その引数は自動的にByRef（参照渡し）として扱われます。

‘ 何も書かないと、これは「ByRef」になる
Sub ProcessData(targetValue As Long)

メモリの視点で見るByValとByRefの本質

この2つの違いを、単なる「値のコピー」か「アドレスの共有」かという表面的な理解から、一歩踏み込んでメモリ（スタック領域）のライフサイクルで捉え直してみましょう。

なぜVBAはByRefをデフォルトにしたのか？

VBAが誕生した1990年代、PCのメモリリソースは極めて制限されていました。巨大な文字列や配列を「ByVal（値渡し）」で毎回コピーすると、メモリ消費量が跳ね上がり、パフォーマンスが著しく低下したためです。

しかし、現代のPCスペックにおいて、プリミティブ型（Long, Double, Booleanなど）や通常の文字列のコピーによるオーバーヘッドなど、砂漠の砂一粒ほどの意味もありません。現代の開発において最優先されるべきは、メモリの微小な節約ではなく、「バグを物理的に発生させない堅牢な設計（非対称性・不変性の担保）」です。

—

2. 実例：ByRefが引き起こす「サイレント・データ破壊」

まずは、実務でよくある「税込み金額を計算し、条件に応じて割引を適用する」という一見シンプルに見える処理を例に、ByRefがもたらす致命的なバグを観察してみましょう。

【悪いコード例】知らないうちに元データが書き換わる恐怖

‘ — 呼び出し元の処理 —
Public Sub MainProcess()
Dim unitPrice As Long
unitPrice = 10000 ‘ 元の単価は10,000円

‘ 1. 税込み金額を計算（この処理の中でバグが発生する）
Dim taxIncluded As Long
taxIncluded = CalculateTax(unitPrice)

‘ 2. 10,000円以上なら割引クーポンを適用したい
‘ しかし、この時点で unitPrice の値は…？
If unitPrice >= 10000 Then
MsgBox “10%割引を適用します！適用前単価: ” & unitPrice
Else
‘ ここを通ってしまう！なぜならunitPriceが11,000に変更されているから
MsgBox “割引対象外です。現在の単価: ” & unitPrice
End If
End Sub

‘ — 税込み金額を算出する関数（ByRefの罠） —
‘ ※ ByRefが省略されているため、priceは参照渡しになる
Private Function CalculateTax(price As Long) As Long
‘ 消費税10%を加算
price = price 1.1 ‘ ★ここで呼び出し元の「unitPrice」そのものを書き換えてしまっている！
CalculateTax = price
End Function

なぜこのコードは最悪なのか？

`CalculateTax` 関数は、引数で受け取った `price` を内部で計算に使い回し、直接書き換えています。
引数が `ByRef`（デフォルト）であるため、この書き換えは呼び出し元の変数 `unitPrice` にダイレクトに伝播します。

結果として、`MainProcess` 内の `unitPrice` は知らないうちに `11000` に化けてしまい、その後の割引判定ロジックが狂います。

このようなバグの恐ろしい点は、「コンパイルエラーにならず、実行時エラー（ランタイムエラー）も吐かずに、ただ静かに間違った結果を返し続ける」という点です。これが金融システムや基幹データとの連携マクロであれば、大惨事を引き起こすのは想像に難くありません。

—

3. 防御的プログラミング：ByValの徹底活用と設計ルール

このサイレント・バグを防ぐ唯一かつ最強の手段が、「ByVal（値渡し）の徹底」です。

改善されたコード

‘ — 税込み金額を算出する関数（ByValによる防御） —
Private Function CalculateTax(ByVal price As Long) As Long
‘ ByValにより、渡された値はコピーされているため、
‘ 内部でどれだけpriceを変更しても呼び出し元には一切影響しない
price = price 1.1
CalculateTax = price
End Function

この1単語 `ByVal` を付与するだけで、呼び出し元の `unitPrice` は完全に保護されます。

【奥義】オブジェクト型におけるByValとByRefの真実

「オブジェクト型（`Worksheet`、`Collection`、`Dictionary`、ユーザー定義クラスなど）を渡すときは、ByValにしても意味がない」という誤解が広く流布しています。これは半分正しく、半分間違いです。

オブジェクト型を `ByVal` で渡した場合、「オブジェクトへの参照（ポインタ）」自体が値渡しされます。

ByValでもできること： オブジェクトの内部状態（プロパティ）の変更。
例：`ByVal ws As Worksheet` としたとき、`ws.Range(“A1”).Value = “Hacked”` と書けば、呼び出し元のシートの値は書き換わります。
ByValだから防げること： オブジェクト変数自体の「再代入（破壊）」の防止。

以下のコードでその挙動の違いを目に焼き付けてください。

Public Sub ObjectSafetyTest()
Dim targetSheet As Worksheet
Set targetSheet = ThisWorkbook.Sheets(1)

‘ ByValでオブジェクトを渡す
DestructiveSubByVal targetSheet
‘ targetSheetはNothingにならず、無事生存している
MsgBox “ByVal後: ” & targetSheet.Name ‘ 正常に動作する

‘ ByRefでオブジェクトを渡す
DestructiveSubByRef targetSheet
‘ targetSheetそのものがNothingに書き換えられてしまっているため、ここでエラー（424）が発生する！
MsgBox “ByRef後: ” & targetSheet.Name
End Sub

‘ 1. ByVal渡し：オブジェクトの再代入から保護する
Private Sub DestructiveSubByVal(ByVal ws As Worksheet)
ws.Range(“A1”).Value = “データ書き換え” ‘ これは呼び出し元にも反映される（オブジェクトが同じであるため）
Set ws = Nothing ‘ ★ wsはコピーされた参照なので、呼び出し元のtargetSheetはNothingにならない！
End Sub

‘ 2. ByRef渡し：オブジェクトそのものを破壊できる（危険）
Private Sub DestructiveSubByRef(ByRef ws As Worksheet)
Set ws = Nothing ‘ ★ 呼び出し元のtargetSheetそのものがNothingになる！
End Sub

実務においては、プロシージャ内で引数のオブジェクト自体を `Set ws = Nothing` としたり、別のオブジェクトに差し替えたりするような破壊的処理を行うことは極めて稀です。したがって、オブジェクト型であっても基本は `ByVal` で渡し、不用意なインスタンスの再代入から保護するのが防御的プログラミングの鉄則です。

—

4. プロダクションコード：保守性と堅牢性を極めたファイル連携処理

ここでは、実際の業務でそのまま使える「CSVファイルからデータを読み込み、データベースやマスターシートに転記する」というシナリオを想定した、極めて堅牢なプロダクションコードを示します。

呼び出し元と呼び出し先の役割（関心の分離）を完全に整理し、すべての引数に意図を持った `ByVal` / `ByRef` 制御を施しています。

Option Explicit

‘ ===========================================================================
‘ メイン制御プロシージャ（エントリーポイント）
‘ ===========================================================================
Public Sub ImportBusinessData()
On Error GoTo ErrorHandler

‘ 呼び出し元の状態変数（不用意な書き換えから徹底ガードする）
Dim csvFilePath As String
csvFilePath = ThisWorkbook.Path & “\import_data.csv”

Dim targetSheet As Worksheet
Set targetSheet = ThisWorkbook.Sheets(“DataMaster”)

Dim processedCount As Long
processedCount = 0 ‘ 処理件数をカウントする変数

‘ 1. ファイルの存在チェック（文字列をByValで安全に渡す）
If Not FileExists(csvFilePath) Then
Err.Raise vbObjectError + 1001, , “インポート対象のCSVファイルが存在しません: ” & csvFilePath
End If

‘ 2. インポート処理の実行
‘ targetSheet: オブジェクト破壊を防ぐためByVal
‘ processedCount: 呼び出し先でのカウントアップ結果を受け取るため【意図的にByRef】で渡す
ImportCSVToSheet csvFilePath, targetSheet, processedCount

‘ 3. 結果報告（processedCountが正しく更新されている）
MsgBox “インポート処理が正常に完了しました。” & vbCrLf & _
“処理件数: ” & processedCount & ” 件”, vbInformation, “成功”

Exit Sub

ErrorHandler:
MsgBox “エラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“エラー内容: ” & Err.Description, vbCritical, “システムエラー”
End Sub

‘ ===========================================================================
‘ ヘルパー関数群（防御的設計）
‘ ===========================================================================

‘ 引数のパス文字列を破壊しないよう、確実にByValで受ける
Private Function FileExists(ByVal filePath As String) As Boolean
FileExists = (Dir(filePath) <> “”)
End Function

‘ @param ByVal filePath: 読み込みファイルパス（不変）
‘ @param ByVal destSheet: 出力先シート（シートインスタンスの再代入を防止）
‘ @param ByRef outCount: 処理件数を呼び出し元に返すための【意図的参照渡し】
Private Sub ImportCSVToSheet( _
ByVal filePath As String, _
ByVal destSheet As Worksheet, _
ByRef outCount As Long)

Dim fileNumber As Integer
fileNumber = FreeFile()

Open filePath For Input As #fileNumber

Dim fileLine As String
Dim lineParts() As String
Dim currentRow As Long

‘ シートの最終行を取得
currentRow = destSheet.Cells(destSheet.Rows.Count, 1).End(xlUp).Row + 1

Do Until EOF(fileNumber)
Line Input #fileNumber, fileLine
lineParts = Split(fileLine, “,”)

‘ シートへ書き込み（destSheetはByValだが、オブジェクトの操作は可能）
destSheet.Cells(currentRow, 1).Value = lineParts(0) ‘ ID
destSheet.Cells(currentRow, 2).Value = lineParts(1) ‘ 値段

‘ 呼び出し元のカウンタをインクリメント（ByRefなので、呼び出し元のprocessedCountが増える）
outCount = outCount + 1
currentRow = currentRow + 1
Loop

Close #fileNumber
End Sub

このコードが堅牢である理由（アーキテクチャ解説）

1. 引数の意図が明確（セルフドキュメンテーション）

`filePath` や `destSheet` は、関数内部で書き換えられては困る「入力値」であるため、`ByVal` で強固に保護しています。
一方で、`outCount` は「処理結果を呼び出し元に持ち帰る」という明確な目的があるため、`ByRef` で渡しています。このように設計者の意図がコード自体から透けて見えるため、他者が保守する際も迷いません。

2. カプセル化と安全性の両立

`ImportCSVToSheet` は、渡されたシートを破壊（`Set destSheet = Nothing`）することが構造上不可能です。これにより、メイン処理のメモリ管理が乱れるリスクを最小限に抑えています。

—

5. まとめ：堅牢なVBAコードを書くための黄金律

本稿のまとめとして、実務でマクロを開発・レビューする際に遵守すべきチェックリストを提示します。

[ ] 原則として、すべての引数に `ByVal` を明示的に付与する。（VBAの「デフォルトByRef」という甘えを許さない）
[ ] 呼び出し元に変数の変更を伝える必要がある場合のみ、`ByRef` を明示する。（暗黙の参照渡しは排除する）
[ ] オブジェクト型であっても、オブジェクト自体の再代入（破壊）を防ぐために、第一選択肢として `ByVal` を検討する。
[ ] 「パフォーマンスのためにByRefにする」という思考停止を捨て、安全性を最優先する。

引数を制する者は、プログラムのデータフローを制します。
明日から書くすべての `Sub` / `Function` に `ByVal` を書き加えるだけで、あなたの作成する業務ツールの安定性は劇的に向上し、原因不明のバグハントに徹夜する日々から解放されることを約束します。