TypeScriptの深淵：Union型を「型ガード」で制圧する、堅牢なアーキテクチャ設計
TypeScriptにおけるUnion型は、強力な武器であると同時に、扱いを誤れば「ランタイムエラーの温床」にもなり得る諸刃の剣です。特に、APIレスポンスやコンポーネントのPropsなど、複数の型が混在する境界線上で、泥臭い `if` 文や `any` キャストに逃げているようでは、TypeScriptの恩恵を半分も受け取れていません。
今回は、TypeScriptの型システムを正しく駆動させ、コンパイラに「型の絞り込み（Type Narrowing）」を確実に認識させるための、実務で即戦力となる実装パターンを伝授します。
—
なぜ `typeof` や `instanceof` だけでは不十分なのか
実務のフロントエンド開発において、最も遭遇するのは「判別可能なUnion型（Discriminated Unions）」のパターンです。
「とりあえず `typeof` でチェックすればいい」と考えるのはジュニア層の思考です。実務では、`{ type: ‘loading’ }` や `{ type: ‘success’, data: T }` といった、共通の識別子を持つオブジェクトの集合を扱うことがほとんどです。
ここで重要なのは、「コンパイラに型の絞り込みを強制する」こと。中途半端なチェックは、リファクタリング時にコードの整合性を崩す元凶となります。
—
推奨パターン：ユーザー定義型ガードによる「型安全の境界線」
非同期APIのレスポンス処理を例に、保守性の高い設計を見てみましょう。
// 1. 型の定義（Discriminated Unions）
type RemoteData
| { status: ‘idle’ }
| { status: ‘loading’ }
| { status: ‘success’; data: T }
| { status: ‘error’; error: Error };
// 2. ユーザー定義型ガード
// 戻り値の型定義に ‘is’ を使うことで、TSコンパイラに「この関数がtrueを返せば、引数はこの型である」と教え込む
const isSuccess =
return data.status === ‘success’;
};
// 3. 実践：処理の分離
const handleResponse =
// ユーザー定義型ガードによる絞り込み
if (isSuccess(state)) {
// ここではstateは { status: ‘success’; data: T } 型として推論される
console.log(‘Data loaded:’, state.data);
return;
}
// ここではまだidle, loading, errorのいずれか
if (state.status === ‘error’) {
console.error(state.error.message);
}
};
なぜこの設計が美しいのか？
- 単一責任の原則: 型ガード関数を切り出すことで、複雑なバリデーションロジックをコンポーネント本体から分離できます。
- 推論の連鎖: `isSuccess` が true を返した瞬間、コンパイラは `else` ブロック側の型からも `success` 型を除外してくれます。
- 拡張性: 新しいステータス（例：`retrying`）が追加された場合、TypeScriptの網羅性チェック（後述）と組み合わせることで、修正漏れをコンパイルエラーとして即座に検知できます。
—
現場の極意：網羅性チェック（Exhaustiveness Check）を忘れるな
どれだけ型ガードを丁寧に書いても、将来的にUnion型に新しいメンバを追加した際に、`switch` 文や `if-else` の分岐を更新し忘れることは避けられません。これを防ぐのが `never` 型を使った網羅性チェックです。
const getMessage = (state: RemoteData
switch (state.status) {
case ‘idle’: return ‘待機中’;
case ‘loading’: return ‘読み込み中’;
case ‘success’: return ‘成功’;
case ‘error’: return ‘エラー発生’;
default:
// ここに到達した時点で、stateは ‘never’ 型でなければならない
const _exhaustiveCheck: never = state;
return _exhaustiveCheck;
}
};
もし将来的に `RemoteData` に `pending` 型を追加し、この `switch` 文を更新し忘れた場合、コンパイラは `Type ‘…’ is not assignable to type ‘never’` という強力な警告を発します。これが「変更に強いコード」の正体です。
—
パフォーマンスと設計上の注意点
1. 過度な抽象化を避ける: 型ガード関数はシンプルに保ってください。内部で重い計算やDOM操作を行うのはNGです。型チェックは純粋関数（Pure Function）として実装するのが鉄則です。
2. ランタイムと型の二重管理を防ぐ: `interface` を定義し、それをチェックする関数を書き、さらにバリデーションライブラリ（Zodなど）を使う場合、型定義が二重三重になります。Zodの `parse` 結果を型ガードとして活用するなど、DRY（Don’t Repeat Yourself）を意識した設計を心がけてください。
結びに：型は「守り」ではなく「攻め」の武器
「TypeScriptがエラーを出すから直す」というスタンスは卒業しましょう。
堅牢な型ガードを構築することは、「未来の自分やチームメンバーが、コードをどう変更しても壊れないことを保証する」という、極めて高度なエンジニアリングの所作です。
コードレビューの際は、「この条件分岐は本当に網羅されているか？」「新しい型が追加されたとき、どこでエラーが出るか？」という視点を持ってください。その視点こそが、あなたを単なるコーダーから、アーキテクトへと進化させるはずです。
さあ、コードを開いて、その雑然とした `if` 文を洗練された型ガードに書き換えてみてください。コンパイラが静かに微笑むはずです。