TypeScriptの境界線：unknownとneverが制御する「型安全の防壁」
TypeScriptの型システムは、コンパイル時のみ存在する抽象的な概念だと誤解されがちだ。しかし、真のアーキテクトは知っている。型とは「ランタイムという名の混沌」に対する唯一の防御壁であり、`unknown`と`never`はその壁の最も内側と外側を定義する、極めて重要な境界線であることを。
今日は、外部入力のバリデーションにおいて、なぜ我々がこの二つを執拗に使いこなさなければならないのか、その深層を解き明かす。
—
1. unknown: コンパイラへの「謙虚な」宣戦布告
`unknown`は、TypeScriptにおける「全知の否定」である。`any`が「何でもあり」という無秩序を許容するのに対し、`unknown`は「現時点では何も知らない」という事実を型システムに刻み込む。
外部からのJSON入力は、まさにこの`unknown`そのものだ。プロトタイプ汚染や予期せぬ型変換を許さないためには、この未知のデータを`Interface`へと昇華させるプロセスが不可欠となる。
安全な境界防壁の構築
単なる`as`キャスト（型アサーション）は、コンパイラに対する「責任放棄」に過ぎない。我々が求めるのは、ランタイムの型チェックを通過した後の「型保証」である。
interface UserProfile {
id: string;
role: ‘admin’ | ‘user’;
}
// 外部入力を受け取るゲートウェイ
function validateUserProfile(data: unknown): UserProfile {
// 構造的型付けを悪用した不正なプロトタイプ注入を排除する
if (typeof data !== ‘object’ || data === null) {
throw new Error(‘Invalid input: Expected object’);
}
// 厳密なプロパティチェック
const input = data as Record
if (typeof input.id === ‘string’ && (input.role === ‘admin’ || input.role === ‘user’)) {
return { id: input.id, role: input.role };
}
throw new Error(‘Validation failed: Structure mismatch’);
}
ここで重要なのは、`data`を直接`UserProfile`として扱うのではなく、一度`unknown`として受け取り、条件分岐（Type Guard）を通じてその範囲を狭めている点だ。これにより、コンパイラは「この後のコードブロックでは、この変数は確実に`UserProfile`である」と確信できる。
—
2. never: 存在しないことを証明する「最強の型」
`never`はボトム型であり、すべての型のサブタイプである。これの真価は、「ここには絶対に到達してはならない」という状態を型として定義できる点にある。
大規模アーキテクチャにおいて、未定義の入力や、あり得ない分岐を検知することは、セキュリティ上の最優先事項だ。
網羅性チェック（Exhaustiveness Checking）の極意
switch文やif-elseの連鎖において、全てのケースを処理しきったことをコンパイラに証明させる手法は、シニアエンジニアの必須教養である。
function handleRole(role: UserProfile[‘role’]) {
switch (role) {
case ‘admin’:
return executeAdminLogic();
case ‘user’:
return executeUserLogic();
default:
// ここに到達した場合、それは未知のロールが追加されたことを意味する
const _exhaustiveCheck: never = role;
return _exhaustiveCheck;
}
}
もし将来的に`role`に`’guest’`が追加されたらどうなるか？ TypeScriptコンパイラは、`default`節に`string`が流れ込むことを検知し、`never`型への割り当てエラーを吐き出す。この瞬間、「修正漏れ」はコンパイル時のエラーとして封殺される。これが、ランタイムでの未定義動作を未然に防ぐ防壁となる。
—
3. コンパイラAPIとメモリ最適化の裏側
TypeScriptの型評価は、実際には遅延評価に近いメカニズムで動作している。特に`unknown`から`Interface`への変換を行う際、不必要なオブジェクトのコピーや再帰的なチェックは、V8エンジンにおけるインラインキャッシュ（IC）の効率を低下させる要因となる。
- 単形性（Monomorphism）の維持: 同じバリデーション関数を使い回すことで、V8はオブジェクトの形状（Hidden Class）を予測しやすくなり、最適化が効く。
- 不変性の担保: バリデーション後に返されるオブジェクトは、可能な限り`Object.freeze`や`readonly`修飾子を使い、ランタイムでの意図しないメモリ書き換えを防ぐべきだ。
// 境界線での防御：readonlyを付与し、メモリの不変性を保証する
function validateAndFreeze
const result = validator(data);
return Object.freeze(result);
}
—
結論：防壁を突破させないために
TypeScriptにおける型システムは、単なる「便利な機能」ではない。それは、複雑怪奇なNode.jsのイベントループ、メモリ管理、そして外部からの悪意ある入力を制御するための「契約（Contract）」である。
1. 未知なるもの（unknown）を入口で厳密に裁く。
2. 到達不能なパス（never）を定義し、未来のバグを型レベルで抹殺する。
3. 型を単なる注釈とせず、ランタイムの整合性を守るための「堅牢な構造」として設計する。
この記事を読んだ君たちには、もう「適当な型定義」で逃げることは許されない。システムアーキテクトとして、コードの端々に防壁を築き、ランタイムの混沌を型という秩序で支配してほしい。
健闘を祈る。