【初心者向け】TypeScript Interfaceの基礎と使い方

---

【初心者向け】TypeScript Interfaceの基礎と使い方：詳細解説

はじめに：なぜTypeScriptを使うのか、そしてInterfaceの役割とは？

プログラミングの世界に足を踏み入れたばかりの方、あるいはJavaScriptでの開発経験があり、TypeScriptに興味を持ち始めた方も多いでしょう。TypeScriptは、JavaScriptに「静的型付け」という強力な概念をもたらす言語です。では、なぜ型付けが重要なのでしょうか？

JavaScriptは非常に柔軟な言語ですが、その柔軟さが思わぬバグの原因となることがあります。例えば、関数にオブジェクトを渡す際に、そのオブジェクトが期待するプロパティを持っているかどうかは実行時にならないと分かりません。プロパティ名にタイポがあったり、存在しないプロパティにアクセスしたりすると、プログラムはエラーで停止するか、予期しない動作をします。

TypeScriptは、このような問題を開発の早い段階、つまりコードを書いている最中やコンパイル時に発見する手助けをしてくれます。静的型付けにより、変数や関数の引数・戻り値などがどのような「型」であるべきかを定義し、コンパイラがそれをチェックしてくれるのです。これにより、実行時エラーを減らし、コードの信頼性を高めることができます。

TypeScriptの型システムの中で、非常に重要な役割を担うのが「Interface（インターフェース）」です。Interfaceは、主にオブジェクトが持つべき構造（プロパティとその型、メソッドのシグネチャなど）を定義するために使われます。これにより、「この関数に渡すオブジェクトは、必ずこのプロパティとあのプロパティを持っている必要がある」といった「契約」を明示的にコードで表現できるようになります。

Interfaceを使うことで、以下のようなメリットが得られます。

• 可読性の向上: コードを見ただけで、どのような構造のデータが扱われているかが分かります。
• 保守性の向上: 型の定義があるため、コードの変更やリファクタリングが安全に行えます。型定義に反する変更はコンパイラが警告してくれるため、意図しない副作用を防ぎやすくなります。
• 開発効率の向上: エディタの補完機能が強化され、オブジェクトが持つプロパティやメソッドを簡単に見つけることができます。

この記事では、TypeScriptのInterfaceについて、その基本的な使い方から、関数型、インデクサ、クラスへの実装、Interfaceの拡張といった応用的なトピックまで、初心者の方にも分かりやすく、詳細に解説していきます。この記事を読み終える頃には、Interfaceを自信を持って使いこなし、より堅牢でメンテナンスしやすいTypeScriptコードを書けるようになっているはずです。

さあ、TypeScriptのInterfaceの世界へ飛び込みましょう！

TypeScriptの型システムの概要

Interfaceの学習を始める前に、TypeScriptの基本的な型システムについて簡単に触れておきましょう。TypeScriptには様々な型がありますが、大きく分けてプリミティブ型とオブジェクト型があります。

プリミティブ型 (Primitive Types)

これはJavaScriptにも存在する基本的な値の型です。

• string: 文字列 ("Hello, world!")
• number: 数値 (123, 3.14)
• boolean: 真偽値 (true, false)
• null: 値がないことを示す特別な値
• undefined: 値が未定義であることを示す特別な値
• symbol: 一意な値を生成するために使用される型
• bigint: 非常に大きな整数を扱うための型

これらの型は、変数宣言時に型注釈（Type Annotation）を使って指定します。

typescript
let name: string = "Alice";
let age: number = 30;
let isActive: boolean = true;

配列型 (Array Type)

同じ型の要素を複数持つ配列の型です。

typescript
let numbers: number[] = [1, 2, 3]; // 数値の配列
let names: Array<string> = ["Alice", "Bob"]; // 文字列の配列 (ジェネリック型記法)

オブジェクト型 (Object Type)

複数のプロパティやメソッドを持つ値の型です。JavaScriptでは、様々なデータ構造がオブジェクトとして表現されます（配列も関数も広義にはオブジェクトです）。

オブジェクトの型を定義する際に、そのオブジェクトがどのようなプロパティを、どのような型で持つべきかを明確に指定する必要があります。ここでInterfaceが非常に役立ちます。

例えば、以下のようなJavaScriptのオブジェクトを考えてみましょう。

javascript
const user = {
id: 1,
name: "Alice",
age: 30,
isActive: true,
};

このオブジェクトの型をTypeScriptで表現したい場合、Interfaceを使わずにインラインで型注釈を書くことも可能ですが、複雑になったり、同じ構造を何度も使ったりする場合には非効率的です。

typescript
// インラインでの型注釈（冗長になりがち）
const anotherUser: { id: number; name: string; age: number; isActive: boolean } = {
id: 2,
name: "Bob",
age: 25,
isActive: false,
};

ここでInterfaceが登場します。Interfaceを使えば、このオブジェクトの構造に名前を付けて再利用できるようになります。

Interfaceとは何か？

Interfaceは、TypeScriptにおいてオブジェクトの「形状（Shape）」を定義するための強力なツールです。形状とは、具体的にはそのオブジェクトが持つべきプロパティの名前、それらのプロパティの型、そしてメソッドのシグネチャ（引数の型と戻り値の型）のことです。

Interfaceは、コードに対して「この値は、Interfaceで定義されたこの構造を満たしていなければならない」という「契約」を結ばせます。もし値がその契約を満たしていない場合、TypeScriptコンパイラはエラーを報告します。

JavaScriptのオブジェクトは、キー（プロパティ名）と値のペアの集まりです。Interfaceは、まさにこの「キーと値のペア」の期待される形を定義します。

“`typescript
// Interfaceの定義
interface User {
id: number;
name: string;
age: number;
isActive: boolean;
}

// Interfaceを型として使用
const user1: User = {
id: 1,
name: “Alice”,
age: 30,
isActive: true,
};

// Interfaceの契約を満たさないオブジェクトはエラーになる
// const user2: User = { // コンパイルエラーが発生する
// id: 2,
// name: “Bob”,
// // ageとisActiveが不足している
// };

// idが数値型ではないためエラー
// const user3: User = { // コンパイルエラーが発生する
// id: “3”,
// name: “Charlie”,
// age: 22,
// isActive: false,
// };
“`

上記の例では、Userという名前のInterfaceを定義しました。このInterfaceは、id（number型）、name（string型）、age（number型）、isActive（boolean型）という4つのプロパティを持つオブジェクトの形状を定義しています。

user1はUser Interfaceの契約を満たしているため、エラーなく代入できます。しかし、user2はageとisActiveプロパティが不足しており、user3はidプロパティの型が異なっているため、どちらもコンパイル時にエラーが発生します。このように、Interfaceは開発の早い段階で型の不一致を発見する手助けをしてくれます。

Interfaceは、TypeScriptコンパイラによって型チェックのためにのみ使用され、実際のJavaScriptコードにはコンパイルされません。これは、TypeScriptのInterfaceが「ダックタイピング (Duck Typing)」の原則に基づいているためです。「もしそれがアヒルのように歩き、アヒルのように鳴くなら、それはアヒルである」という考え方です。Interfaceは、特定の構造を持っているかどうかだけをチェックし、そのオブジェクトがどこから来たのか（どのクラスのインスタンスなのかなど）は問いません。

Interfaceと型エイリアス (Type Alias) の違い（簡単な紹介）

TypeScriptには、Interfaceと似た目的で使用される「型エイリアス (Type Alias)」という機能もあります。

“`typescript
// 型エイリアスの定義
type UserAlias = {
id: number;
name: string;
age: number;
isActive: boolean;
};

// 型エイリアスを型として使用
const user4: UserAlias = {
id: 4,
name: “David”,
age: 28,
isActive: true,
};
“`

見た目は非常に似ています。どちらもオブジェクトの形状に名前を付けて再利用できます。基本的なオブジェクトの型定義においては、どちらを使っても大きな違いはありません。

しかし、Interfaceと型エイリアスにはいくつか違いがあります。後ほど詳細に比較しますが、主な違いは以下の点です。

• 拡張性: Interfaceは extends キーワードを使って拡張（継承）できます。型エイリアスも似たようなことはできますが、構文が異なります。
• 宣言マージ (Declaration Merging): 同じスコープ内で同じ名前のInterfaceを複数宣言すると、それらは自動的にマージされます。型エイリアスはマージされません。
• 定義できるもの: Interfaceは主にオブジェクトの形状を定義しますが、型エイリアスはプリミティブ型、Union型、Intersection型、タプル型など、より多様な型に別名を与えることができます。

オブジェクトの形状を定義するのが主な目的であれば、Interfaceを使うのが一般的です。特に、後からその型を拡張する可能性がある場合や、ライブラリの型定義などでマージの恩恵を受けたい場合にはInterfaceが適しています。

この記事ではまずInterfaceに焦点を当て、その使い方を深く理解することを目指します。型エイリアスとの比較は、Interfaceの応用的な使い方を学んだ後で行います。

Interfaceの基本的な使い方

では、Interfaceの最も基本的な使い方を見ていきましょう。Interfaceを使ってオブジェクトの構造を定義する方法です。

シンプルなオブジェクトの定義

Interfaceは、interface キーワードを使って定義します。波括弧 {} の中に、オブジェクトが持つべきプロパティ名と、そのプロパティが持つべき型をコロン : で区切って記述します。プロパティが複数ある場合は、カンマ , またはセミコロン ; で区切ります（どちらを使っても構いませんが、一般的にはカンマがよく使われます）。

“`typescript
interface Product {
id: number;
name: string;
price: number;
}

const product1: Product = {
id: 101,
name: “Laptop”,
price: 120000,
};

// エラー例: priceがnumber型ではない
// const product2: Product = {
// id: 102,
// name: “Keyboard”,
// price: “5000”, // string型なのでエラー
// };

// エラー例: nameプロパティが不足している
// const product3: Product = {
// id: 103,
// price: 3000,
// };
“`

Interfaceで定義されたプロパティは、デフォルトではすべて「必須（Required）」です。つまり、Interfaceの型を持つオブジェクトは、定義されたすべてのプロパティを正確な型で持っている必要があります。

任意プロパティ (Optional Properties) ?

オブジェクトによっては、一部のプロパティが必ずしも存在するとは限らない場合があります。例えば、商品の説明（description）はすべての商品にあるとは限りません。このような場合、プロパティ名の末尾に ? を付けることで、そのプロパティを「任意（Optional）」にすることができます。

“`typescript
interface ProductWithOptional {
id: number;
name: string;
price: number;
description?: string; // descriptionプロパティは任意
}

const productA: ProductWithOptional = {
id: 201,
name: “Mouse”,
price: 2500,
description: “Ergonomic wireless mouse.”, // descriptionがあってもOK
};

const productB: ProductWithOptional = {
id: 202,
name: “Monitor”,
price: 35000,
// descriptionがなくてもOK
};

// エラー例: descriptionプロパティは存在しうるが、string型ではない
// const productC: ProductWithOptional = {
// id: 203,
// name: “Webcam”,
// price: 8000,
// description: 123, // number型なのでエラー
// };
“`

任意プロパティは、そのプロパティが存在しない場合があることを明示します。TypeScriptでは、任意プロパティの型は その型 | undefined として扱われます。例えば、上記のdescription?: string; は実質的に description: string | undefined; と同じ意味になります（ただし、書き方としては?:が推奨されます）。

任意プロパティにアクセスする際は、そのプロパティが存在するかどうかを確認するか、Optional Chaining (?.) を使うと安全です。

``typescript
function printProductDescription(product: ProductWithOptional) {
if (product.description !== undefined) {
console.log(Description: ${product.description}`);
} else {
console.log(“No description available.”);
}

// または Optional Chaining を使う
console.log(Description (via ?.): ${product.description?.toUpperCase()}); // descriptionが存在すればtoUpperCase()を実行
}

printProductDescription(productA); // Description: Ergonomic wireless mouse. … DESCRIPTION (VIA ?.): ERGONOMIC WIRELESS MOUSE.
printProductDescription(productB); // No description available. … DESCRIPTION (VIA ?.): undefined
“`

読み取り専用プロパティ (Readonly Properties) readonly

オブジェクトのプロパティの中には、一度値が設定されたらその後は変更されてほしくないものがあります。例えば、オブジェクトのIDなどは通常、後から変更すべきではありません。このようなプロパティには、プロパティ名の前に readonly キーワードを付けることで、「読み取り専用」にすることができます。

読み取り専用プロパティは、オブジェクトが作成される時や初期化される時には値を設定できますが、その後は値を変更しようとするとコンパイルエラーになります。

“`typescript
interface UserProfile {
readonly id: number; // 読み取り専用
name: string;
age: number;
}

const userProfile: UserProfile = {
id: 1001,
name: “Charlie”,
age: 25,
};

userProfile.name = “Charles”; // nameは読み取り専用ではないので変更可能
userProfile.age = 26; // ageは読み取り専用ではないので変更可能

// エラー例: idは読み取り専用なので変更できない
// userProfile.id = 1002; // Cannot assign to ‘id’ because it is a read-only property.
“`

読み取り専用プロパティは、意図しない値の変更を防ぎ、データの不変性（Immutability）を保証するのに役立ちます。

Interfaceを引数に持つ関数の定義

Interfaceの一般的な使い方の1つは、関数の引数の型注釈として使用することです。これにより、その関数がどのような構造のオブジェクトを期待しているかを明確にできます。

“`typescript
interface Point {
x: number;
y: number;
}

function printCoordinates(p: Point): void {
console.log(Coordinates: (${p.x}, ${p.y}));
}

const myPoint = { x: 10, y: 20 };
printCoordinates(myPoint); // Coordinates: (10, 20)

// エラー例: Point Interfaceの契約を満たさないオブジェクトを渡そうとするとエラー
// const anotherPoint = { x: 5 }; // yプロパティが不足
// printCoordinates(anotherPoint); // Argument of type ‘{ x: number; }’ is not assignable to parameter of type ‘Point’.
“`

この例では、printCoordinates 関数は Point 型の引数 p を期待しています。myPoint オブジェクトは Point Interfaceの契約を満たしているため、問題なく関数に渡せます。しかし、anotherPointはyプロパティが不足しているため、コンパイルエラーが発生します。

これにより、関数が受け取るデータの形状が保証され、関数内部で安全にプロパティにアクセスできるようになります。

Interfaceを戻り値とする関数の定義

関数が特定の構造を持つオブジェクトを返す場合、その戻り値の型としてInterfaceを指定することもできます。

“`typescript
interface Circle {
center: Point; // Point Interfaceを別のInterface内で使用
radius: number;
}

function createCircle(x: number, y: number, r: number): Circle {
return {
center: { x: x, y: y },
radius: r,
};
}

const myCircle = createCircle(0, 0, 5);
console.log(Circle radius: ${myCircle.radius}); // Circle radius: 5
console.log(Circle center x: ${myCircle.center.x}); // Circle center x: 0

// エラー例: Circle Interfaceの契約を満たさないオブジェクトを返そうとするとエラー
// function createInvalidCircle(x: number, y: number, r: number): Circle {
// return { // Property ‘radius’ is missing in type ‘{ center: { x: number; y: number; }; }’ but required in type ‘Circle’.
// center: { x: x, y: y }
// // radiusが不足
// };
// }
“`

この例では、createCircle 関数は Circle 型のオブジェクトを返すことを宣言しています。戻り値のオブジェクトがCircle Interfaceの契約（centerプロパティとradiusプロパティを持つこと）を満たさない場合、コンパイルエラーが発生します。

このように、Interfaceを関数の引数や戻り値に使うことで、関数間のデータの受け渡しにおける契約を明確にすることができます。これは、大規模なアプリケーション開発やチーム開発において、コードの連携ミスを防ぐ上で非常に重要です。

実践的なInterfaceの応用

Interfaceは単にオブジェクトのプロパティを定義するだけでなく、より高度な型を表現するためにも使用できます。ここでは、Interfaceを使った関数型の定義、インデクサシグネチャの定義、そしてクラスへのInterfaceの実装方法について解説します。

関数型の定義 (Defining Function Types)

JavaScriptでは、関数もまたオブジェクトの一種です。特定の引数の型を持ち、特定の戻り値の型を持つ関数を定義したい場合、Interfaceを使うことができます。

関数型をInterfaceで定義するには、Interfaceの定義の中に「コールシグネチャ (Call Signature)」を記述します。コールシグネチャは、引数リストと戻り値の型を (parameter: Type): ReturnType の形式で記述します。プロパティ名はありません。

“`typescript
// Interfaceを使った関数型の定義
interface SearchFunc {
(source: string, subString: string): boolean;
}

// Interfaceの型を持つ変数に関数を代入
const mySearch: SearchFunc = function(source: string, subString: string): boolean {
const result = source.search(subString);
return result > -1;
};

console.log(mySearch(“Hello world”, “world”)); // true

// エラー例: Interfaceの契約（引数の型や戻り値の型）を満たさない関数を代入しようとするとエラー
// const myInvalidSearch: SearchFunc = function(source: number, subString: string): boolean { // 引数sourceの型が異なる
// return true;
// };

// エラー例: 戻り値の型が異なる
// const myOtherInvalidSearch: SearchFunc = function(source: string, subString: string): string { // 戻り値の型が異なる
// return “found”;
// };
“`

この例では、SearchFunc Interfaceは「2つの文字列型の引数を取り、真偽値型の戻り値を返す関数」の型を定義しています。mySearch 変数に代入された匿名関数は、この型定義を満たしているため問題ありません。しかし、引数の型や戻り値の型が異なる関数を代入しようとすると、コンパイルエラーが発生します。

このようにInterfaceで関数型を定義するメリットは、関数シグネチャに名前を付けて再利用できる点です。同じシグネチャを持つ複数の関数がある場合や、コールバック関数の型を明確にしたい場合に便利です。

関数型は型エイリアスでも定義できますが（例: type SearchFuncAlias = (source: string, subString: string) => boolean;）、Interfaceで定義することで、後述するInterfaceの拡張などの機能を利用できる場合があります。

インデクサシグネチャの定義 (Defining Index Signatures)

オブジェクトのプロパティ名が動的に決まる場合、例えばキーが文字列で値が特定の型を持つような「辞書型」や、数値のインデックスでアクセスする「配列ライク」なオブジェクトの型を定義したいことがあります。このような場合、Interfaceに「インデクサシグネチャ (Index Signature)」を定義します。

インデクサシグネチャは、角括弧 [] を使ってキーの型と値の型を指定します。キーの型には string または number を指定できます。

文字列インデックスシグネチャ

プロパティ名が文字列で、その値がすべて同じ型を持つオブジェクトの型を定義する場合に使います。

“`typescript
interface StringDictionary {
[key: string]: string; // キーは文字列、値は文字列
}

const myDictionary: StringDictionary = {
greeting: “Hello”,
message: “Welcome”,
// count: 123, // エラー: 値が文字列型ではない
};

const value1 = myDictionary[“greeting”]; // value1の型はstring
const value2 = myDictionary.message; // value2の型もstring (ドット記法でもアクセスできる)
“`

このStringDictionary Interfaceは、「任意の文字列をキーとしてアクセスすると、文字列型の値が得られるオブジェクト」の型を定義しています。Interfaceで定義されたプロパティ以外の動的なプロパティも、このインデクサシグネチャの型を満たしている必要があります。

注意点として、文字列インデクサシグネチャを定義した場合、そのInterfaceに明示的に定義されたプロパティも、インデクサシグネチャの型を満たしている必要があります。

typescript
interface MixedTypeDictionary {
[key: string]: number; // キーは文字列、値は数値
count: number; // 明示的に定義されたプロパティ (数値型なのでOK)
// name: string; // エラー: 値が文字列型であり、インデクサシグネチャの数値型と一致しない
}

数値インデクサシグネチャ

プロパティ名が数値（正確には文字列に変換可能な数値インデックス）で、その値がすべて同じ型を持つ配列ライクなオブジェクトの型を定義する場合に使います。

“`typescript
interface NumberArrayLike {
[index: number]: string; // キーは数値、値は文字列
}

const myArrayLike: NumberArrayLike = [“Apple”, “Banana”, “Cherry”]; // 配列も数値インデクサシグネチャを満たす
// const myArrayLike: NumberArrayLike = { 0: “Apple”, 1: “Banana”, 2: “Cherry” }; // オブジェクトでもOK

const item1 = myArrayLike[0]; // item1の型はstring
// const item2 = myArrayLike[“1”]; // stringキーでのアクセスも可能だが、型チェックは数値インデクサで行われる
// myArrayLike[0] = 123; // エラー: 値が文字列型ではない
“`

文字列と数値インデクサシグネチャの組み合わせ

一つのInterfaceに文字列と数値の両方のインデクサシグネチャを定義することも可能ですが、いくつかルールがあります。数値インデクサでアクセスする際は、内部的にキーが文字列に変換されます。そのため、数値インデクサシグネチャの値の型は、文字列インデクサシグネチャの値の型のサブタイプ（より具体的な型）である必要があります。

typescript
interface MixedIndexInterface {
[key: string]: any; // 文字列インデクサ: 値は何でもよい
[index: number]: string; // 数値インデクサ: 値は文字列 (anyのサブタイプなのでOK)
// name: string; // 明示的なプロパティもOK
// count: number; // エラー: numberはstringのサブタイプではない
}

インデクサシグネチャは、動的なプロパティを持つオブジェクトの型を柔軟に表現するのに役立ちます。

クラスへのInterfaceの実装 (Implementing Interfaces in Classes)

Interfaceは、クラスが特定の「契約」を満たしていることを強制するためにも使用できます。クラス定義で implements キーワードを使うと、そのクラスが指定されたInterfaceで定義されたすべてのインスタンスメンバー（プロパティやメソッド）を持っているかをTypeScriptがチェックしてくれます。

“`typescript
interface Greetable {
name: string;
greet(phrase: string): void;
}

// Greetable Interfaceを実装するクラス
class Person implements Greetable {
name: string; // Interfaceで定義されたプロパティを実装する必要がある
age = 30; // Interfaceで定義されていないプロパティも持てる

constructor(n: string) {
this.name = n;
}

greet(phrase: string): void { // Interfaceで定義されたメソッドを実装する必要がある
console.log(${phrase} ${this.name});
}
}

const person1 = new Person(“Max”);
person1.greet(“Hello, my name is”); // Hello, my name is Max

// PersonクラスはGreetable Interfaceの契約を満たしているので、
// Greetable型の変数に代入できる
const greeter: Greetable = new Person(“Anna”);
greeter.greet(“Hi there, I’m”); // Hi there, I’m Anna

// エラー例: Interfaceの契約を満たさないクラスはコンパイルエラーになる
// class InvalidPerson implements Greetable { // Property ‘name’ is missing in type ‘InvalidPerson’ but required in type ‘Greetable’.
// // nameプロパティがない
// greet(phrase: string): void {
// console.log(phrase);
// }
// }
“`

この例では、Greetable Interfaceは name という文字列型のプロパティと、1つの文字列引数を取り戻り値がない greet というメソッドを持つことを定義しています。Person クラスは implements Greetable と宣言することで、この契約を守ることを約束しています。もし Person クラスが name プロパティや greet メソッドを実装していなかったり、それらの型がInterfaceの定義と異なったりする場合、コンパイラはエラーを報告します。

implements キーワードは、クラスの「インスタンス側」の型のみをチェックします。つまり、Interfaceに定義されたプロパティやメソッドは、クラスのインスタンスが持つメンバーである必要があります。クラスの静的メンバー（staticキーワードで定義されたメンバー）は、Interfaceによる型チェックの対象にはなりません。

Interfaceをクラスに実装させることで、複数のクラスが共通のインターフェースを持つことを保証できます。これは、デザインパターン（例えばファクトリーパターンやストラテジーパターン）や、オブジェクト指向の原則（ポリモーフィズム）を適用する際に非常に役立ちます。特定のInterfaceを実装しているオブジェクトであれば、その具体的なクラスが何であるかに関わらず、同じように扱うことができるようになります。

Interfaceの拡張 (Extending Interfaces)

Interfaceは、他のInterfaceを「拡張（Extend）」することができます。これは、あるInterfaceが別のInterfaceの定義をすべて含み、さらに独自のメンバーを追加する、Interface版の継承のようなものです。extends キーワードを使って行います。

“`typescript
interface Shape {
color: string;
}

// Shape Interfaceを拡張する
interface Square extends Shape {
sideLength: number;
}

const mySquare: Square = {
color: “blue”, // Shapeから継承したプロパティ
sideLength: 10, // Square独自のプロパティ
};

// エラー例: 継承元Shapeのcolorプロパティが不足している
// const anotherSquare: Square = { // Property ‘color’ is missing in type ‘{ sideLength: number; }’ but required in type ‘Square’.
// sideLength: 5,
// };
“`

この例では、Square Interfaceは Shape Interfaceを拡張しています。これは、「SquareはShapeのすべてのプロパティ（この場合はcolor）を持ち、さらにsideLengthプロパティも持つ」という意味になります。したがって、Square型のオブジェクトは、colorとsideLengthの両方のプロパティを持っている必要があります。

複数のInterfaceの拡張

Interfaceは、複数のInterfaceを同時に拡張することも可能です。複数のInterfaceの名前をカンマで区切って extends の後に列挙します。

“`typescript
interface Serializable {
serialize(): string;
}

interface Loggable {
log(): void;
}

// Shape, Serializable, Loggable の3つのInterfaceを拡張する
interface PersistentShape extends Shape, Serializable, Loggable {
id: string;
}

class MyPersistentSquare implements PersistentShape {
color: string;
sideLength: number;
id: string;

constructor(color: string, sideLength: number, id: string) {
this.color = color;
this.sideLength = sideLength;
this.id = id;
}

serialize(): string {
return JSON.stringify({ id: this.id, color: this.color, sideLength: this.sideLength });
}

log(): void {
console.log(Shape ID: ${this.id}, Color: ${this.color}, Side: ${this.sideLength});
}
}

const pSquare = new MyPersistentSquare(“red”, 20, “shp-001”);
console.log(pSquare.serialize()); // {“id”:”shp-001″,”color”:”red”,”sideLength”:20}
pSquare.log(); // Shape ID: shp-001, Color: red, Side: 20
console.log(pSquare.color); // red
“`

PersistentShape Interfaceは、Shape、Serializable、Loggableの3つのInterfaceからプロパティとメソッドの定義をすべて継承し、さらに独自のidプロパティを追加しています。したがって、PersistentShape型のオブジェクトは、color, serialize(), log(), idのすべてを持っている必要があります。

Interfaceの拡張は、共通のプロパティやメソッドを持つInterfaceを再利用し、新しいInterfaceを定義する際にコードの重複を避けるために非常に便利です。また、関連する機能ごとにInterfaceを分割しておき、必要に応じてそれらを組み合わせて新しいInterfaceを作成するといった、モジュール性の高い設計を促進します。

Interfaceのマージ (Interface Merging)

TypeScriptには、「宣言マージ (Declaration Merging)」と呼ばれるユニークな機能があり、Interfaceもその対象となります。同じスコープ内で同じ名前のInterfaceを複数宣言した場合、TypeScriptコンパイラはそれらの宣言を自動的に1つのInterfaceに結合します。

“`typescript
// 最初の宣言
interface User {
id: number;
name: string;
}

// 同じ名前のInterfaceを別の場所（または同じファイル内）で宣言
interface User {
age: number;
}

// さらに別の場所で宣言
interface User {
isActive: boolean;
}

// 結果的に、User Interfaceは以下のようになる
/
interface User {
id: number;
name: string;
age: number;
isActive: boolean;
}
/

const myUser: User = {
id: 1,
name: “Alice”,
age: 30,
isActive: true,
};

// エラー例: マージ後のすべてのプロパティが必要
// const incompleteUser: User = { // Property ‘isActive’ is missing in type ‘{ id: number; name: string; age: number; }’ but required in type ‘User’.
// id: 2,
// name: “Bob”,
// age: 25,
// };
“`

この例では、Userという名前のInterfaceが3回宣言されています。TypeScriptコンパイラはこれらの宣言をマージし、最終的にUser Interfaceはid, name, age, isActiveのすべてのプロパティを持つ型として扱われます。

マージのルール:

• プロパティ: 同じ名前のプロパティが異なる宣言で定義されている場合、それらは結合されます。ただし、同じ名前のプロパティで型が異なる場合はエラーになります。
• メソッド: 同じ名前のメソッドが異なる宣言で定義されている場合、それらはメソッドのオーバーロードとして扱われます。つまり、複数のシグネチャを持つ1つのメソッドとして結合されます。後の宣言のシグネチャが優先される場合（特に、引数の数が少ないシグネチャが後に来る場合）、呼び出しシグネチャの順序に注意が必要です。

“`typescript
interface MyInterface {
a: number;
method(x: number): void;
}

interface MyInterface {
b: string;
method(x: string): void; // methodのオーバーロードを追加
method(x: number, y: string): void; // 別のオーバーロードを追加
}

// 結果的に、MyInterfaceは以下のようになる
/
interface MyInterface {
a: number;
b: string;
method(x: number): void;
method(x: string): void;
method(x: number, y: string): void;
}
/

const obj: MyInterface = {
a: 10,
b: “hello”,
method(x: number | string, y?: string) {
if (typeof x === ‘number’ && y !== undefined) {
console.log(Called with number and string: ${x}, ${y});
} else if (typeof x === ‘number’) {
console.log(Called with number: ${x});
} else {
console.log(Called with string: ${x});
}
}
};

obj.method(5); // Called with number: 5
obj.method(“world”); // Called with string: world
obj.method(10, “test”); // Called with number and string: 10, test
// obj.method(5, 10); // エラー: 第2引数がstringではない
“`

Declaration Mergingは、特にJavaScriptのライブラリに型定義（.d.ts ファイル）を追加する場合に非常に便利です。既存のJavaScriptオブジェクトやクラスに対して、TypeScriptの型情報を分割して定義し、それらが自動的にマージされることで、元のコードを変更することなく型を拡張できます。例えば、有名なライブラリのグローバルなオブジェクトに独自のプロパティの型定義を追加したい場合などに活用されます。

一般的なアプリケーションコードでInterfaceを分割して宣言することはあまり推奨されませんが、マージ機能の存在を知っておくと、型定義ファイルの理解や、特定のフレームワーク・ライブラリの型拡張を行う際に役立ちます。

Interfaceと型エイリアス (Type Alias) の比較

ここまでInterfaceの使い方を中心に見てきましたが、冒頭でも触れたように、TypeScriptには「型エイリアス (Type Alias)」という似た機能があります。ここでは、Interfaceと型エイリアスの共通点と違いを詳しく見て、どちらをどのような状況で使うべきか考えてみましょう。

共通点

• どちらも新しい型に名前を付けて定義し、再利用可能にします。
• どちらもオブジェクトの形状を定義できます（プロパティ名とその型、メソッドシグネチャ）。
• どちらもOptional (?) プロパティやReadonly (readonly) プロパティを定義できます。
• どちらも関数の引数や戻り値の型、変数の型として使用できます。

“`typescript
// Interfaceでの定義
interface PointInterface {
x: number;
y: number;
}

// 型エイリアスでの定義
type PointTypeAlias = {
x: number;
y: number;
};

const point1: PointInterface = { x: 1, y: 2 };
const point2: PointTypeAlias = { x: 3, y: 4 };
“`

基本的なオブジェクトの型定義においては、構文以外にほとんど違いはありません。

違い

特徴	Interface	Type Alias
定義できるもの	主にオブジェクトの形状、クラスが実装すべき契約	オブジェクトの形状、プリミティブ型、Union型、Intersection型、タプル型、Mapped Type など
拡張	extends キーワードを使用	Intersection型 (&) を使用して組み合わせる
実装	クラスで implements キーワードを使用	クラスで implements キーワードを使用可能
宣言マージ	同じスコープで複数宣言すると自動的にマージされる	同じスコープで複数宣言するとエラーになる
自己参照	自己参照型を定義しやすい（Recursive Types）	自己参照型を定義するのに工夫が必要な場合がある
エラーメッセージ	コンパイラのエラーメッセージがより分かりやすい傾向がある	複雑な型エイリアスの場合、エラーメッセージが詳細でないことがある

最も重要な違い:

1. 拡張性 (extends vs &):

   • Interfaceは extends を使って他のInterfaceを拡張し、既存の定義に新しいメンバーを追加できます。これはオブジェクト指向の継承に近い考え方です。
   • 型エイリアスは & を使ったIntersection型で複数の型を「結合」することで、似たようなことができます。これは複数の型のプロパティをすべて持つ新しい型を作るイメージです。

   “`typescript
   interface PersonI {
   name: string;
   }

   interface EmployeeI extends PersonI { // PersonIを拡張
   employeeId: number;
   }

   type PersonT = {
   name: string;
   };

   type EmployeeT = PersonT & { // PersonTと新しいプロパティ型を結合
   employeeId: number;
   };

   const empI: EmployeeI = { name: “Alice”, employeeId: 123 };
   const empT: EmployeeT = { name: “Bob”, employeeId: 456 };
   ``
どちらも結果として同じ形状の型ができますが、拡張性の概念と構文が異なります。Interfaceのextends`は、既存の定義を「基盤」として新しい定義を構築するニュアンスが強いです。

2. 宣言マージ:

   • Interfaceは同じ名前で複数回宣言すると自動的にマージされます。これは前述のように、型定義ファイルの拡張や、既存の型に後からプロパティなどを追加したい場合に特に便利です。
   • 型エイリアスはマージされません。同じ名前の型エイリアスを複数宣言すると、重複エラーになります。

3. 定義できる範囲:

   • Interfaceは主にオブジェクトの形状（プロパティ、メソッド、コールシグネチャ、インデクサ）を定義するために設計されています。
   • 型エイリアスは、オブジェクト形状だけでなく、プリミティブ型に別名を付けたり、Union型（A | B）、Intersection型（A & B）、タプル型など、より多様な型を表現するために使用されます。

   “`typescript
   type StringOrNumber = string | number; // Union型

   type Point3D = [number, number, number]; // タプル型

   type Status = “loading” | “success” | “error”; // リテラル型のUnion

   type Nullable = T | null; // Generic型エイリアス

   // これらの型はInterfaceでは直接表現できません（オブジェクトのプロパティとしては使えますが）
   “`

どちらを使うべきか？（一般的な推奨事項）

• オブジェクトの形状を定義する場合: Interfaceを使うのが一般的です。 特に、その型がオブジェクトであり、将来的に拡張される可能性がある場合や、クラスが実装する契約として使用したい場合は、Interfaceが適しています。Interfaceはコンパイラのエラーメッセージが分かりやすい傾向にあるという利点もあります。
• オブジェクトの形状以外の型（Union型、Intersection型、プリミティブ型、タプル型など）を定義する場合: 型エイリアスを使うしかありません。 Interfaceではこれらの型を直接定義できないからです。
• 型をマージしたい場合: Interfaceを使う必要があります。 型エイリアスはマージされません。これはライブラリの型定義などで重要な考慮事項となります。

結論として、TypeScriptコミュニティの多くの開発者は、オブジェクトの形状を定義する際はInterfaceをデフォルトで使い、Union型やIntersection型など、Interfaceで表現できない型を定義する際に型エイリアスを使うという使い分けをしています。これはTypeScript公式ドキュメントでも推奨されているアプローチです。

Interfaceと型エイリアスは似ていますが、得意なことや特徴が異なります。これらの違いを理解することで、状況に応じて適切な方を選択できるようになります。

Interfaceを使った設計パターン

Interfaceは単なる型定義のツールではなく、より良いコード設計を実現するための強力な手段でもあります。ここでは、Interfaceがどのように設計パターンに応用されるか、いくつか例を挙げます。

依存性注入 (Dependency Injection)

依存性注入は、オブジェクトが依存する他のオブジェクトを、そのオブジェクト自身が生成するのではなく、外部から注入（提供）してもらうパターンです。これにより、モジュールの結合度を下げ、テストや再利用を容易にすることができます。

依存性注入を行う際、具体的なクラスではなく、Interfaceに依存することで、依存関係を抽象化できます。

“`typescript
// ログ出力機能のInterface
interface Logger {
log(message: string): void;
error(message: string): void;
}

// Logger Interfaceを実装する具体的なクラス（例：コンソールに出力）
class ConsoleLogger implements Logger {
log(message: string): void {
console.log([INFO] ${message});
}
error(message: string): void {
console.error([ERROR] ${message});
}
}

// Logger Interfaceに依存するクラス
class UserService {
private logger: Logger; // 具体的なクラスではなく、Interfaceに依存

constructor(logger: Logger) { // コンストラクタで依存を注入
this.logger = logger;
}

createUser(name: string): void {
// ログ出力には注入されたLogger Interfaceを使う
this.logger.log(User ${name} created.);
// 実際のログ出力処理は注入されたLoggerの実装に任せる
}
}

// サービスの利用
const consoleLogger = new ConsoleLogger();
const userService = new UserService(consoleLogger); // ConsoleLoggerのインスタンスを注入

userService.createUser(“Alice”); // [INFO] User Alice created.

// 後で別のLogger実装に簡単に置き換え可能（例：ファイル出力Loggerなど）
// const fileLogger = new FileLogger(…);
// const userServiceWithFileLogging = new UserService(fileLogger);
“`

この例では、UserServiceは具体的なConsoleLoggerクラスには依存せず、Logger Interfaceに依存しています。これにより、UserServiceはどんなLogger Interfaceを実装したオブジェクトでも受け入れることができるようになります。テスト時には、本物のロガーの代わりに、ログが呼ばれたかだけを確認する「モックオブジェクト」をLogger Interfaceとして作成し、UserServiceに注入することで、UserService単体のテストを容易に行えます。

ファクトリーパターン (Factory Pattern)

ファクトリーパターンは、オブジェクトの生成処理をサブクラスに任せるか、専用の生成メソッドに集約するパターンです。生成するオブジェクトの種類が増えても、クライアントコードはファクトリーのInterfaceに依存することで、具体的なクラス名を知る必要がなくなります。

“`typescript
// 製品のInterface
interface Product {
getName(): string;
}

// 製品の具体的な実装
class ProductA implements Product {
getName(): string { return “Product A”; }
}

class ProductB implements Product {
getName(): string { return “Product B”; }
}

// ファクトリーのInterface
interface ProductFactory {
createProduct(): Product; // Product Interfaceを返す
}

// ファクトリーの具体的な実装
class ConcreteFactoryA implements ProductFactory {
createProduct(): Product {
return new ProductA();
}
}

class ConcreteFactoryB implements ProductFactory {
createProduct(): Product {
return new ProductB();
}
}

// クライアントコードはProductFactory Interfaceに依存
function useFactory(factory: ProductFactory): void {
const product = factory.createProduct(); // 具体的なクラスは知らなくてもよい
console.log(Created product: ${product.getName()});
}

// 利用例
const factoryA = new ConcreteFactoryA();
useFactory(factoryA); // Created product: Product A

const factoryB = new ConcreteFactoryB();
useFactory(factoryB); // Created product: Product B
“`

この例では、useFactory 関数は ProductFactory Interfaceを受け取ります。この関数は、ファクトリーの具体的な実装（ConcreteFactoryAやConcreteFactoryB）が何であるかを知る必要がありません。ただ、ProductFactory Interfaceが持つ createProduct() メソッドを呼び出すだけで、Product Interfaceを実装したオブジェクトが得られることを期待しています。これにより、製品の種類が増えたり、生成ロジックが変更されたりしても、クライアントコードに影響を与えにくくなります。

Interfaceは、このような設計パターンにおいて、抽象化のレイヤーを提供し、コードの柔軟性、テスト容易性、保守性を向上させるための重要な役割を果たします。

Interface利用時のベストプラクティスと注意点

Interfaceを効果的に利用するために、いくつかベストプラクティスと注意点があります。

1. 名前付け規則:
   Interfaceの名前は、一般的にPascalCase（単語の先頭を大文字にする）で記述し、内容を表す名詞または形容詞句に「-able」や「-ible」を付けた形（例: Greetable, Serializable）にすることが多いです。ただし、オブジェクトの形状を表すだけのシンプルなInterfaceの場合は、末尾に「Interface」や「I」を付ける必要はありません（例: User, Product）。これは、型名と変数名を区別しやすくするためです。

2. Interfaceは不変な構造を定義するのに適している:
   Interfaceは、オブジェクトが「どのような構造を持つか」という静的な側面を定義するのに長けています。一方、オブジェクトの状態の変化や振る舞いの違いによって型が変化するような複雑なロジックをInterfaceだけで表現するのは難しい場合があります。そういった場合は、Union型やIntersection型、あるいはクラスと組み合わせて使用することを検討しましょう。

3. 複雑な型には名前を付ける:
   複数のプロパティを持つオブジェクト型や、Union型、Intersection型などで、同じ形状を何度も使う場合は、Interfaceまたは型エイリアスを使って名前を付けましょう。これにより、コードの可読性が格段に向上し、重複を避けることができます。インラインで { prop: Type, ... } のように書くのは、その場で一度だけ使うごく単純なオブジェクトにとどめましょう。

4. Interfaceは詳細すぎるべきではない (Avoid overly specific Interfaces):
   必要以上に多くのプロパティやメソッドをInterfaceに詰め込むと、そのInterfaceを使う側が不要なプロパティまで考慮しなければならなくなったり、Interfaceの実装が難しくなったりします。Interfaceは、そのInterfaceを使う特定の文脈（例えば、関数が必要とする引数の形状、クラスが提供すべき機能）で必要なメンバーのみを定義するように心がけましょう。これは、「Interface分離の原則 (Interface Segregation Principle)」というSOLID原則の一つにも通じる考え方です。

5. Optional Chaining (?.) と Nullish Coalescing (??) との組み合わせ:
   Interfaceで定義した任意プロパティ (?:) にアクセスする際は、存在しない可能性があることを考慮する必要があります。Optional Chaining (?.) や Nullish Coalescing (??) 演算子を使うことで、安全かつ簡潔に任意プロパティを扱えます。

   “`typescript
   interface Config {
   timeout?: number;
   retryAttempts?: number;
   logLevel?: “info” | “warn” | “error”;
   }

   function processConfig(config: Config) {
   // timeoutプロパティが存在する場合のみ値を使用
   const timeout = config.timeout; // timeoutは number | undefined 型

   // Optional Chaining: logLevelが存在する場合のみtoUpperCase()を呼び出す
   const logLevelUpper = config.logLevel?.toUpperCase(); // logLevelUpperは “INFO” | “WARN” | “ERROR” | undefined 型

   // Nullish Coalescing: retryAttemptsがnullish (null or undefined) の場合にデフォルト値を使用
   const attempts = config.retryAttempts ?? 3; // attemptsは number 型
   console.log(Retry attempts: ${attempts});
   }

   processConfig({}); // Retry attempts: 3
   processConfig({ timeout: 5000, retryAttempts: 5, logLevel: “warn” }); // Retry attempts: 5
   “`

6. Interfaceと型の互換性:
   TypeScriptの型システムは構造的部分型付け（Structural Typing）に基づいています。これは、Interfaceを実装したり、型エイリアスとして定義されたオブジェクト型を満たすかどうかは、そのオブジェクトがInterfaceで定義されたすべてのプロパティとメソッドを、正しい型とシグネチャで持っているかどうかにのみ依存するということです。明示的に implements と書かなくても、構造的に互換性があればその型の変数に代入できます（ただし、クラスがInterfaceの契約を守ることを明示したい場合は implements が推奨されます）。

   “`typescript
   interface Named {
   name: string;
   }

   const myObj = { name: “Alice”, age: 30 };

   // myObjはNamed Interfaceの構造を満たしているので、Named型の変数に代入できる
   const named: Named = myObj;
   console.log(named.name); // Alice
   // named.age; // エラー: Named Interfaceにはageプロパティが定義されていない
   “`
   これはInterfaceがダックタイピングの原則に従っていることの表れです。この特性を理解しておくと、TypeScriptの型チェックの挙動をより深く理解できます。

まとめ

この記事では、TypeScriptのInterfaceについて、その基礎から応用までを詳細に解説しました。

• Interfaceは、オブジェクトの「形状」を定義するための強力なツールであり、コードに型安全性をもたらします。
• プロパティの定義（必須、任意、読み取り専用）から始まり、関数型、インデクサ、クラスへの実装など、様々な型を表現できます。
• extends キーワードを使ったInterfaceの拡張により、コードの再利用とモジュール性が向上します。
• Declaration Mergingにより、同じ名前のInterfaceが自動的に結合される仕組みを理解しました。
• Interfaceと型エイリアスは似ていますが、定義できる範囲や拡張性、マージの可否などの違いがあり、一般的にはオブジェクトの形状にはInterfaceが推奨されます。
• Interfaceは、依存性注入やファクトリーパターンといった設計パターンにおいて、抽象化と疎結合を実現するための鍵となります。

Interfaceは、TypeScriptで堅牢で保守性の高いコードを書く上で欠かせない概念です。これらの基礎と応用をしっかり理解することで、TypeScriptのメリットを最大限に活かせるようになります。

最初はInterfaceの定義や使い方に戸惑うかもしれませんが、実際にコードを書きながら試してみることが最も効果的な学習方法です。エディタの補完機能やコンパイラのエラーメッセージは、Interfaceの使い方を学ぶ上での強力な味方となります。

TypeScriptの学習は、プログラミングスキルを大きく向上させる投資です。ぜひInterfaceを使いこなし、より高品質なアプリケーション開発を目指してください。

この記事が、TypeScriptのInterfaceを学ぶ皆さんの一助となれば幸いです。

---