TypeScriptの深淵：Intersection Typesが引き起こす「型の崩壊」とコンパイラの静寂
TypeScriptの型システムは、集合論の厳密な形式言語と、JavaScriptの動的な柔軟性を強引に接ぎ木した怪物だ。我々アーキテクトがこの怪物と対峙する際、最も注意深く観察しなければならないのが `Intersection Types (A & B)` の挙動である。
多くのエンジニアが「型を合成すれば機能が増える」と信じているが、コンパイラから見れば、それは「制約の積算」に過ぎない。特にプロパティの衝突と `never` 型の生成は、大規模なアプリケーションにおいて、不可解なランタイムエラーや、型ガードが機能しない「型安全の死角」を作り出す。
今日は、TypeScriptのコンパイラが裏側でどう型を「評価」し、なぜそれが我々を裏切るのかを深掘りする。
—
1. 集合論の罠：プリミティブの交叉が導く `never`
まずは、もっとも基礎的かつ致命的な誤解から解こう。以下のコードを見てほしい。
type StringAndNumber = string & number;
一見、何の問題もないように見えるかもしれない。しかし、コンパイラはこの型をどう評価するか？ 答えは `never` だ。
- コンパイラの内部挙動: TypeScriptにおいて `&` は「積集合（Intersection）」を意味する。`string` 型の集合と `number` 型の集合には、共通の要素（交わり）が存在しない。したがって、この型の要素は空集合、すなわち `never` となる。
- 実務上の教訓: 汎用的なユーティリティ型を作る際、ジェネリクスに制限をかけず、安易に `T & U` を行うと、ある日突然、型推論の結果が `never` になり、コード全体がコンパイルエラーの海に沈むことになる。
—
2. プロパティ衝突の「暗黙の仕様」
オブジェクトの合成において、プロパティの型が衝突した場合、TypeScriptはどう振る舞うのか。
interface A {
prop: string;
}
interface B {
prop: number;
}
type Intersection = A & B;
// ここで Intersection.prop は何になるのか？
const val: Intersection = { prop: “test” as any }; // エラーにはならないが…
このとき、`Intersection.prop` は `string & number`、すなわち `never` になる。
なぜこれが危険なのか？
この `prop` には、物理的に「何の値も代入できない」ことになる。しかし、TypeScriptの構造的部分型（Structural Typing）の甘さにより、初期化時にこのプロパティが存在しなくても、あるいは `any` を経由すると、コンパイラは即座にエラーを吐かない場合がある。
この「型は `never` なのに、実行時には値が存在する」という乖離が、メモリ上の構造と型定義の不一致を招き、V8エンジンが最適化（Hidden Classの最適化）に失敗する要因にもなり得る。
—
3. 型の防壁を突破する：Mapped Typesによる強制的な解決
では、どうやってこの「型が `never` に陥る」事態を回避すべきか。単に交叉させるのではなく、衝突を解決する戦略（Strategy）をコンパイラに明示する必要がある。
以下は、衝突時に優先順位を決定する高度なパターンだ。
type Merge
[K in keyof T | keyof U]: K extends keyof U
? U[K]
: K extends keyof T
? T[K]
: never;
};
interface UserBase { id: string; name: string; }
interface UserOverride { id: number; role: ‘admin’ | ‘user’; }
// Intersectionを使わず、衝突をUの型で解決する
type FixedUser = Merge
// 結果: { id: number; name: string; role: ‘admin’ | ‘user’; }
この手法は、`keyof` を用いてキー空間をマッピングし、衝突した際にどちらの型を優先するかをコンパイラに演算させている。これが「型システムを掌握する」ということだ。
—
4. チーフアーキテクトからの提言：コンパイラの限界を知れ
TypeScriptの型システムは、チューリング完全な計算機である。しかし、それは型レベルの計算であって、実行時のメモリ操作ではない。
1. デバッグの極意: 型が `never` になった場合、`type Debug
2. イベントループとの関連: 大規模な交叉型（Intersection）を多用すると、TSコンパイラの型チェック負荷が指数関数的に増大する。これはIDEのレスポンスを著しく悪化させ、Node.js上で動作するTSCのイベントループをブロックする。
3. 結論: `&` は強力だが、依存関係の複雑化を招く。プロパティの衝突が予見される場所では、`Pick` や `Omit` を活用し、型を明示的に合成せよ。「型が推論してくれる」という甘えを捨て、型定義の主導権を人間が握ることこそが、堅牢なシステムを作る唯一の道だ。
TypeScriptは、単なるJavaScriptの補完ツールではない。これは、コンパイラという名の静的解析エンジンと戦い、その挙動をハックし続けるための言語である。この重みを理解した者だけが、真に保守可能なアーキテクチャを構築できる。