型の衝突という「特異点」：Intersection Typesが隠蔽するメモリと評価の深淵
TypeScriptの型システムにおいて、`type`（型エイリアス）と`interface`は、単なる構文上の好みの問題ではない。これらはコンパイラ内部の「型合成器」に対して異なる指示を出す。特に、`&`（Intersection Types）を用いた合成において発生するプロパティの衝突は、単なるコンパイルエラーの問題を超え、複雑なアーキテクチャにおける「型の不整合」の根源となる。
今日は、Intersection Typesがプロパティの競合をどう処理し、なぜその挙動がランタイムの安全性に直結するのかを、コンパイラAPIの深層から紐解く。
—
1. Intersection Typesの「評価」の正体
多くのエンジニアは `type C = A & B` を「AとBをマージして新しい型を作る」と捉えている。しかし、コンパイラ内部において、Intersectionは「すべての制約を満たす必要がある論理的な論理積」として扱われる。
ここで問題になるのが、プロパティ衝突だ。例えば、同じプロパティ名で型が異なる場合、コンパイラは `never` を推論する。
type A = { id: string; payload: number };
type B = { id: number; metadata: string };
type C = A & B;
// C.id は string & number となり、事実上の ‘never’ に帰結する
// 実行時には、このプロパティにアクセスした瞬間に型安全性が崩壊する
なぜこれが危険か？TypeScriptの型検査は静的だが、JavaScriptランタイムは動的だ。もし `C` 型として定義されたオブジェクトを、コンパイルオプションの緩さ（`any`の混入など）で無理やり生成した場合、メモリ上では `id` に `number` が入っているにもかかわらず、TSは `string` として振る舞おうとする。これはV8エンジンにおける最適化ヒント（Hidden Classes）の不一致を招き、最悪の場合、JITコンパイル後の最適化パスを破壊し、予期せぬパフォーマンス劣化を引き起こす。
—
2. 衝突を「解決」ではなく「支配」する
衝突が起きたとき、安易に `Omit` や `Pick` で切り抜けるのはシニアの取るべき戦略ではない。型システムの力を借りて、競合を「構造的な衝突」から「安全なオーバーライド」へと昇華させる必要がある。
最もエレガントな解決策の一つが、条件付き型（Conditional Types）を用いた型ベースの競合解決だ。
/
- 競合時にBaseの型を優先し、Overrideで上書きする
- ユーティリティ型：Override
/
type Override
type Base = { id: string; status: ‘pending’ | ‘active’ };
type New = { id: number };
// id を number で強制的に上書きし、整合性を保つ
type Optimized = Override
// Optimized は { id: number; status: ‘pending’ | ‘active’ } となる
この実装の核心は、`Omit` によって一度 `Base` から競合元を「除外」し、その後で交差させることで、コンパイラの評価順序を制御している点にある。これはコンパイラの型解決エンジンに対し、衝突を「論理積の破綻」から「優先順位付けされた構造」へと再定義させる行為だ。
—
3. 型評価のオーバーヘッドとコンパイラAPI
大規模なプロジェクトにおいて、複雑なIntersectionは「Type Instantiation Exceeded」エラーを頻発させる。これは、コンパイラが再帰的な型評価を行う際、メモリ上のスタックを食いつぶしている証拠だ。
特に、以下のような再帰的合成は避けるべきだ。
// 危険な実装：再帰的なIntersectionは評価コストが指数関数的に増大する
type RecursiveMerge
大規模システムでは、「型を評価する前に、型をフラット化（Flatten）する」のが鉄則である。以下のユーティリティは、型をオブジェクトとして一度再構築することで、コンパイラの評価キャッシュを効率化する。
type Flatten
// Flatten を噛ませることで、コンパイラは複雑な交差型を一つのオブジェクト形状としてキャッシュする
type Result = Flatten
`& {}` という空のオブジェクトとのIntersectionは、TypeScriptの秘伝のタレだ。これはコンパイラに対し、型を簡略化（Simplify）して評価するように強制するトリガーとなる。これにより、複雑な合成型がIDE上で展開された際、可読性が劇的に向上し、型検査器の計算量も削減される。
—
4. 結びに：型システムは「防壁」である
型システムは単なるドキュメントではない。それは、ランタイムのメモリ空間を論理的に守るための「防壁」だ。
プロパティの競合を放置することは、物理的なメモリ領域において「型の解釈の不一致」を許容することに等しい。我々が書く型定義の一つ一つが、V8エンジンのHidden Class最適化に影響を与え、さらにはNode.jsのイベントループにおけるオブジェクトのライフサイクル管理にまで波及する。
型を掌握せよ。そして、コンパイラの評価の仕組みを理解した上で、意図的に型を「再構築」せよ。それが、堅牢なシステムを構築するための唯一の道である。
次回の記事では、この「型フラット化」のテクニックを駆使した、DI（依存性の注入）コンテナの型安全性設計について深く掘り下げていく。準備はいいか。