こんにちは！TypeScriptの世界へようこそ。
日々、フロントエンドからバックエンドまで設計していると、「あれ？ このコード、型定義は合っているはずなのに、なぜか赤く波線（エラー）が出るぞ…？」と首を傾げたくなる瞬間に出会いませんか？
TypeScriptの根幹をなすのは「構造的部分型（ダック・タイピング）」という思想です。「歩き、鳴き、カモのように振る舞うなら、それはカモだ」という考え方で、要するに「必要なプロパティさえ持っていれば、余計なものが入っていてもOK」というのが本来のルールです。
しかし、不思議なことに、「直接書いたオブジェクト（オブジェクトリテラル）」を代入しようとした時だけ、このルールが急に厳しくなり、コンパイラから「そんな余計なプロパティは認めません！」と怒られてしまいます。これが今回解説する「余剰プロパティチェック（Excess Property Checking）」です。
ここをクリアすれば、TypeScriptの型システムの本質と「なぜそんな仕組みになっているのか」が手に取るように分かりますよ。さあ、一緒に紐解いていきましょう！
—
1. そもそも「構造的部分型」とはどういうこと？
まずは基本のおさらいです。TypeScriptは、オブジェクトが「どんな形（構造）をしているか」で型の一致を判断します。
以下のコードを見てください。
interface User {
name: string;
}
// 正常なパターン：変数経由で渡す場合
const rawData = { name: “Alice”, age: 25 }; // nameの他に age も持っている
const user: User = rawData; // 咦？エラーにならない！
console.log(user.name); // “Alice”
変数 `rawData` は `name` のほかに `age` という余分なプロパティを持っていますが、`User` 型の変数 `user` に代入してもエラーになりません。これが構造的部分型の恩恵です。「`User`として必要な `name` さえ持っていれば、追加の情報（`age`）が混ざっていても、受け取る側は困らないよね」という思想ですね。
—
2. なぜか怒られる？「オブジェクトリテラル」の厳格な罠
ところが、先ほどの `rawData` という変数を挟まず、オブジェクトを直接（リテラルで）代入しようとすると、景色が一変します。
interface User {
name: string;
}
// コンパイルエラー！
const user: User = {
name: “Alice”,
age: 25 // 💥 Error: Object literal may only specify known properties, and ‘age’ does not exist in type ‘User’.
};
「あれっ？ さっきは通ったのに、なんで直接書くと怒られるの？」って思いますよね。
構造的部分型なのに、なぜオブジェクトリテラルだけにこんな厳しい制限があるのでしょうか？
脳内イメージ：それは「タイポ（打ち間違い）」を防ぐためのセーフティネット
TypeScriptチームがこの仕様を入れた最大の理由は、開発者のケアレスミス（タイポ）をコンパイル時に検知するためです。
もし、あなたが本当は `userName` というプロパティを書きたかったのに、うっかり `usreName` と打ち間違えてしまったと想像してください。
interface Settings {
userName: string;
}
const settings: Settings = {
usreName: “Bob” // 打ち間違い！
};
もし余剰プロパティチェックがなかったら、TypeScriptはこのコードを「`Settings` 型に余分な `usreName` が生えているだけ」と解釈してしまい、エラーになりません。結果、アプリを実行した後に「あれ？設定が反映されない…」と頭を抱えることになります。
オブジェクトリテラルに直接値を書くときは、「開発者がその型のプロパティ名を完全に意図して書いているはずだ」という強い仮定が置かれます。そのため、型定義に存在しないプロパティが見つかった瞬間に、「おいおい、君が書こうとしたプロパティ、型定義にないけど打ち間違えじゃないのかい？」とTypeScriptが優しく（厳しく）教えてくれるのです。これが余剰プロパティチェックの正体です。
—
3. この制限をスマートに回避するパターン
実務では、「APIから受け取ったデータをごっそり流し込みたい」「一時的に色々なプロパティが混ざったオブジェクトを扱いたい」など、この厳格なチェックをすり抜けたい場面が必ず出てきます。
代表的な3つの回避パターンをマスターしておきましょう。
回避策 A: いったん別変数に逃がす（構造的部分型を適用させる）
最初に見せた例ですね。一度変数に代入してから渡すことで、オブジェクトリテラルに対する厳格なチェックの対象外（通常の構造的部分型）になります。
interface Point {
x: number;
y: number;
}
// 一度変数に受ける
const inputData = { x: 10, y: 20, z: 30 };
const p: Point = inputData; // 💡 変数経由なら余剰プロパティ(z)は無視される！
回避策 B: 型アセッション（`as` を使う）を使う
「このオブジェクトはこの型として扱うんだ！」とTypeScriptに明示的に伝える方法です。コンパイラに対する強い上書き命令になります。
interface Point {
x: number;
y: number;
}
// 型アサーションで強制的に Point 型として教え込む
const p = { x: 10, y: 20, z: 30 } as Point;
※注意：型アサーションは強力ですが、本当に意図した型になっているか注意深く使う必要があります。
回避策 C: インデックスシグネチャ（Index Signature）を使う
型定義の段階で、「あらかじめ決められたプロパティ以外に、任意の名前と型のプロパティを受け入れてもいいよ」と許可する方法です。
interface FlexibleUser {
name: string;
[key: string]: any; // 👈 これがインデックスシグネチャ
}
// z や other などの未知のプロパティがいくらあっても怒られない！
const user: FlexibleUser = {
name: “Charlie”,
age: 30,
location: “Tokyo”
};
汎用的な設定オブジェクトや、動的なデータを扱うときによく使われるテクニックです。
—
まとめ：TypeScriptの優しさを味方に付けよう
ここまでの話をギュッとまとめてみましょう。
1. 基本は「構造的部分型」：必要なプロパティさえあれば、余分なものがあっても受け入れるのがTypeScriptの基本スタンス。
2. オブジェクトリテラルだけは特別：タイポ（打ち間違い）によるバグを防ぐため、直接書いたオブジェクトには「余剰プロパティチェック」が走り、未知のプロパティを弾く。
3. 必要に応じて回避策を使う：変数に逃がしたり、型アサーションを使ったり、インデックスシグネチャを活用することで、状況に応じた柔軟な型設計ができる。
TypeScriptのこうした一見「厳しすぎる挙動」の裏には、常に「実行時エラーを未然に防ぎたい」という開発者への深い愛と設計思想が隠されています。
ここをクリアできれば、もうTypeScriptの型システムに戸惑うことはありません。自信を持って、より堅牢で美しいコードを書いていきましょう！