TypeScript で API のレスポンスに as User と型アサーションを書いた場合、実行時の挙動として正しいものはどれですか？

解説

正解は「実行時には一切チェックされず、型が合っていなくてもそのまま処理が進みます」です。as による型アサーションはコンパイラへの宣言にすぎず、生成される JavaScript には何も残りません。コンパイル後に as が消えるTypeScript の型情報はコンパイル時にすべて取り除かれます（型消去と呼ばれます）。そのため as User は「この値を User として扱え」とコンパイラに伝えるだけで、検証コードは生成されません。// TypeScript const user = await res.json() as User; console.log(user.name); // コンパイル後の JavaScript（as は跡形もない） const user = await res.json(); console.log(user.name); // name が無ければ undefined になるだけ他の選択肢が誤りの理由TypeError が発生する: 検証自体が行われないため、例外は投げられません。エラーは後続処理で初めて表面化します。undefined で補われる: TypeScript は変換処理も既定値の補完も生成しません。オブジェクトは受け取ったままです。strict なら実行時にチェックされる: strict はコンパイル時の型チェックを厳しくする設定であり、実行時の挙動には影響しません。「型が付いている＝データが正しい」の落とし穴アサーションを書くと補完が効くようになるため安心してしまいますが、実際にはAPIの仕様変更やレスポンス形式の揺れをまったく検知できません。バグは user.name.trim() のような遠く離れた行で顕在化し、原因の特定に時間がかかります。外部データは実行時に検証する境界をまたぐデータには、アサーションではなくバリデーションを使います。const User = z.object({ id: z.number(), name: z.string() }); // 形式が違えばこの行で例外になる const user = User.parse(await res.json());自前で書く場合は、ユーザー定義型ガード（value is User）で絞り込む方法もあります。Type Assertions - TypeScript Handbook