皆さん、こんにちは！ TypeScriptの奥深さに魅了され、日夜その型システムと格闘しているチーフアーキテクトの〇〇です。
さて、TypeScriptを学び始めた皆さん、あるいは他の言語からTypeScriptの世界に足を踏み入れた皆さんの中には、「型ってなんだか堅苦しいな」「どうしてこのコードがOKで、このコードはNGなんだろう？」と戸惑っている方もいるかもしれませんね。
でも、安心してください！ TypeScriptの型システムには、ちょっとした「お作法」があるんです。そのお作法の一つが、今日皆さんにご紹介する「構造的部分型（Structural Typing）」、別名「ダックタイピング」の正体です。
ここをクリアすれば、TypeScriptの基本はバッチリマスターできますよ！ さあ、一緒にTypeScriptの真髄に触れていきましょう。
—
🦆 TypeScriptの「型」って、そもそも何？ – ダックタイピングの正体
TypeScriptの最大の魅力は、JavaScriptに「型」という概念をもたらし、コードの品質と堅牢性を飛躍的に高める点にあります。でも、その型のチェックの仕方が、実は他の多くの言語とは一線を画していることをご存知でしょうか？
多くの言語、特にJavaやC#のような「名前的型付け言語（Nominal Typing）」では、あるオブジェクトが特定の型であるかどうかを、その「名前」で判断します。例えば、`Cat`クラスのインスタンスは`Cat`型であり、`Animal`型であるためには`Animal`という名前のインターフェースを明示的に実装している必要があります。名前が異なれば、中身が同じでも別の型として扱われます。
「アヒルのように鳴き、アヒルのように歩けば、それはアヒルである」
一方、TypeScriptが採用しているのは「構造的部分型（Structural Typing）」です。これは通称「ダックタイピング」とも呼ばれます。この言葉は、こんな格言から来ています。
> 「もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
つまり、TypeScriptの型システムは、オブジェクトの「名前」ではなく、その「中身（構造）」に注目するんです。たとえ名前が違う型同士でも、持っているプロパティやメソッドの「構造」が合っていれば、互換性があると判断される。これがTypeScriptの型の最も基本的な考え方になります。
ちょっと面白いですよね？ では、具体的なコードでその違いを見ていきましょう。
名前的型付け言語 vs. 構造的部分型付け言語
名前的型付けのイメージ（TypeScriptでは通常こうはならない）
// 仮にTypeScriptが名前的型付け言語だったとしたら…
class Dog {
name: string;
constructor(name: string) { this.name = name; }
bark() { console.log(`${this.name}: Bow-wow!`); }
}
class Animal {
name: string;
constructor(name: string) { this.name = name; }
walk() { console.log(`${this.name} walks.`); }
}
let myDog: Dog = new Dog(“Pochi”);
// let myAnimal: Animal = myDog; // ここでエラー！ DogとAnimalは名前が違うため互換性がないと判断されるはず
もしTypeScriptが名前的型付け言語だったら、`Dog`と`Animal`はそれぞれ異なるクラス名を持つため、たとえ同じプロパティやメソッドを持っていても、互換性がないと判断されるでしょう。
TypeScriptの構造的部分型（実際のTypeScriptの挙動）
実際のTypeScriptでは、クラスも結局は「構造」を持つオブジェクトとして扱われます。
// 実際のTypeScriptの挙動
class Dog {
name: string;
constructor(name: string) { this.name = name; }
bark() { console.log(`${this.name}: Bow-wow!`); }
}
// Animalという名前のインターフェースを定義してみましょう
interface Animal {
name: string;
// 犬も猫も動物なので、名前を持っているはずですよね
}
let myDog: Dog = new Dog(“Pochi”);
let myAnimal: Animal;
// myDogは`name`プロパティを持っているので、`Animal`型に代入できます！
myAnimal = myDog;
console.log(myAnimal.name); // 出力: Pochi
// myAnimal.bark(); // エラー！ Animalインターフェースにはbarkメソッドがないため
どうでしょう？ `myDog`は`Dog`クラスのインスタンスですが、`Animal`インターフェースが要求する`name`プロパティを持っているため、`Animal`型として扱えるんです。これが構造的部分型の核心です。
`Animal`インターフェースは`name`プロパティしか要求していないので、`bark`メソッドを持つ`myDog`を`myAnimal`に代入しても問題ありません。しかし、`myAnimal`が`bark`メソッドを持っている保証はないため、`myAnimal.bark()`はコンパイルエラーになります。ここがポイントですね。
—
🛠️ TypeScriptにおける構造的部分型の基本ルール
では、TypeScriptがオブジェクトの構造をどうやって比較し、互換性を判断しているのか、その具体的なルールを見ていきましょう。
基本的に、TypeScriptは「代入される側の型（ターゲット型）」が要求するすべてのプロパティを、「代入する側の型（ソース型）」が持っているかどうかをチェックします。
判定ルール：ターゲット型がソース型の「部分」であること
- プロパティ名と型の一致:
- ターゲット型が持つすべてのプロパティについて、ソース型も同じ名前のプロパティを持ち、かつそのプロパティの型が互換性を持っている必要があります。
- 余分なプロパティはOK:
- ソース型がターゲット型にはない余分なプロパティを持っていても、それは問題になりません。ターゲット型が要求する構造を満たしていればOKです。
- メソッドもプロパティとして扱われる:
- メソッドもプロパティの一種です。メソッドの型（シグネチャ、つまり引数と戻り値の型）が互換性を持っている必要があります。
- オプションプロパティの扱い:
- ターゲット型がオプションプロパティを持っている場合、ソース型がそのプロパティを持っていなくても構いません。持っている場合は、型が互換性を持っている必要があります。
コード例で理解する基本ルール
// ターゲットとなる型を定義します
interface Person {
name: string;
age: number;
}
// ソースとなるオブジェクトをいくつか用意してみましょう
let personA = { name: “Alice”, age: 30 };
let personB = { name: “Bob”, age: 25, occupation: “Engineer” }; // 余分なプロパティあり
let personC = { name: “Charlie” }; // ageプロパティが不足
let personD = { name: “David”, age: “twenty” }; // ageプロパティの型が不一致
let p1: Person = personA; // OK: nameとageを持つ
console.log(p1); // { name: ‘Alice’, age: 30 }
let p2: Person = personB; // OK: nameとageを持ち、occupationは余分だが問題なし
console.log(p2); // { name: ‘Bob’, age: 25, occupation: ‘Engineer’ }
// let p3: Person = personC; // エラー: Property ‘age’ is missing in type ‘{ name: string; }’ but required in type ‘Person’.
// console.log(p3);
// let p4: Person = personD; // エラー: Type ‘string’ is not assignable to type ‘number’.
// console.log(p4);
この例からもわかるように、`Person`インターフェースが求める`name: string`と`age: number`を両方とも持っているオブジェクトであれば、`Person`型として扱えるんです。`personB`のように`occupation`という余分なプロパティがあっても、何ら問題ありません。
—
🧑💻 コードで学ぶ構造的部分型 – さらに深く！
もう少し複雑なケースで、構造的部分型を見ていきましょう。
例1: メソッドを持つオブジェクトの代入
メソッドもプロパティの一種として構造がチェックされます。
interface Speaker {
name: string;
speak(): void; // speakメソッドを持つことを要求
}
class Doggo {
name: string;
constructor(name: string) {
this.name = name;
}
// speakメソッドのシグネチャがSpeakerインターフェースと一致しています
speak(): void {
console.log(`${this.name} says woof!`);
}
}
class Catto {
name: string;
constructor(name: string) {
this.name = name;
}
// Cattoはmeowメソッドを持ちます（speakメソッドではない）
meow(): void {
console.log(`${this.name} says meow!`);
}
}
let dog: Doggo = new Doggo(“Fido”);
let cat: Catto = new Catto(“Whiskers”);
let speaker1: Speaker = dog; // OK: Doggoはnameとspeak()メソッドを持つ
speaker1.speak(); // 出力: Fido says woof!
// let speaker2: Speaker = cat; // エラー: Property ‘speak’ is missing in type ‘Catto’ but required in type ‘Speaker’.
// catはspeak()メソッドを持たないため、Speaker型には代入できません
`Doggo`クラスのインスタンスは`name`プロパティと`speak()`メソッドの両方を持っているため、`Speaker`型として代入可能です。しかし、`Catto`クラスのインスタンスは`meow()`メソッドは持っていますが、`speak()`メソッドは持っていないため、`Speaker`型としては扱えません。
例2: オプションプロパティと型互換性
オプションプロパティの有無も、構造的部分型では重要な要素です。
interface Car {
brand: string;
model: string;
year?: number; // yearはオプションプロパティ
}
// yearを持たないオブジェクト
let carA = { brand: “Toyota”, model: “Corolla” };
// yearを持つオブジェクト
let carB = { brand: “Honda”, model: “Civic”, year: 2020 };
// 余分なプロパティも持つオブジェクト
let carC = { brand: “Nissan”, model: “Leaf”, year: 2022, electric: true };
let myCar1: Car = carA; // OK: yearがなくてもCar型に代入できる
console.log(myCar1); // { brand: ‘Toyota’, model: ‘Corolla’ }
let myCar2: Car = carB; // OK: yearがあってもCar型に代入できる
console.log(myCar2); // { brand: ‘Honda’, model: ‘Civic’, year: 2020 }
let myCar3: Car = carC; // OK: 余分なelectricプロパティがあっても問題なし
console.log(myCar3); // { brand: ‘Nissan’, model: ‘Leaf’, year: 2022, electric: true }
// もしターゲット型がオプションではないプロパティを要求したら？
interface FullCar {
brand: string;
model: string;
year: number; // yearが必須
}
// let fullCar1: FullCar = carA; // エラー: Property ‘year’ is missing in type ‘{ brand: string; model: string; }’ but required in type ‘FullCar’.
// carAはyearプロパティを持たないため、FullCar型には代入できません
`Car`インターフェースの`year`がオプションなので、`carA`のように`year`プロパティがなくても問題なく代入できます。しかし、`FullCar`インターフェースのように`year`が必須になると、`year`を持たない`carA`は代入できなくなります。
陥りやすい「フレッシュネスチェック」との関係（補足）
「余分なプロパティがあってもOK」というルールは、オブジェクトリテラルを直接変数に代入する際には、少しだけ厳しくなります。これを「オブジェクトリテラルフレッシュネスチェック」と呼びます。
interface Point {
x: number;
y: number;
}
interface Point3D {
x: number;
y: number;
z: number;
}
let p2d: Point = { x: 10, y: 20 }; // OK
// let p2d_error: Point = { x: 10, y: 20, z: 30 }; // エラー！
// オブジェクトリテラルを直接代入する場合、ターゲット型にないプロパティがあるとエラーになる
// Type ‘{ x: number; y: number; z: number; }’ is not assignable to type ‘Point’.
// Object literal may only specify known properties, and ‘z’ does not exist in type ‘Point’.
// しかし、一度別の変数に代入すればOK
let p3d_obj = { x: 10, y: 20, z: 30 };
let p2d_ok: Point = p3d_obj; // OK！
// これは構造的部分型のルールに基づき、p3d_objがPointの構造を満たしているため。
// p3d_objは「フレッシュ」なオブジェクトリテラルではないと見なされるため、余分なプロパティがあっても許容されます。
console.log(p2d_ok); // { x: 10, y: 20, z: 30 }
これは初学者が少し混乱しやすいポイントですが、「オブジェクトリテラルを直接代入する時だけは、型に明示されていない余分なプロパティは許容しない」という、エラーを未然に防ぐためのTypeScriptの親切な機能だと思ってください。一度別の変数に代入してしまえば、通常の構造的部分型のルールが適用されます。
—
✨ 構造的部分型がもたらす恩恵と設計思想
TypeScriptがなぜ構造的部分型を採用しているのか、その背景には非常に合理的な理由があります。
1. JavaScriptとの高い親和性:
JavaScriptは元々、オブジェクトの構造を重視する言語です。特定のクラスやインターフェースを明示的に継承・実装しなくても、必要なメソッドやプロパティを持っていれば、その機能を使えるという、まさにダックタイピング的な性質を持っています。TypeScriptが構造的部分型を採用していることで、JavaScriptのこの柔軟な特性を損なわずに、型安全性を確保できるんです。
2. 柔軟なコード設計とリファクタリング:
「このオブジェクトは、このインターフェースを実装しているはずだ」と推測するのではなく、「このオブジェクトは、このインターフェースが要求する構造を実際に持っている」と判断してくれるため、既存のコードを修正することなく、新しいインターフェースに適合させることができます。これは、特に大規模なプロジェクトや、ライブラリとの連携において、非常に大きなメリットとなります。
3. 結合度の低い設計:
特定の名前の型に強く依存することなく、「この機能を使うためには、こういう構造のオブジェクトが必要だ」というミニマルな要件だけを型として定義できます。これにより、各コンポーネント間の結合度を低く保ち、変更に強いシステムを構築しやすくなります。
4. テストのしやすさ:
モックオブジェクト（テストのために一時的に作成するダミーオブジェクト）を作成する際にも、非常に便利です。特定のインターフェースを実装したクラスを作る必要がなく、テストに必要なプロパティとメソッドだけを持つシンプルなオブジェクトを生成すれば、型チェックが通ります。
—
🚀 まとめ：TypeScriptの型マスターへの道！
今日、私たちはTypeScriptの型システムの根幹をなす「構造的部分型」について深く掘り下げてきました。
- TypeScriptは名前ではなく、オブジェクトの「構造（中身）」で型の互換性を判断する。
- ターゲット型が要求するすべてのプロパティ（メソッドも含む）をソース型が持っていれば、代入可能である。
- ソース型がターゲット型にはない余分なプロパティを持っていても、基本的には問題ない（ただしフレッシュネスチェックには注意）。
この構造的部分型の理解こそが、TypeScriptの型システムを真にマスターするための第一歩です。この特性を理解していれば、「なぜこのコードはエラーになるのか」「なぜこのコードはエラーにならないのか」というTypeScript特有の疑問の多くが、スッと腹落ちするはずです。
TypeScriptは、単にJavaScriptに型を追加しただけでなく、その型チェックの思想自体が非常にモダンで実用的です。この知識を武器に、皆さんのTypeScript開発がより一層スムーズで楽しいものになることを願っています！
これからも一緒に、TypeScriptの奥深い世界を探求していきましょうね！