TypeScriptのsatisfies演算子とas型アサーションの違い

TypeScript Frontend TypeSystem
結論

構造チェックと型推論の精密化を両立するには as ではなく satisfies を使用します。

// TypeScript 4.9公式仕様：satisfies 演算子の構文
type Colors = 'red' | 'green' | 'blue';
type RGB = [red: number, green: number, blue: number];

const palette = {
  red: [255, 0, 0],
  green: '#00ff00',
  blue: [0, 0, 255],
} satisfies Record<Colors, string | RGB>;

// ⭕ satisfies のおかげで string 固有メソッド (toUpperCase) が補完可能！
palette.green.toUpperCase();

TypeScript公式仕様：3つの型指定手法の比較

評価軸satisfies (TS 4.9+)明示的型注釈 (: Type)型アサーション (as Type)
型の検証 (Validation)◯ 厳格にチェック◯ 厳格にチェック❌ チェックを無視 (危険)
リテラル型の保持◯ 保持する (Narrowing)❌ 広い型へ拡張 (Widening)❌ 指定型へ強制上書き
存在しないプロパティ❌ エラーを検出❌ エラーを検出❌ エラーが検出されない

実際に起こる事故：as 型アサーションによるランタイムエラー

as（型アサーション）は TypeScript コンパイラに対して「型チェックを黙らせる」操作です。

APIレスポンスや設定ファイルに対して const data = response as User のように as を安易に使用すると、実際の実行時データに email プロパティが存在しなかった場合でもコンパイルを通過し、本番環境で TypeError: Cannot read properties of undefined を発生させてアプリケーションが停止する事故が発生します。

使い分けの鉄則

  1. 設定オブジェクト・テーマ定義
    元の具体的な値（配列やカラーコード文字列）の型情報をそのまま保持したい場合は satisfies を使用する
  2. DOM要素の取得（document.querySelector 等）
    コンパイラより開発者の方が型を明確に知っている場所のみ as HTMLInputElement を例外的に許可する
  3. 外部APIレスポンスの検証
    as を使わず、Zod などのランタイムバリデータでパースして安全な型を得る