【実務・中級編】Interfaceの「ジェネリクス制約」におけるinferの活用：関数の戻り値を抽出する型定義 – TypeScript コア・型システムの基礎解析バイブル

Interfaceとinferの深淵：関数シグネチャから「型」を抽出する極限の設計術

TypeScriptの型システムを「単なるガードレール」だと思っているなら、それは大きな誤解だ。型は、実行時の挙動を記述する「コードの設計図」そのものである。

特に、大規模なフロントエンド開発や複雑なAPIクライアントを構築する際、「外部から与えられた関数の戻り値だけを抽出して、別の型として再利用したい」という要件は頻出する。このとき、多くのエンジニアが `ReturnType` を安易に使い、あるいは型をハードコーディングして技術的負債を積み上げる。

本稿では、`interface`と`infer`を組み合わせ、コンパイラの推論能力を極限まで引き出すプロフェッショナルな型抽出の設計手法を伝授する。

—

なぜ「推論（infer）」が必要なのか

TypeScriptの型システムにおいて、`infer` はブラックボックスである関数の内部構造を透視する唯一の手段だ。

例えば、Reactのカスタムフックや、外部ライブラリのAPIが返す複雑なオブジェクトから、特定のプロパティの型を抽出したい場面を想像してほしい。型エイリアスで愚直に記述することも可能だが、再利用性やDRY原則を考慮すると、「関数シグネチャを引数として受け取り、その戻り値を分解する」というジェネリクス制約付きのインターフェース設計が最も堅牢だ。

実践：関数シグネチャから戻り値を抽出する汎用Interface

まず、単なる `ReturnType` を超えた、実戦配備可能な抽出器を見てみよう。

Tが関数であることを保証し、その戻り値を抽出する抽出器。
@template T – 関数型である必要がある
@template R – 抽出された戻り値の型（自動推論）

/
interface ExtractReturnValue any> {
// infer R を使い、関数の戻り値をRとして確定させる
result: T extends (…args: any[]) => infer R ? R : never;
}

// 使用例：API通信の戻り値を抽出する
const fetchUserData = async (id: string) => ({
id,
name: “John Doe”,
roles: [“admin”, “editor”] as const
});

// この関数の戻り値の型を、関数を実行せずに「型」として取得する
type UserData = ExtractReturnValue[“result”];

// UserDataは自動的に { id: string; name: string; roles: readonly (“admin” | “editor”)[] } になる

この設計の凄み

型安全性の担保: `T extends (…args: any[]) => any` と制約をかけることで、関数以外の型が渡された瞬間にコンパイルエラーを吐く。
計算コストの低減: TypeScriptのコンパイラは型評価においてキャッシュを行う。この形式でインターフェースを定義しておけば、大規模なプロジェクトでも型推論の競合が起きにくい。

—

現場で使える「Advancedパターン」：非同期APIのデータ抽出

実務では、`Promise`でラップされた値を扱うことが多いはずだ。単なる `ReturnType` では `Promise` が返ってきてしまい、後続の型変換で躓く。ここで `infer` を二重に使うテクニックが光る。

非同期関数の「解決後の値」のみを抽出する

/
type UnwrappedAsyncReturn = T extends (…args: any[]) => Promise
? R
: never;

// 使用例：
async function getSettings() {
return { theme: “dark”, notifications: true };
}

// 複雑なPromiseの階層を無視して、中身のオブジェクト型だけを取り出す
type Settings = UnwrappedAsyncReturn;
// => { theme: string; notifications: boolean; }

パフォーマンスと保守性の注意点

「型を複雑にすればするほど、コンパイル速度は落ちる」。これがTSの冷厳な事実だ。

1. 過度なネストを避ける: インターフェースのジェネリクス制約は強力だが、3段階以上の条件付き型（Conditional Types）のネストは避けるべきだ。コンパイラの推論深度（Recursion depth）制限に触れ、`Type instantiation is excessively deep` という悪名高いエラーに直面することになる。
2. 型定義を名前付きでエクスポートする: `type T = …` とインラインで書くよりも、上記のように `interface` や名前付き `type` に切り出すことで、IDEの推論ヒント（ホバー時の表示）が劇的に読みやすくなる。

チーフアーキテクトからの助言

多くのエンジニアが「型は書くもの」だと勘違いしている。しかし、真のTypeScriptマスターは「型を導き出す」。

今回紹介した `infer` を活用した設計は、APIの仕様変更が起きたとき、型定義を書き換える必要をなくすための布石だ。元の関数を修正すれば、それに依存する全ての型定義がコンパイル時に自動的に追従する。これこそが、メンテナンスコストをゼロに近づける「宣言的プログラミング」の極致である。

次にコードを書く際、`any` で逃げたくなったその瞬間、一度立ち止まって考えてみてほしい。「この型は、推論できないほど複雑なのだろうか？」と。大抵のケースで、`infer` は答えを知っているはずだ。