【テクニカル・上級編】VB.NETのDirectCastとCType、TryCastの性能差と使い分け：安全な型キャストでInvalidCastExceptionを防ぐ – Visual Basic (VB / VB.NET)解析バイブル

VB.NETキャストの極意：DirectCast・CType・TryCastの内部挙動とパフォーマンスの境界線

レガシーなVB 6（VBA）の呪縛から脱却し、真の.NETオブジェクト指向アーキテクチャを構築するにあたり、避けて通れないのが「型キャスト（Type Casting）」の最適化である。

多くの開発者は、オブジェクト型（`Object`）やインターフェース型から具象型へダウンキャストする際、深く考えずに `CType` を叩いている。あるいは、安全性を求めて何でも `TryCast` で受け、後続で `Is Nothing` のチェックを乱発している。

シニアアーキテクトよ、目を覚ませ。
その「なんとなくのキャスト」が、GC（ガベージコレクション）のプレッシャーを高め、インターフェースディスパッチのオーバーヘッドを生み、ミリ秒を争う高頻度バッチ処理やWin32 API連携のパフォーマンスを静かに蝕んでいるのだ。

今回は、`DirectCast`、`CType`、`TryCast` の3者の内部動作（ILとCLRの挙動）を丸裸にし、システムに一滴の無駄も残さないための極限の知見を共有する。

—

1. キャスト3兄弟の内部挙動とアーキテクチャ

まずは、これら3つの構文が共通言語ランタイム（CLR）および中間言語（IL）レベルで何を行っているのか、その本質を理解しなければならない。

DirectCast：厳格さと圧倒的な速度

`DirectCast` は、CLRの `castclass` IL命令に直接コンパイルされる。余計な変換ロジックの介入を一切許さず、「指定された型とオブジェクトの実行時型が完全に一致（または継承関係にある）」ことを一瞬で検証する。
パフォーマンスは最速だが、型が一致しない場合は容赦なく `InvalidCastException` が飛ぶ。

CType：柔軟性の代償としてのオーバーヘッド

`CType` は、Visual Basic特有の「融通の利く」演算子である。単なる型キャストだけでなく、プリミティブ型同士の変換（例: `Integer` から `Double`）や、ユーザー定義の型変換演算子（`Narrowing` / `Widening`）の呼び出しを伴う。
そのため、裏で余分なメソッド呼び出しやボクシング/アンボクシングが発生するリスクがあり、純粋なオブジェクトのダウンキャストにおいては `DirectCast` よりもオーバーヘッドが大きい。

TryCast：例外コストを回避する安全弁

`TryCast` は、CLRの `isinst` 命令を使用する。型が一致すればキャスト後の参照を返し、一致しなければ例外を発生させずに `Nothing` を返す。
「例外をスロー・キャッチするコスト」は.NETにおいて非常に重いため、型が不確実な場合（例えば、プラグイン構造やリフレクション、レガシーCOMオブジェクトの相互運用など）において、例外制御フローを回避するための極めて有効な手段となる。

—

2. 【実証】パフォーマンスとメモリ効率の現実

百聞は一見にしかず。以下のコードを見てほしい。大規模なコレクションや、高頻度で呼び出されるWindows APIのコールバック、イベントハンドラー内で `Object` 型として渡された引数を処理する際のベンチマーク的観点を含んだ実装例だ。

Imports System.Diagnostics

Public Class CastBenchmark

‘ 高速な処理を想定したダミーの基底クラスと派生クラス
Public Class BaseNode
End Class

Public Class DerivedNode
Inherits BaseNode
Public Sub Execute()
‘ 何らかの高速処理
End Sub
End Class

Public Shared Sub RunTest()
Dim obj As Object = New DerivedNode()
Dim sw As Stopwatch = New Stopwatch()
Const iterations As Integer = 10000000

‘ — 1. DirectCast の計測 —
sw.Start()
For i As Integer = 0 to iterations – 1
Dim node As DerivedNode = DirectCast(obj, DerivedNode)
Next
sw.Stop()
Console.WriteLine($”DirectCast: {sw.ElapsedMilliseconds} ms”)

‘ — 2. CType の計測 —
sw.Restart()
For i As Integer = 0 to iterations – 1
Dim node As DerivedNode = CType(obj, DerivedNode)
Next
sw.Stop()
Console.WriteLine($”CType: {sw.ElapsedMilliseconds} ms”)

‘ — 3. TryCast の計測 —
sw.Restart()
For i As Integer = 0 to iterations – 1
Dim node As DerivedNode = TryCast(obj, DerivedNode)
Next
sw.Stop()
Console.WriteLine($”TryCast: {sw.ElapsedMilliseconds} ms”)
End Sub

End Class

チーフアーキテクトの考察

DirectCast は、型が保証されている環境において最もオーバーヘッドが少ない。IL命令レベルで最適化されているため、ループ内であってもCPUパイプラインを阻害しない。
CType は、オブジェクト階層のダウンキャストであっても、背後で「ユーザー定義変換が存在するかどうか」の判定ロジックが働くため、わずかだが確実に `DirectCast` より遅い。
TryCast は、`isinst` 命令のコストに加え、戻り値が `Nothing` かどうかの分岐（JITコンパイラによる最適化はあるものの）が入るため、型が確実に分かっているシーンで使うべきではない。

—

3. 現場で使えるベストプラクティスと使い分けの鉄則

レガシーシステムのリファクタリングや、堅牢性が求められる基幹システムにおいて、どのようにこれらを使い分けるべきか。以下の「黄金律」をチームのコーディング規約として徹底してほしい。

鉄則1：型が100%確実な場合は、迷わず `DirectCast` を使え

イベントハンドラの `sender As Object` や、自前のコレクションから取り出した要素など、「設計上、このオブジェクトはこの型以外ありえない」と断言できる場合は、`DirectCast` を使用する。
これにより、意図しない型混入のバグを早期（実行時即座）に検知でき、パフォーマンスも最大化される。

‘ 【正しい例】Windows APIのコールバックやコントロールのイベント内
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
‘ senderがButtonであることは絶対的なのでDirectCast
Dim btn As Button = DirectCast(sender, Button)
btn.Text = “Processing…”
End Sub

鉄則2：型が流動的な場合、あるいは安全なフォールバックが必要な場合は `TryCast` を使え

プラグイン構造、JSONやXMLの動的なシリアライズ結果のデシリアライズ、あるいはレガシーなCOMオブジェクト（Excel VBA等からのInterop経由のオブジェクトなど）を扱う場合、型が期待通りでない可能性が常に存在する。
このようなケースで `CType` や `DirectCast` を使うと、`InvalidCastException` が発生してプロセスがクラッシュするリスクがある。`TryCast` を用いてガード節を構築せよ。

‘ 【正しい例】外部連携や動的オブジェクトの安全な処理
Public Sub ProcessComObject(comObj As Object)
‘ COMオブジェクトの型安全なダウンキャスト
Dim excelSheet As Excel.Worksheet = TryCast(comObj, Excel.Worksheet)

If excelSheet Is Nothing Then
‘ 例外を発生させずに、安全にエラーハンドリングやログ出力を行う
System.Diagnostics.Trace.WriteLine(“渡されたオブジェクトはワークシートではありません。”)
Return
End If

‘ 安全に処理を続行
excelSheet.Cells(1, 1).Value = “Data”
End Sub

‘ ❌【アンチパターン】TryCastの結果をチェックせずに使う
‘ Dim sheet = TryCast(comObj, Excel.Worksheet)
‘ sheet.Name = “Test” ‘ sheetがNothingの場合、NullReferenceExceptionの嵐となる！

鉄則3：プリミティブ型変換やカスタム構造体には `CType` を使え

オブジェクトの参照型キャストではなく、`Integer` から `Long`、あるいは独自の `Narrowing / Widening` 演算子を定義した構造体・クラス間の変換には、そもそも `DirectCast` や `TryCast` はコンパイルエラーになる。ここでは `CType`（またはVBのC#風キャスト関数 `CInt`, `CStr` 等）を使用する。

—

4. レガシー環境・Win32 API連携におけるメモリ最適化の極意

最後に、レガシーシステムとの統合や、ネイティブAPI（`DllImport`）を叩く極限の最適化が求められる現場の知見を授ける。

VB.NETから非マネージドなポインタや、COMインターフェースを扱う際、不要なキャストの連発や、それによる不必要なオブジェクトのボックス化（Boxing）は、GCのヒープ領域に負荷をかけ、Gen 0/1/2のGC一時停止（Stop-the-world）を引き起こす原因となる。

1. `Option Strict On` は絶対の前提
アーキテクトとして言及するまでもないが、`Option Strict Off` の世界では、すべてのキャストが実行時バインディング（Late Binding）の温床となり、`CType` すら機能しないレベルのパフォーマンス劣化を引き起こす。常に `On` にし、型安全性をコンパイラに強制させよ。
2. Win32 APIの `IntPtr` と `Marshal` 操作におけるキャスト
APIから返る `IntPtr` や `Integer` のハンドルを構造体にマッピングする際、無駄な `CType` を挟むとパフォーマンスが落ちる。 `DirectCast` による参照の再解釈や、`Marshal.PtrToStructure` の適切な型指定を活用し、ランタイムの型チェックコストを最小限に抑えること。

—

結論

キャスト構文の選択は、単なる「コーディングスタイルの好み」ではない。それはアプリケーションのパフォーマンス、スケーラビリティ、そして堅牢性を左右するアーキテクチャの根幹である。

迷ったら、まずは `DirectCast` の適用を検討せよ（最速・厳格）。
型が不確実な外部境界では `TryCast` で優しく受け止めよ（安全・例外回避）。
プリミティブやカスタム型変換には `CType` を使え（柔軟性）。

この原則を血肉とし、一滴の無駄もない洗練されたVB.NETコードベースを築き上げてほしい。