TypeScriptの型システムを「単なる型の羅列」から「コンパイル時に関数を実行するメタプログラミング環境」へと昇華させる鍵、それが Conditional Types（条件付き型） です。
フロントエンドのコンポーネント設計や、型安全なAPIクライアントを書く際、「引数の型によって戻り値を完全に連動させたい」という要件に直面したことはないでしょうか。古臭い関数のオーバーロード（Function Overloads）で型を何行も並べ立てるのは、メンテナンスの観点からも、コンパイラの評価パフォーマンスの観点からも、もう終わらせるべきアンチパターンです。
今回は、実務の現場で即座に使える、Conditional Typesを用いた「引数の型による戻り値の動的変換」の極限設計をコードレビューの視点から伝授します。
—
なぜ「オーバーロード」ではなく「Conditional Types」なのか？
関数オーバーロードは、見かけ上は美しくとも、以下のような致命的なスケーラビリティの限界を抱えています。
1. 実装シグネチャの乖離: オーバーロードシグネチャと、実際の処理を行う実装シグネチャ（Implementation Signature）の型が緩くなりがちで、内部で `as any` の魔術に頼らざるを得なくなる。
2. 分岐の組合せ爆発: 引数のバリエーションが増えた際、すべての順列をオーバーロードで定義すると、TypeScriptコンパイラの型チェックコスト（Instantiation depth）が跳ね上がり、IDEの補完が重くなる。
Conditional Typesを活用すれば、「入力された型 $T$ を条件分岐させ、単一のジェネリック関数シグネチャで厳密な戻り値を導出する」 ことが可能です。これにより、コンパイラは型評価を効率的に行い、IDEのレスポンスも劇的に改善されます。
—
実践：APIクライアントにおける「モード別」動的戻り値の設計
例として、実務で頻出する「フェッチするリソースの種類（モード）によって、返却されるデータの構造が完全に変わる汎用APIラッパー」を設計します。
ここでは、アンチパターンとなるオーバーロードの迷宮を避け、Conditional TypesとTemplate Literal Typesを融合させたプロダクションクオリティのコードを示します。
プロダクションコード例
/
- APIリソースの定義マップ（Single Source of Truth）
/
interface ApiResourceMap {
user: { id: string; name: string; email: string };
post: { id: number; title: string; body: string; published: boolean };
settings: { theme: ‘light’ | ‘dark’; notifications: boolean };
}
/
- リソースのキー型
/
type ApiResourceKey = keyof ApiResourceMap;
/
- 応用要件：フェッチオプションの挙動も型で制御する
- raw: true の場合はパース前のレスポンスオブジェクトを返す
/
interface FetchOptions
resource: T;
id?: string;
raw?: TRaw;
}
/
- 【極限の型設計】Conditional Types による戻り値の動的変換
- 引数 `Options` の `raw` プロパティが `true` なら Response型、
- そうでなければ ApiResourceMap から引いたドメインモデル型を返す。
/
type FetchResult<
T extends ApiResourceKey,
Options extends FetchOptions
> = Options[‘raw’] extends true
? Response
: ApiResourceMap[T];
/
- 型安全な汎用APIフェッチャー
- 実装シグネチャは1つのみ。内部の `as` は型システムの保証下で安全に機能する。
/
declare function fetchApiResource<
T extends ApiResourceKey,
Options extends FetchOptions
>(options: Options): Promise
// ==========================================
// 実際の利用シーン（すべてコンパイル時に型が確定）
// ==========================================
async function run() {
// 1. 通常モード: resourceが ‘user’ なので、戻り値は Promise<{ id: string; name: string; email: string }>
const user = await fetchApiResource({ resource: ‘user’, id: ‘123’ });
console.log(user.name); // 完全に型安全。IDEの補完が効く
// 2. 投稿モード: resourceが ‘post’ なので、戻り値は Promise<{ id: number; title: string; ... }>
const post = await fetchApiResource({ resource: ‘post’ });
console.log(post.title); // 正常
// 3. Rawレスポンスモード: raw: true を指定した瞬間、戻り値が強制的に Promise
const rawResponse = await fetchApiResource({ resource: ‘settings’, raw: true });
// rawResponse.json(); 等の Response のメソッドが利用可能
console.log(rawResponse.ok);
}
—
コードレビュー：なぜこの設計が優れているのか？
チーフアーキテクトの視点から、このコードが持つ優位性を3つのポイントで解説します。
1. 「分散条件付き型（Distributive Conditional Types）」の回避と制御
ジェネリック型パラメータが裸の型（naked type parameter）である場合、Union型が渡されるとConditional Typesは自動的に分散（Distribute）され、予期せぬUnionの戻り値を返してしまいます。
今回の `Options[‘raw’] extends true` のように、特定のプロパティを参照する形式にすることで、不必要な分散を防ぎ、精緻な型評価を維持しています。
2. メンテナンス性の圧倒的な高さ
新しいAPIエンドポイントが追加された場合、開発者が修正すべきは `ApiResourceMap` インターフェースの1箇所だけです。関数のシグネチャや内部の型定義を書き換える必要は一切ありません。これが「拡張に開く（Open-Closed Principle）」の型レベルでの実現です。
3. 実行時オーバーヘッドのゼロ化
TypeScriptの型はすべてコンパイル時に消去されます。どれほど複雑なConditional Typesを組もうとも、出力されるJavaScriptは極めてクリーンな単一の関数になり、実行時のパフォーマンスに一切悪影響を与えません。
—
パフォーマンス上の注意点（型システムの最適化）
Conditional Typesを多用する際、一つだけ注意すべきなのが 「TypeScriptコンパイラの型 instantiation（インスタンス化）コスト」 です。
複雑キッチュな条件分岐を何重にもネストさせると、TypeScriptの言語サーバー（tsserver）がCPUを大量消費し、エディタのタイピングが重くなる現象（いわゆる「型地獄」）が発生します。
対策:
- 条件分岐はなるべく浅く保つ。
- 複雑な判定結果は、一度ヘルパー型（例：`isTrue
` など）に切り出し、意味のある名前をつけてキャッシュ（再利用）しやすい形にする。 - `infer` キーワードを組み合わせる際は、不要なユニオンの爆発を避けるために `[T] extends [U]` のようにタプルでラップして分散を抑制するテクニックを忘れないこと。
—
まとめ
型は単なる「エラー検出ツール」ではありません。「ドメインの仕様をコードの構造そのものに埋め込み、不正な状態や間違った使い方の余地をコンパイル時に抹殺するための契約書」 です。
オーバーロードの泥沼から脱却し、Conditional Typesを駆使したダイナミックな型推論を手に入れたとき、あなたの書くTypeScriptコードは、読む者を唸らせる芸術品へと昇華するでしょう。
今日の業務から、無駄なオーバーロードを消し去り、型による真の動的表現を実装してみてください。