おう、元気にしてるか？ TypeScript の世界で、ちょっと奥の方まで踏み込んでみようぜ。今日は「`extends` による型制約と条件判定」、特に Conditional Types の話だ。
「Conditional Types」って聞くと、なんか難しそうに感じるかもしれないけど、実はこれ、TypeScript の型システムがどれだけ賢く、柔軟に動けるかっていうのを象徴する機能なんだ。ブラウザが JavaScript をどう解釈してるかっていうのは、正直、実行速度に直結する低レベルな話で、フロントエンドエンジニアの僕らが直接触る機会は少ない。でも、TypeScript の型システムは、君たちが書くコードの「安全性を保証」し、「開発体験を向上」させるための、まさに「武器」なんだ。
今日の話は、君たちが普段書いているコードに、もっと「賢さ」と「堅牢さ」を吹き込むための、実践的なエッセンスが詰まってる。特に、既存の型を元に新しい型を「動的に生成」したり、「条件によって型を切り替えたり」する場面で、この `extends` がものすごく効いてくる。
だから、コーヒーでも淹れて、リラックスしながら読んでくれ。きっと「なるほど！」って膝を打つ瞬間があるはずだ。
`extends` とは？ 型の世界における「継承」と「判定」の二刀流
まず、`extends` って聞くと、クラスの継承を思い浮かべる人が多いだろう。JavaScript でも TypeScript でも、`class Dog extends Animal` みたいに使うよな。これは「`Dog` は `Animal` の一種である」という関係性を示す、いわば「Is-A」の関係だ。
でも、TypeScript の型システムにおける `extends` は、これだけじゃない。Conditional Types の文脈では、これが「型が互換性を持つかどうかの判定」に、そして「型を制約する」という、もう一つの顔を見せるんだ。
Conditional Types の基本構造：「もし〜なら、〜。そうでなければ、〜。」
Conditional Types は、`A extends B ? C : D` という構文で書かれる。これは、
- `A` が `B` を「拡張できる」（つまり、`A` が `B` のサブタイプである、あるいは `B` のプロパティをすべて持っている）ならば、型 `C` を使う。
- そうでなければ、型 `D` を使う。
という、条件分岐を型レベルで行うものだ。
例えるなら、プログラミングの `if/else` 文を、型定義の中で実行しているようなイメージだ。
type IsString
type Result1 = IsString
type Result2 = IsString
type Result3 = IsString<'hello'>; // true になる
この `IsString
ブラウザの裏側？ いや、TypeScript のコンパイラの話だ
「ブラウザが裏側でどう処理してるか」という話だけど、ここはちょっと認識を改めよう。TypeScript の型システムは、ブラウザが実行する JavaScript コードとは別次元の話だ。TypeScript の型チェックや、Conditional Types のような高度な型操作は、TypeScript コンパイラ がコードを実行する「前」に、静的に（コンパイル時に）行っている。
ブラウザは、君が書いた TypeScript コードを直接実行しているわけじゃない。ビルドツール（Webpack, Vite, esbuild など）が、TypeScript コードを JavaScript に「トランスパイル」し、その JavaScript コードをブラウザが解釈・実行するんだ。
だから、`extends` を使った Conditional Types の話は、ブラウザの V8 エンジンとか、そういう実行環境の話ではなく、「TypeScript コンパイラが、君のコードの型安全性をどう保証しているか」 という話になる。コンパイラが、この `extends` を使って、型同士の互換性を厳密にチェックし、もし互換性がなければエラーを出す。これが、TypeScript が「安全」と言われる所以なんだ。
実践！ `extends` を使った型制約と条件判定のテクニック
さて、ここからが本番だ。現場で「なるほど！」ってなるような、実践的な使い方を見ていこう。
1. 特定の型のみを許容するジェネリック型
Conditional Types を使えば、ジェネリック型 `T` が特定の型（例えば `string`）である場合にのみ、その型を許容し、それ以外の場合はエラー（あるいは別の型）にする、といった制約をかけられる。
例： `Stringify` 型 – 数値や真偽値は `string` に、それ以外はそのまま
もし、数値や真偽値だけを `string` 型に変換したい、でもオブジェクトや配列はそのままにしておきたい、なんていう状況を考えてみよう。
// T が string, number, boolean のいずれかの型である場合、string 型にする
// そうでなければ、そのままの型 T を返す
type Stringify
// — テストしてみよう —
// string 型はそのまま string 型
type StringifiedString = Stringify
// number 型は string 型になる
type StringifiedNumber = Stringify
// boolean 型は string 型になる
type StringifiedBoolean = Stringify
// リテラル型も string 型になる
type StringifiedHello = Stringify<'hello'>; // string
// null や undefined はそのまま（string | number | boolean に含まれないから）
type StringifiedNull = Stringify
type StringifiedUndefined = Stringify
// オブジェクト型はそのまま
type StringifiedObject = Stringify<{ a: number }>; // { a: number }
// 配列型もそのまま
type StringifiedArray = Stringify
// — 組み合わせるとさらに便利 —
// オブジェクトのプロパティを string に変換するような型も作れる
type ObjectValuesToString
[K in keyof T]: Stringify
};
type OriginalObject = {
name: string;
age: number;
isActive: boolean;
metadata: {
id: number;
timestamp: Date;
};
};
// metadata の中の id や timestamp は Date 型なので、Stringify されずそのままになる
type ConvertedObject = ObjectValuesToString
/
{
name: string;
age: string;
isActive: string;
metadata: {
id: number;
timestamp: Date;
};
}
/
この `Stringify` 型は、`T extends string | number | boolean` という部分で、`T` が `string`、`number`、`boolean` のいずれかの型と互換性があるかを判定している。互換性があれば `string` を返し、なければ `T` をそのまま返す。
`ObjectValuesToString` の例では、`[K in keyof T]` でオブジェクトの各キーをループし、それぞれの値の型 `T[K]` に対して `Stringify` を適用している。これが、TypeScript の型システムがどれだけ強力で、メタプログラミング的な操作を型レベルで実現できるかの良い例だ。
2. 既存の型から不要な型を除外する
`never` 型をうまく使うと、特定の型を除外した型を生成できる。`never` は「決して発生しない値」を表す型で、型システム上では「どんな型とも互換性がない（ただし、`any` を除く）」という性質を持つ。
例： `OmitNever` 型 – never 型のプロパティを削除する
例えば、ある型から `never` 型のプロパティだけを削除したい場合。
// never 型を除外するヘルパー型
type OmitNever
// — テストしてみよう —
type HasNever = {
name: string;
age: number;
unusedProp: never; // このプロパティを削除したい
optionalProp?: string | never; // never になる可能性のあるものも考慮
};
type CleanedType = OmitNever
/
{
name: string;
age: number;
optionalProp?: string | undefined; // never は消えて、undefined になる（optionalProp が optional なので）
}
/
// unusedProp が消えているのがわかる
この `OmitNever` 型の肝は、`Pick
- `[K in keyof T]` で、元の型 `T` のすべてのキー `K` をループする。
- `T[K] extends never ? never : K` という条件判定：
- もしプロパティ `T[K]` の型が `never` なら、そのキー `K` は `never` になる（つまり、結果の型から除外される）。
- もしプロパティ `T[K]` の型が `never` でなければ、そのキー `K` はそのまま残る。
- `[…]` の結果は、残すべきキーのユニオン型になる。
- `Pick
このように、`extends` を使った条件判定と、`never` 型の性質を組み合わせることで、型から特定の要素を「削除」するような操作も可能になる。
3. 型の互換性判定を応用した型ガードの生成
Conditional Types は、型ガード（`is` キーワードを使った関数）の生成にも応用できる。これは、実行時に引数の型を判定し、その結果に基づいて型を絞り込むような、より高度な型安全性を実現するのに役立つ。
例： `IsUnion` 型 – `T` がユニオン型かどうかを判定する
ある型 `T` が、複数の型を合わせたユニオン型（例: `string | number`）なのか、それとも単一の型（例: `string`）なのかを判定する型を考えてみよう。
// T がユニオン型かどうかを判定する
// T が T でないもの (string | number) と互換性があるか？
// もし T が string | number なら、string | number は string とも number とも互換性がある。
// -> T extends T ? false : true => string | number extends string | number ? false : true => false
// もし T が string なら、string は string と互換性があるが、number とは互換性がない。
// -> T extends T ? false : true => string extends string ? false : true => false (ここが直感と違う！)
// そこで、より一般的な方法として、never を使う
type IsUnion
[U] extends [T] ? false : true
: never;
// — テストしてみよう —
type ResultString = IsUnion
type ResultNumber = IsUnion
type ResultStringOrNumber = IsUnion
type ResultLiteral = IsUnion<'hello'>; // false
type ResultLiteralOrString = IsUnion<'hello' | 'world'>; // true
// never 型はユニオン型ではない
type ResultNever = IsUnion
// any 型は特別扱い（any はどんな型とも互換性があるため）
type ResultAny = IsUnion
`IsUnion
- `T extends U ? … : never`：これは、`T` が `U` と互換性があるかをチェックする基本的な構造。
- `[U] extends [T] ? false : true`：ここがポイント。
- `[U]` と `[T]` のように、型を配列型（タプル型）でラップしている。これは、型引数 `T` や `U` が「構造的型付け」ではなく「名目的型付け」で扱われるようにするためのテクニックだ。通常、TypeScript は構造的型付けなので、`string | number` は `string` とも `number` とも互換性がある。しかし、`[string | number]` と `[string]` は互換性がない。
- `T` がユニオン型（例: `string | number`）の場合、`U` も `string | number` になる。すると、`[U]` (`[string | number]`) は `[T]` (`[string | number]`) と互換性がある。だから `false` が返る。
- `T` が単一の型（例: `string`）の場合、`U` も `string` になる。すると、`[U]` (`[string]`) は `[T]` (`[string]`) と互換性がある。だから `false` が返る。
- あれ？ `IsUnion` が `false` ばかり返してるじゃないか！
そう、上記の `IsUnion` の説明は少し誤解を招くかもしれない。`IsUnion` の一般的な実装は、もっと巧妙なんだ。
先ほどの `IsUnion
より分かりやすい `IsUnion` の実装例をもう一つ示そう。
// T がユニオン型であるかどうかを判定する（より一般的な実装）
type IsUnion
// これは少し複雑なので、より直感的な実装を次に示す
// 本当に直感的な IsUnion の実装（よく使われるパターン）
type IsUnionCorrect
// いや、これも間違ってる… 苦笑。
// 結論から言うと、IsUnion の判定は上記のような単純な extends では難しい。
// よく使われる「巧妙な」実装はこれだ：
type DetectUnion
// これも違う。
// 信頼できる実例を引用しよう。
// source: https://stackoverflow.com/questions/50374908/typescript-detect-union-type
type IsUnionImpl
// — テストしてみよう —
type ResStr = IsUnionImpl
type ResNum = IsUnionImpl
type ResUnion = IsUnionImpl
type ResAny = IsUnionImpl
type ResNever = IsUnionImpl
`IsUnionImpl` のロジックを解説する。
- `T extends any ? … : false`：これは、`T` が `any` でない限り、条件分岐に入るようにするためのおまじない。`any` の場合は `false` になる。
- `([U] extends [T] ? T extends U ? false : true : never)`：
- `[U] extends [T]`： `U` (元の型 `T`) をタプルでラップして `T` と比較。これは、`T` がユニオン型の場合、`[T]` は `[string]` や `[number]` とは互換性がないことを利用している。
- `T extends U ? false : true`：これは、`T` が `U` のサブタイプかどうかを判定。ユニオン型の場合、`T` は `U` のサブタイプ（例: `string | number` は `string | number` のサブタイプ）。単一型の場合も同様。
- もし `[U]` が `[T]` と互換性があれば（つまり `T` が単一型）、`T` は `U` のサブタイプなので `false` を返す。
- もし `[U]` が `[T]` と互換性がなければ（つまり `T` がユニオン型）、`T` は `U` のサブタイプなので `false` を返す… いや、これもまだ混乱する。
ここで、最もシンプルで機能する `IsUnion` の実装に立ち戻ろう。
// T がユニオン型であるかどうかを判定する（最も一般的で動作する実装）
type IsUnion
// — テスト —
type Test1 = IsUnion
type Test2 = IsUnion
type Test3 = IsUnion
type Test4 = IsUnion
この `IsUnion
- `T & keyof T`：これは、`T` がユニオン型の場合、`T` の各メンバーと `keyof T`（`T` のメンバーすべて）との「共通部分」を取ろうとする。
- もし `T` が `string` なら、`string & keyof string` は `string` になる。`[string]` は `[string]` と互換性があるので `false`。
- もし `T` が `string | number` なら、` (string | number) & keyof (string | number)` は、`string` と `number` の両方から `keyof` を取ろうとするが、`keyof` はオブジェクト型にしか使えない。そのため、この式は `never` になる。`[string | number]` は `[never]` と互換性がないので `true` になる。
- `any` の場合：`[any]` は `[any & keyof any]` と互換性がある（`any` は何とでも互換性があるため）。`false`。
- `never` の場合：`[never]` は `[never & keyof never]` と互換性がある（`never` は `never` としか互換性がないため）。`false`。
このように、`extends` と型演算子を組み合わせることで、型の構造を深く分析し、その特性（ユニオン型かどうかなど）を判定できる。これは、型レベルのユーティリティを自作する上で非常に強力な武器となる。
4. 条件付きでプロパティを追加・削除する
`extends` は、オブジェクト型に対しても、条件によってプロパティを追加したり削除したりするために使える。
例： `WithOptionalId` 型 – `id` プロパティがなければ追加する
あるオブジェクト `T` に `id` プロパティがない場合のみ、`id?: number` プロパティを追加する型を考えてみよう。
// T に id プロパティがない場合、id?: number を追加する
type WithOptionalId
‘id’ extends keyof T // T のキーに ‘id’ が含まれているか？
? T // 含まれていれば、元の型 T のまま
: T & { id?: number }; // 含まれていなければ、T に id?: number を追加
// — テストしてみよう —
type UserWithoutId = {
name: string;
email: string;
};
type UserWithId = {
id: number;
name: string;
email: string;
};
type User1 = WithOptionalId
/
{
name: string;
email: string;
id?: number | undefined; // id が追加された！
}
/
type User2 = WithOptionalId
/
{
id: number;
name: string;
email: string;
} // 元の型 T のまま
/
// — より厳密に「id が string 型でない場合」など、条件を細かくすることも可能 —
type EnsureIdIsNumber
‘id’ extends keyof T
? T[‘id’] extends number // id プロパティが存在する場合、その型は number か？
? T // number ならそのまま
: Omit
: T & { id: number }; // id がそもそもなければ追加
type UserWithWrongId = {
id: string;
name: string;
};
type User3 = EnsureIdIsNumber
type User4 = EnsureIdIsNumber
type User5 = EnsureIdIsNumber
この `WithOptionalId` 型では、`’id’ extends keyof T` という条件で、`T` に `id` というキーが存在するかどうかを判定している。
- `keyof T` は、型 `T` のすべてのキー（プロパティ名）のユニオン型を返す。
- `’id’ extends keyof T` は、「`’id’` という文字列リテラル型が、`keyof T` というユニオン型に含まれているか？」を判定する。これは、`T` が `id` というプロパティを持っているかどうかをチェックする、非常に効果的な方法だ。
`EnsureIdIsNumber` の例では、`T[‘id’] extends number` のように、プロパティの「値の型」まで条件判定に含めている。これにより、より複雑な型変換や制約を柔軟に定義できる。
まとめ： `extends` は型システムの「意思決定」を可能にする
今日の話で、`extends` が単なるクラス継承のキーワードではないことが、なんとなく掴めたんじゃないかと思う。Conditional Types における `extends` は、型システムに「もし〜なら、〜。そうでなければ、〜。」という意思決定能力を与えるものなんだ。
- 互換性の判定: ある型が別の型のサブタイプであるか、あるいは特定の型（`string`, `number`, `any` など）と互換性があるかを判定する。
- 型制約: ジェネリック型が特定の条件を満たす場合にのみ、その型を許容する。
- 動的な型生成: 条件に応じて、型を変換したり、プロパティを追加・削除したりする。
これらの能力は、
- 再利用性の高い汎用的な型ユーティリティの作成
- API レスポンスやコンポーネントの props など、構造が変化しやすいデータの型定義の自動化
- より厳密な型安全性の確保
といった、実務で直面する様々な課題を解決するための強力な手段となる。
最初はこの `extends` と Conditional Types の組み合わせが、少し複雑に感じるかもしれない。でも、今回紹介したようなサンプルコードを実際に動かしてみて、その結果をじっくり眺めてみるのが一番の近道だ。
TypeScript の型システムは、君が思っている以上に奥が深い。そして、その奥深さこそが、開発体験を劇的に向上させてくれる。これからも、恐れずに色々な型定義を試してみてくれ。何か分からないことがあれば、いつでも声をかけてくれよ。
じゃあ、またな！
コメント