VB.NET型キャストの深層：DirectCast、CType、TryCastの性能特性と極限の使い分け
長年、VBAによるデスクトップ自動化から、数百万行規模のレガシーVB.NETシステム、そして最新の.NET Core環境に至るまで、数多くの企業システムを構築・保守してきた。
その中で、最も頻繁に、かつ無造作に書かれ、システムのパフォーマンス低下や予期せぬクラッシュの温床となっているのが「型キャスト」の処理である。
「とりあえず `CType` を使っておけば動く」
「`Object` 型から戻すときは `DirectCast` が速いらしい」
もし、あなたのコードベースにこのような曖昧な理由でキャストが乱立しているなら、今すぐその手を止めてほしい。型キャストは単なる「型の辻褄合わせ」ではない。CLR（Common Language Runtime）の型システムとメモリ管理のメカニズムを直結させる、きわめてシリアスなアーキテクチャ上の意思決定なのだ。
本稿では、`DirectCast`、`CType`、`TryCast` の3つの演算子について、アセンブリレベルの挙動、パフォーマンスの差、そして実務における鉄則の使い分けを、極限の知見とともに解き明かす。
—
1. 3つのキャスト演算子の本質とCLRレベルの挙動
まずは、それぞれの演算子が内部で何を行っているのか、その「素性」を正確に把握する。
CType：多機能だが「変換のコスト」を払う重鎮
`CType` は、VB.NETの歴史的背景（VB6のなごり）もあり、非常に柔軟な構文だ。
- 継承関係にある型同士の変換はもちろん、
- 値型間の数値変換（例：`Integer` から `Double`）、
- ユーザー定義の型変換演算子（`Widening` / `Narrowing`）の呼び出し
までをひとまとめにこなす。
しかし、この「万能性」の代償として、実行時には型安全性を保つためのオーバーヘッドや、場合によってはボックス化（Boxing）・アンボックス化（Unboxing）、さらにはメソッド呼び出しのコストが発生する。
DirectCast：型チェッカーのメスを入れる高速の刃
`DirectCast` は、.NETの共通型システム（CTS）における「参照型」または「値型」の実行時の型が、指定した型と完全に一致している場合のみ機能する。
- ユーザー定義の変換は一切行わない。
- CLRの `isinst` 命令（型チェック）を伴うが、`CType` のような複雑な解決ロジックを持たないため、パフォーマンスはきわめて高い。
- 型が一致しない場合は即座に `InvalidCastException` をスローする。
TryCast：例外を出さない安全装置
`TryCast` は `DirectCast` の安全な親戚だ。キャストに失敗した場合、例外をスローする代わりに `Nothing` を返す。
「このオブジェクトは本当に目的の型か？」が確信できないポリモーフィックな状況において、例外処理コスト（Performance Hit）を回避するための極めて洗練されたアプローチである。ただし、戻り値が `Nothing` になるため、その後の `Null` チェックが必須となる。
—
2. パフォーマンス比較：なぜ「なんとなくCType」が罪深いのか
実務において、数万件のレコードをループ処理しながらポリモーフィックなコレクション（例：`List(Of Object)` や `ControlCollection`）を操作するシーンは多い。
ここで `CType` を安易に使うことが、どれほどボトルネックになるかを示そう。
以下のベンチマーク的視点を見てほしい。
.net
‘ 【アンチパターン】不必要な場面での CType の乱用
Dim obj As Object = “123”
Dim val As Integer = CType(obj, Integer)
‘ ここでは Object(文字列) から Integer への「値のパース/変換」が発生するため、重い処理が走る。
もし、オブジェクトの型が既に分かっている（あるいは特定のインターフェイスを実装していることが保証されている）にもかかわらず `CType` を使うと、コンパイラは実行時に余分な型変換ロジックを挟み込む。
速度順位の現実
1. `DirectCast` （最速。JITコンパイラが直接的な型キャストIL命令に最適化しやすい）
2. `TryCast` （DirectCastと同等の速度だが、失敗時の `Nothing` 判定分岐が入る）
3. `CType` （最も遅い。変換メソッドの探索や数値のパース処理が内部で発動するため）
—
3. 実務で迷わないための「使い分けの鉄則」
シニアエンジニアとして、チーム全体に徹底させるべき使い分けの基準を明文化する。
| 演算子 | 対象ケース | 失敗時の挙動 | 実務での推奨度 |
| :— | :— | :— | :— |
| `DirectCast` | 継承関係やインターフェイスの実装が100%確実な場合 | `InvalidCastException` | 最優先で使用（速度重視） |
| `TryCast` | キャスト可能か怪しい場合、または「違っていれば無視したい」場合 | `Nothing` を返す | 安全性を担保したい場面で使用 |
| `CType` | 数値型同士の変換（`Integer` to `Double`等）や、明示的な変換演算子がある場合 | `InvalidCastException` / 変換エラー | 型変換が必要な場合のみ限定使用 |
—
4. 実践コード：Windows APIとオブジェクト操作における安全な実装
ここでは、Windows APIのハンドル操作や、レガシーな `Control` コレクションの走査を想定した、実務に耐えうる堅牢なコードを示す。
`InvalidCastException` を完全に防ぎつつ、パフォーマンスを極限まで高めた実装だ。
.net
Imports System.Runtime.InteropServices
Public Class FormOptimizationEngine
‘ Win32 APIの宣言例（IntPtrを駆使する低レイヤー操作）
Private Shared Function GetWindowLong(hWnd As IntPtr, nIndex As Integer) As IntPtr
End Function
Private Const GWL_USERDATA As Integer = -21
”’
”’
Public Sub ProcessContainerControls(container As Control)
For Each rawControl As Object In container.Controls
‘ 【鉄則1】TryCastを使い、型不一致による例外コスト（パフォーマンス低下）を完全に排除する
Dim targetCtrl As ICustomOptimizedControl = TryCast(rawControl, ICustomOptimizedControl)
If targetCtrl IsNot Nothing Then
‘ キャスト成功：安全にポリモーフィックなメソッドを叩く
targetCtrl.ExecuteOptimizedRender()
‘ 【鉄則2】100%型が保証されている内部オブジェクトの取り出しには DirectCast を使用する
Dim nativeHandle As IntPtr = DirectCast(targetCtrl, Control).Handle
‘ Windows API呼び出しの例
Dim userData As IntPtr = GetWindowLong(nativeHandle, GWL_USERDATA)
If userData <> IntPtr.Zero Then
‘ 更なる低レイヤー処理…
End If
Else
‘ 型が一致しない場合のフォールバック（例外を投げずに優雅にスルー）
System.Diagnostics.Debug.WriteLine(“対象外のコントロールスキップされました。”)
End If
Next
End Sub
End Class
”’
”’
Public Interface ICustomOptimizedControl
Sub ExecuteOptimizedRender()
End Interface
このコードのアーキテクチャ的解説
1. `For Each rawControl As Object` の罠への対策
レガシーな `Control.Controls` コレクションは、内部的に `Control` 型を返すものの、古いVBの遺産やCOM相互運用が絡むと `Object` として扱われることが多い。ここで `CType(rawControl, Button)` などと安易に書くと、ボタン以外のコントロール（例：`Label`）が混入した瞬間に `InvalidCastException` が爆発する。
2. `TryCast` による防壁
「もしかしたら違うかもしれない」という不確実性がある境界領域では、必ず `TryCast` を選び、`Nothing` チェックでガードする。これにより、例外オブジェクトの生成・スタックトレースのキャプチャという重たい処理（CLRにとって非常に高コスト）を完全に回避している。
3. 確実な領域での `DirectCast` への切り替え
`targetCtrl` が `Nothing` でないことが証明された瞬間、その実体は確実に `Control` を継承している。そのため、生ハンドル（`Handle`）を取得するフェーズでは、余計な検証を省くために `DirectCast(targetCtrl, Control)` を用い、パフォーマンスを極限まで引き出している。
—
5. チーフアーキテクトからの最終提言
コードの品質は、こうした「細部へのこだわり」の積み重ねによってのみ決まる。
「動けばいい」という妥協の産物は、システムがスケールしたときに必ず牙をむく。
- 型が分かっているなら `DirectCast` で速度を稼ぐ。
- 型が不確実なら `TryCast` で優雅に弾く。
- 数値変換や独自変換が必要なときだけ `CType` を召喚する。
この原則をチームの開発規約に組み込み、レビューの目を光らせること。それこそが、レガシーの呪縛を断ち切り、モダンで高パフォーマンスなVB.NETアーキテクチャを維持唯一の道である。
