Select Case文の極限最適化：If文の巣窟からの脱却と、VBAランタイムの真髄
レガシーシステムの改修現場に足を踏み入れたとき、我々を最初に迎える悪夢は、インデントが右へ右へと暴走した「迷宮のようなIf文のネスト」だ。
‘ 【アンチパターン】保守性を完全に破壊するIfの巣窟
If status = 1 Then
If type = “A” Then
‘ 処理1
Else
‘ 処理2
End If
ElseIf status = 2 Then
If region = “JP” Then
‘ 処理3
End If
Else
‘ 処理4
End If
このようなコードを書くプログラマは、コンパイラの挙動やVBAの内部アーキテクチャについて無知と言わざるを得ない。数多の条件分岐が連鎖する時、VBAの実行エンジンは上から順にすべての条件を評価し、メモリ上で無駄なジャンプ命令を繰り返す。
本稿では、`Select Case`文の本質的なパフォーマンス特性、複数条件や範囲指定のスマートな捌き方、そして極限の現場で求められる堅牢なコード設計について、チーフアーキテクトの視点から徹底的に解説する。
—
1. なぜ `Select Case` なのか？（コンパイルと評価のメカニズム）
多くの開発者は、`Select Case` が単に「見栄えの良い If-ElseIf の糖衣構文（シンタックスシュガー）」だと勘違いしている。それは大きな誤りだ。
評価式の単一評価（Single Evaluation）
If文で複数の条件を書く場合、各行で変数や関数が何度も評価されるリスクがある。
例えば、`If GetStatus() = 1 Then … ElseIf GetStatus() = 2 Then …` と書いた場合、`GetStatus()` という重い関数（外部API呼び出しやシート検索など）が条件の数だけ実行される可能性が生まれる。
一方、`Select Case` は、最初に評価式を一度だけ評価し、その結果をメモリ上に保持した状態で各 `Case` 節との比較を行う。
‘ 【高効率】GetStatus() は1度しか実行されない
Select Case GetStatus()
Case 1
‘ 処理A
Case 2, 3
‘ 処理B（複数の値を一括評価）
Case Else
‘ 処理C
End Select
この「一度だけ評価して保持する」という挙動こそが、大規模なデータ処理や複雑なステータス判定において、実行速度のボトルネックを解消する最大の武器となる。
—
2. 実践：複雑な条件分岐を美しくスラッシュするパターン集
現場で即座に使える、`Select Case` の高度な活用パターンを提示する。
パターンA：範囲指定（Toキーワード）と条件比較（Isキーワード）
数値や日付の範囲判定において、`And` や `Or` を乱用したIf文を書くのは愚の骨頂だ。`To` や `Is` を組み合わせることで、人間の脳の認知負荷を劇的に下げることができる。
Public Sub EvaluatePerformance(ByVal score As Integer)
Select Case score
Case Is < 0, Is > 100
‘ 異常値のガード節
Err.Raise 9999, , “スコアが不正な範囲です。”
Case 90 To 100
Debug.Print “評価：S（極めて優秀）”
Case 70 To 89
Debug.Print “評価：A（良好）”
Case 50 To 69
Debug.Print “評価：B（要改善）”
Case Else
Debug.Print “評価：C（不合格）”
End Select
End Sub
パターンB：文字列のワイルドカード比較
VBAの `Select Case` は、文字列のパターンマッチングもサポートしている。ファイル名やログの解析において、正規表現を持ち出すまでもない簡易的なフィルタリングにはこれが最適解となる。
Public Sub ParseLogLine(ByVal logMessage As String)
Select Case logMessage
Case “INFO:”
‘ INFOで始まるログの処理
Call ProcessInfoLog(logMessage)
Case “ERROR:DB_”, “ERROR:API_”
‘ データベースまたはAPI関連のエラー処理
Call NotifyCriticalError(logMessage)
Case Else
‘ その他
Call ProcessStandardLog(logMessage)
End Select
End Sub
—
3. レガシーシステムとシステム間連携における実用アーキテクチャ
外部APIとの連携や、レガシーなCOMコンポーネント（ADODBやExcelシート間のデータ同期など）を扱うシステムでは、エラーハンドリングとステータス管理が命綱となる。
以下のコードは、APIからのレスポンスコード（HTTPステータスなど）と、自前の業務エラーコードを `Select Case` で完全に分離・制御する堅牢なプロシージャのテンプレートである。メモリの無駄な消費を防ぐため、オブジェクトのライフサイクルにも配慮している。
Public Sub ExecuteSystemIntegration(ByVal apiEndpoint As String)
Dim http As Object
Dim responseCode As Long
‘ オブジェクトの遅延バインディングによる環境依存の排除（または事前バインディング）
Set http = CreateObject(“MSXML2.ServerXMLHTTP.6.0”)
On Error GoTo ErrorHandler
http.Open “GET”, apiEndpoint, False
http.send
responseCode = http.status
‘ ステータスコードに基づく厳密な分岐処理
Select Case responseCode
Case 200
‘ 正常系：データのパース処理へ
Call ParseJsonResponse(http.responseText)
Case 400, 404
‘ クライアントエラー：ログ出力して処理を安全に中断
Call LogMessage(“Client Error detected. Status: ” & responseCode)
Exit Sub
Case 500 To 599
‘ サーバーサイドエラー：リトライシーケンスへ移行
Call ExecuteRetrySequence(apiEndpoint)
Case Else
‘ 予期せぬステータス
Err.Raise vbObjectError + 1000, “API連携”, “未定義のHTTPステータス: ” & responseCode
End Select
CleanUp:
‘ 【メモリ最適化】COMオブジェクトの明示的解放
‘ VBAのガベージコレクタを信用せず、スコープを抜ける前に必ずNothingを代入する
If Not http Is Nothing Then Set http = Nothing
Exit Sub
ErrorHandler:
MsgBox “システムエラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
—
4. チーフアーキテクトからの提言：可読性と保守性の境界線
`Select Case` をどれほど極めても、一つのプロシージャ内に50行も100行も `Case` が並ぶようであれば、それは単に「巨大な単一責任の原則（SRP）違反」という別の病巣を生み出しているに過ぎない。
もし条件分岐の各ケース内の処理が肥大化する場合は、「ポリモーフィズム（クラスモジュール）」の導入を検討すべきだ。VBAであっても、インターフェース的振る舞いを利用して処理を委譲する設計が可能である。
しかし、日々の業務自動化や、数千行規模の既存VBAツールのリファクタリングにおいて、まずは If文のネストを撲滅し、`Select Case` によるフラットで直感的な条件分岐に置き換えること。これだけで、コードのバグ率は半減し、後任のエンジニアからの呪詛の言葉を感謝の言葉に変えることができる。
コードは美しく、論理的で、そしてコンパイルの効率まで計算されていなければならない。今日からあなたのマクロの `If…ElseIf` をすべて `Select Case` の高みへと昇華させよ。
