【実務・中級編】引数に渡す「関数」の戻り値型を別の引数の型として利用する「依存型」のシミュレーション – TypeScript コア・型システムの基礎解析バイブル

フロントエンド開発や複雑な非同期API連携の現場で、こんなコードに直面したことはないだろうか。

「ある関数が別の関数を引数として受け取る。そして、その引数関数の戻り値の型が、別の引数の入力型として制約にならなければならない」

純粋な依存型（Dependent Types）を持つ言語（IdrisやAgdaなど）であれば一撃で解決できるこの問題も、TypeScriptの静的型システムの上では一筋縄ではいかない。なぜなら、TypeScriptの型評価は基本的に「上から下へ、左から右へ」進行し、同一スコープ内の引数同士が動的に依存し合う関係をデフォルトでは構築できないからだ。

コードレビューでよく見かけるのが、ここを `any` や `unknown` で逃げたり、不毛な型アサーション（`as`）でコンパイラを黙らせているアンチパターンだ。

今回は、TypeScriptのジェネリクスと条件付き型（Conditional Types）、そして推論の方向性を制御するテクニックを駆使し、「引数に渡す関数の戻り値型を別の引数の型として完全に連動させる（依存型をシミュレーションする）」ための極限の設計パターンを伝授する。

—

なぜ通常の関数定義では「引数間の依存」が破綻するのか？

まず、よくある失敗例を見てほしい。APIクライアントやフォームビルダーなどによくあるユースケースだ。

// 【アンチパターン】これでは型が連動しない
function processPayload(
factory: () => unknown, // 何を返すか分からない
handler: (data: unknown) => void // 型安全性が完全に死んでいる
) {
const data = factory();
handler(data);
}

このコードの問題点は明白だ。`factory` が何を返すのかをコンパイラが固定できないため、`handler` の引数 `data` は `unknown` になり、呼び出し側で型安全性を一切担保できなくなる。

「じゃあ、ジェネリクスを使えばいいじゃないか」と、以下のように書く開発者がいる。

// 【惜しいが、まだ不完全なアプローチ】
function processPayload(
factory: () => T,
handler: (data: T) => void
) {
// …
}

一見うまく動きそうに見える。しかし、実務でこのシグネチャを使うと、呼び出し側でジェネリクスを明示的に渡さなければ推論が崩壊するケースや、コールバックのクロージャ内で型がミスマッチを起こす現象に直面する。特に、関数のオーバーロードや、複数の引数が複雑に絡み合う高度なコンポーネント設計においては、このナイーブな型パラメータの配置ではコンパイラは音を上げてしまう。

真に堅牢な依存関係を構築するには、「型推論の方向（Inference Direction）」をコンパイラに正しく指し示す必要がある。

—

解決策：ジェネリクスの単一方向バインディングと制約の連鎖

TypeScriptのコンパイラ（tsserver）に「まず `factory` の戻り値を推論させ、その型を `handler` の引数に強制的にバインドせよ」と伝えるためのプロダクションコードを見てほしい。

以下のコードは、型安全性が完全に保たれた状態の「依存型シミュレーション」の完成形だ。

/

  • 任意のコンテキストとファクトリー、そしてその結果を処理するハンドラーを受け取る
  • 依存型シミュレーション・エンジン

/
type AsyncFactory = () => Promise | T;
type ResultHandler = (result: T) => void | Promise;

interface ExecutionContext> {
/ 1. データを生成するファクトリー関数 /
factory: TFactory;

/

  • 2. factoryの戻り値型（TFactoryから抽出）に厳密に依存するハンドラー
  • ReturnType を使うことで、戻り値がPromiseであってもアンラップした型を追跡可能にする

/
handler: ResultHandler>>;

/ 3. エラーフック（オプショナル） /
onErrorHandler?: (error: unknown) => void;
}

/

  • 実行関数：コンパイラに型の依存関係を正しく推論させる

/
async function executeWithDependency>(
config: ExecutionContext
): Promise {
try {
// 実行時に型が完全に保証されているため、無駄なキャストは不要
const rawData = config.factory();
const data = rawData instanceof Promise ? await rawData : rawData;

await config.handler(data);
} catch (error) {
if (config.onErrorHandler) {
config.onErrorHandler(error);
} else {
throw error;
}
}
}

この設計が優れている理由（コンパイラ内部の挙動）

1. `Awaited>` の活用
`factory` が同期関数であっても非同期（Promiseを返す）であっても、コンパイラは `Awaited<>` ユーティリティ型を通じて「最終的に解決される値の型」を正確に抽出する。
2. 単一の型パラメータ `TFactory` による依存の閉じ込め
関数全体のジェネリクスをむやみに増やさず、`TFactory` という単一の型変数から `ReturnType` を経由して `handler` の型を導出している。これにより、TypeScriptの型推論エンジンは「推論の競合（Inference Conflict）」を起こさず、一意に型を決定できる。

—

実務での応用：APIクライアントとバリデーションの結合

このパターンが真価を発揮するのは、例えば「APIからデータを取得する関数」と「そのデータを処理するコンポーネントのPropsやバリデーター」を1つのパイプラインに流し込むようなシーンだ。

実務でそのままコピー＆ペーストして使える、より実践的なモジュールの例を示す。

// — 実務応用コード —

type ApiFetcher = (signal: AbortSignal) => Promise;
type ValidatorFn = (data: TInput) => boolean;

interface PipelineConfig> {
fetcher: TFetcher;
// ここで fetcher の解決値型（Awaited>）が、
// バリデーターの引数型に完全に依存・強制される
validator: ValidatorFn>>;
onSuccess: (data: Awaited>) => void;
}

export async function createValidatedPipeline>(
config: PipelineConfig
): Promise {
const controller = new AbortController();

// 型安全なフェッチ処理
const data = await config.fetcher(controller.signal);

// バリデーション実行（dataの型は正しく推論されている）
const isValid = config.validator(data);

if (!isValid) {
throw new Error(“Pipeline validation failed: Data structure mismatch.”);
}

config.onSuccess(data);
}

// ==========================================
// 【利用側のコード（IDEでの補完と型安全性の検証）】
// ==========================================

// モックAPI
const fetchUserProfile = async (_signal: AbortSignal) => {
return {
id: 1,
name: “Architect”,
roles: [“admin”, “core-dev”] as const,
};
};

// 実行
createValidatedPipeline({
fetcher: fetchUserProfile,

// 💡 ここで引数 `data` の型は自動的に { id: number; name: string; roles: readonly (“admin” | “core-dev”)[] } に固定される！
validator: (data) => {
// 存在しないプロパティにアクセスしようとすると、即座にコンパイルエラーになる
return data.id > 0 && data.name.length > 0;
},

onSuccess: (data) => {
console.log(`Welcome, ${data.name}!`);
},
});

このコードを書いてIDE（VSCode等）で確認してほしい。`validator` の引数 `data` にマウスオーバーした瞬間、手動で型注釈を書いていないにもかかわらず、`fetchUserProfile` の戻り値構造が完璧に逆算されて推論されていることが分かるはずだ。

—

パフォーマンスと型評価のコストに関する知見

チーフアーキテクトとして、パフォーマンスの観点についても言及しておかねばならない。

TypeScriptの型システムはTuring Complete（チューリング完全）であるため、過度に複雑な条件付き型や、無限にネストするジェネリクスを多用すると、LSP（Language Server Protocol）の応答速度が著しく低下し、エディタの動作が重くなる（いわゆる「Red Squiggly（赤波線）の遅延」）。

今回の設計で意識すべきパフォーマンス上のベストプラクティスは以下の2点だ。

1. ホイスト（事前定義）可能なユーティリティ型の活用
複雑なインラインの条件付き型を関数シグネチャに直接書くのではなく、`AsyncFactory` や `ResultHandler` のように一度名前を付けた型（Type Alias）として切り出すこと。これにより、TypeScriptコンパイラは型をキャッシュしやすくなり、型評価のオーバーヘッドが軽減される。
2. `any` の適切な境界防御
`TFactory extends AsyncFactory` のように、制約のベースラインに `any` を用いることは、型安全性を緩めるものではなく、「任意の返り値を持つ関数を受け入れる」というジェネリクスのワイルドカードとして機能する。ここを `unknown` にすると、関数のシグネチャとの互換性エラー（Type ‘unknown’ is not assignable to type ‘Function’ 等）を踏みやすくなるため、あえて `any` で境界を抽象化するのがコンパイラとの正しい付き合い方だ。

—

まとめ

TypeScriptにおける「依存型シミュレーション」は、言語仕様の隙間を縫うテクニックではなく、モダンなフロントエンド・バックエンドアーキテクチャにおいて堅牢性を担保するための必須教養である。

  • 引数間の型依存は、単一のジェネリックパラメータと `ReturnType` / `Awaited` を組み合わせることで解決する。
  • コンパイラに正しい推論の方向性を教えることで、開発者の手動による型注釈（ボイラープレート）を極限まで削減できる。
  • 保守性の高いコードとは、型アサーション（`as`）を排除し、コンパイラの静的解析能力を120%引き出したコードのことだ。

次のコードレビューで、誰かが `any` や `unknown` で引数の型をごまかしているのを見かけたら、このパターンを静かに差し出してほしい。あなたのチームのコードベースは、一段上のステージへと進化するはずだ。

スポンサーリンク
タイトルとURLをコピーしました