余剰プロパティチェックの迷宮：コンパイラが隠す「構造的型付け」の例外と境界防壁
TypeScriptの型システムは、基本的に「構造的型付け（Structural Subtyping）」をベースに構築されている。ダック・タイピングの思想を受け継ぎ、オブジェクトがどのような形状（プロパティ）を持つかによって型の適合性を判定する。
しかし、実務でTypeScriptを書くエンジニアなら誰もが一度は遭遇する「謎の現象」がある。
オブジェクトリテラルを直接関数の引数に渡すとコンパイルエラーになるのに、一度変数に代入してから渡すと何事もなかったかのようにスルーされる挙動だ。
interface Config {
host: string;
port: number;
}
function connect(config: Config) {
/ … /
}
// 1. 直接渡す：エラーになる
connect({ host: “localhost”, port: 8080, protocol: “https” });
// Error: Object literal may only specify known properties, and ‘protocol’ does not exist in type ‘Config’.
// 2. 変数経由で渡す：通る
const myConfig = { host: “localhost”, port: 8080, protocol: “https” };
connect(myConfig); // OK
なぜこのような二重基準が存在するのか。これはTypeScriptコンパイラ（`tsc`）の型チェッカーが実装する余剰プロパティチェック（Excess Property Checking: EPC）という特殊なフェーズに起因する。
今回は、この余剰プロパティチェックの内部仕様、型推論メカニズム、そしてランタイムやメモリ最適化の文脈において、この挙動が何を意味するのかをコンパイラの中枢から解き明かす。
—
1. 構造的型付け vs 余剰プロパティチェック
本来、TypeScriptの構造的型付けの原則に従えば、`Config`型を要求する関数に対して、`protocol`という余分なプロパティを持つオブジェクトを渡すことは完全に合法であるべきだ（「`Config`が要求する最小限の構造を満たしているため」）。事実、変数経由（2のケース）ではこの原則通りに型が合致し、エラーにならない。
では、なぜオブジェクトリテラル直接の場合（1のケース）のみ、厳しい検問が行われるのか。
その理由は、「開発者のタイポや意図しないバグを早期に検出するため」という極めて実用的なヒューリスティックにある。もし構造的型付けを厳密に適用しすぎると、プロパティ名を誤記した際に、エラーにならずに「無視される」という最悪のサイレントバグを生む。
interface UserOptions {
retries: number;
}
// 開発者は「retry」と書きたかったがタイポした
setup({ retry: 3 });
もし余剰プロパティチェックがなければ、`retry`は無視され、`retries`はデフォルト値のまま実行されるか、意図しない挙動を引き起こす。EPCはこの種のヒューマンエラーを防ぐための、コンパイラによる防壁なのだ。
—
2. コンパイラ内部：`checkTypeRelatedTo` と Freshness（鮮度）の概念
TypeScriptのコンパイラ（`checker.ts`）は、オブジェクトリテラルを評価する際に「Freshness（鮮度）」という内部フラグ（あるいは概念）を管理している。
コンパイルの過程において、コード中に直接記述されたオブジェクトリテラルは「Fresh（新鮮）」な状態としてマークされる。一方、変数に代入されたり、関数から返されたり、型アサーション（`as Config`）を通ったオブジェクトは「Stale（古くなった／既知の変数）」な状態に遷移する。
チェックのアルゴリズム的挙動
コンパイラが型の一致を検証する際、以下の条件が揃った極めて限定的なシチュエーションでのみ、余剰プロパティチェックが発動する。
1. 検証対象のターゲット型がオブジェクト型であること。
2. ソースがオブジェクトリテラル（Freshな状態）であること。
3. ターゲット型に存在しないプロパティ（Excess Property）がソースに含まれていること。
変数に代入された瞬間、オブジェクトは `Stale` になり、鮮度を失う。鮮度を失ったオブジェクトに対しては、通常の構造的型付け（Subtyping）のみが適用されるため、余分なプロパティは単に無視され、エラーは発生しない。
—
3. シニアエンジニアが知るべき「防壁の抜け穴」と型安全性の罠
この仕様の裏側を知ることで、私たちは型システムの隙間を突き、あるいは意図的に挙動をコントロールできるようになる。
パターンA: 型アサーションによる鮮度の強制剥奪
`as` 構文やアサーション関数を用いると、コンパイラに対して「このオブジェクトの鮮度を落とせ（＝私を信じろ）」と強制できる。
connect({ host: “localhost”, port: 8080, protocol: “https” } as Config);
// EPCはバイパスされ、コンパイルは成功する
これはセキュリティや堅牢性の観点から危険な場合がある。外部からの動的ペイロードを扱う際、意図しないフィールドが混入しているにもかかわらず、型アサーションで無理やりコンパイルを通すと、ランタイムで予期せぬデータ構造を引き回す原因になる。
パターンB: インデックスシグネチャによるチェックの無効化
インターフェースに文字列インデックスシグネチャ（Index Signature）を定義すると、余剰プロパティチェックの挙動は根本から変わる。
interface FlexibleConfig {
host: string;
port: number;
[key:-string]: unknown; // インデックスシグネチャ
}
// エラーにならない！
connect({ host: “localhost”, port: 8080, protocol: “https” });
コンパイラは「任意のプロパティを受け入れてよい」と解釈するため、オブジェクトリテラルであっても余剰プロパティチェックを行わなくなる。プラグイン機構や設定ファイルのパーサーを作る際、この挙動を意図して利用することが多い。
—
4. ランタイム・メモリ最適化との関連性
「コンパイル時の型チェック」はランタイムの実行速度やメモリ消費に直接影響を与えない――というのがTypeScriptの基本原則である（TypeScriptは最終的にただのJavaScriptにトランスパイルされるため、型情報はすべて消去される）。
しかし、「余剰プロパティを許容するかどうか」の設計は、V8などのJavaScriptエンジンにおけるメモリレイアウト（Hidden Classes / Shapes）と密接に関係している。
厳密な型定義（余剰プロパティを持たないオブジェクト）を強制することは、アプリケーション全体で生成されるオブジェクトの形状（Shape）を均一化することにつながる。V8エンジンは、同じ形状を持つオブジェクトに対して同じ Hidden Class を割り当てることで、インラインキャッシュ（IC）を最適化し、プロパティアクセスを高速化する。
余剰プロパティが不規則に混入するコードベースは、オブジェクトの形状を多様化させ、メガモーフィック（多態的）な状態を引き起こし、エンジンの最適化効率を低下させる要因になり得る。つまり、TypeScriptの厳格な余剰プロパティチェックは、コードの意図を明確にするだけでなく、結果的にランタイムのメモリ効率・実行性能を最適化する方向へと開発者を導くセーフティネットとしても機能しているのだ。
—
まとめ
TypeScriptの余剰プロパティチェックは、単なる「お節介なエラーメッセージ」ではない。
それは、構造的型付けの柔軟性と、堅牢なソフトウェア設計のための静的検証を両立させるためにコンパイラが巧妙に張り巡らせた防壁である。
- オブジェクトリテラル（Fresh）はタイポ検知のために厳しく検閲される。
- 変数経由（Stale）になると、構造的型付けの原則に従い、余分なプロパティは許容される。
- インデックスシグネチャや型アサーションによって、この防壁の挙動は制御可能である。
この低レイヤのメカニズムを完全に掌握した上で型を設計すること。それこそが、単なる「型ヒント書き」から脱却し、TypeScriptの神髄を使いこなすシニアエンジニアの条件である。