`never` の真髄：コンパイラを飼い慣らし、ランタイムの崩壊を型で封じ込める
TypeScriptにおいて、`never` 型を単なる「何も返さない関数」と認識しているなら、それはまだ表層しか見えていない。
我々アーキテクトにとって、`never` とは型システムの「特異点（Singularity）」だ。これは単なる戻り値の欠如ではない。コンパイラに対し、「このパスに到達した時点で、制御フローの宇宙は崩壊し、後続の計算は物理的に不可能である」と宣言する物理法則の書き換えなのだ。
本稿では、例外スロー専用関数（`assertNever` や `panic`）を題材に、なぜこの型が堅牢なシステムの防壁となるのかを、ランタイムの挙動まで含めて解剖する。
—
1. コンパイラが「到達不可能」を判定するロジック
TypeScriptの型推論エンジンは、制御フロー解析（Control Flow Analysis）に基づいている。関数が `never` を返すということは、その関数が「制御を呼び出し元に戻さない」ことを意味する。
/
- 呼び出し元へのリターンを許さない：ランタイムにおける非局所脱出
/
function panic(message: string): never {
throw new Error(`[PANIC]: ${message}`);
}
この関数が呼び出された瞬間、V8エンジン上のスタックフレームは即座に巻き戻される（Unwinding）。TypeScriptのコンパイラは、`panic()` 以降のコードを「デッドコード」として型解析から除外する。
もし戻り値を `void` と定義した場合、コンパイラは「関数は正常に終了し、呼び出し元へ戻ってくる」と誤認する。その結果、本来不要な変数チェックや、到達し得ない `undefined` のハンドリングが型定義に混入し、コードベースが汚染される。
2. 網羅性チェック（Exhaustiveness Checking）の極意
`never` の真価は、`switch` 文や `if-else` チェーンにおける「完全網羅」の強制にある。
type Action = ‘CREATE’ | ‘READ’ | ‘DELETE’;
function handleAction(action: Action) {
switch (action) {
case ‘CREATE’: / … / break;
case ‘READ’: / … / break;
case ‘DELETE’: / … / break;
default:
// ここで action は never 型として推論されるべき
const _exhaustiveCheck: never = action;
return _exhaustiveCheck;
}
}
このパターンにおいて、もし将来的に `Action` 型に `’UPDATE’` が追加された場合、`default` 句の `action` は `string` 型（正確には `’UPDATE’`）となり、`never` 型への代入は型エラーを引き起こす。
これが我々の防壁だ。 プログラマが修正を忘れた瞬間、コンパイルが通らなくなる。テストコードを走らせるまでもなく、静的解析の段階でランタイムの論理矛盾を物理的に排除できる。
3. イベントループとコールスタックの安全性
例外スロー専用関数を適切に定義することは、単なる静的解析の最適化ではない。Node.jsのようなイベントループ駆動型の環境において、これは「未定義状態のリーク」を未然に防ぐ重要な設計だ。
非同期処理の連鎖において、予期せぬ状態遷移で例外を投げずに曖昧な値を返すと、その値はPromiseチェーンを伝播し、意図しない場所でクラッシュを引き起こす。あるいは、最悪の場合、サイレントに壊れたメモリ状態が保持され続ける。
`never` を明示的に指定し、`panic` を呼び出すことは、「イベントループからこの処理を即座に引き剥がし、エラーハンドラに制御を移譲する」という明確な意思表示だ。これにより、GC（ガベージコレクション）のルートから外れた不要なオブジェクトの参照を最短時間で断ち切ることができる。
4. 実戦的アーキテクチャ：堅牢な防壁の構築
大規模システムでは、単なる例外投げ以上のメタデータを保持する `panic` 関数を実装すべきだ。
/
- 致命的な不整合を検知した際、コンパイラとランタイムの両方に通知する
/
function unreachable(message: string, value?: any): never {
// セキュリティ上の懸念：機密情報を含む値をログに出さないよう制御を挟む
const safeValue = typeof value === ‘object’ ? ‘object’ : value;
// コンパイル時は型安全性を保証し、実行時は即座に停止させる
throw new Error(`Invariant Violation: ${message}. Received: ${safeValue}`);
}
なぜ `never` を徹底するのか
1. 型推論の精緻化: 余計な `| undefined` や `| null` が型から消え、業務ロジックの可読性が劇的に向上する。
2. 実行時効率: コンパイラが到達不可能なコードを最適化（除去）できるため、生成されるJavaScriptのバイナリサイズがわずかに削減される。
3. 認知負荷の低減: 開発者は「ここには絶対に到達しない」と確信できるため、複雑な条件分岐の網羅を脳内で繰り返す必要がなくなる。
—
結論：型は物理法則である
TypeScriptにおける `never` は、単なる型のラベルではない。それは、あなたが設計したプログラムの「不変条件（Invariant）」に対する最強の宣戦布告だ。
「このコードパスは存在しない」とコンパイラに刻み込むことで、あなたのプログラムは、記述された瞬間から堅牢な防壁を纏う。動的言語が抱える「実行してみるまで分からない」という不安を、型という名の物理法則で駆逐せよ。
シニアエンジニアたるもの、言語の機能を使うのではなく、言語の「裏側にあるロジック」を掌中に収めること。それこそが、大規模アーキテクチャを安定させる唯一の道である。