【実務・中級編】TypeScriptの型推論エンジンをハックする：条件付き型の基礎と応用 – TypeScript コア・型システムの基礎解析バイブル

TypeScriptの型推論エンジンをハックする：条件付き型の基礎と応用

テックリードの私だ。コードレビューをしていると、未だに「とりあえず `any` や `as` で型アサーションをつけて逃げる」という悪癖を目撃する。特に、APIのレスポンスやコンポーネントのプロパティが複雑に分岐するシチュエーションで、思考停止した型定義がプロダクションコードの保守性を静かに蝕んでいる。

TypeScriptの型システムは、単なる「静的チェックの道具」ではない。コンパイル時に関数やロジックを実行できる、極めて強力なメタプログラミング環境だ。

今回は、その中核をなす条件付き型（Conditional Types）を徹底的に解剖し、実務のフロントエンド開発や非同期API連携で即座に使える、堅牢で美しいプロダクションコードの設計パターンを授けよう。

—

1. 条件付き型の本質：型レベルの三項演算子

条件付き型は、一言で言えば「型における `T ? A : B`」である。

T extends U ? X : Y

この構文を見たとき、単に「`T` が `U` を満たしていれば `X`、そうでなければ `Y`」と直感的に理解するだけでは二流だ。型推論エンジンがこのコードをどう評価しているか。その内部挙動をイメージできなければならない。

分配条件付き型（Distributive Conditional Types）の罠と魔力

条件付き型が `T`（型パラメータ）に対して裸（naked）の状態で使われるとき、型は自動的に分散（distribute）する。これを知らないと、意図しない型爆発を引き起こす。

type ToArray = T extends any ? T[] : never;

// 以下の評価結果はどうなるか？
type Result = ToArray;
// 答え: string[] | number[] （配列のユニオン）
// × (string | number)[] ではない！

なぜこうなるのか？ コンパイラはユニオン型が渡されたとき、それを一つひとつの要素に分解し、それぞれに対して条件付き型を適用した後に再度ユニオンで結合するからだ。

この挙動を意図的に制御するのが、タプルによるラップだ。

// 分配を阻止したい場合
type ToArrayNonDistributive = [T] extends [any] ? T[] : never;

type ResultSafe = ToArrayNonDistributive;
// 答え: (string | number)[]

この「分散するか、させないか」のコントロールは、実務で高度なユーティリティ型を作る際の基礎体力となる。

—

2. 実践：APIレスポンスの「状態」を型で完全にハックする

非同期API連携において、以下のような「ローディング中」「成功」「エラー」を内包するレスポンス型をよく書くだろう。

type ApiResponse =
| { status: ‘loading’ }
| { status: ‘success’; data: T }
| { status: ‘error’; error: Error };

ここで、特定のステータスに応じたペイロードだけを安全に取り出したい。`any` やオプショナルチェーンの乱用はバグの温床だ。ここで条件付き型を用いた型抽出エンジンを構築する。

プロダクションコード：型安全なペイロード抽出パターン

以下のコードを見てほしい。コンパイル時に型を絞り込み、ランタイムの安全性を担保する洗練された設計だ。

/

• 1. 条件付き型を用いたステータス別レスポンス抽出エンジン

/
type ExtractResponseByStatus =
TResponse extends { status: TStatus } ? TResponse : never;

// 使用例のベースとなるAPIレスポンス型
type UserProfileResponse = ApiResponse<{ id: string; name: string; email: string }>;

// コンパイル時に型が完全に確定する
type SuccessPayload = ExtractResponseByStatus;
// 評価結果: { status: ‘success’; data: { id: string; name: string; email: string; } }

type ErrorPayload = ExtractResponseByStatus;
// 評価結果: { status: ‘error’; error: Error; }

さらに、これを利用して「状態に応じたハンドラー関数（パターンマッチング）」の引数の型を動的に決定するユーティリティを組む。

/

• 2. レスポンスの状態に応じた厳密なハンドラー型定義

/
type ApiHandler = {
[K in TResponse[‘status’]]: (payload: ExtractResponseByStatus) => void;
};

// 実装例：ハンドラーオブジェクトの型が完全に強制される
const userHandler: ApiHandler = {
loading: () => {
console.log(‘Loading…’);
},
success: (res) => {
// res.data は { id: string; name: string; email: string; } であることが保証される
console.log(`Welcome, ${res.data.name}`);
},
error: (res) => {
// res.error は Error 型であることが保証される
console.error(res.error.message);
}
};

この設計の美しさは、APIレスポンスの構造（`ApiResponse`）が変更された際、`ApiHandler` の実装側でコンパイルエラーとして即座に検知できる点にある。保守性は飛躍的に向上する。

—

3. 高度な応用：推論（`infer`）の合わせ技

条件付き型を真に強力にしているのが `infer` キーワードだ。これを使うことで、条件付き型のマッチングプロセスの中で、未知の型を「キャプチャ（推論）」して取り出すことができる。

例えば、関数の戻り値型や、Promiseの中身の型（Awaitedの自作）を動的に抽出するケースだ。

/

• 自製 DeepAwaited: ネストしたPromiseや配列を再帰的にアンラップする

/
type DeepUnwrap =
T extends Promise ? DeepUnwrap :
T extends Array ? Array> :
T;