条件型が何重にも入れ子になった型があり、誰も中身を説明できません。どう扱いますか。
まず何を保証したい型なのかを確かめ、単純な型で足りないか検討します。複雑さが必要なら途中の型に名前を付けて分け、@ts-expect-error を使った型のテストで挙動を固定します。
面接官が見ているのは型の複雑さを保守の問題として扱えるか。読めない型を正当化しないか。
これは「function findById<T>(items: T[], id: string) と書いたら、中で item.id を読むところでエラーになりました。どうしますか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- 何を保証したい型なのかを確かめ、途中の型に名前を付けて分けるか、より単純な型で足りないか検討する。挙動は型のテストで固定する
その通りです。読めない型は、壊れても誰も気づけません。単純にできないなら、テストで挙動を固定します。 - 動いているなら触らない
当面はそれでも動きますが、変更が必要になった時に誰も直せません。少なくとも挙動をテストで固定します。 - 型を any にして単純化する
単純にはなりますが、その型が守っていたものをすべて失います。 - 型が複雑なほど安全なので、そのままでよい
複雑さと安全さは別物です。読めない型は、間違っていても気づけません。
模範解答
まず、その型が何を保証するためのものかを確かめます。呼び出し側でどんな間違いを防ぎたいのかが分かれば、もっと単純な型で同じことができる場合が少なくありません。
複雑さが必要なら、途中の型に名前を付けて分け、それぞれに説明のコメントを残します。1つの式に入れ子で書くより、読む人が段階を追えます。
そして、挙動を型のテストで固定します。「この使い方は通る」「この使い方はエラーになる」を、@ts-expect-error を使ったテストとして書いておけば、書き換えたときに壊れたかどうかが分かります。
読めない型は、壊れても誰も気づけません。複雑な型ほど、テストが要ります。
対象: TypeScript 5.x〜7.0 照合した一次資料: 公式ドキュメント 照合: 2026-10-25 最終更新: 2026-10-25
お使いの版で挙動が違う場合があります。誤りに気づいたらこの解説を報告するから教えてください。