VB.NETにおける実行時型情報（RTTI）の極意：GetTypeとTypeOf…Isの境界線と実務最適化
オブジェクト指向プログラミングの美徳はポリモーフィズム（多態性）にある。共通のインターフェースや基底クラスを定義し、具象クラスの差異を隠蔽して呼び出す。これは教科書通りの正論だ。
だが、現場の現実は残酷である。
レガシーシステムとの統合、サードパーティ製COMコンポーネントのラップ、あるいは非構造化データ（JSON等）の動的バインディングの渦中において、「今、目の前にあるオブジェクトの正確な型は何なのか」を暴く必要に迫られる瞬間は必ず訪れる。
VB.NETには、実行時型情報（RTTI: Run-Time Type Information）を扱うための強力な武器が用意されている。それが `GetType` 演算子（および `GetType()` メソッド）と `TypeOf…Is` 演算子だ。
本稿では、これら二つのメカニズムの本質的な違い、パフォーマンスへの影響、そしてWindows API連携やメモリ管理が絡む過酷なエンタープライズ環境における実践的な活用知見を、チーフアーキテクトの視点から叩き込む。
—
1. `TypeOf…Is` と `GetType` の決定的な違い
まずは基本を整理する。多くのジュニアプログラマーがこの二つを混同し、パフォーマンスを劣化させたり、思わぬバグを生み出したりしている。
- `TypeOf…Is` 演算子:
オブジェクトが特定の型、あるいはその派生型（継承チェーン）であるかを評価する。内部的には `is` 演算子（C#）と同等であり、型階層を考慮した安全な多態性チェックに向いている。
- `GetType` 演算子 / `GetType()` メソッド:
コンパイル時または実行時に、そのオブジェクトの完全修飾された厳密な型（Typeオブジェクト）を取得する。継承関係を無視し、「型が完全に一致するかどうか」を厳密に比較する際に用いる。
パフォーマンスとガベージコレクションの重み
`GetType` は `System.Type` インスタンスを返す。これはマネージドヒープ上にアロケーションが発生する可能性を秘めており、頻繁なループ内での `GetType().Name` のような文字列比較は、GC（ガベージコレクション）に無駄な負荷をかける。
一方、`TypeOf…Is` はJITコンパイルされた型メタデータのポインタ比較に近い形で処理されるため、圧倒的に高速である。
—
2. 実務における使い分け：ポリモーフィズムの限界を突破する
エンタープライズの現場では、異なるベンダーが提供するCOMオブジェクトや、構造の異なるDTO（Data Transfer Object）を単一の `Object` 型のコレクションとして受け取らざるを得ないシーンがある。
以下のコードは、動的に渡された未知のオブジェクト群を安全に処理しつつ、特定のレガシーデータ構造に対してのみWin32 APIを叩く特殊な処理を行う実践的アーキテクチャの断片である。
Imports System.Runtime.InteropServices
Public Class RTTIController
‘ メモリ最適化と安全な型判定を行う処理ルーチン
Public Sub ProcessDynamicPayload(ByVal rawData As Object)
If rawData Is Nothing Then Exit Sub
‘ 1. 高速な継承・実装チェック (TypeOf…Is)
‘ 共通インターフェース ILegacyData を実装しているか
If TypeOf rawData Is ILegacyData Then
Dim legacyObj As ILegacyData = DirectCast(rawData, ILegacyData)
legacyObj.ExecuteStandardSync()
Return
End If
‘ 2. 厳密な型一致チェック (GetType)
‘ サードパーティ製の特殊なCOMラッパー構造体（派生を許さない型）をピンポイントで捕捉
Dim targetType As Type = rawData.GetType()
If targetType Is GetType(Com.Vendor.LegacyStructWrapper) Then
‘ 厳密に型が一致する場合のみ、低レベルなアンマネージド処理へ橋渡し
HandleUnmanagedPayload(rawData)
Return
End If
‘ 3. 想定外の型に対するフォールバック
Throw New InvalidCastException($”サポートされていないペイロード型です: {targetType.FullName}”)
End Sub
Private Sub HandleUnmanagedPayload(ByVal obj As Object)
‘ GCHandleを用いたメモリのピン留めとWin32 API連携のシミュレーション
Dim handle As GCHandle = GCHandle.Alloc(obj, GCHandleType.Pinned)
Try
Dim ptr As IntPtr = handle.AddrOfPinnedObject()
‘ 例: 外部のアンマネージドDLL（C++製等）へポインタを渡す
‘ NativeMethods.SendToLegacySystem(ptr)
Finally
‘【極限の知見】アンマネージド・マネージド境界でのメモリリーク阻止
‘ GCHandleは必ず明示的に解放しなければならない
If handle.IsAllocated Then
handle.Free()
End If
End Try
End Sub
End Class
Public Interface ILegacyData
Sub ExecuteStandardSync()
End Interface
コードの解説とアーキテクトの視点
1. `TypeOf…Is` による高速フィルタリング: 標準的なインターフェース実装であれば、継承関係を考慮する `TypeOf…Is` を使い、分岐コストを最小化している。
2. `GetType` による完全一致: サードパーティ製ライブラリのバージョン差異などにより、意図しない派生型やモックオブジェクトが混入するリスクを防ぐため、`targetType Is GetType(…)` で厳密な一致を担保している。
3. `GCHandle` の明示的解放 (`Finally` ブロック): 型判定を経てアンマネージド領域へ踏み込む際、メモリのピン留めを行う。VB.NETと言えども、COMやP/Invokeが絡む領域では、デベロッパー自身がリライフサイクルを完全に制御する気概が不可欠である。
—
3. レガシー保守とパフォーマンスチューニングの鉄則
VB.NETシステム（特にWindows FormsやWCFをベースにした老舗基幹系）において、RTTIを乱用すると「見えないボトルネック」に足元をすくわれる。以下の鉄則を遵守せよ。
鉄則1: ループ内での `GetType().Name` 比較の禁止
文字列の比較（`If obj.GetType().Name = “MyClass” Then`）は、文字列のハッシュ計算とアロケーションが発生するため、極めて低速である。
型比較を行う場合は、必ず `GetType(MyClass)` との参照比較（`Is` 演算子）を使用せよ。
‘ 【悪臭を放つアンチパターン】
‘ For Each item In heavyCollection
‘ If item.GetType().Name = “SpecialData” Then ‘ 文字列生成と比較のオーバーヘッドが蓄積する
‘ …
‘ End If
‘ Next
‘ 【洗練されたベストプラクティス】
Dim targetType As Type = GetType(SpecialData)
For Each item In heavyCollection
If item IsNot Nothing AndAlso item.GetType() Is targetType Then
‘ 高速な参照同一性チェック
End If
Next
鉄則2: `TryCast` との組み合わせによる最適化
型判定を行ってからキャストするというコードは、冗長であるだけでなく、オブジェクトの型チェックを2回実行することになりかねない。
VB.NETの `TryCast` を使用し、キャストの成否と変数への代入を1アトミックな操作として処理するのがスマートだ。
‘ TypeOfで確認してからDirectCastする冗長なコードを避ける
Dim typedObj As SpecificClass = TryCast(rawObject, SpecificClass)
If typedObj IsNot Nothing Then
‘ キャスト成功時の処理（型判定コストが1回で済む）
typedObj.ExecuteHighSpeedRoutine()
End If
—
結びにかえて
VB.NETは、その歴史の長さゆえに「古い言語」とやゆされることがある。しかし、言語仕様の背後にある .NET Runtime（CLR）のメカニズムを深く理解したエンジニアが操るVB.NETは、C#と遜色ない、あるいはそれ以上にシビアなメモリ管理と堅牢性を発揮する。
`GetType` と `TypeOf…Is` は、単なる条件分岐の道具ではない。それは、オブジェクトの生存戦略を見極め、安全な領域と危険なアンマネージド領域の境界線を引くための「知性のメス」である。
このメスを正確無比に使いこなし、極限まで最適化されたコードベースを構築することこそが、真のプロフェッショナル・アーキテクトの仕事である。
