TypeScriptを掌握する極限の知見：なぜ `{}` 型は「何でも許す」罠と化すのか、そのコンパイラ挙動と防壁の構築
TypeScriptの型システムは、一見すると堅牢な静的防壁のように見える。しかし、その内部構造の機微を知らなければ、コンパイルの網目をすり抜ける危険な脆弱性を自らの手でコードベースに埋め込むことになる。
今回は、多くのシニアエンジニアすら見落としがちな `{}`（空オブジェクト型）が実質的に `any` のように振る舞う仕様上の罠 について、TypeScriptコンパイラの型評価メカニズム、V8ランタイムのメモリモデル、そしてイベントループを汚染する挙動の観点から解剖する。
中途半端なリファレンスをなぞる時間は終わりだ。型システムの深淵へ踏み込む。
—
1. コンパイラが `{}` を「何でも許すプリミティブ」と評価する理由
TypeScriptにおいて、 `{}` とは何か？ 直感的には「プロパティを持たないオブジェクト」を指すように思える。しかし、コンパイラ（checker.ts）の型チェッカーの内部実装において、 `{}` は「`null` と `undefined` 以外のすべてのプリミティブ値を含む、すべての型の下位型（Bottom-ishな存在）」として定義されている。
ここに由来するコードの挙動を見てほしい。
// 以下の代入は、一見すると「空のオブジェクト」しか受け付けないように見える
const strictBox: {} = {};
// しかし、実際には以下のすべてがコンパイルを通過する
strictBox.foo = “bar”; // TSのバージョンや設定によってはエラーになるが、代入自体は成立する
const a: {} = 42; // 数値は通過する
const b: {} = “string”; // 文字列も通過する
const c: {} = true; // 真偽値も通過する
const d: {} = { name: “architect” }; // オブジェクトはもちろん通過する
// 唯一、NGとなるのはこれらのみ
// const e: {} = null; // Error: Type ‘null’ is not assignable to type ‘{}’.
// const f: {} = undefined; // Error: Type ‘undefined’ is not assignable to type ‘{}’.
なぜこのような仕様になっているのか？
TypeScriptの型システムは、JavaScriptの動的なプロトタイプチェーンの振る舞いを模倣している。JavaScriptでは、プリミティブ値（例: `42` や `”hello”`）に対しても、一時的にラッパーオブジェクト（`Number` や `String`）のプロトタイプチェーンが適用され、メソッド（`toString()` など）を呼び出すことができる。
コンパイラは「`null` と `undefined` 以外のすべての値は、オブジェクトのプロトタイプメソッドを継承している（あるいはラップ可能である）」という解釈をとるため、 `{}` は事実上の「万物の祖（ただし `null` / `undefined` を除く）」として振る舞う。これが、 `{}` が `any` に近い挙動を示す根本原因である。
—
2. ジェネクスと条件付き型（Conditional Types）における破滅的な影響
この `{}` の性質は、汎用的なユーティリティ型を自作する際、最も凶悪なバグを引き起こす。例えば、引数がオブジェクトであるかを厳密に判定する型を書こうとしたとする。
// 悪夢の始まり：IS_OBJECT判定のつもりが…
type IsObject
type Test1 = IsObject
type Test2 = IsObject
type Test3 = IsObject
type Test4 = IsObject
type Test5 = IsObject
シニアエンジニアがここで絶望するのは、`T extends {}` が「オブジェクト型かどうか」ではなく、「`null` と `undefined` ではないか」という判定にすり替わっている点だ。
ライブラリの型定義などで、「任意のオブジェクトのみを受け入れたい」という意図で `T extends {}` を使用している場合、それは数値をはじめとするプリミティブの侵入を完全に許容していることになる。
—
3. 防壁の構築：真に厳密な型を選ぶための3つの選択肢
では、この脆弱性を断ち切り、安全なアーキテクチャを構築するにはどうすればよいのか。用途に応じた3つの防壁を使い分ける必要がある。
① `Record` : 「ガチガチの空オブジェクト」を強要する
真に「1つのプロパティすら持たない空のオブジェクト」を表現したい場合、 `{}` を使ってはならない。代わりに `Record
type EmptyObject = Record
const validEmpty: EmptyObject = {}; // OK
// コンパイラはプロパティの追加や他の型の混入を完全にシャットアウトする
// validEmpty.foo = “hack”; // Error: Property ‘foo’ does not exist on type ‘Record
// const invalidNum: EmptyObject = 42; // Error: Type ‘number’ is not assignable to type ‘Record
なぜこれで機能するのか？
`never` 型は、どの型も代入できない「底（Bottom）の型」である。`Record
② `object` （小文字）: プリミティブを排除した「真の非プリミティブ型」
TypeScriptには、小文字の `object` 型が存在する。これは `{}` と混同されやすいが、コンパイラ内部では全く異なるルールで評価される。
const obj: object = { a: 1 }; // OK
const primitiveObj: object = 42; // Error: Type ‘number’ is not assignable to type ‘object’.
`object` 型は、配列、関数、オブジェクトリテラルなどの非プリミティブ値のみを許可する。数値や文字列、真偽値はここで完全に弾かれる。ただし、プロパティの有無や型構造の制約は持たないため、「何かオブジェクトが欲しい」という場合の最も安全なベースラインとなる。
③ `Record` または `Record` : 拡張可能なデータ構造
「任意のプロパティを持つが、中身は未知（`unknown`）であるため、安全に取り出してから型ガードを通す必要がある」という、動的なJSONペイロード等を扱う場合はこちらを使う。
type SafePayload = Record
const payload: SafePayload = JSON.parse(userInput);
// payload.foo は unknown 型になるため、直接メソッドを呼ぶことはできず、安全性が担保される
—
4. ランタイムへの影響とメモリ最適化の視点
チーフアーキテクトとして、型システムがランタイムのパフォーマンスやメモリ最適化にどう影響するかについても言及しておかねばならない。
`{}` 型を用いて「何でも入る箱」を作ってしまうと、開発者はTypeScriptの型推論に依存したまま、実行時に不確定な構造のオブジェクトをV8エンジンへ流し込むことになる。
V8（Chrome/Node.jsのJavaScriptエンジン）は、オブジェクトの形状（Hidden Class / Shapes）が安定しているときにインラインキャッシュ（IC）を最適に効かせ、メモリ上のプロパティオフセットを固定化する。
`{}` が `any` のように振る舞うことで、コードベース全体でオブジェクトの構造が流動化（Shapesのメガモーフィック化）すると、JITコンパイラは最適化を諦め、メモリ消費量の増大とガベージコレクション（GC）の頻発を招く。
厳格に `Record
—
まとめ：プロダクションコードへの適用指針
1. `{}` はコードから駆逐せよ
`{}` は「空のオブジェクト」ではなく「非 `null/undefined` の万物」であるという事実をチーム全体で共通認識とせよ。
2. 「プロパティが存在してはならないオブジェクト」には `Record
ステートの初期値や、パラメータを持たないアクションの型定義にはこれ以外の選択肢はない。
3. 「プリミティブを除外したオブジェクト」には小文字の `object` を使え
関数の引数などで「オブジェクト全般」を受け入れたい場合、 `{}` ではなく `object` を選ぶことで、プリミティブの混入というヒューマンエラーをコンパイラに防がせる。
型システムは、開発者の「意図」をコンパイラに正確に伝えるための防壁である。その防壁の隙間（`{}` の罠）を理解し、堅牢な型設計を行うことこそが、真にスケーラブルなシステムを維持する唯一の道である。