ユニオン型は「型」の暴力ではない。我々が制御すべき「状態の境界線」である。
TypeScriptの型システムにおいて、`Union Types（ユニオン型）`を単なる「AかBか、どちらか入る箱」としか認識していないなら、それはまだ入り口に立ったに過ぎない。
大規模なWebアプリケーションにおいて、データ構造の曖昧さはそのままバグの温床となる。特にサーバーからのレスポンスを扱う際、`any`や`unknown`で逃げるのはエンジニアとしての敗北だ。今回は、ユニオン型を単なる型定義から、堅牢なアプリケーションを支える「ステートマシン」へと昇華させるための知見を共有しよう。
—
1. ユニオン型と「直和型」の深淵
多くのエンジニアが陥る罠は、ユニオン型を単なる「値の許容範囲」として捉えることだ。真のアーキテクトは、ユニオン型を「タグ付きユニオン（Discriminated Unions）」として設計する。
これは、メモリ効率や型安全性を担保するための最重要テクニックだ。
// 悪い例：プロパティの存在確認だけで分岐を判断する
interface User {
id: string;
role: ‘admin’ | ‘guest’;
adminLevel?: number;
}
// 良い例：識別子（タグ）で状態を完全に分離する
interface Admin {
kind: ‘admin’; // リテラル型による明確なタグ付け
id: string;
adminLevel: number;
}
interface Guest {
kind: ‘guest’;
id: string;
}
type UserState = Admin | Guest;
// この構造にすることで、TypeScriptのコンパイラはメモリ空間における
// 形状の不一致を瞬時に検知し、安全な絞り込み（Type Narrowing）を強制する
この「タグ」があることで、後述する型ガードの精度が格段に向上する。コンパイラが「このパスでは絶対に`adminLevel`が存在する」と静的に保証できるため、無駄なオプショナルチェーンや型アサーション（`as`）を排除でき、実行時のランタイムエラーを根絶できる。
—
2. 型ガード：ブラウザエンジンを味方につける最適化
型ガード（`typeof`, `instanceof`, `in`）は、単にエラーを消すための手段ではない。これは、ブラウザのJITコンパイラがコードを最適化するためのヒントでもある。
効率的な絞り込みのコツは、判定のコストが最も低いものから順番に並べることだ。
function handleUserAction(user: UserState) {
// 1. リテラル型の比較は非常に高速
if (user.kind === ‘admin’) {
// ここで user は Admin 型に確定する
console.log(`管理権限レベル: ${user.adminLevel}`);
return;
}
// 2. それ以外（Guest）として処理
// 複雑な判定を繰り返さず、構造を絞り込むことで、
// V8などのエンジンは最適化されたマシンコードを生成しやすくなる
console.log(‘一般ユーザーとして処理’);
}
特に非同期処理の結果を扱う際、`unknown`型からユニオン型へガードする過程で、バリデーションライブラリ（Zod等）を噛ませるのは現代の定石だ。通信コストを最小化しつつ、メモリ上のオブジェクト構造を確定させる。このフローこそが、巨大なフロントエンドコードベースを腐らせないための「防波堤」となる。
—
3. パフォーマンスとスケーラビリティの視点
ユニオン型を使いすぎると、型推論の計算コスト（型検査時間）が増大し、`tsc`のビルド速度が低下するのではないかと懸念する声がある。しかし、適切に定義されたタグ付きユニオンは、むしろ「予測可能なデータフロー」を作るため、レンダリング負荷の削減に寄与する。
- コンポーネントの再レンダリング防止: 状態をユニオン型で厳密に分けることで、Reactなどのフレームワークにおいて不要なプロパティの更新を抑止できる。
- 非同期の競合回避: `Pending | Success | Failure` のようなユニオン型でステータスを管理すれば、`isLoading`と`isError`が同時に`true`になるというような、物理的にあり得ない状態を型レベルで排除できる。
—
結び：TypeScriptは「設計図」そのものである
ユニオン型を使いこなすということは、あなたのアプリケーションが取り得る「すべての状態」を支配下に置くということだ。
もし今、あなたのコードに`any`が溢れ、型ガードが`if`文の迷宮のようになっているなら、それはデータモデルの設計が甘い証拠だ。ユニオン型を適切に切り分け、タグで状態を管理する。この泥臭くも静かな努力の積み重ねが、数年後にコードベースが巨大化したとき、あなたを救う唯一の武器になる。
型定義は、ただの記法ではない。あなたの設計思想そのものなのだ。さあ、次はどの状態を型に刻み込む？
コメント