関数シグネチャにおける「引数の依存関係」の罠
フロントエンドのコンポーネント設計や、型安全なAPIクライアントを構築しているとき、次のようなコードに直面したことはないだろうか。
// ❌ やってはいけない「なんちゃって型定義」のアンチパターン
type EventType = ‘click’ | ‘change’ | ‘submit’;
interface EventPayloadMap {
click: { x: number; y: number };
change: { value: string };
submit: { formData: Record
}
function sendEvent(type: EventType, payload: EventPayloadMap[EventType]) {
// 処理…
}
// 呼び出し側
sendEvent(‘click’, { value: ‘hoge’ }); // 💥 コンパイルエラーにならない！ (click なのに change の payload が渡せてしまう)
このコードの問題点に気づいただろうか。`EventPayloadMap[EventType]` と書いた瞬間、TypeScriptは联合型（Union）の分散（Distributive）を引き起こし、`payload` の型は `EventPayloadMap[‘click’] | EventPayloadMap[‘change’] | EventPayloadMap[‘submit’]` のスーパーセット（すべてのプロパティを内包する許容範囲の広い型）に落ち込んでしまう。
結果として、`click` イベントに対して `change` のペイロードを渡しても、TypeScriptコンパイラはエラーを検知できない。「引数の値（`type`）によって、別の引数（`payload`）の型が完全に決定される」という依存関係が、型システムに正しく伝わっていないからだ。
本記事では、この課題をジェネリクスと条件付き型（Conditional Types）を駆使して完全に克服し、コンパイルタイムにバグを駆逐するプロダクションレベルの設計パターンを伝授する。
—
解決アプローチ：条件付き型連鎖とジェネリック制約
TypeScriptの型システムにおいて、引数同士の依存関係を表現するためのアプローチは主に2つある。
1. ジェネリックパラメータの推論（Inference from Parameters）
2. ディスパッチング・ユニオン（分派型）によるシグネチャのオーバーロード
実務で最も美しく、拡張性が高いのは「ジェネリクスによる推論と制約の組み合わせ」だ。先ほどの `sendEvent` を、型安全の要塞へと生まれ変わらせてみよう。
匠のプロダクションコード例
/
- 1. ドメインの型定義（拡張性を見据えたマップ構造）
/
interface EventRegistry {
click: { x: number; y: number; button: ‘left’ | ‘right’ };
change: { targetName: string; value: string };
submit: { formData: Readonly
}
type EventKey = keyof EventRegistry;
/
- 2. 依存関係を完全に制御する関数シグネチャ
- T extends EventKey によって、第一引数は EventRegistry のキーのいずれかに制限される。
- さらに、payload はインデクスアクセス型 T[K] を用いて動的に決定される。
/
function dispatchDomainEvent
type: T,
payload: EventRegistry[T]
): void {
console.log(`[Event Dispatch]: ${type}`, payload);
}
// ==========================================
// 呼び出し側の検証（IDEの補完と型チェック）
// ==========================================
// ✅ 完璧な組み合わせ：型エラーなし
dispatchDomainEvent(‘click’, { x: 100, y: 200, button: ‘left’ });
// ✅ 完璧な組み合わせ：型エラーなし
dispatchDomainEvent(‘change’, { targetName: ‘username’, value: ‘architect’ });
// ❌ コンパイルエラー:
// Argument of type ‘{ x: number; y: number; button: string; }’ is not assignable to parameter of type ‘{ targetName: string; value: string; }’.
dispatchDomainEvent(‘change’, { x: 100, y: 200, button: ‘left’ });
この実装において、第一引数に `’change’` を渡した瞬間、TypeScriptの推論エンジンは `T` を `’change’` として確定させ、第二引数 `payload` に要求される型を瞬時に `EventRegistry[‘change’]` へと特化させる。これが「引数の依存関係を型レベルで担保する」ということの本質だ。
—
さらに実践的：戻り値の型も依存させる（APIクライアントの設計）
実務では、引数だけでなく「戻り値の型」も別の引数に依存するケースが頻出する。例えば、エンドポイントやメソッド名に応じて、返ってくるレスポンスの型が厳密に変わる非同期APIラッパーを設計する場合だ。
// エンドポイントごとのスキーマ定義
interface ApiEndpoints {
‘/users’: {
query: { limit?: number; offset?: number };
response: Array<{ id: string; name: string }>;
};
‘/settings’: {
query: { userId: string };
response: { theme: ‘dark’ | ‘light’; notifications: boolean };
};
}
/
- エンドポイント（URL）に依存して、queryの型とPromiseの戻り値の型が自動的に決まるfetcher
/
async function apiFetch
endpoint: T,
query: ApiEndpoints[T][‘query’]
): Promise
// モックとしての実装
const mockParams = new URLSearchParams(query as Record
const response = await fetch(`${endpoint}?${mockParams}`);
return response.json() as Promise
}
// — 現場での利用例 —
// usersUsers の型は自動的に Array<{ id: string; name: string }> に推論される
const users = await apiFetch(‘/users’, { limit: 10 });
users[0].name; // 補完が効き、型安全
// settings の型は自动的に { theme: … } に推論される
const settings = await apiFetch(‘/settings’, { userId: ‘123’ });
settings.theme; // 補完が効き、型安全
// 💥 コンパイルエラー: ‘/settings’ なのに limit を渡そうとすると怒られる
await apiFetch(‘/settings’, { limit: 10 });
—
パフォーマンス上の注意点とコンパイラ負荷への配慮
テクニカルリーダとしてチームにコードを導入する際、パフォーマンスへの配慮を忘れてはならない。TypeScriptの型推論は強力だが、複雑すぎる条件付き型や、巨大なユニオン型の乱用は、コンパイル時間（TSServerの応答速度）を劇的に悪化させる。
1. 型のインデックスアクセスを活用し、無駄な `infer` や条件分岐を避ける
Conditional Types (`T extends … ? A : B`) を何重にもネストさせると、TypeScriptコンパイラはパスの組合せを爆発的に計算し始める。可能な限り、上記で示したような `EventRegistry[T]` のようなダイレクトなインデックスアクセス を優先せよ。これらはコンパイラにとって非常に処理コストが低い。
2. `as const` との組み合わせによるリテラル型の維持
関数の引数に渡すオブジェクトが、途中で `string` や `number` にWidening（型の拡幅）されてしまうと、ジェネリクスの推論が失敗する原因になる。
const config = {
endpoint: ‘/users’,
query: { limit: 10 }
} as const; // 必ずリテラル型として固定する
apiFetch(config.endpoint, config.query);
—
まとめ：型定義は「ドキュメント」であり「コンパイル時の単体テスト」である
優れた型定義は、コードを書いているその瞬間にエディタ上でバグを消滅させる。今回解説した「引数の依存関係をジェネリクスで表現する手法」は、単なるテクニックではなく、「不正な状態を表現不可能な型にする（Make illegal states unrepresentable）」という堅牢な設計思想の具現化だ。
明日からのコードレビューで、引数同士の関係性が曖昧なコードを見つけたら、ぜひこのジェネリックな依存関係のパターンを導入し、チームのコードベースをワンランク上の高みへと導いてほしい。