呼出元の命運を握る「ポインタ」の制御：ByValとByRefの深淵と防御的アーキテクチャ
Excel VBAという、一見すると親しみやすいスクリプト言語の皮を被った環境において、多くの開発者が一度は「不可解なバグ」の迷宮に迷い込みます。昨日まで正常に動作していたマクロが、データ量の増加や業務フローの変更に伴い、突如として異常な計算結果を出力し始める。その原因の多くは、変数やオブジェクトがプロシージャ間でどのように受け渡されているか——すなわち、「ByVal（値渡し）」と「ByRef（参照渡し）」の挙動に対する理解の甘さに起因します。
VBAは、歴史的な経緯（16bit/32bit過渡期のメモリ制約）から、引数のデフォルト値としてByRef（参照渡し）を採用しています。しかし、現代のソフトウェアエンジニアリングにおいて、明示的な理由なき参照渡しは「共有可変状態（Shared Mutable State）」を作り出し、バグを誘発する最大の温床となります。
本稿では、VBAにおけるメモリのライフサイクル、スタックとヒープの構造、Windows API呼び出し時の挙動までを網羅し、意図しない副作用を完全に排除する「防御的プログラミング」の極限を解説します。
—
1. メモリ空間で解き明かす「ByVal」と「ByRef」の真実
多くのテキストでは「ByValは値のコピー、ByRefは変数の共有」と単純化されていますが、これではプロフェッショナルな設計には耐えられません。我々は、Win32/Win64サブシステムが管理する物理・仮想メモリの視点から、この挙動を解剖する必要があります。
プリミティブ型（数値・日付・ブール値など）の挙動
VBAの実行エンジン（VBE7.dll）において、プロシージャ呼び出し時の引数は「スタック領域」を介して制御されます。
【ByVal（値渡し）のメモリ空間】
[呼び出し元スタック] [呼び出し先スタック]
+——————+ +——————+
| 変数 X (値: 100) | –(コピー)–> | 引数 Y (値: 100) |
+——————+ +——————+
※呼び出し先でYを書き換えても、Xのメモリ領域は完全に保護される。
【ByRef（参照渡し）のメモリ空間】
[呼び出し元スタック] [呼び出し先スタック]
+——————+ +——————+
| 変数 X (値: 100) | <--(ポインタ)- | 引数 Y (アドレス) |
+------------------+ +------------------+
※引数Yは、変数Xの物理メモリアドレスを指す。Yへの代入は、Xのメモリ領域を直接汚染する。
- ByVal: スタック上に新たなメモリ領域を確保し、呼び出し元の値を「複製」して格納します。呼び出し先プロシージャが終了すると、このスタック領域は即座にポップ（破棄）されます。
- ByRef: 呼び出し元の変数が格納されているメモリのアドレス（ポインタ）を渡します。呼び出し先でのいかなる変更も、同一のメモリ番地を指しているため、呼び出し元の変数にリアルタイムで反映されます。
オブジェクト型（クラス・ワークシート・Rangeなど）の罠
VBA開発者の多くが陥る最大の誤解が、「オブジェクト型をByValで渡せば安全である」という錯覚です。
オブジェクト変数は、本質的に「ヒープ領域に存在する実体（インスタンス）へのポインタ」を格納しています。
- ByRef Obj As TargetClass: 「ポインタ変数のアドレス（ポインタへのポインタ）」を渡します。
- ByVal Obj As TargetClass: 「ポインタ変数の値（インスタンスへのポインタ）」をスタックにコピーして渡します。
【ByValでオブジェクトを渡した場合の挙動】
[スタック領域] [ヒープ領域]
呼び出し元ポインタ [0x0012FF40] –+
|
+–> [インスタンス実体 (0x0A001020)]
|
呼び出し先ポインタ [0x0012FF10] –+
※ポインタ変数自体はコピー（別物）だが、指し示しているヒープ領域の実体は「同一」である。
したがって、`ByVal` でオブジェクトを渡したとしても、呼び出し先で `Obj.Property = NewValue` を実行すれば、呼び出し元のオブジェクトの状態は書き換わります（副作用の発生）。
ただし、`ByVal` と `ByRef` では、「インスタンスそのものの差し替え（Set）」に対する挙動が決定的に異なります。
- `ByRef` で渡されたオブジェクトに、呼び出し先で `Set Obj = Nothing` または `Set Obj = New TargetClass` を行うと、呼び出し元の変数自体が `Nothing` になるか、あるいは新しいインスタンスにすり替わります。
- `ByVal` で渡されたオブジェクトに対して同様の操作を行っても、呼び出し元のポインタ変数は影響を受けず、元のインスタンスを指し示し続けます。
—
2. 意図しない副作用（Side Effect）がもたらす致命的バグ
具体的なコードをベースに、参照渡し（ByRef）が引き起こす「静かなるバグ」のシミュレーションを行います。
プリミティブ型における「静かなる値の破壊」
以下は、消費税込みの金額を算出するプロシージャにおいて、暗黙の `ByRef`（VBAのデフォルト）が引き起こすロジック崩壊の例です。
‘ — 悪しき実装例：デフォルトのByRefによる副作用 —
Public Sub CalculateInvoice()
Dim unitPrice As Long
Dim quantity As Long
Dim totalAmount As Long
unitPrice = 10000 ‘ 単価
quantity = 5 ‘ 数量
‘ 合計金額を計算。この時、unitPriceが内部で書き換えられていることに気付けない
totalAmount = ApplyBulkDiscount(unitPrice, quantity)
‘ 期待値: 単価 10,000 数量 5 = 50,000 (割引前ベースの処理を継続したい)
‘ 実際値: 割引処理によってunitPrice自体が8,000に書き換わっているため、以降の処理が狂う
Debug.Print “単価: ” & unitPrice & ” 円” ‘ 出力: 単価: 8000 円（バグ発生）
Debug.Print “合計: ” & totalAmount & ” 円”
End Sub
‘ VBAでは明示しない場合「ByRef」となる
Private Function ApplyBulkDiscount(price As Long, qty As Long) As Long
If qty >= 5 Then
‘ 5個以上の場合は単価を20%OFFにするという仕様
‘ 引数priceを直接加工してしまったため、呼び出し元の「unitPrice」が書き換わる
price = price 0.8
End If
ApplyBulkDiscount = price qty
End Function
このバグの恐ろしい点は、「コンパイルエラーにならず、実行時エラーも発生しない」という点です。単に計算結果が狂うだけであり、ERPシステムや財務システムとの連携において、極めて深刻なデータの不整合を引き起こします。
防御的アプローチ：ByValによるカプセル化
この問題を解決する極めてシンプルなアプローチが、明示的なByValの指定です。
‘ — 防御的設計：ByValによる隔離 —
Private Function ApplyBulkDiscount(ByVal price As Long, ByVal qty As Long) As Long
If qty >= 5 Then
price = price 0.8 ‘ スタック上のコピーを変更しているため、呼び出し元には無影響
End If
ApplyBulkDiscount = price qty
End Function
—
3. Windows API連携における「ByVal」と「ByRef」の極限の使い分け
Windowsのコアシステム（DLL群）と連携するWindows APIの呼び出しにおいては、`ByVal` と `ByRef` の選択ミスは、単なるバグに留まらず、「Excelの強制終了（GPF: 一般保護違反）」や「OSのブルースクリーン」に直結します。
C/C++で記述されたWindows APIにおいて、引数は以下のように解釈されます。
- C言語の「値渡し」 $\rightarrow$ VBAでは `ByVal`
- C言語の「ポインタ渡し（“ や `&`）」 $\rightarrow$ VBAでは `ByRef`
文字列（String）の特殊性：VBA最深部の挙動
VBAの文字列型（`String`）は、内部的にはCOM規格の `BSTR`（文字長ヘッダ付きUnicode文字列へのポインタ）です。
Windows API（多くの場合はANSI版の `A` サフィックス付き関数、またはUnicode版の `W` サフィックス付き関数）に文字列を渡す際、VBAは極めて特殊な橋渡しを行います。
- `ByVal As String`: VBAは、BSTR文字列の内容を一時的にANSI（またはUnicode）のヌル終端文字列（`char` または `wchar_t`）に変換し、そのメモリバッファへのポインタをAPIに渡します。
- `ByRef As String`: VBAは、BSTRポインタそのもののアドレス（ポインタへのポインタ）を渡します。API側がこれを想定していない場合、不正なメモリ空間へのアクセスとなり、Excelは即座にクラッシュします。
API呼び出しの実践例：システムメモリ情報の取得
以下は、システムのメモリ状況を取得する `GlobalMemoryStatusEx` APIを安全に呼び出すための実装例です。ユーザー定義型（UDT: User Defined Type）をAPIに渡す場合、構造体のポインタを渡す必要があるため、`ByRef`（または明示的なポインタ指定）を用います。
Option Explicit
‘ メモリ構造体の定義（DWORDLONGは8バイト整数。VBAではCurrencyまたはDouble/Decimalで代用するが、
‘ ここでは正確なアライメントのために、バイナリ互換のレイアウトを定義）
Private Type MEMORYSTATUSEX
dwLength As Long
dwMemoryLoad As Long
ullTotalPhys As Double ‘ 8バイトの格納にDoubleを使用（符号なし64bit代替）
ullAvailPhys As Double
ullTotalPageFile As Double
ullAvailPageFile As Double
ullTotalVirtual As Double
ullAvailVirtual As Double
ullAvailExtendedVirtual As Double
End Type
‘ Win32 API宣言
‘ 引数 lpBuffer は構造体のポインタを要求するため「ByRef」で渡す必要がある
If VBA7 Then
Private Declare PtrSafe Sub GlobalMemoryStatusEx Lib “kernel32” (ByRef lpBuffer As MEMORYSTATUSEX)
Else
Private Declare Sub GlobalMemoryStatusEx Lib “kernel32” (ByRef lpBuffer As MEMORYSTATUSEX)
End If
Public Sub GetSystemMemoryDiagnostics()
Dim memStatus As MEMORYSTATUSEX
‘ 構造体のサイズを初期化（API呼び出し時の必須処理）
memStatus.dwLength = LenB(memStatus)
On Error GoTo Error_Handler
‘ ByRefによるメモリアドレスの受け渡し
GlobalMemoryStatusEx memStatus
‘ メモリ情報の出力（Doubleからギガバイト換算）
Dim bytesToGB As Double
bytesToGB = 1024# 1024# 1024#
Debug.Print “— メモリ診断結果 —”
Debug.Print “メモリ使用率: ” & memStatus.dwMemoryLoad & ” %”
Debug.Print “物理メモリ総量: ” & Round(memStatus.ullTotalPhys / bytesToGB, 2) & ” GB”
Debug.Print “利用可能物理メモリ: ” & Round(memStatus.ullAvailPhys / bytesToGB, 2) & ” GB”
Exit Sub
Error_Handler:
MsgBox “API呼び出しで致命的なエラーが発生しました。”, vbCritical, “システムエラー”
End Sub
—
4. 防御的プログラミング：堅牢性とパフォーマンスを両立する設計手法
VBA開発において、コードの堅牢性（バグの排除）と、レガシー環境におけるパフォーマンスのトレードオフをどうコントロールすべきか。チーフアーキテクトとしての設計思想を提示します。
原則1：引数は「ByVal」を基本原則（デフォルト）とする
「パフォーマンス向上のためにすべてByRefにする」という古典的なアドバイスは、現代のPCスペックにおいてはほぼ無意味です。プリミティブ型（Long, Double, Booleanなど）のコピーに要する時間は数ナノ秒のレベルであり、ByRefによるポインタ参照のオーバーヘッドと相殺されます。
コードの可読性と安全性、そして「呼び出し先で値が変更されない保証（不変性：Immutability）」を得るメリットの方が、遥かに巨大です。
原則2：ByRefを「意図的」に適用すべき3つの例外
1. 巨大な文字列（数メガバイト以上）や、巨大なユーザー定義型（UDT）を渡す場合
- コピーによるメモリ確保とCPUサイクルの消費を避けるため、パフォーマンス観点から `ByRef` を選択します。
2. 複数の値を呼び出し元に返却したい場合
- 関数（Function）の戻り値は1つだけですが、`ByRef` 引数を複数用意することで、実質的に複数の値を呼び出し元に書き戻すことができます。
3. API呼び出しでポインタが要求されている場合
- 構造体（UDT）やバッファポインタを直接操作するAPI連携。
原則3：オブジェクトの明示的なライフサイクル管理
オブジェクトを `ByRef` で受け渡す場合、呼び出し先での `Nothing` 代入による予期せぬ解放リスクが常に付きまといます。これを防ぐため、オブジェクトの「所有権（Ownership）」を明確にします。
‘ — 所有権を保持したまま安全にオブジェクトのプロパティを操作する —
Public Sub ProcessWorkflow()
Dim targetBook As Workbook
Set targetBook = Workbooks.Open(“C:\Database\Source.xlsx”)
‘ ByValで渡すことで、内部でtargetBook自体を書き換えられるリスクを完全に排除
ImportData targetBook
‘ ここでtargetBookがNothingになっていないことが保証される
targetBook.Close SaveChanges:=False
Set targetBook = Nothing
End Sub
‘ ByValで受け取ることで、引数「bk」への再代入（Set bk = Nothingなど）は
‘ 呼び出し元の「targetBook」に一切影響を与えない
Private Sub ImportData(ByVal bk As Workbook)
If bk Is Nothing Then Exit Sub
Dim ws As Worksheet
Set ws = bk.Sheets(1)
‘ データの読み取り処理に専念
Debug.Print ws.Range(“A1”).Value
‘ 仮に不具合でここでNothingが代入されても、呼び出し元は無傷
Set bk = Nothing
End Sub
—
5. 実践：堅牢性とメモリ管理を極めた「Win32 API型セーフメモリコピー」
最後に、ByValとByRefの挙動を極限まで活用し、かつVBAにおけるメモリリークやクラッシュを徹底的に防ぐ、実用的な「高速メモリコピー（RtlMoveMemory）」の実装を示します。
このクラスモジュールは、任意の変数からバイト配列、またはその逆のメモリコピーを安全に行うラッパーです。
クラスモジュール：`SafeMemoryCopier`
Option Explicit
‘ カーネルAPIの宣言
‘ RtlMoveMemoryはメモリの重複を許容する安全なコピーAPI
If VBA7 Then
Private Declare PtrSafe Sub CopyMemory Lib “kernel32” Alias “RtlMoveMemory” ( _
ByVal Destination As LongPtr, _
ByVal Source As LongPtr, _
ByVal Length As Long)
Else
Private Declare Sub CopyMemory Lib “kernel32” Alias “RtlMoveMemory” ( _
ByVal Destination As Long, _
ByVal Source As Long, _
ByVal Length As Long)
End If
‘ ===========================================================================
‘ @Description: 任意の変数のメモリイメージを、安全にバイト配列にダンプする
‘ @Param: sourceVar [ByRef] コピー元の変数（型を問わないためVariant/ByRefで受ける）
‘ @Param: destBytes [ByRef] 出力先のバイト配列
‘ ===========================================================================
Public Sub VariableToByteArray(ByRef sourceVar As Variant, ByRef destBytes() As Byte)
‘ Variantの内部構造（16バイト：64bit環境では24バイト）にアクセス
‘ VarPtrで変数の実データのアドレスを取得
#If VBA7 Then
Dim pSource As LongPtr
#Else
Dim pSource As Long
#End If
‘ Variantのデータ領域へのポインタを取得
pSource = VarPtr(sourceVar)
‘ データサイズを判定（簡易的にVariant内の特定データ型をハンドリング）
Dim dataSize As Long
dataSize = LenB(sourceVar)
If dataSize = 0 Then Err.Raise 5, , “指定された変数のデータサイズがゼロです。”
‘ 出力バッファの確保
ReDim destBytes(0 To dataSize – 1)
‘ メモリブロックの高速コピー
‘ Destination: バイト配列の先頭要素のアドレス（ByValでアドレス値を直接渡す）
‘ Source : コピー元変数のアドレス（ByValでアドレス値を直接渡す）
#If VBA7 Then
CopyMemory VarPtr(destBytes(0)), pSource, dataSize
#Else
CopyMemory VarPtr(destBytes(0)), pSource, dataSize
#End If
End Sub
標準モジュールでの検証コード
Public Sub TestSafeCopy()
Dim copier As New SafeMemoryCopier
Dim testValue As Double
testValue = 12345.6789
Dim buffer() As Byte
‘ 実行：Double型のメモリ表現（8バイト）をバイト配列に直接抽出する
copier.VariableToByteArray testValue, buffer
‘ メモリの生バイナリを16進数で出力
Dim i As Long
Dim hexOutput As String
For i = LBound(buffer) To UBound(buffer)
hexOutput = hexOutput & Right$(“0″ & Hex(buffer(i)), 2) & ” ”
Next i
‘ IEEE 754 形式での浮動小数点数のメモリダンプが得られる
Debug.Print “Double値 ” & testValue & ” のメモリダンプ:”
Debug.Print hexOutput
End Sub
—
6. まとめ：技術的負債を生まないための「シニアの決断」
Excel VBAという環境は、そのカジュアルさゆえに「動けば良い」というコードが量産され、数年後に誰もメンテナンスできない「スパゲッティ・モンスター」へと成長しがちです。
引数の設計における `ByVal` と `ByRef` の厳密な使い分けは、コードの「意図（Intent）」をコンパイラと後続の開発者に対して明示する、最も基本的な意思表示です。
- 理由なき `ByRef` は直ちに廃止せよ。
- 引数は原則 `ByVal` で受け、副作用を徹底的に排除せよ。
- オブジェクトの所有権（ポインタの寿命）を常に意識せよ。
- Windows APIを呼び出す際は、C言語のシグネチャとVBAのポインタ受け渡しの整合性をミリ秒単位で精査せよ。
このレベルの厳密さを積み重ねることだけが、数十万行規模のエンタープライズVBAシステムを安定稼働させ続ける唯一の道です。
