型定義という名の「計算コスト」：InterfaceとType Aliasがコンパイラを殺す境界線
大規模なTypeScriptプロジェクトにおいて、型定義は単なるドキュメントではない。それはコンパイラ（`tsc`）に対する実行命令そのものだ。
我々が書くコードが、コンパイル時にどれだけのメモリを消費し、どれほどのAST（抽象構文木）トラバーサルを強制しているのか。この深淵を理解せねば、大規模アーキテクチャの設計者とは呼べない。今回は、`interface`の拡張と`type`の交差型（Intersection）がコンパイラの内部でどう解釈され、どのようなパフォーマンス劣化を引き起こすのかを解剖する。
—
1. コンパイラの深淵：型解決と「計算の複雑性」
TypeScriptの型システムは構造的部分型（Structural Subtyping）に基づいている。しかし、型が複雑化すればするほど、コンパイラは型を「評価」するために莫大な計算コストを支払うことになる。
特に問題となるのは、「型定義のキャッシュ」と「再帰的な評価」だ。
Interface拡張（extends）の挙動
`interface A extends B` は、型システム内部では「BのプロパティをAの構造にマージする」という、比較的軽量な操作として扱われる。コンパイラは`A`を解決する際、`B`の構造を継承した単一のフラットな型として内部キャッシュしやすい。
交差型（Intersection）の爆発
一方で、`type A = B & C` は異なる。これは「BとCの全てのプロパティを持つ型を生成する」という演算であり、コンパイラはこれを評価するたびに「BとCの共通部分および全集合」を論理的に計算する。複雑な交差型がネストされると、コンパイラの型推論エンジンは指数関数的なメモリ消費を引き起こす可能性がある。
—
2. なぜ `interface` が大規模開発で有利なのか
大規模プロジェクトにおいて `interface` を推奨する理由は、単なる「オブジェクト指向っぽさ」ではない。「宣言のマージ（Declaration Merging）」と「型チェックの遅延評価」にある。
宣言のマージによるメモリ最適化
`interface`は、同じ名前で複数回宣言することで、コンパイラが一度の走査で型をマージする。これはコンパイラのメモリ空間において効率的に管理される。
// 複数のファイルに分散していても、tscは最終的に一つのシンボルとして扱う
interface User { id: number; }
interface User { name: string; }
// コンパイラは { id: number; name: string } を単一のオブジェクト型として管理する
const user: User = { id: 1, name: “Architect” };
交差型の罠：型推論エンジンのスタックオーバーフロー
一方、複雑な交差型は、コンパイラが型を解決する際、常に「全結合」を試みるため、型定義が深くなればなるほど `tsc` のメインスレッドを占有する。
// これを100階層繰り返すとどうなるか？
type Base = { a: number };
type T1 = Base & { b: number };
type T2 = T1 & { c: number };
// … この連鎖は、コンパイラが「T100」を解決する際、
// 再帰的にベース型まで遡ってプロパティをマージし続ける
大規模な型ライブラリで `type` を多用しすぎると、IDEのレスポンス（Language Service）が極端に悪化するのは、この計算コストが原因だ。
—
3. シニアエンジニアが守るべき最適化戦略
コンパイラのパフォーマンスを維持し、開発効率を最大化するための原則を提示する。
原則1：インターフェースの拡張を優先せよ
再利用可能なデータ構造には `interface` を使用する。これにより、コンパイラは型を「フラット化」してキャッシュできるため、後続の型チェックが高速化する。
原則2：交差型は「末端の合成」に限定せよ
`type` は複雑な条件付き型（Conditional Types）やユーティリティ型に限定すべきだ。データモデルとして `type` を連鎖させるのは技術的負債となる。
原則3：型定義の「フラット化」を意識せよ
大規模なライブラリを作成する場合、型を再帰的に生成するのではなく、`Pick` や `Omit` を多用して中間型を減らすこと。
// 非推奨：複雑な交差型の連鎖
type Config = A & B & C & D;
// 推奨：インターフェースによる継承
interface Config extends A, B, C, D {}
—
4. 結び：コンパイラと共存するために
TypeScriptは、単なるJavaScriptの補完機能ではない。「型システムという名の静的解析エンジン」そのものだ。
あなたが書く一文字の型定義が、コンパイラのASTを駆け巡り、イベントループのキューを消費し、メモリを浪費する。この事実を自覚しているエンジニアだけが、数百万行規模のコードベースを管理し、一瞬でビルドが完了する快適な環境を維持できる。
型定義を「整理整頓」するのではない。「コンパイラが最短ルートで答えを出せるよう、地図を描く」。それが、アーキテクトとしてのTypeScriptの掌握術である。
もしあなたのIDEが `(await) …` と表示し、型定義の補完に数秒かかるようなら、今すぐその交差型の連鎖を断ち切り、`interface` のフラットな構造へとリファクタリングせよ。それが、システムエンジニアとしての正当な防壁となる。