TypeScriptの深淵：Interfaceの拡張か、交差型(Intersection)か？ コンパイル時間を支配する「型評価」の真実
大規模なReactプロジェクトや複雑なNode.jsバックエンドを設計する際、多くのエンジニアが「なんとなく」で`interface`と`type`を使い分けている。しかし、型定義が数万行を超えるプロジェクトにおいて、その選択は単なるコーディングスタイルの問題ではない。TypeScriptコンパイラ（`tsc`）のパフォーマンスと、IDEの応答速度を左右する死活問題なのだ。
今日は、TypeScriptの型システムにおける「型評価戦略」の裏側を覗き、なぜ大規模コードベースで`interface`の拡張（`extends`）が推奨されるのか、その技術的根拠を紐解いていく。
—
1. 内部挙動の違い：型検査器は「どう」評価しているのか
まず、`interface`と`type`の最大の決定的な違いを理解する必要がある。それは「型がどうキャッシュされるか」だ。
インターフェースの拡張 (extends)
インターフェースは「名前付きの型」として保持され、拡張されると、コンパイラはそれを単一のオブジェクト型としてメモリ上にキャッシュする。型解決を行う際、コンパイラは宣言をマージし、単一の構造体として効率的に型チェックを実行する。
交差型 (Intersection / `&`)
交差型は「型Aと型Bを組み合わせる」という計算式そのものだ。コンパイラは、交差型が出現するたびに「プロパティの再計算」を行う。大規模プロジェクトで無闇に`type T = A & B & C & D…`と積み上げると、コンパイラは型を評価するたびに複雑な計算を繰り返すことになり、メモリ消費量が指数関数的に増大する。
—
2. なぜ「交差型」はコンパイルを鈍化させるのか
`type`による交差型は、コンパイラにとって「遅延評価される計算式」である。
- インターフェースの拡張: 評価済みの結果（キャッシュ）を再利用できる。
- 交差型: 参照されるたびに、型の構成要素を再帰的に展開し、プロパティの競合を解決し、整合性を検証する。
特に、ReactのPropsやAPIレスポンスの型定義で「汎用的な型を細かく`&`で繋ぐ」設計を多用すると、TSサーバーのCPU使用率は跳ね上がり、VS Codeの「型チェック中…」の時間が伸びる。これが大規模プロジェクトにおける「DX（開発者体験）の死」の正体だ。
—
3. 実践：保守性が高く、かつコンパイラに優しい設計パターン
実務では、以下の基準で型を選択してほしい。
1. 基本は `interface` を使う: オブジェクト型であれば、迷わず`interface`だ。拡張性があり、エラーメッセージも明快になる。
2. `type` は「型計算」にのみ使う: `Pick`, `Omit`, `Partial` などのユーティリティ型や、Mapped Types、Conditional Typesを使う場合は`type`が必要だ。
3. `&` を使うなら「最終的な結合」のみ: 複数の型を最後に合成する場合以外、中間の型定義で`&`を乱用してはならない。
良い例：Interfaceの拡張によるクリーンな設計
// ベースとなるインターフェース
interface BaseEntity {
id: string;
createdAt: Date;
}
// 拡張による責務の分離（コンパイラにとってキャッシュ効率が最大化される）
interface User extends BaseEntity {
username: string;
email: string;
}
// APIレスポンス等の合成が必要な場合
interface UserResponse extends User {
token: string;
}
/
- 【ポイント】
- インターフェースを使用することで、型エラーが発生した際に
- “Property ‘x’ is missing in type ‘UserResponse'” といった
- 非常に読みやすいスタックトレースが返ってくる。
/
悪い例：Intersectionの多用によるパフォーマンス低下
// 非推奨：型が複雑になり、再計算のコストが高い
type User = BaseEntity & { username: string } & { email: string };
type UserResponse = User & { token: string };
/
- 【なぜ悪いのか】
- コンパイラは各コンポーネントが評価されるたびに、
- この複雑な交差型のプロパティを解決しようと試みる。
- プロジェクトの規模が大きくなると、この「解決コスト」が積み重なり、
- tscのコンパイル時間が数秒〜数十秒単位で遅延する。
/
—
4. プロのチーフアーキテクトからの助言
大規模プロジェクトにおいて最も重要なのは、「型定義の可読性と、コンパイラの評価効率を一致させること」だ。
- 型定義が複雑になりすぎたら: `type`で`&`を繋ぐのではなく、`interface`で細分化し、階層的に`extends`せよ。
- IDEが重いと感じたら: 型定義の中に複雑な`Conditional Types`が隠れていないか確認せよ。`if-else`を型の中でやりすぎると、コンパイラは沈黙する。
- 「型安全」の追求にはコストがかかる: すべてを型で解決しようとせず、時にはランダムな構造を持つデータに対しては`unknown`で受け取り、ガード関数（Type Guard）で検証する現実的な設計も重要だ。
TypeScriptは単なるJavaScriptの拡張ではない。型システムそのものが強力なツールだ。そのツールが「どう動いているか」を理解し、コンパイラの精神衛生を保つことこそが、伝説的なコードベースを維持する唯一の道である。
さあ、コードを開いて、その無駄な`&`を`interface`に置き換えてみよう。それだけで、あなたのチームの生産性は確実に向上する。