なぜ「宣言マージ」を殺すべきなのか：TypeScriptの型システムを「閉じた系」として設計する極意
TypeScriptのコードベースが成長するにつれ、最も厄介な敵の一つとなるのが「意図しない型拡張」です。特に `interface` の強力すぎる機能である「宣言マージ（Declaration Merging）」は、小規模なプロジェクトでは便利ですが、大規模なエンタープライズ開発においては、バグの温床であり、型推論のパフォーマンスを劣化させる「型システムのノイズ」に成り下がります。
本稿では、なぜあえて `interface` の宣言マージを封じ、`type` エイリアスによる厳密な型定義へとシフトすべきなのか、その理論的背景と実践的な設計指針を伝授します。
—
1. 宣言マージがもたらす「型推論の汚染」
TypeScriptの `interface` は、同じ名前で複数回宣言されると、それらが統合（マージ）されます。一見すると、サードパーティライブラリの型定義を拡張するのには便利ですが、自前で定義したドメインモデルにこれを許容すると、以下のようなカオスが生まれます。
// src/types/user.ts
export interface User {
id: string;
name: string;
}
// 別の場所で勝手に拡張されてしまう
// src/features/admin/user-extension.ts
export interface User {
role: ‘admin’ | ‘user’; // コンパイラはこれを許容し、User型を汚染する
}
この結果、どこで定義されたか追跡困難なプロパティが `User` 型に混入し、IDEの補完候補は肥大化し、意図せぬデータがコンポーネントに渡るリスクが高まります。「型は、定義された場所で完結しているべき」という原則を破壊しているのです。
—
2. 厳密な型定義のための「Type Alias」への移行
宣言マージを禁止し、型を「閉じた系」にするための唯一かつ最強の手段は、`interface` を捨て `type` エイリアスを利用することです。
`type` は宣言マージを許しません。同じ名前で定義しようとすれば、即座にコンパイルエラーとなります。これが、大規模開発における「型の一貫性」を保つ強力な防波堤となります。
プロダクションコード例：堅牢なデータ構造の設計
/
- UIコンポーネントのPropsやAPIのレスポンス定義は、
- typeを用いて「拡張不能な状態」で定義する。
/
export type UserProfile = {
readonly id: string;
readonly name: string;
readonly email: string;
};
// もし同じ名前で定義しようとすると…
// export type UserProfile = { age: number };
// -> ❌ Error: Duplicate identifier ‘UserProfile’.
なぜ `readonly` を付けるのか？
型定義を厳密にすることは、イミュータビリティを保証することと同義です。`readonly` を付与することで、オブジェクトの意図しない書き換えを防ぎ、Reactのレンダリング最適化や副作用の排除に大きく貢献します。
—
3. コンパイラによる制御：なぜこの設定が必要か
もしチーム開発でどうしても `interface` を使う必要がある場合や、強制的に宣言マージを禁止したい場合は、ESLintのルールを活用するのが最も効果的です。`@typescript-eslint/no-redeclare` を厳格に設定し、`interface` の重複宣言をCIで弾く構成にしましょう。
// .eslintrc.json
{
“rules”: {
“@typescript-eslint/no-redeclare”: [“error”, { “ignoreDeclarationMerge”: false }]
}
}
この設定により、開発者がうっかり `interface` を再定義して宣言マージを誘発することを未然に防ぎます。
—
4. 拡張が必要な時は「継承」か「合成」を使う
「じゃあ、拡張したい時はどうするのか？」という問いに対して、安易に宣言マージに逃げるのは設計の怠慢です。拡張が必要なら、明示的な継承（Intersection） を使いましょう。
// 拡張可能なベース型を定義
export type BaseUser = {
id: string;
name: string;
};
// 継承によって新しい型を生成する（明示性が高い）
export type AdminUser = BaseUser & {
role: ‘admin’;
permissions: string[];
};
このように定義すれば、`AdminUser` が `BaseUser` を拡張していることが一目で分かります。どこかのファイルで勝手に `BaseUser` が書き換えられる恐怖から解放され、型定義の依存関係がツリー構造として可視化されます。
—
結論：型は「意図」を語るべき
型定義は、単なるデータ構造の羅列ではなく、「このデータがどうあるべきか」という設計者の意図そのものです。
1. 宣言マージを禁止する：型定義の衝突をコンパイルレベルで排除し、唯一の正解を保証する。
2. `type` を優先する：名前空間の汚染を防ぎ、再定義による予期せぬ挙動を抑制する。
3. 明示的な合成を行う：継承やIntersectionを活用し、依存関係をコード上で明確にする。
TypeScriptを掌握するということは、言語の「便利機能」に振り回されるのではなく、言語の「制約」を戦略的に活用して、バグが入り込む余地のない堅牢なシステムを組み上げることです。今日から、`interface` を宣言するときに一歩立ち止まり、「これは本当にマージされるべきか？」と自問してみてください。その疑念こそが、優れたアーキテクトへの第一歩です。