Select Caseの極限最適化：VB.NETパターンマッチングとメモリ効率の真実
レガシーシステムの保守からモダンな.NET Coreへの移行まで、現場の最前線に立ち続けるエンジニアなら誰もが一度は直面する課題がある。それが「巨大化した条件分岐（Conditional Branching）のメンテナンス性悪化とパフォーマンス劣化」だ。
特にVBAからVB.NETへステップアップした開発者が陥りがちなのが、`If…ElseIf`のネスト地獄、あるいは型安全性を無視した暗黙の型変換によるパフォーマンス低下である。
今回は、VB.NETの`Select Case`文が持つ真のポテンシャルを解放し、`Is`キーワード、`To`演算子、そしてC#譲りのパターンマッチング的アプローチを駆使して、「極限まで可読性が高く、かつCPUサイクルとメモリを無駄に消費しない」スマートな分岐処理のデザインパターンを解説する。
—
1. 従来の `If…ElseIf` が抱える構造的欠陥と `Select Case` の優位性
多重の `If…ElseIf` は、コードのインデントを深くし、認知負荷を跳ね上げるだけでなく、JIT（Just-In-Time）コンパイラによる最適化の恩恵を受けにくいケースがある。
一方、`Select Case` は、コンパイル時に条件の数や種類（値の型）に応じて、ジャンプテーブル（Jump Table）や効率的なバイナリサーチに最適化される。特に定数の比較においては、`If`文の線形探索（上から順に評価していく処理）に比べ、圧倒的な実行速度の優位性を持つ。
レガシーな思考からの脱却：アンチパターン
.net
‘ 【悪夢のIf-ElseIf構造】メンテナンス性とCPU効率の最悪な組み合わせ
If status = 100 Or status = 101 Or status = 102 Then
ProcessRunning()
ElseIf status >= 200 And status <= 299 Then
ProcessSuccess()
ElseIf status >= 400 And status <= 599 And Not isIgnoredError Then
ProcessError()
Else
ProcessUnknown()
End If
このコードは、条件の評価順序が依存しており、将来的な仕様変更でバグの温床になりやすい。これをVB.NETの高度な機能を用いて書き換える。
---
2. `To` と `Is` を駆使した高度な範囲指定
VB.NETの `Select Case` は、単なる「値の一致」にとどまらず、`To` 演算子による範囲指定や、`Is` キーワードによるプレディケート（述語）的な比較をネイティブでサポートしている。これらは内部的に効率的な比較演算子へコンパイルされる。
以下の実務コードを見てほしい。ステータスコードの範囲や、メモリ効率を考慮した文字列操作をスマートに処理する例である。
.net
Imports System.Runtime.CompilerServices
Public Class StatusCodeProcessor
”’
”’
Public Sub HandleStatus(status As Integer, isIgnoredError As Boolean)
Select Case status
‘ 1. 複数値の列挙（OR条件のスマートな表現）
Case 100, 101, 102
ProcessRunning()
‘ 2. To演算子による数値範囲の指定（境界値含む）
Case 200 To 299
ProcessSuccess()
‘ 3. Isキーワードと論理演算子(And/Or)の組み合わせによる動的範囲指定
Case 400 To 599 When Not isIgnoredError
ProcessError()
‘ 4. 不定形な条件（境界値の外側）
Case Is >= 600
ProcessCriticalFailure()
‘ 5. デフォルトフォールバック
Case Else
ProcessUnknown()
End Select
End Sub
Private Sub ProcessRunning() : Console.WriteLine(“Running…”) : End Sub
Private Sub ProcessSuccess() : Console.WriteLine(“Success.”) : End Sub
Private Sub ProcessError() : Console.WriteLine(“Error detected.”) : End Sub
Private Sub ProcessCriticalFailure() : Console.WriteLine(“Critical Failure!”) : End Sub
Private Sub ProcessUnknown() : Console.WriteLine(“Unknown status.”) : End Sub
End Class
チーフアーキテクトの視点：`When` 句（ガード条件）の威力
VB.NET（.NET Framework 4.6.1+ / .NET Core以降）では、`Case` 式に `When` 句を付与できる。これにより、値の範囲だけでなく、外部の状態変数（上記の `isIgnoredError`）を評価に組み込むことが可能になり、無駄な `If` のネストを完全に排除できる。
—
3. 文字列評価におけるメモリ最適化とアロケーション削減
業務システムで頻出するのが、文字列の分岐処理だ。ここで注意すべきは、文字列の比較において不要な大文字小文字変換（`ToUpper()` や `ToLower()`）をその場で行わないことである。これらはヒープ上に一時的なStringオブジェクトをアロケーション（生成）し、ガベージコレクタ（GC）に負荷をかける。
以下のパターンは、メモリ効率を極限まで高めた文字列の `Select Case` 活用術だ。
.net
Public Class CommandRouter
”’
”’
Public Sub RouteCommand(rawCommand As String)
If rawCommand Is Nothing Then Return
‘ 致命的ミス：rawCommand.ToUpper() をCaseで呼ぶと毎回メモリが消費される。
‘ あらかじめ正規化された文字列、またはStringComparisonを意識した設計にする。
‘ ここでは高速かつアロケーションゼロのSpan、あるいはString.Equalsの利用を想定しつつ
‘ Select Case自体の文字列表現力を活用する
Select Case rawCommand.Trim().ToUpperInvariant()
Case “RUN”, “START”, “BEGIN”
ExecuteStart()
Case “STOP”, “HALT”, “ABORT”
ExecuteStop()
Case Else
‘ パターンマッチングの応用：プレフィックス判定
Select Case True
Case rawCommand.StartsWith(“LOG:”, StringComparison.OrdinalIgnoreCase)
ExecuteLog(rawCommand.Substring(4))
Case Else
Throw New NotSupportedException($”Unknown command: {rawCommand}”)
End Select
End Select
End Sub
Private Sub ExecuteStart() : End Sub
Private Sub ExecuteStop() : End Sub
Private Sub ExecuteLog(arg As String) : End Sub
End Class
> アーキテクトの戒め:
> `Select Case True` というイディオムは、一見すると邪道に見えるかもしれない。しかし、「左辺に `True` を置き、各 `Case` に論理式を記述する」この手法は、複雑なAND/OR条件が絡み合うビジネスロジックにおいて、`If-ElseIf` の嵐よりも遥かに美しくコードをカプセル化できる強力な武器となる。
—
4. レガシー環境・相互運用（COM / Windows API）における実務応用
社内システムやデスクトップアプリケーション（Windows Forms / WPF）の現場では、Windows APIのエラーコード（`HRESULT` や `DWORD`）のハンドリングが品質を左右する。
C#にはパターンマッチング（`switch expression`）が導入されたが、VB.NETであっても、ここまで解説した `Select Case` の拡張構文を使いこなすことで、同等以上の保守性とパフォーマンスを確保できる。
以下は、Windows APIの戻り値を安全かつ高速に処理する実務コードの断片である。
.net
Imports System.Runtime.InteropServices
Public NotInheritable Class Win32ApiHelper
‘ Windows APIのインポート例
Public Shared Function GetLastError() As UInteger
End Function
‘ 定数定義
Private Const ERROR_SUCCESS As UInteger = 0UI
Private Const ERROR_ACCESS_DENIED As UInteger = 5UI
Private Const ERROR_OUTOFMEMORY As UInteger = 8UI
”’
”’
Public Sub ProcessApiResult(errorCode As UInteger)
Select Case errorCode
Case ERROR_SUCCESS
‘ 正常系
Exit Sub
Case ERROR_ACCESS_DENIED, 5UI ‘ 冗長な定義の排除
Throw New UnauthorizedAccessException(“アクセスが拒否されました。権限を確認してください。”)
Case ERROR_OUTOFMEMORY
‘ メモリ不足時はGCを強制実行してから例外送出を検討するレベルのクリティカル
GC.Collect()
GC.WaitForPendingFinalizers()
Throw New OutOfMemoryException(“システムリソースが限界に達しています。”)
Case 1200UI To 1299UI ‘ ネットワーク関連エラーのレンジ
LogNetworkError(errorCode)
Case Else
Throw New SystemException($”予期せぬAPIエラーが発生しました。Code: 0x{errorCode:X8}”)
End Select
End Sub
Private Shared Sub LogNetworkError(code As UInteger)
‘ ログ出力処理
End Sub
End Class
—
5. まとめ：コードの品位は「分岐」に宿る
優れたエンジニアと、動くだけのプログラマーを分ける境界線は、「条件分岐の美しさと効率性」にある。
- `To` 演算子 を使ってマジックナンバーや冗長な `AND` 条件を排除する。
- `Is` キーワードと `When` 句 を使って、評価ロジックを宣言的に記述する。
- 文字列比較では メモリのアロケーション（GCプレッシャー） を常に意識し、無駄なオブジェクト生成を避ける。
- ネストの深い `If` から脱却し、コンパイラの最適化を引き出す `Select Case` の構造を設計する。
VB.NETは決して「古い言語」ではない。.NETの進化とともに、その構文の裏側では高度な最適が行われている。この知見を武器に、あなたの手元にあるレガシーなコードベースを、圧倒的に堅牢で高速なシステムへと昇華させてほしい。
