判別可能な共用体（Discriminated Unions）の深淵：型システムによる状態遷移の完全制御
TypeScriptの型システムを単なる「静的検査ツール」と捉えているのであれば、それは言語が提供する真の力を過小評価している。型とは、プログラムが取り得る全ての状態空間をコンパイル時に定義する「数理論理学的な防壁」である。
本稿では、`Discriminated Unions`（判別可能な共用体）を駆使し、実行時の予期せぬ状態遷移を物理的に不可能にする、堅牢なアーキテクチャの構築法を解説する。
—
1. 物理的な型定義：なぜ `interface` ではなく `type` なのか
多くのエンジニアは「InterfaceかTypeか」という瑣末な議論に時間を費やす。しかし、状態遷移を定義する場合、我々が選択すべきは常に `type` による共用体だ。
`interface` はオープンな宣言であり、`declaration merging` によって後から拡張が可能である。これはモジュール境界を曖昧にし、堅牢性を低下させる。対して `type` を用いた共用体は、閉じた世界（Closed Set）を形成する。
// 状態の定義：閉じた世界
type State =
| { status: ‘idle’ }
| { status: ‘loading’; progress: number }
| { status: ‘success’; data: string }
| { status: ‘error’; error: Error };
この `status` フィールドこそが、コンパイラに対する「判別子（Discriminant）」となる。TypeScriptのフロー解析エンジンは、この単一フィールドの比較を通じて、メモリ上のオブジェクトレイアウトを動的に絞り込む。
—
2. Exhaustive Check：コンパイラによる「思考の強制」
状態遷移において最も恐ろしいのは、新しい状態を追加した際に `switch` 文の更新を忘れることだ。これを防ぐには、`never` 型を用いた網羅性チェックが必須となる。
function handleState(state: State): void {
switch (state.status) {
case ‘idle’:
console.log(‘待機中’);
break;
case ‘loading’:
console.log(`進行度: ${state.progress}%`);
break;
case ‘success’:
console.log(`完了: ${state.data}`);
break;
case ‘error’:
console.error(state.error);
break;
default:
// ここに到達した時点でコンパイラは「網羅されていない状態」を突きつける
const _exhaustiveCheck: never = state;
throw new Error(`未定義の状態遷移: ${JSON.stringify(_exhaustiveCheck)}`);
}
}
この `never` への代入は、単なるエラーハンドリングではない。「コンパイラが到達不可能と判断したパスに、物理的に侵入した場合」を検知するための、型システムへの挑戦状である。
—
3. ランタイムの裏側：イベントループとメモリの整合性
TypeScriptの型は実行時に消滅する。しかし、この `Discriminated Unions` を使用することで、ランタイムのイベントループにおける「データの不整合」を排除できる。
例えば、非同期処理のレスポンスを扱う際、以下のように定義すれば、メモリ上のオブジェクト形状と、処理中のイベントが完全に同期する。
// メモリの不整合を防ぐための防壁
type Action =
| { type: ‘FETCH_START’ }
| { type: ‘FETCH_SUCCESS’; payload: string }
| { type: ‘FETCH_FAILURE’; reason: string };
function reducer(state: State, action: Action): State {
// コンパイラがActionの型ごとにStateの整合性を追跡する
if (action.type === ‘FETCH_SUCCESS’) {
return { status: ‘success’, data: action.payload };
}
// …
}
ここでのポイントは、「状態の型」と「アクションの型」が1対1で対応するように強制できる点にある。これにより、非同期のイベントループ（`Promise` の解決や `setTimeout` のコールバック）がどれほど複雑に重なり合っても、`state` が不正な形状（例：`loading` なのに `data` が存在する等）になることは数学的にあり得なくなる。
—
4. チーフアーキテクトからの提言：防壁を突破されないために
セキュリティ研究の観点から言えば、脆弱性の多くは「状態の遷移不全」から生じる。例えば、`loading` 状態をすっ飛ばして `success` に遷移させる攻撃コードや、型のキャスト（`as`）を乱用した意図的なメモリ破壊だ。
1. `any` や `as` への絶対的な忌避: これらは型システムの防壁を無効化するバックドアである。
2. `readonly` の強制: 状態遷移は必ず新しいオブジェクトを生成する「イミュータブルな設計」を採用せよ。オブジェクトの参照破壊を防ぐことは、メモリ安全性への第一歩だ。
3. 判別子の単一化: 判別子は常にリテラル型（`string` や `number`）を使用し、`enum` は避けること。`enum` は数値変換等の副作用があり、コンパイル後の挙動が予測困難になるケースが多い。
TypeScriptの型システムは、単なる補助輪ではない。それは、あなたが書くコードが実行時に「暴走しない」ことを保証するための、唯一無二の厳格なプロトコルである。このプロトコルを極限まで突き詰め、コンパイラをあなたの最も優秀な防衛戦力として従わせろ。
それが、プロのエンジニアが到達すべき「コードの掌握」という境地だ。