【テクニカル・上級編】 インターセクション型（Intersection Types）の定義と活用 – TypeScript実践ガイド

インターセクション型（&）：オブジェクト合成の「甘い罠」と、その先にあるアーキテクチャの真実

TypeScriptを長く触っていると、`&` 演算子によるインターセクション型（交差型）は、まるで魔法の接着剤のように見えてくるはずだ。`A & B` と書けば、両方のプロパティを併せ持つ最強の型が爆誕する。確かにその通りだ。しかし、この「便利さ」の裏側にある型システムの挙動を深く理解せず、安易に巨大なインターセクションを構築し続けると、いずれ必ず「型推論の迷宮」と「コンパイル時間の爆発」という名の借金に首を絞められることになる。

今回は、単なる構文の解説は飛ばす。プロフェッショナルとして、この型がメモリやレンダリング、そして何より「保守性」という観点でどう機能すべきか、その深淵を覗いていこう。

—

1. インターセクションの正体：マージか、競合か

インターセクション型は、集合論における「積集合」だ。しかし、オブジェクト型におけるそれは、単純なマージではない。プロパティが重複した時、何が起きるか。

type Base = { id: string; meta: { version: number } };
type Extension = { id: number; data: string };

// このインターセクションは、id: string & number という「never」を生む
type DangerousCombo = Base & Extension;

const item: DangerousCombo = {
id: 123 as any, // 結局こうやって逃げる羽目になる
meta: { version: 1 },
data: “payload”
};

ここで重要なのは、「型定義レベルでの競合は、即座に静的解析のノイズになる」という点だ。特にAPIレスポンスの型定義を自動生成している場合、インターセクションを多用すると、型解決が極端に遅くなる。TypeScriptのコンパイラは、Intersectionを解決する際に各メンバーを詳細に再帰チェックするため、深い階層でこれを行うと `tsc` が悲鳴を上げる。

2. メモリとレンダリング負荷への影響

フロントエンドにおいて、巨大なインターセクション型を `props` や `state` にそのまま突っ込むのは、パフォーマンスの観点から見れば時限爆弾だ。

特に、Reactの `memo` や `useMemo` を使う際、インターセクションで定義された大きなオブジェクトを依存配列に含めると、意図しない再レンダリングを誘発しやすい。なぜなら、インターセクションによって生成されたオブジェクトが、実は「プロパティの列挙順序」や「内部的な構造化」によって、異なるインスタンスとして評価される可能性があるからだ。

// パフォーマンスを意識した、インターセクションの「フラット化」
interface UserBase { id: string; name: string; }
interface UserMetrics { loginCount: number; lastActive: Date; }

// これをそのまま使うのではなく、必要な分だけpick/omitする
type UserProfile = UserBase & UserMetrics;

// 推奨：コンポーネントのPropsには、必要なインターセクションの結果を
// 抽出（Pick）した型を渡す。これにより、不要なプロパティの変化による
// 再レンダリングの連鎖を物理的に遮断できる。
type UserSummary = Pick;

3. 非同期処理とインターセクションの「静かなるバグ」

非同期処理において、`Promise` を扱う際、最も恐ろしいのは「一部だけが解決される」という中途半端な状態を、型が弾いてくれないことだ。