Intersection Typesの深淵：型衝突を「制圧」し、プロダクションコードを堅牢にする技術
TypeScriptを書いていると、必ず一度は突き当たる壁がある。`Type A & Type B` — いわゆるIntersection Types（交差型）による型合成だ。
「とりあえずインターフェースを合成すればいい」と安易に考えていないだろうか？ 異なるソースから型をマージする際、同じプロパティ名で異なる型定義が衝突した瞬間、TypeScriptの型システムは静かに牙を剥く。`never` 型の増殖、あるいは「なぜか型が `any` になってしまう」という不気味な挙動。
今日は、フロントエンドのフロントラインで戦うエンジニアに向けて、この「型衝突」という厄介な現象を、コンパイラの挙動から読み解き、いかにエレガントに解決するかを伝授する。
—
1. なぜIntersection Typesは「衝突」するのか
まず、コンパイラの視点に立とう。`interface A { id: string }` と `interface B { id: number }` を結合するとどうなるか？
type Conflict = { id: string } & { id: number };
// 評価結果: { id: string & number } -> { id: never }
`string & number` は物理的に存在し得ない。結果として `id` プロパティは `never` になる。これは型安全の観点では正しい挙動だが、外部APIのレスポンスやレガシーなDB定義を扱う際、現場ではこれが「地雷」となる。
「とりあえず `any` に逃げる」のは敗北だ。我々は、型システムを破壊せずに衝突を解決する必要がある。
—
2. 衝突解決の神髄：`Omit` と `Overwrite` パターン
実務で最も多用すべきは、衝突を未然に防ぐ「型の上書き」パターンだ。単純な結合ではなく、「優先される型で衝突分を削る」というアプローチを取る。
実践的ユーティリティ型：`Overwrite`
/
- TのプロパティをUで上書きする。
- Uに存在するキーをTから除外(Omit)してから、Uを結合する。
/
type Overwrite
interface UserBase {
id: string; // 本来はstringだが…
name: string;
}
interface UserOverride {
id: number; // APIの仕様変更でnumberになった
}
// これなら ‘id’ は正しく number に解決される
type FixedUser = Overwrite
const user: FixedUser = {
id: 123, // 正常に推論される
name: “Alice”
};
このアプローチの利点は、コンパイラの再帰的な型評価を最小限に抑えられることだ。複雑な `Conditional Types` をネストさせるより、`Omit` を介したマージの方が、IDE（LSP）の補完速度も速く、型定義ファイルの見通しも良くなる。
—
3. 【応用】非同期API連携における「型安全なマージ」
フロントエンド開発でよくあるのが、「Base（共通定義）」と「APIレスポンス（動的な拡張）」の衝突だ。特に `data` フィールドが絡むと、型が複雑化しやすい。
ここで、「条件付き型（Conditional Types）」を組み合わせて、衝突時にどちらを優先するかを動的に制御する高度なパターンを紹介する。
type Merge
[K in keyof (T | U)]: K extends keyof U ? U[K] : T[K];
};
// 現場で役立つ「衝突を無視してUを優先する」マージ
type SmartMerge
interface BaseProps {
isLoading: boolean;
data: { status: string };
}
interface ApiProps {
data: { status: number; code: number }; // Baseと衝突
}
// 衝突しても、ApiPropsの型が正しく適用される
type FinalProps = SmartMerge
/
- 評価結果:
- {
- isLoading: boolean;
- data: { status: number; code: number };
- }
/
—
4. パフォーマンスと保守性への視点
最後に、チーフアーキテクトとして忠告したい。型定義を「パズル」にしてはいけない。
1. 深いネストを避ける: `T extends A ? (U extends B ? … : …) : …` のような深い条件分岐は、TypeScriptの型チェック時間を指数関数的に増加させる。CI/CDパイプラインが重くなる原因の多くはここにある。
2. `interface` vs `type`: 基本的には `interface` を使い、宣言的マージ（Declaration Merging）の恩恵を受けるべきだ。しかし、今回のようなプロパティ衝突の解決が必要な複雑なロジックを組む際は、`type` を使ったユーティリティ型の設計が適している。
3. 型を「ドキュメント」として扱う: 複雑なユーティリティ型を作った際は、必ず `tsdoc` を付与すること。あなたが書いた型は、半年後の自分やチームメンバーが読む「仕様書」そのものだ。
結論
TypeScriptの型衝突は、バグではなく「設計の不整合」を知らせるシグナルだ。`never` になった型を見て「動かない」と嘆くのではなく、`Omit` や `keyof` を駆使して「どのソースの定義が優先されるべきか」を明示的にコードで宣言する。
この思考プロセスこそが、TypeScriptを単なる「JavaScriptに毛が生えたもの」から「堅牢なシステムを構築するための最強のツール」へと昇華させる。
今日紹介した `Overwrite` 型をプロジェクトの `types/utils.d.ts` に忍ばせてみてほしい。それだけで、あなたのチームの型定義の品質は一段上のステージへと引き上げられるはずだ。
さあ、コードを書こう。コンパイラを味方につけるために。