【実務・中級編】Interfaceの「継承」と「交差型」：どちらがコンパイル速度に影響するか – TypeScript コア・型システムの基礎解析バイブル

TypeScriptの「Interface継承」と「交差型」：その境界線がビルドパフォーマンスに与える深淵なる影響

フロントエンドの大規模開発において、型定義の「積み方」は単なる好みの問題ではない。それはTypeScriptコンパイラ（`tsc`）の型チェックエンジンである`checker.ts`が、どれほど効率的に型推論を行うかに直結する。

多くのエンジニアが「Interfaceの継承（`extends`）」と「交差型（`&`）」を同義だと誤解しているが、コンパイラの内部挙動から見れば、これらは全く別の演算として処理されている。今回は、この選択が大規模プロジェクトのビルド時間にどう影を落とすのか、そして何を基準に選ぶべきかを説く。

—

1. コンパイラは「継承」と「交差型」をどう見ているか

TypeScriptの型システムにおいて、この2つは以下のような決定的な違いを持つ。

Interfaceの継承 (`extends`)

`interface`は「遅延評価（Lazy Evaluation）」の恩恵を受ける。コンパイラは`interface`同士の継承関係を保持し、実際にその型が参照されるまで、プロパティを再帰的に解決することを避ける傾向がある。また、同名のインターフェースを複数定義すれば自動的に「宣言結合（Declaration Merging）」が行われるため、メモリ上の型構造を構築するコストが非常に低い。

交差型 (`&`)

一方で`&`演算子は、「即時評価（Eager Evaluation）」に近い挙動をとる。複数の型を合成する際、コンパイラは`&`で繋がれた全ての型を統合し、一つの新しい「型構造」を計算しようとする。特に複雑なオブジェクト型同士を`&`で繋ぐと、TSコンパイラはプロパティの衝突チェックを即座に走らせ、膨大な推論コストを支払うことになる。

結論: 大規模なプロジェクトにおいて、深いネストを持った`&`の多用は、型チェックの計算量を爆発させ、`tsc –watch`のレスポンスを悪化させる一因となる。

—

2. 実践：保守性とビルド速度を両立させる設計

現場のコードでは、以下の指針を徹底してほしい。

基本原則：再利用可能な型は Interface で定義する

コンポーネントのPropsやAPIレスポンスのスキーマは、基本的に`interface`で定義すべきだ。継承チェーンを活用することで、コンパイラは「型Aは型Bの一部である」という構造をキャッシュしやすくなる。

// 良い設計：継承チェーンを明示する
interface BaseEntity {
id: string;
createdAt: number;
}

interface User extends BaseEntity {
name: string;
email: string;
}

// 悪い設計：過度な交差型の利用（ビルド速度低下の温床）
type UserProfile = BaseEntity & { name: string; email: string };

なぜ `interface` が優れているのか

`interface`はエラーメッセージも親切だ。`interface`同士でプロパティが競合した場合、コンパイラは「どのインターフェースのどの行が原因か」を明確に示せる。しかし、複雑な`&`を多用すると、エラーメッセージが「Type X & Y & Z…」という巨大な文字列で出力され、デバッグ不能に陥る。

—

3. 現場で使える「型合成」の最適解

もちろん、`type` aliasが不要なわけではない。条件付き型（Conditional Types）やMapped Typesを使う場合は`type`が必要だ。しかし、オブジェクトを組み立てる際は以下のパターンを推奨する。

高度な型合成のパターン
継承でベースを作り、必要な場合のみ交差型で「付加情報」を足す

/
interface ApiResponse {
status: number;
data: unknown;
}

// 継承でベースを固定
interface UserResponse extends ApiResponse {
data: { id: string; name: string };
}

// ユーティリティ的な拡張のみ & を使う
type WithTimestamp = T & { timestamp: number };

// 使用例
type TimedUserResponse = WithTimestamp;

—

4. リードエンジニアからの提言：パフォーマンスを意識せよ

大規模プロジェクトで「型チェックが遅い」と感じたら、まず以下のチェックリストを確認してほしい。

1. 深い交差型は存在しないか？

`A & B & C & D…` と続いている箇所があれば、それは`interface`の継承に置き換えられないか検討する。

2. 型エイリアスを再帰的に呼んでいないか？

`type`による複雑な計算型（ユーティリティ型）は、計算のステップ数を増やす。可能な限り静的な`interface`で定義を固定する。

3. 宣言結合を活用しているか？

外部ライブラリの型拡張などは、`declare module`と`interface`の宣言結合を使うのが、最もコンパイラに優しい。

TypeScriptは単なるJavaScriptのラッパーではない。型システムそのものが一つのプログラムであり、その設計の良し悪しが、そのままCI/CDの待ち時間や、開発者の認知負荷に跳ね返ってくる。

「動けばいい」というコードから、「コンパイラと対話する」コードへ。その意識の差こそが、真に堅牢で保守性の高いプロダクトを生む唯一の道だ。今日から、君の型定義を見直してみよう。