こんにちは！TypeScriptの世界へようこそ。
日々フロントエンドやNode.jsの開発でTypeScriptを書いていると、「おっ、型定義がピタッと決まって気持ちいい！」という瞬間があれば、「あれ？ なんで意図しないプロパティが補完に出てくるんだ…？」と頭を抱える瞬間もありますよね。
他のプログラミング言語、例えばJavaやC#、あるいは素のJavaScriptから入った人にとって、TypeScriptの「型システムが裏側でどう動いているか」は、最初はちょっとした魔法のように見えるかもしれません。
今回は、TypeScriptの数ある機能の中でも、特に強力でありながら、時として魔物のような挙動を引き起こす「インターフェースの宣言マージ（Declaration Merging）」と、それによって起こるグローバル名前空間の汚染、そしてそのエレガントな回避策について、一緒に深く掘り下げていきましょう。
ここをクリアすれば、TypeScriptの型システムの本質がグッと見えてきますよ。さあ、始めましょう！
—
1. そもそも「宣言マージ」ってなに？
TypeScriptには、同じ名前の`interface`を複数定義すると、コンパイラが勝合せて一つの巨大な型にしてくれるというユニークな機能があります。これが「宣言マージ（Declaration Merging）」です。
まずは、基本の動きを見てみましょう。
// 1つ目の宣言
interface User {
name: string;
}
// 2つ目の宣言（同じ名前の ‘User’）
interface User {
age: number;
}
// ── ここでコンパイラはどう評価しているか？ ──
// TypeScriptは、同じスコープ内にある同名のinterfaceを見つけると、
// 自動的にプロパティを合体させます。
// 実質的に、以下のように定義したのと同じ状態になります：
// interface User {
// name: string;
// age: number;
// }
const tanaka: User = {
name: ‘田中’,
age: 28, // 両方のプロパティが必須になります！
};
この機能、サードパーティ製のライブラリ（例えばExpressやReactなど）の型定義を拡張したいときには、神のように便利な機能です。
「ライブラリ側が用意した標準の型に、独自のプロパティを追加したい！」というユースケースでは、この宣言マージが大活躍します。
—
2. 【閲覧注意】宣言マージが生む「グローバル汚染」の恐怖
便利な宣言マージですが、一歩使い方を間違えると、コードベース全体をジワジワと蝕むバグの温床になります。
特にやってしまいがちなのが、「モジュール化されていないファイル（グローバルスコープ）で、既存の組み込み型やグローバルな型をうっかり上書き・拡張してしまう事故」です。
次のコードを見てください。
// globals.ts （もしこのファイルがモジュール化されていない、つまり import/export が無い場合…）
interface String {
// 便利なオレオレメソッドを追加したつもり
isNumeric(): boolean;
}
// あら不思議、文字列型（String）のインスタンスに勝手にメソッドが生えてきます
const str = “12345”;
str.isNumeric(); // コンパイルエラーにはならない！
一見すると「すごい！String型が拡張できた！」と感動するかもしれませんが、これはTypeScriptの型システムにおける禁忌です。
何が恐ろしいかというと、
1. 影響範囲がファイル単位ではなく、プロジェクト全体（グローバル）に波及する。
2. チームメンバーの誰も予期していないところで `String` や `Window` などの標準オブジェクトの型が書き換わり、コードのメンテナビリティが完全に崩壊する。
3. 他のライブラリの型定義と衝突し、原因不明のコンパイルエラーに悩まされる。
これこそが、意図しない型拡張による「グローバル名前空間の汚染」です。他の言語出身の開発者が最もハマりやすい罠の一つですね。
—
3. なぜこの現象が起きるのか？（TypeScriptのスコープの仕組み）
TypeScript（およびJavaScript）において、ファイル内に `import` や `export` が1つも書かれていない場合、そのファイルは「グローバルスクリプト」として扱われます。
グローバルスクリプト内で定義された `interface` は、プログラム全体から見える共通の空間（グローバル名前空間）にプワッと広がってしまいます。これが、意図しないマージを引き起こす根本原因です。
健全なモジュールスコープの世界へ行こう
では、どうすればこの汚染を防げるのでしょうか？
答えは非常にシンプルです。「ファイルに必ず `import` か `export` を書き、モジュールとして扱うこと」です。
// safe-types.ts
// 空の export を書くだけで、このファイルは「モジュール」になります！
export {};
// この中で宣言した interface は、このファイル（または明示的にエクスポートした範囲）に閉じ込められます
interface User {
id: string;
}
// 他のグローバルな User 型と混ざる心配がありません！
TypeScriptは、ファイルがモジュール（ES Modules）として認識された瞬間、その中の宣言をローカルスコープに閉じ込めます。これにより、意図しない宣言マージを防ぐことができるのです。
—
4. 現場で使える！安全に型を拡張するベストプラクティス
「いや、でもサードパーティの型を拡張したいんだよ！」という正当な理由がある場合もありますよね。そのときは、グローバルを汚染せず、安全に型を拡張する正しい作法を使いましょう。
パターンA: モジュール拡張（Ambient Modules）の正しい作法
外部ライブラリの型や、Node.jsのグローバル変数を拡張したい場合は、`declare global` やモジュール augmentation を正確な構文で使います。
// augmentations.d.ts （型定義ファイル）
// 1. これがモジュールであることを明確にする
export {};
// 2. グローバルなスコープに影響を与えることを「明示的」に宣言する
declare global {
interface Window {
// 独自のカスタムプロパティを安全に追加
myAppConfig: {
apiEndpoint: string;
version: string;
};
}
}
// これにより、コードの他の場所で以下のように安全にアクセスできます
// window.myAppConfig.apiEndpoint;
ここで重要なのは、「どこを拡張しているのか」がファイル名や `declare global` ブロックによって一目でわかることです。闇雲にコードのあちこちで `interface String` や `interface User` を再定義するのとは、安全性において雲泥の差があります。
—
まとめ：TypeScriptの型を「掌握」するために
今回は、Interfaceの宣言マージの仕組みと、それが引き起こすグローバル名前空間の汚染、そしてその回避策について解説しました。
- 宣言マージは、同名のInterfaceを合体させる強力な機能である一方、諸刃の剣。
- `import` / `export` のないファイル（グローバルスクリプト）で書くと、プロジェクト全体を汚染するバグの温床になる。
- ファイルをモジュール化（`export {}`などを活用）するか、拡張する意図を `declare global` で明示することで、安全で堅牢なコードベースを保つことができる。
型システムは、私たち開発者の敵ではなく、最高の相棒です。裏側でコンパイラがどう型を評価しているのかを少しだけ意識してあげるだけで、あなたの書くTypeScriptコードは見違えるほど洗練されたものになりますよ。
ここをクリアしたあなたなら、もう中級者の扉は完全に開いています。明日からのコーディングで、ぜひ意識してみてくださいね！