【テクニカル・上級編】引数の値渡し（ByVal）と参照渡し（ByRef）の挙動を徹底解剖 – Excel VBA解析バイブル

引数の魔力：ByValとByRefの深層と、VBAアーキテクチャの極意

VBAのコードレビューを行っていると、いまだに散見されるバグがある。それは「予期せぬ変数の書き換え」だ。プロシージャに渡したはずのデータが、いつの間にか別の値に化けている。そして、その原因究明のために何時間ものデバッグ地獄へと引きずり込まれる。

この悪夢の根源は、VBAのデフォルト仕様である ByRef（参照渡し） の無自覚な乱用にある。

シニアエンジニアや社内システム管理者であれば、動くコードを書くだけでなく、「メモリの挙動」や「オブジェクトのライフサイクル」までを完全に支配していなければならない。本稿では、ByValとByRefの機械的メカニズムを解剖し、レガシー環境の保守から高度なAPI連携までを見据えた「安全なプロシージャ設計」の極限の知見を伝授する。

—

1. メモリの深層：ByVal と ByRef の決定的な違い

VBAにおける変数の受け渡しは、単なるデータのコピーではない。CPUとメモリの対話そのものだ。

• ByVal（By Value / 値渡し）
• 挙動: 実引数の「値のコピー」をスタック領域に積み、それを子プロシージャへ渡す。
• 影響: 子プロシージャ側で変数をどう書き換えようとも、親プロシージャ側のオリジナルの変数は微動だにしない。
• ByRef（By Reference / 参照渡し）
• 挙動: 実引数の「メモリ上のアドレス（ポインタ）」そのものを子プロシージャへ渡す。
• 影響: 子プロシージャ側での操作は、メモリの直書き換えを意味する。親の変数はダイレクトに書き換わる。

VBAの恐ろしいところは、キーワードを省略すると強制的に `ByRef` になるという言語仕様だ。これが「意図しない破壊」を引き起こす最大の要因である。

危険なレガシーコードの典型例

Sub MainProcess()
Dim targetCount As Long
targetCount = 10

‘ 意図せず targetCount が書き換わる地雷コード
Call CalculateBonus(targetCount)

‘ ここで targetCount は 10 のはずが… 110 に化けている！
Debug.Print “Final Count: ” & targetCount
End Sub

Sub CalculateBonus(ByRef cnt As Long)
‘ ByRef なので親の変数に直接干渉する
cnt = cnt + 100
End Sub

この仕様は、C言語のポインタ操作に通じる柔軟性を持つ一方で、大規模なシステム開発やスパゲッティ化したレガシーコードにおいては「百害あって一利なし」のバグ製造機となる。

—

2. Windows API 呼び出しにおける生死を分ける選択

このByValとByRefの理解が甘いと、`Declare` ステートメントを用いた Windows API（DLL）呼び出し の際、Excelごと一瞬でクラッシュ（落ちる）する。APIはVBAの甘えを一切許さない。C/C++の世界のルールがそのまま適用されるからだ。

以下のコードを見てほしい。Windows APIから文字列やポインタを取得する際の極めて実用的な例だ。

‘ 32ビット/64ビット環境両対応のAPI宣言
If VBA7 Then
Private Declare PtrSafe Function GetComputerName Lib “kernel32” Alias “GetComputerNameA” ( _
ByVal lpBuffer As String, _
ByRef nSize As Long) As Long
Else
Private Declare PtrSafe Function GetComputerName Lib “kernel32” Alias “GetComputerNameA” ( _
ByVal lpBuffer As String, _
ByRef nSize As Long) As Long
End If

Sub GetPCName()
Dim buf As String
Dim length As Long

‘ バッファの領域を事前に確保（これがないとメモリ違反で落ちる）
buf = String(255, Chr$(0))
length = Len(buf)

‘ 【重要】
‘ lpBuffer は文字列の「ポインタ（先頭アドレス）」を渡す必要があるため ByVal
‘ length は API側で実サイズに書き換えてもらう必要があるため ByRef
Dim result As Long
result = GetComputerName(buf, length)

If result <> 0` Then
‘ ヌル文字以降をトリミング
buf = Left$(buf, InStr(buf, Chr$(0)) – 1)
MsgBox “コンピュータ名: ” & buf
Else
MsgBox “API呼び出し失敗”, vbCritical
End If
End Sub

なぜ `lpBuffer` は `ByVal` なのか？

C言語の文字列は「文字配列の先頭アドレス」を指すポインタである。VBAの文字列変数を `ByVal` で渡すと、VBAは「文字列変数が保持しているメモリ上のアドレス値（ポインタのコピー）」をAPIに渡す。
もしこれを `ByRef` にしてしまうと、「ポインタを格納している変数のアドレスのアドレス」という二重ポインタになり、APIはメモリを誤認してExcelを強制終了させる。API連携において、この違いを理解していないエンジニアは即座に失格の烙印を押されるべきだ。

—

3. オブジェクトのライフサイクルとメモリ最適化

「オブジェクト型（Object, Worksheet, Rangeなど）」を引数に取る場合、VBAの裏側では何が起きているのだろうか。

オブジェクト変数は、実態として「ポインタ（参照）」を格納している。そのため、オブジェクト変数をプロシージャに渡す場合、`ByRef` であろうが `ByVal` であろうが、渡されるのはオブジェクトの参照アドレスである。

しかし、ここでメモリ管理上の重大な罠がある。それは 「意図しない参照カウントの変動とメモリリーク」 だ。

安全かつ高速なオブジェクト渡しの設計パターン

Sub ProcessWorksheet()
Dim wsTarget As Worksheet
Set wsTarget = ThisWorkbook.Sheets(“DataSheet”)

‘ オブジェクトは必ず ByVal（または明示的に）で渡し、内部での参照保持に注意する
Call OptimizeSheet(wsTarget)

‘ 呼び出し元での確実な解放
Set wsTarget = Nothing
End Sub

Sub OptimizeSheet(ByVal ws As Worksheet)
‘ 【極限の知見】
‘ オブジェクト自体は ByVal で渡しても参照型なのでプロパティは書き換わる。
‘ しかし、変数 ws 自体を別のシートに向け替えても呼び出し元の wsTarget には影響しない。

With ws
.EnableCalculation = False
.ScreenUpdating = False

‘ 処理…

.ScreenUpdating = True
.EnableCalculation = True
End With

‘ 子プロシージャ内で生成・取得した一時オブジェクトは即座に解放する
Dim rngTemp As Range
Set rngTemp = ws.Range(“A1”)
‘ … 処理 …
Set rngTemp = Nothing ‘ 明示的解放
End Sub

シニアエンジニアが守るべき鉄則

1. オブジェクト変数は原則として `ByVal` で渡せ：
オブジェクト変数を `ByRef` にする正当な理由はほぼ存在しない。子プロシージャ内でうっかり `Set ws = Nothing` や別のシートを代入してしまい、呼び出し元の参照が破壊される事故を防ぐため、オブジェクトは常に `ByVal` で保護すべきだ。
2. プリミティブ型（Long, String, Boolean等）は原則 `ByVal`：
データを受け取って加工するだけの関数であれば、すべて `ByVal` にする。これにより、純粋関数（Pure Function）に近い設計となり、デバッグ効率が劇的に向上する。

—

4. システム間連携における堅牢なプロシージャ設計

レガシーな業務システムでは、Excel VBAから外部のCOMコンポーネント（連携ソフトやDBドライバなど）を叩く機会が多い。ここでは、エラーハンドリングとメモリの安全性を両立させた、実戦投入レベルの設計テンプレートを提示する。

‘ 外部システムへのデータ送信を行う堅牢なラッパー関数
Public Function SendDataToExternalSystem( _
ByVal ConnectionString As String, _
ByRef PayloadData() As String) As Boolean

‘ 戻り値の初期化
SendDataToExternalSystem = False

‘ 引数の整合性チェック（ガード cláus）
If Trim(ConnectionString) = “” Then Exit Function
If Not (Not PayloadData() Is Nothing) Then Exit Function ‘ 配列の初期化チェック

Dim objClient As Object
On Error GoTo ErrorHandler

‘ 外部COMオブジェクトの生成（遅いバインディングによるバージョン差異の吸収）
Set objClient = CreateObject(“ExternalSystem.Client”)

objClient.Initialize ConnectionString

‘ 配列データを安全に送信
‘ PayloadData は ByRef だが、この関数内では読み取り専用として扱う
Dim i As Long
For i = LBound(PayloadData) To UBound(PayloadData)
objClient.SendRecord PayloadData(i)
Next i

objClient.Commit
SendDataToExternalSystem = True

Cleanup:
‘ 【重要】COMオブジェクトの確実な解放
If Not objClient Is Nothing Then
On Error Resume Next
objClient.Close
Set objClient = Nothing
On Error GoTo 0
End If
Exit Function

ErrorHandler:
‘ ログ出力やエラーハンドリングのロジックをここに記述
Debug.Print “Error in SendDataToExternalSystem: ” & Err.Description
Resume Cleanup
End Function

このコードでは、`PayloadData()` をあえて `ByRef` にしている。巨大な配列データを扱う場合、`ByVal` にすると配列全体のメモリコピーが発生し、パフォーマンスが劇的に劣化するためだ。
パフォーマンスのために `ByRef` を採用しつつ、関数内では「値を書き換えない（イミュータブルとして扱う）」という強い規律をコードとコメントで担保する。これがプロフェッショナルのアプローチである。

—

5. 総括：VBAを「制御」するということ

VBAは、初心者にとって親しみやすい言語であると同時に、メモリ管理や型安全性の概念を無視すれば、あっという間にカオスなシステムを生み出す諸刃の剣だ。

• デフォルトの `ByRef` 依存から脱却し、意識的に `ByVal` を選択する。
• APIや外部連携では、メモリのポインタ構造を意識し、クラッシュを防ぐ。
• オブジェクトのライフサイクルを管理し、リソースリークを根絶する。

これらの知見を血肉とし、あなたの書くVBAコードを、保守性に優れ、エラーを知らない「強靭なインフラストラクチャ」へと昇華させてほしい。