オブジェクト変数の初期化忘れを防ぐ：クラスのInitializeイベント活用法
VBA（Visual Basic for Applications）の現場において、`Object variable or With block variable not set`（実行時エラー 91）ほど、開発者の時間を無駄に奪うエラーはない。
特に、大規模な業務システムや、複数のクラスモジュールが協調動作するアーキテクチャにおいて、インスタンスの生成漏れや、プロパティの遅延初期化の失敗は、プロダクション環境での致命的な障害に直結する。
今回は、標準モジュールや場当たり的な `If obj Is Nothing` のチェックという悪しき習慣を排除し、クラスの `Class_Initialize` イベントを完全に掌握することで、オブジェクトの初期化漏れを構造的に根絶する極限の設計パターンを解説する。
—
1. なぜ「使う直前のNullチェック」は悪手なのか
多くの初中級プログラマは、オブジェクト変数を使用する直前に以下のようなコードを書く。
‘ 悪臭を放つアンチパターン
If theService Is Nothing Then
Set theService = New BusinessService
End If
theService.Execute
このアプローチは一見して安全に見えるが、アーキテクチャの観点からは以下の重大な問題点を抱えている。
1. 責任の分散とコードの肥大化: オブジェクトを消費するすべてのクライアント側で、初期化の有無を気にし続けなければならない。
2. 不変条件（Invariants）の崩壊: 「このクラスは常に有効な内部リソースを持つ」という前提が崩れ、システム全体の状態が予測不可能になる。
3. メモリとAPIハンドルのリーク: 初期化のタイミングが散在すると、多重インスタンス化や解放忘れの温床となる。
シニアエンジニアリングの原則において、「不正な状態のオブジェクトを絶対に生成させない（Make illegal states unrepresentable）」ことは鉄則である。これをVBAで実現する唯一の鍵が、クラスモジュールのライフサイクルイベントである。
—
2. `Class_Initialize` による自己防衛型クラスの設計
VBAのクラスモジュールには、インスタンス生成時に自動発火する `Class_Initialize` が存在する。これを利用し、「生成と同時に必須リソースやデフォルト値を強制バインドする」構造を構築する。
ここでは、実務で遭遇しやすい「Windows APIのハンドル管理」および「内部コレクションの初期化」を内包した、堅牢なクラスの実装例を示す。
実装例：安全なリソース管理クラス (`SecureConnection.cls`)
VERSION 1.0 CLASS
BEGIN
MultiUse = -1 ‘True
END
Attribute VB_Name = “SecureConnection”
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False
Option Explicit
‘ Windows API宣言（メモリ最適化とシステム連携の例）
If VBA7 Then
Private Declare PtrSafe Function GetTickCount Lib “kernel32” () As Long
Else
Private Declare Function GetTickCount Lib “kernel32” () As Long
End If
‘ 内部保持するオブジェクト変数
Private m_InternalCache As Collection
Private m_SessionID As Long
‘ ==========================================================
‘ コンストラクタ (Initialize イベント)
‘ ==========================================================
Private Sub Class_Initialize()
On Error GoTo ErrorHandler
‘ 1. 内部コレクションの確実な初期化（NullReferenceの根絶）
Set m_InternalCache = New Collection
‘ 2. システム連携に必要な初期値の割り当て（APIからの値取得など）
m_SessionID = GetTickCount()
‘ 3. ログ記録や初期トレース
Debug.Print “SecureConnection: Initialized at Tick = ” & m_SessionID
Exit Sub
ErrorHandler:
‘ 初期化失敗時は致命的エラーとして上位へ伝播させる
Err.Raise vbObjectError + 1001, “SecureConnection”, “初期化に失敗しました: ” & Err.Description
End Sub
‘ ==========================================================
‘ デストラクタ (Terminate イベント)
‘ ==========================================================
Private Sub Class_Terminate()
‘ 明示的な参照の解放とメモリ最適化
If Not m_InternalCache Is Nothing Then
‘ コレクションの中身をクリア
Dim i As Long
For i = m_InternalCache.Count To 1 Step -1
m_InternalCache.Remove i
Next i
Set m_InternalCache = Nothing
End If
Debug.Print “SecureConnection: Terminated and Memory Released.”
End Sub
‘ ==========================================================
‘ パブリックプロパティ・メソッド
‘ ==========================================================
Public Property Get SessionID() As Long
SessionID = m_SessionID
End Property
Public Sub AddData(ByVal Key As String, ByVal Value As Variant)
‘ m_InternalCache は Initialize で確実に New されているため、
‘ ここで Is Nothing チェックを行う必要は一切ない。
m_InternalCache.Add Value, Key
End Sub
—
3. この設計がもたらす圧倒的なメリット
上記の `SecureConnection` クラスを呼び出す側のコードを見てほしい。
Sub ClientRoutine()
‘ インスタンス化の瞬間に、Initializeが走り、内部のCollectionやAPI値の取得が保証される
Dim conn As SecureConnection
Set conn = New SecureConnection
‘ クライアント側は「初期化されているか？」を気にする必要がゼロになる
conn.AddData “Key001”, “Enterprise Data”
Debug.Print “Active Session: ” & conn.SessionID
‘ スコープアウト時のTerminateによる自動解放
Set conn = Nothing
End Sub
チーフアーキテクトの知見：なぜこれが「極限の最適化」なのか
1. 防御的コードの排除による高速化:
すべてのメソッド内で `If obj Is Nothing` の条件分岐を記述すると、数千回のループ内では無視できないオーバーヘッドとなる。初期化を保証することで、分岐命令そのものを排除できる。
2. メモリリークの完全防御:
VBAのガベージコレクション（参照カウント方式）は循環参照に弱い。しかし、`Class_Initialize` で生成したリソースを `Class_Terminate` で対にして確実に解放する規しきを徹底すれば、レガシー環境特有のリソース枯渇を完璧に防げる。
3. 保守性の飛躍的向上:
将来的に「初期化時に設定ファイルを読む」という仕様変更が生じた場合でも、修正すべき箇所は `Class_Initialize` の内部だけで完結する。呼び出し側のコードベースを一切汚染しない。
—
4. レガシー環境・大規模システムにおける実践的注意点
長年稼働しているVBAシステムをリファクタリングする際、以下の罠に陥ることがある。
- オブジェクトの遅延バインディング（CreateObject）との併用注意:
外部COMコンポーネントを操作する場合、インスタンス生成直後にAPIエラーが発生することがある。`Class_Initialize` 内で外部リソースを叩く場合は、必ず `On Error` による堅牢なエラーハンドリングを記述し、不完全なインスタンスが野放図に生成されるのを防ぐこと。
- グローバル変数やUDFでのインスタンス保持の危険性:
ワークシートの数式から呼び出されるユーザー定義関数（UDF）内でインスタンスを乱立させると、Excelの再計算サイクルごとに無駄な初期化・解放が発生し、パフォーマンスが崩壊する。このような文脈では、シングルトンパターンや静的スコープの活用を検討すべきである。
—
結びにかえて
VBAは、その手軽さゆえに「動けばいい」という場当たり的なコードが蔓延しやすい言語だ。しかし、真に堅牢なエンタープライズ・アプリケーションを構築するためには、言語仕様の裏側にあるオブジェクトのライフサイクル（生成・生存・消滅）を完全に支配下に対象に置く必要がある。
`Class_Initialize` を制する者は、VBAのメモリ管理とエラーハンドリングを制する。
今日からあなたの書くクラスモジュールにコンストラクタの概念を導入し、「未初期化エラー」という呪縛から完全に脱却してほしい。
