実行時型情報の極意：`GetType`と`TypeOf…Is`でポリモーフィズムの限界を突破する
オブジェクト指向設計の教科書を開けば、決まってこう書かれている。「型判定を行うな。ポリモーフィズムを使え」と。
まったくその通りだ。基底クラスやインターフェースに定義された仮想メソッド（Overridable / MustOverride）を呼び出し、具象クラスに処理を委譲するのがオブジェクト指向の美徳であり、拡張性を担保する王道である。
しかし、我々が日々向き合う「業務アプリケーションの現場」はどうだろうか？
外部からJSONやXMLなどのスキーマレスなデータが流れ込み、動的に生成されたオブジェクト群をさばき、Excelファイルやリ relational データベース（RDB）へバルクインサートする――。こんな泥臭い要件の前では、綺麗ごとだけのポリモーフィズムはたびたび息切れを起こす。
「このオブジェクトが特定の型である場合のみ、固有のプロパティを安全に抽出したい」
「動的に渡された未知の型リストから、特定の構造を持つものだけをフィルタリングしたい」
このような、ポリモーフィズムの網の目をすり抜けるエッジケースにおいて、VB.NETの実行時型情報（RTTI: Run-Time Type Information）である `GetType` と `TypeOf…Is` は、開発者の強力な武器となる。
今回は、これら二つのメカニズムの本質的な違いを見極め、バグを生まない堅牢な実務コードへと昇華させる極意を伝授しよう。
—
1. `TypeOf…Is` と `GetType` の決定的な違い
まずは、この二つの違いを曖昧に理解したままコードを書く悪癖を断ち切ろう。
- `TypeOf expression Is Type`
- 評価タイミング: 実行時（Runtime）
- 特徴: 指定されたオブジェクトが、特定の型（あるいはその派生型、インターフェースの実装型）であるかを `Boolean` で返す。
- 主用途: 条件分岐。ポリモーフィズムの原則から「どうしても逸脱せざるを得ない例外的な型処理」のガード節に使う。
- `GetType(Type)`
- 評価タイミング: コンパイル時（厳密には型トークンとして処理される）
- 特徴: クラスや構造体のメタデータ（`System.Type` オブジェクト）そのものを取得する。
- 主用途: リフレクションの起点、DIコンテナへの型登録、シリアライゼーションの制御。インスタンスが手元にない「型そのもの」を比較・操作したい場合に使う。
⚠️ アンチパターン：不毛な型比較
初心者にありがちなのが、以下のような冗長なコードだ。
.net
‘ 【悪例】GetTypeを使った無駄に冗長な型チェック
If obj.GetType().Equals(GetType(MyClass)) Then
‘ 処理…
End If
`GetType().Equals()` は、派生型を考慮しない（厳密にその型枠と一致しなければFalseになる）うえに、`obj` が `Nothing` の場合に NullReferenceException を引き起こす地雷コードだ。
継承関係を正しくポリorphicに判定したい場合、あるいは安全に安全を期したい場合は、後述する `TypeOf…Is` や `TryCast` を使うべきである。
—
2. 実務で直面する課題：異種混合オブジェクトの安全なフィルタリング
例えば、ファイルやDBから読み込んだ「設定値やトランザクションデータの詰め合わせ（`Object` 型のリスト）」から、特定のデータ構造体だけを安全に抽出し、一括処理するバッチモジュールを想像してほしい。
ここで `DirectCast` を安易に使えば、型不一致による `InvalidCastException` が発生し、夜間バッチは容赦なくクラッシュする。
以下のプロダクションコードを見てほしい。ここでは、`TypeOf…Is` による安全な型判定と、VB.NETの隠れた名機能であるパターンマッチング（VB 16.0 / .NET Core以降）を組み合わせた、極めて堅牢な実装を示す。
堅牢なデータ処理エンジンのサンプルコード
.net
Imports System
Imports System.Collections.Generic
Imports System.Linq
Namespace Enterprise.Automation
‘ 基底インターフェース
Public Interface IRecordData
Property Id As String
End Interface
‘ 具体的なデータ型A
Public Class CustomerRecord
Implements IRecordData
Public Property Id As String Implements IRecordData.Id
Public Property CompanyName As String
End Class
‘ 具体的なデータ型B
Public Class OrderRecord
Implements IRecordData
Public Property Id As String Implements IRecordData.Id
Public Property Amount As Decimal
End Class
Public NotInheritable Class DataProcessor
”’
”’
Public Sub ProcessMixedData(rawDataSource As IEnumerable(Of Object))
If rawDataSource Is Nothing Then Throw New ArgumentNullException(NameOf(rawDataSource))
For Each item In rawDataSource
‘ 1. TypeOf…Is を使った安全なガード節（またはVBのTypeOf…Isパターン）
If TypeOf item Is IRecordData Then
‘ 2. 処理のパフォーマンスと安全性を両立させる TryCast の併用
‘ （一度の判定でキャストまで行いたい場合の常套手段）
Dim record = TryCast(item, IRecordData)
If record IsNot Nothing Then
DispatchRecord(record)
End If
Else
‘ 想定外の型が混入している場合のログ監査（業務アプリでは必須）
Console.WriteLine($”[WARN] 未知の型が検出されました: {If(item?.GetType().FullName, “Null”)}”)
End If
Next
End Sub
”’
”’
Private Sub DispatchRecord(record As IRecordData)
‘ VB.NET 16.0以降（Visual Studio 2019+ / .NET Core）でのTypeOf Is 型推論パターン
Select Case record
Case Dim c As CustomerRecord
Console.WriteLine($”[顧客処理] ID: {c.Id}, 企業名: {c.CompanyName}”)
‘ 顧客固有のデータベース保存処理など…
Case Dim o As OrderRecord
Console.WriteLine($”[受注処理] ID: {o.Id}, 金額: {o.Amount:C}”)
‘ 受注固有のデータベース保存処理など…
Case Else
Console.WriteLine($”[情報] 未知のIRecordData実装体: {record.Id}”)
End Select
End Sub
End Class
End Namespace
—
3. データベース・ファイル連携におけるパフォーマンスと注意点
業務自動化ツールにおいて、RTTI（リフレクションや型判定）を多用する際に最も警戒すべきは 「パフォーマンスの劣化」 と 「メモリリーク（型メタデータのキャッシュ枯渇）」 だ。
① ループ内での過剰な `GetType()` 呼び出しを避ける
数万件のレコードを処理するループの中で、毎回 `obj.GetType()` や `GetType(T)` を比較するコードを書くと、わずかではあるがオーバーヘッドが蓄積する。
型判定が必要な場合は、可能な限りポリモーフィズム（仮想メソッド）で解決できないか設計を疑うこと。どうしても型判定が必要な場合は、ループの外で `Dim targetType As Type = GetType(TargetClass)` のように型トークンを一度だけ取得し、それを使い回せ。
② データベースのORM（Entity FrameworkやDapperなど）との協調
DapperなどのマイクロORMを使って動的にクエリ結果をマッピングする際、DBのNULL許容型（`DBNull.Value`）が .NET の値型（`Integer?` や `DateTime?`）にうまくバインドされず、型不一致エラーを起こすことがよくある。
このような現場特有のトラブルを防ぐためにも、データの境界線（Boundary）では `TypeOf…Is` で厳密に型をガードし、想定外の `DBNull` がビジネスロジック層に侵入するのを防ぐバリデーションを挟む設計が、バグゼロを生む鉄則となる。
—
4. チーフアーキテクトからの提言
`GetType` と `TypeOf…Is` は、オブジェクト指向の美しさを妥協させる「諸刃の剣」である。これらに依存するコードが増えれば増えるほど、コードベースは拡張性を失い、条件分岐のジャングルと化す。
しかし、レガシーシステムとの統合、外部APIのラッパー、そして堅牢なエラーハンドリングが求められる業務自動化の現場において、「型を疑い、型を制する」技術は不可欠だ。
無闇に型判定に逃げるな。だが、必要に迫られたときは、今回紹介した安全なガード節とパターンマッチングを駆使し、びくともしない堅牢なアーキテクチャを構築してほしい。
君たちの書くコードが、明日の現場の平穏を支えている。妥協なき設計を続けたまえ。
