なぜその「ファクトリ関数」は型安全ではないのか？
コードレビューをしていて、次のようなコードに出くわすことはないだろうか。
// よくある「一見動くが、型安全の担保がザルな」ファクトリ
function createInstance(ctor: any, …args: any[]): any {
return new ctor(…args);
}
フロントエンドのコンポーネント駆動設計、あるいはNode.jsでのプラグイン機構やDI（依存性注入）コンテナを実装していると、「特定のインターフェースを実装したクラスのコンストラクタ」を引数に受け取り、安全にインスタンス化するファクトリ関数を書きたくなる場面に多々遭遇する。
しかし、上記の `any` を使った実装や、浅い知識で書かれた `Function` 型の利用は、TypeScriptの恩恵を自ら捨てる行為に他ならない。コンパイル時には何も検知されず、実行時になって初めて `TypeError: ctor is not a constructor` や、予期せぬプロパティの欠落に悩まされることになる。
今回は、TypeScriptの型システムを極限まで駆動させ、「特定のインターフェースを満たすクラスのみを受け入れ、そのコンストラクタ引数まで完璧に推論・保証するファクトリ関数」を実装するベストプラクティスを伝授する。
—
1. 基礎：クラスコンストラクタの型表現
TypeScriptにおいて、クラスは「インスタンスの型」であると同時に、値としては「コンストラクタ関数」である。
ここで重要になるのが、`new` シグネチャを持つオブジェクト型、すなわちコンストラクタ型（Constructor Type）の理解だ。
interface
id: string;
render(): void;
}
// これが「インターフェース T を実装したクラスのコンストラクタ型」の基本形
type ComponentConstructor
この `new (…args: any[]) => T` という記法により、TypeScriptコンパイラに対して「この関数（またはオブジェクト）は、`new` 演算子と共に呼び出すことができ、戻り値として `T` 型のインスタンスを返す」という契約を結ばせることができる。
—
2. 実践：コンストラクタ引数を完璧に推論するファクトリ関数
単に「インスタンスが返る」だけでは実務の役には立たない。クラスごとに異なるコンストラクタの引数（パラメータ）の型を、ファクトリ関数の呼び出し元で完全に静的解析させたい。
ここでージェネリック・パラメータの伝播（Propagation）と、組み込みユーティリティ型 `ConstructorParameters
以下のプロダクションコードを見てほしい。これが、TypeScriptの型推論を極限まで活かした究極のファクトリ実装だ。
/
- 1. ベースとなるインターフェースの定義
/
interface IPlugin {
name: string;
initialize(): Promise
}
/
- 2. クラスのコンストラクタ型を表現する汎用型
- C は IPlugin を満たすインスタンスを返す、任意のコンストラクタ
/
type PluginConstructor
/
- 3. 堅牢なプラグイン・ファクトリ関数
- 【ここがポイント】
- 抽象クラスや具象クラスのコンストラクタ型 `C` をジェネクスで受け、
- `ConstructorParameters
` を利用して、インスタンス化に必要な引数の型を - ファクトリ関数の第2引数以降へ完全にスルーレイ（転送）する。
/
function createPluginInstance
ctor: C,
…args: ConstructorParameters
): InstanceType
// 実行時のアサーションや追加のライフサイクル検証をここに挟むことも可能
const instance = new ctor(…args);
// 例: インスタンス生成直後の共通バリデーション
if (typeof instance.initialize !== ‘function’) {
throw new Error(`Invalid plugin: ${ctor.name} must implement initialize() method.`);
}
return instance;
}
// ==========================================
// 使用例（プロダクションコード）
// ==========================================
// 具象クラスA：引数なし
class AnalyticsPlugin implements IPlugin {
public name = ‘Analytics’;
async initialize() { console.log(‘Analytics initialized’); }
}
// 具象クラスB：設定オブジェクトを引数に取る
interface LoggerOptions {
level: ‘debug’ | ‘info’ | ‘error’;
}
class LoggerPlugin implements IPlugin {
public name = ‘Logger’;
constructor(private options: LoggerOptions) {}
async initialize() { console.log(`Logger initialized with level: ${this.options.level}`); }
}
// 正常系：型安全にインスタンス化される
const analytics = createPluginInstance(AnalyticsPlugin);
// 型: AnalyticsPlugin
// 引数なしなので追加引数は不要
const logger = createPluginInstance(LoggerPlugin, { level: ‘debug’ });
// 型: LoggerPlugin
// 第2引数に LoggerOptions が強制的・自動的に要求される！
// 異常系（コンパイルエラー）の検知：
// const invalid = createPluginInstance(LoggerPlugin);
// -> ❌ Error: Expected 2 arguments, but got 1. (LoggerOptions が不足しているためコンパイルエラー)
// const wrongClass = createPluginInstance(class NotAPlugin {});
// -> ❌ Error: Argument of type ‘typeof NotAPlugin’ is not assignable to parameter of type ‘PluginConstructor’.
// (IPlugin インターフェースを満たしていないため拒絶される)
—
3. この設計がもたらす圧倒的な優位性
なぜこのパターンが「極限まで堅牢」と言えるのか。テクニカルリードの視点から、その理由をロジカルに分解する。
1. `ConstructorParameters
クラス側のコンストラクタシグネチャを変更（例: 引数を追加・削除）した際、ファクトリ関数の呼び出し側を修正し忘れても、TypeScriptコンパイラが即座にビルドを失敗させてくれる。手動での型定義の二重管理（DRY原則の違反）が完全に排除される。
2. `InstanceType
`any` や基底インターフェース (`IPlugin`) ではなく、具象クラスそのものの型 (`AnalyticsPlugin`, `LoggerPlugin`) として戻り値が推論される。そのため、具象クラス特有のプロパティやメソッドにアクセスする際も、型キャスト（Type Assertion）が一切不要になる。
3. 構造的型付け（Structural Subtyping）によるインターフェース強制
`C extends PluginConstructor` の制約により、「`IPlugin` の構造を持たないクラス」をコンパイルタイムで完全に弾き出す。誤ったモジュールがDIコンテナに登録されるバグを根絶する。
—
4. パフォーマンスとコンパイル時の注意点
TypeScriptの高度な型操作（特に条件付き型や組み込みユーティリティ型）を多用すると、大規模なコードベースにおいてIDE（VSCodeなど）の型推論の速度（TSServerの応答性）に悪影響を及ぼすことがある。
- 過剰なネストを避ける: 型定義のモジュール化を進めるあまり、何層ものジェネリック型をラップしすぎると、エラーメッセージが解読不能なほど長大化する（いわゆる「Type instantiation is excessively deep and possibly infinite」エラー）。
- `abstract class` への配慮: もしファクトリに渡されるクラスがインスタンス化不可能な抽象クラスであるべきではない場合、コンストラクタ型にアノテーションを追加してインスタンス化を制限することも視野に入れよ。
// 抽象クラスの混入を防ぎたい場合のテクニック
type ConcretePluginConstructor
abstract new (…args: any[]) => never; // 抽象クラスは new できな…
// いや、ここでは逆に「抽象クラスではないこと」を強制するために抽象コンストラクトシグネチャを排除する
// 通常の new シグネチャのみであれば抽象クラスは代入できない（TypeScriptの仕様により抽象クラスのコンストラクタは abstract new となるため）
TypeScriptの仕様上、`abstract class` のコンストラクタ型は `abstract new (…) => T` となり、通常の `new (…) => T`（具象クラス専用）とは厳密に区別される。したがって、上記の `new (…args: Args) => T` という定義だけで、誤って抽象クラスがファクトリに渡されるのを防ぐ防壁としても機能するのだ。
—
結びにかえて
型定義は、単なる「エディタの補完をリッチにするおまけ」ではない。「実行時エラーをコンパイル時エラーに昇華させ、プロダクトの信頼性を担保する最初の防衛線」である。
今回解説した `ConstructorParameters` とジェネリックなコンストラクタ型の組み合わせは、DI、プラグインシステム、コンポーネントローダーなど、あらゆるメタプログラミング的なアプローチにおいて強力な武器となる。
あなたのコードベースの `any` を撲滅し、コンパイラを最も優秀なレビュアーへと仕立て上げるために、ぜひ今日の業務からこのパターンを導入してみてほしい。