TypeScriptの型システムを「武器」にする：Interface継承と交差型の深淵と最適化戦略
大規模なプロダクト開発において、TypeScriptのコンパイル時間は単なる待ち時間ではありません。それは「型システムの複雑さ」という負債のバロメーターです。
多くのエンジニアが「なんとなく」使い分けている `interface` の継承（`extends`）と `type` の交差型（`&`）。これらがコンパイラ（`tsc` / `tsserver`）の内部でどう扱われ、なぜ大規模プロジェクトでビルドを遅延させるのか。その「メモリ消費の正体」と、現場で採用すべき「美しく堅牢な設計」について解説します。
—
1. コンパイラが「型」を評価する際、何が起きているのか？
TypeScriptの型システムは構造的部分型（Structural Subtyping）に基づいています。コンパイラが型を評価する際、最もコストがかかるのは「型メンバーの再帰的な解決」です。
Interfaceの `extends` が「賢い」理由
`interface` は名前付きのシンボルとしてキャッシュされます。`extends` を使用する場合、コンパイラは「親の型定義をベースに、差分だけを統合する」という最適化パスを通ります。これは型定義のキャッシュ効率が極めて高く、コンパイラのメモリ占有を抑えられます。
交差型 `&` が「重い」理由
対して `type A = B & C` は、評価のたびに「BとCの全プロパティをマージした新しい型」を構築しようとします。特に、複雑なネストを持つオブジェクトや、条件付き型（Conditional Types）が絡む交差型は、コンパイラにとって「再計算コストの塊」です。大規模プロジェクトで `Type Alias` を乱用すると、`tsserver` のメモリ使用量が数GBに達し、エディタの補完が極端に遅くなるのはこのためです。
—
2. 実践：パフォーマンスを意識した型設計戦略
「とにかく動けばいい」というコードから、「コンパイラに優しい」コードへ。現場で明日から使える設計パターンを提示します。
アンチパターン：交差型の連鎖
// 悪い例：深い交差型はコンパイラの評価コストを増大させる
type User = Base & Auth & Profile & Settings & Preferences;
// コンパイラは、この「User」にアクセスするたびに、
// 5つの型を統合した新しい構造体として評価を試みる。
推奨パターン：Interfaceの集約と拡張
// 良い例：Interfaceで名前を付け、名前空間で管理する
// 名前があることで、コンパイラは「型名」をキーにして計算結果をキャッシュできる
interface UserBase { id: string; }
interface UserAuth extends UserBase { token: string; }
interface UserProfile extends UserAuth { name: string; }
// 継承を利用することで、コンパイラは型定義を「フラットな結合」として最適化できる
—
3. 「美しい」プロダクションコードのための設計指針
大規模なAPI連携やコンポーネント設計では、以下の戦略を徹底してください。
① 型は「名前」を付ける（Interfaceの優先）
再利用性の高い型は必ず `interface` で定義し、可能な限り `extends` を使って階層化してください。`type` は「ユニオン型（Union Types）」や「Mapped Types」といった、`interface` では表現できない複雑な計算が必要な時に限定します。
② コンポーネントPropsの最適化
Reactなどのコンポーネント設計では、Propsの交差型を避けるのが鉄則です。
// 良い設計例：インターフェースの分離と再利用
interface BaseButtonProps {
label: string;
disabled?: boolean;
}
interface IconButtonProps extends BaseButtonProps {
iconName: string;
}
// 複雑な型合成を避け、明示的な階層を作ることでIDEの補完速度を維持する
export const IconButton: React.FC
);
③ 巨大な型定義を避けるための「名前空間的な分割」
一つのファイルに何百行もの型定義を詰め込むのはやめましょう。`domain/types/` のようにディレクトリを切り、型定義を物理的に分割してください。これにより、コンパイラのパーサーが一度に読み込む範囲を制限し、メモリ消費を最適化できます。
—
結論：型システムの「重み」を意識する
TypeScriptの型システムは強力ですが、万能ではありません。
- `interface` は静的でキャッシュしやすい。
- `type` (交差型) は動的で計算コストが高い。
この事実を理解しているかどうかが、シニアエンジニアとジュニアエンジニアの境界線です。大規模なプロジェクトを維持するためには、「読みやすい型」よりも「コンパイラが計算しやすい型」を設計する視点を持ってください。
あなたの書いた型定義が、明日もチームの生産性を向上させる強力なドキュメントであり、同時にコンパイラにとってもストレスのない、洗練されたコードであることを期待しています。
—
執筆後記:
型定義は単なる静的な検証ルールではありません。それはプログラムの骨格であり、パフォーマンスの源泉です。もし「最近エディタが重い」と感じたら、まずはその複雑すぎる `&` を `interface` に置き換えるところから始めてみてください。世界が変わるはずです。