プロシージャの引数：ByRefの深淵なる危険性とByValによる堅牢な防御的プログラミングの鉄則
諸君、私は長年、VBAシステムという名の遺産と格闘し、時にその脆さに絶望し、時にその奥深さに感銘を受けてきた。VBAの世界では、些細な設計判断がシステムの寿命や保守コストに決定的な影響を与える。その中でも、プロシージャの引数渡し、すなわち「ByRef」と「ByVal」の選択は、システムの堅牢性を左右する根源的な要素でありながら、往々にして軽視されがちだ。
この記事では、VBAのデフォルトである参照渡し（ByRef）が秘める深淵なる危険性を暴き、値渡し（ByVal）による防御的プログラミングの鉄則を説く。単なるシンタックスの説明ではない。オブジェクトのライフサイクル、メモリの挙動、そしてシステム全体への影響という視点から、この本質的なテーマを深く掘り下げていく。
1. ByRefの深淵なる危険性：表面的な理解を超えて
VBAにおける引数渡しは、特に明示しない限り `ByRef`（参照渡し）となる。これは、プロシージャに渡されるのが変数の「値そのもの」ではなく、「変数の格納されているメモリアドレス」である、ということを意味する。一見、効率的に思えるこのデフォルトの挙動が、実は数多のバグとシステムの不安定性の温床となる。
1.1. 意図しない副作用とデバッグの地獄
`ByRef`で渡された引数は、呼び出されたプロシージャ内でその値を変更すると、呼び出し元の変数も容赦なく変更される。
‘ ByRefの危険性を示すコード
Sub DangerousByRefExample()
Dim originalValue As Long
originalValue = 10
Debug.Print “呼び出し前: ” & originalValue ‘ 出力: 呼び出し前: 10
Call ModifyValueByRef(originalValue) ‘ ここでoriginalValueが書き換わる
Debug.Print “呼び出し後: ” & originalValue ‘ 出力: 呼び出し後: 100
‘ 大規模システムにおける問題点:
‘ 1. プロシージャ名から変更を予期できない場合がある。
‘ 2. 複数のプロシージャが連鎖的に呼び出される中で、どこで値が変更されたのか追跡が困難。
‘ 3. 複数人での開発において、意図しない副作用が頻発し、デバッグ工数が跳ね上がる。
End Sub
‘ ByRefで引数を受け取り、その値を変更するプロシージャ
Sub ModifyValueByRef(ByRef target As Long)
‘ 呼び出し元の originalValue が直接変更される
target = 100
End Sub
これは単純な値型の例だが、オブジェクト型になるとさらに複雑化する。
1.2. オブジェクト参照の罠とメモリ管理の破綻
オブジェクト型変数を`ByRef`で渡すと、オブジェクトそのものではなく、「オブジェクトインスタンスへの参照」が渡される。この参照が、呼び出されたプロシージャ内で別のオブジェクトに再割り当てされたり、`Nothing`に設定されたりすると、呼び出し元のオブジェクト参照も影響を受ける。
‘ オブジェクト型をByRefで渡す危険性
Sub DangerousObjectByRefExample()
Dim myCollection As Collection
Set myCollection = New Collection
myCollection.Add “初期アイテム”
Debug.Print “呼び出し前 (Count): ” & myCollection.Count ‘ 出力: 1
Debug.Print “呼び出し前 (Item(1)): ” & myCollection.Item(1) ‘ 出力: 初期アイテム
‘ 参照を渡すことで、内部でオブジェクトが変更される
Call ModifyCollectionByRef(myCollection)
Debug.Print “呼び出し後 (Count): ” & myCollection.Count ‘ 出力: 2
Debug.Print “呼び出し後 (Item(1)): ” & myCollection.Item(1) ‘ 出力: 変更されたアイテム
‘ 参照そのものを別のオブジェクトに再割り当て、あるいはNothingにする例
Debug.Print “再割り当て前 (Count): ” & myCollection.Count ‘ 出力: 2
Call ReassignCollectionByRef(myCollection)
‘ myCollectionは、ReassignCollectionByRef内でNothingにされたため、もはや有効ではない
If myCollection Is Nothing Then
Debug.Print “myCollectionはNothingになった” ‘ 出力: myCollectionはNothingになった
Else
Debug.Print “myCollectionは別のオブジェクトを参照している”
End If
End Sub
‘ コレクションオブジェクトをByRefで受け取り、その状態を変更するプロシージャ
Sub ModifyCollectionByRef(ByRef targetCollection As Collection)
‘ targetCollectionは呼び出し元のmyCollectionと同一のオブジェクトインスタンスを指す
targetCollection.Remove 1
targetCollection.Add “変更されたアイテム”
‘ ここでの操作は、呼び出し元の myCollection に直接影響する
End Sub
‘ コレクションオブジェクトをByRefで受け取り、参照そのものを変更するプロシージャ
Sub ReassignCollectionByRef(ByRef targetCollection As Collection)
‘ 呼び出し元の myCollection が指すオブジェクト参照を直接変更する
Set targetCollection = Nothing ‘ 呼び出し元の myCollection も Nothing になる
‘ あるいは Set targetCollection = New Collection とすれば、
‘ 呼び出し元の myCollection も新しい Collection インスタンスを指すようになる
End Sub
このように、`ByRef`でオブジェクト参照を渡すことは、呼び出し元と呼び出し先の間に強固な結合を生み出し、予測不能な挙動やメモリリークの原因となる。特に、オブジェクトが`Nothing`に設定されることで、本来のライフサイクル管理が困難になるケースは少なくない。
2. ByValによる堅牢な防御的プログラミングの鉄則
上記のような危険性を回避し、堅牢なシステムを構築するための鉄則はただ一つ、引数は原則として`ByVal`（値渡し）で渡すことである。
2.1. 値型のByVal：シンプルな安全性
値型（`Integer`, `Long`, `String`, `Boolean`など）を`ByVal`で渡した場合、呼び出し元の変数の「コピー」がプロシージャに渡される。これにより、プロシージャ内で引数の値を変更しても、呼び出し元の変数には一切影響が及ばない。
‘ ByValによる防御的プログラミング
Sub SafeByValExample()
Dim originalValue As Long
originalValue = 10
Debug.Print “呼び出し前: ” & originalValue ‘ 出力: 呼び出し前: 10
Call ModifyValueByVal(originalValue)
Debug.Print “呼び出し後: ” & originalValue ‘ 出力: 呼び出し後: 10 (変更されない)
‘ このように、プロシージャが独立し、副作用の心配がなくなる。
‘ コードの見通しが良くなり、デバッグも容易になる。
End Sub
‘ 値型をByValで受け取るプロシージャ
Sub ModifyValueByVal(ByVal target As Long)
‘ ここでの変更は、target変数のコピーに対して行われるため、
‘ 呼び出し元の originalValue には影響しない
target = 100
End Sub
2.2. オブジェクト型のByVal：見落とされがちな真実
オブジェクト型変数を`ByVal`で渡した場合、プロシージャに渡されるのは「オブジェクトインスタンスへの参照の値のコピー」である。ここが重要だ。
‘ オブジェクト型をByValで渡す際の真実
Sub SafeObjectByValExample()
Dim myCollection As Collection
Set myCollection = New Collection
myCollection.Add “初期アイテム A”
Debug.Print “呼び出し前 (Count): ” & myCollection.Count ‘ 出力: 1
Debug.Print “呼び出し前 (Item(1)): ” & myCollection.Item(1) ‘ 出力: 初期アイテム A
‘ ByValでオブジェクト参照のコピーを渡す
Call HandleCollectionByVal(myCollection)
‘ 呼び出し元のmyCollectionの状態を確認
Debug.Print “呼び出し後 (Count): ” & myCollection.Count ‘ 出力: 2 (!!!! 意図せず変更されている可能性 !!!!)
Debug.Print “呼び出し後 (Item(1)): ” & myCollection.Item(1) ‘ 出力: 初期アイテム A
‘ ByValで渡された参照変数を別のオブジェクトに再割り当てする例
Debug.Print “再割り当て前 (myCollectionがNothingか): ” & (myCollection Is Nothing) ‘ False
Call ReassignCollectionReferenceByVal(myCollection)
‘ 呼び出し元の myCollection は影響を受けない
Debug.Print “再割り当て後 (myCollectionがNothingか): ” & (myCollection Is Nothing) ‘ False (変わらず)
Debug.Print “再割り当て後 (Count): ” & myCollection.Count ‘ 出力: 2 (前の操作による)
End Sub
‘ コレクションオブジェクトをByValで受け取るプロシージャ
Sub HandleCollectionByVal(ByVal targetCollection As Collection)
‘ ここで targetCollection は、呼び出し元の myCollection が指す
‘ オブジェクトインスタンスへの「参照のコピー」を受け取っている。
‘ つまり、myCollection と targetCollection は「同じオブジェクトインスタンス」を指している。
‘ そのため、targetCollection を使ってオブジェクトの状態を変更すると、
‘ 呼び出し元の myCollection が指すオブジェクトも変更される！
targetCollection.Add “追加されたアイテム ByVal内部” ‘ これによりmyCollectionも変更される
‘ Debug.Print targetCollection.Item(1) ‘ 出力: 初期アイテム A
‘ targetCollection を別のオブジェクトに再割り当てしても、
‘ 呼び出し元の myCollection は影響を受けない
Set targetCollection = New Collection
targetCollection.Add “ByVal内部で作成された新しいオブジェクト”
Debug.Print “ByVal内部で新しいオブジェクトを生成 (Item(1)): ” & targetCollection.Item(1)
End Sub
‘ オブジェクト参照をByValで受け取り、内部で再割り当てを試みるプロシージャ
Sub ReassignCollectionReferenceByVal(ByVal targetCollection As Collection)
‘ targetCollection は呼び出し元のオブジェクトへの参照のコピー。
‘ ここで別のオブジェクトを割り当てても、呼び出し元の myCollection は影響を受けない。
Set targetCollection = New Collection
targetCollection.Add “完全に新しいオブジェクト (ByVal内部)”
Debug.Print “ReassignCollectionReferenceByVal内部: ” & targetCollection.Item(1)
End Sub
この`SafeObjectByValExample`における`HandleCollectionByVal`の挙動こそが、ByValオブジェクト引数の「見落とされがちな真実」であり、「極限の知見」と呼ぶに値する。`ByVal`は、渡された参照変数を別のオブジェクトに再割り当てしても呼び出し元には影響しないという点で安全だが、参照先のオブジェクトの状態を変更する操作（例: `targetCollection.Add`）は、呼び出し元のオブジェクトに直接影響するのだ。
3. オブジェクト型引数におけるByValの限界と真の防御戦略
ByValでもオブジェクトの状態変更を防げないという事実は、真に不変なオブジェクトを扱いたい場合の課題となる。この課題を克服するための真の防御戦略は、以下のいずれか、あるいは組み合わせとなる。
3.1. オブジェクトのクローン（ディープコピー）
プロシージャ内でオブジェクトの状態を変更しても、呼び出し元に影響を与えない最も確実な方法は、オブジェクトの「ディープコピー」を渡すことだ。VBAには`ICloneable`インターフェースのような標準機能はないため、自前で実装する必要がある。
‘ 簡易的なオブジェクトのディープコピーの概念（VBAでの実装例は複雑になるため概念のみ）
‘ MyClassを複製してプロシージャに渡す場合
‘ Sub ProcessMyObject(ByVal obj As MyClass)
‘ Dim clonedObj As MyClass
‘ Set clonedObj = obj.Clone ‘ CloneメソッドをMyClassに実装しておく
‘ clonedObj.ModifyProperty = “New Value”
‘ End Sub
‘ VBAでディープコピーを実装する一般的な方法:
‘ 1. 各プロパティを個別にコピーするコンストラクタやメソッドを実装する。
‘ 2. オブジェクトをシリアライズ（例: JSON文字列化）し、デシリアライズして新しいインスタンスを生成する。
‘ （これはVBA標準機能では難しいため、外部ライブラリや自作のパーサーが必要）
ディープコピーはメモリとCPUのオーバーヘッドを伴うため、パフォーマンスがクリティカルな場面では慎重な検討が必要だ。
3.2. イミュータブル（不変）オブジェクトの設計
最も理想的な防御戦略は、オブジェクトそのものを不変（Immutable）として設計することである。つまり、一度生成されたオブジェクトは、その状態を後から変更できないようにする。VBAでは`Property Get`のみを提供し、`Property Let`/`Set`を実装しないクラスとして実現できる。
‘ 不変オブジェクトの概念
‘ Class ImmutableUser
‘ Private Const m_UserName As String
‘ Private Const m_UserID As Long
‘
‘ Public Property Get UserName() As String
‘ UserName = m_UserName
‘ End Property
‘
‘ Public Property Get UserID() As Long
‘ UserID = m_UserID
‘ End Property
‘
‘ ‘ コンストラクタ（Class_Initialize）で初期化し、その後は変更不可
‘ Private Sub Class_Initialize()
‘ ‘ 初期化ロジック
‘ End Sub
‘
‘ End Class
イミュータブルオブジェクトは、一度作成すればその状態が保証されるため、参照渡しであっても副作用の心配がなくなる。しかし、VBAでの複雑なイミュータブルオブジェクトの設計は、かなりの手間と工夫を要する。
4. パフォーマンスとメモリの重み：ByRef/ByValの選択基準
パフォーマンスとメモリ使用量は、特に大規模なデータ処理やレガシー環境でのVBAアプリケーションにおいて、常に意識すべき要素だ。
- 値型とByVal: `Integer`, `Boolean`のような小さな値型は、コピーにかかるオーバーヘッドが極めて小さいため、`ByVal`を積極的に使用すべきだ。`Long`や`String`も、一般的な長さであれば`ByVal`で問題ない。
- 大きな構造体（User-Defined Type）とByRef/ByVal: VBAの構造体は、`ByVal`で渡すとその内容が丸ごとコピーされる。構造体が多数のフィールドを持つ場合、このメモリコピーのコストは無視できない。この場合、`ByRef`で参照渡しを選択する方がパフォーマンス上有利な場合がある。ただし、その副作用を完全に理解し、ドキュメント化し、テストを徹底することが絶対条件だ。
- オブジェクト型とByRef/ByVal: どちらも「参照の値」が渡されるため、参照渡し自体のコストは小さい。繰り返しになるが、選択の基準は「副作用の許容度」と「オブジェクトの状態変更を許すか否か」である。
5. Windows API呼び出しにおけるByRefの必然性
VBAが真価を発揮する場面の一つに、Windows APIの呼び出しがある。この領域では、`ByRef`は単なるオプションではなく、必須の指定となることが多々ある。
5.1. `Declare`ステートメントとポインタ渡し
Windows API関数は、C/C++言語で記述されており、引数としてメモリ上のポインタを要求することが一般的だ。VBAの`ByRef`は、この「ポインタ渡し」をエミュレートする役割を果たす。
‘ Windows APIのByRef例: GetUserNameW (Unicode版)
‘ ユーザー名を取得するAPI。バッファとバッファサイズへのポインタを要求する。
If VBA7 Then ‘ 64bit環境対応 (VBA7以降)
‘ PtrSafeキーワードは64bit環境でポインタサイズを正しく扱うために必須
Private Declare PtrSafe Function GetUserNameW Lib “advapi32.dll” ( _
ByVal lpBuffer As LongPtr, _ ‘ バッファ（文字列）の先頭アドレスを値として渡す
ByRef nSize As Long _ ‘ バッファサイズ変数のアドレスを参照として渡す
) As Long
Else ‘ 32bit環境 (VBA6以前)
Private Declare Function GetUserNameW Lib “advapi32.dll” ( _
ByVal lpBuffer As Long, _
ByRef nSize As Long _
) As Long
End If
Sub GetCurrentWindowsUserName()
Dim userNameBuffer As String
Dim bufferSize As Long
Dim apiResult As Long
‘ ユーザー名の最大長を考慮し、十分なバッファを確保。
‘ Windowsユーザー名は通常256文字（終端NULL含む）が最大。
bufferSize = 256
‘ Unicode NULL文字 (ChrW(0)) で埋めることで、APIが書き込める領域を確保
userNameBuffer = String(bufferSize, ChrW(0))
‘ GetUserNameW を呼び出し
‘ lpBuffer: StrPtr(userNameBuffer) で文字列バッファの先頭アドレスをByVal (値)として渡す
‘ APIは指定されたアドレスにユーザー名を書き込む。
‘ nSize: bufferSize 変数のアドレスをByRef (参照)として渡す。
‘ APIはここに実際に書き込まれた文字数を格納する。
apiResult = GetUserNameW(StrPtr(userNameBuffer), bufferSize)
If apiResult <> 0 Then
‘ 終端NULL文字までの部分文字列を取得
Dim nullPos As Long
nullPos = InStr(userNameBuffer, ChrW(0))
If nullPos > 0 Then
Debug.Print “現在のユーザー名: ” & Left(userNameBuffer, nullPos – 1)
Else
Debug.Print “ユーザー名取得失敗: NULL文字が見つかりません”
End If
Else
‘ エラー処理
Debug.Print “ユーザー名取得失敗。エラーコード: ” & Err.LastDllError
End If
End Sub
この例では、`nSize`引数が`ByRef`で渡されている。これは、APIが呼び出し元の`bufferSize`変数を直接書き換え、実際にユーザー名が格納された文字数を返すためだ。このようなAPI連携においては、`ByRef`の正確な理解が不可欠であり、誤った指定はメモリ破壊やアプリケーションのクラッシュ（ACCESS VIOLATION）に直結する。
特に64bit環境では、ポインタのサイズが32bitから64bitに変わるため、`LongPtr`型と`PtrSafe`キーワードの利用が必須となる。これを怠ると、メモリ破壊を引き起こし、デバッグ不能なバグの温床となる。
6. レガシーシステム保守とシステム間連携の極限の知見
6.1. 既存ByRefコードへの対処
多くのレガシーVBAシステムは、`ByRef`がデフォルトであるという理由だけで、あるいはパフォーマンス上の安易な理由で`ByRef`を多用している。これらのコードを改修する際、安易に`ByVal`へ変更することは、既存システムの動作を破壊する可能性が非常に高い。
- 影響範囲の分析: 変更前に、その引数がどこで、どのように使われているかを徹底的に分析する。
- リグレッションテスト: 変更後には、広範囲なリグレッションテストを計画し、実行する。
- 段階的改修: 一度に全てを変更しようとせず、影響の少ない部分から段階的に`ByVal`化を進める。
- ドキュメント化: `ByRef`を残す場合は、その理由と副作用を明確にドキュメントに残す。
6.2. COM連携とシステム間連携
VBAは、COM（Component Object Model）を通じて他のアプリケーション（Outlook, Word, Accessなど）や外部DLLと連携する。COMインターフェースの定義によっては、引数が`ByRef`で設計されている場合もある。
- IDL（Interface Definition Language）の理解: COMコンポーネントの提供元が公開しているIDLやドキュメントを熟読し、引数渡し規約を正確に理解する。
- DLLとの連携における型マッピング: C/C++で書かれたDLL関数を`Declare`ステートメントで呼び出す際、VBAのデータ型とDLL側のデータ型（特に構造体のアライメントやポインタサイズ）を厳密にマッピングする必要がある。ここでの不一致は、前述の通りメモリ破壊に繋がるため、細心の注意を払うべきだ。`LongPtr`の適切な使用、`Type`ステートメントによる構造体の定義、そして`VarPtr`, `StrPtr`, `ObjPtr`といった内部関数を駆使してメモリを直接操作する知識が、この領域では不可欠となる。
7. 結論：堅牢性への飽くなき追求
Excel VBAにおける`ByRef`と`ByVal`の選択は、単なる文法上の問題ではない。それは、プロシージャの独立性、デバッグの容易性、システムの安定性、そして最終的には保守性の全てに影響を与える、アーキテクチャ上の重要な意思決定である。
- 原則ByVal: 値型、そしてオブジェクト参照のコピーを渡すことで、プロシージャの独立性を高め、予期せぬ副作用を防ぐ。
- ByValの限界認識: オブジェクト型を`ByVal`で渡しても、参照先のオブジェクトの状態変更は防げない。真の不変性を求めるなら、クローンまたはイミュータブルな設計を検討する。
- ByRefは最終手段: Windows API呼び出しや、パフォーマンスが極度にクリティカルで、かつ副作用を完全に管理できる場合にのみ、明確な理由をもって`ByRef`を使用する。その際は、徹底的なドキュメント化とテストを怠らないこと。
- レガシーコードへの敬意と警戒: 既存の`ByRef`コードを改修する際は、その影響範囲を慎重に分析し、段階的なアプローチと十分なテストを実施する。
我々は、VBAという強力なツールを手にしている。その力を最大限に引き出し、同時にその脆弱性を理解し制御することで、堅牢で持続可能なシステムを構築できる。この知見が、諸君が直面する課題解決の一助となることを切に願う。
