C# の interface が分かる人が TypeScript の interface で戸惑う3つ — 構造的型付けと implements 不要の世界

みなさんこんにちは！ヒロポンです！

C# でずっとやってきて、TypeScript の案件に初めて入った時の話。interface を書いて、それを使うクラスに implements を…って、探したんですよ。

無いんです。

implements を書いてないのに、型が通ってる。「え、これで合ってるの？？」って、しばらく固まりました。

C# の interface と TypeScript の interface。名前は同じなのに、中身の思想が違う。ここを知らずに C# の感覚で書くと、地味に足をすくわれます。

この記事は、TypeScript interface C# 出身者向けの橋渡し。C# の interface（公称型・明示 implements）を踏み台にして、TS の構造的型付け（structural typing）との違いを3つ、C# コードと TS コードを対で並べて翻訳していきます。

C# が分かってるなら、TS の interface は「差分」だけ押さえれば済みます。ゼロから覚え直す必要はないんですよね。

C# interface と TypeScript interface の対応マップ

まず全体像から。同じ interface でも、判定方式からして別物です。

この5行を、コードで1つずつ潰していきます。

違い1: implements は任意 — 形が合えば暗黙に互換

C# は 公称型（nominal typing）。interface を実装するには : ILogger と明示して、宣言した名前で互換性が決まります。

interface ILogger { void Log(string msg); }

// C# は : ILogger を明示しないと互換にならない
class FileLogger : ILogger {
    public void Log(string msg) { /* 出力処理 */ }
}

ILogger logger = new FileLogger();   // OK（implements してるから）

TypeScript は 構造的型付け（structural typing）。implements を書かなくても、プロパティとメソッドの形が一致すれば勝手に互換扱いになります。

interface Logger { log(msg: string): void; }

// implements Logger を書いてない
class FileLogger {
    log(msg: string): void { /* 出力処理 */ }
}

const logger: Logger = new FileLogger();   // OK（形が一致してるから通る）

C# 脳だと「implements 書いてないのに、なんで代入できるの？？」となる。

ここが最初の壁です。

TS では implements は書いてもいい。タイプミスを早期に検出できる利点はあります。ただ、必須じゃない。形さえ合えば通る、という発想に切り替えるのが第一歩です。

違い2: interface は実行時に消える — 型レベルだけの存在

C# の interface は実行時にも存在します。is ILogger で判定したり、リフレクションで型情報を取れる。実体があるんですね。

object x = new FileLogger();
if (x is ILogger logger) {     // 実行時に型判定できる
    logger.Log("hello");
}

TypeScript の interface は 型注釈だけの存在。コンパイルして JavaScript になった瞬間に消えます。だから実行時には影も形もない。

const x: unknown = new FileLogger();

// ❌ interface は実行時に存在しないので instanceof できない
// if (x instanceof Logger) { ... }   // これはコンパイルエラー

// ✅ 実行時に形を確かめたいなら、自分でプロパティの有無を見る
if (typeof (x as any).log === "function") {
    (x as Logger).log("hello");
}

C# の「型は実行時も生きてる」感覚のまま instanceof Logger と書くと、エディタに怒られます。ん？なんでや、ってなるやつ。いい感じに混乱するポイント。interface は設計図であって実体じゃない、と覚えておくと腑に落ちます。

違い3: 型の合成が緩い — ダックタイピング的に通る

C# は interface を多重に implements して型を組み合わせます。あくまで「宣言した interface」が基準。

TypeScript は extends を複数つなげたり、交差型 & で型を合成できる。しかも構造で見るので、宣言してない型でも形が合えば通ります。いわゆるダックタイピング（「アヒルみたいに鳴けばアヒル」）的な世界。

interface Point { x: number; y: number; }

function distance(p: Point): number {
    return Math.sqrt(p.x * p.x + p.y * p.y);
}

// Point を名乗ってないオブジェクトでも、x と y を持ってれば通る
const data = { x: 3, y: 4, label: "A" };
distance(data);   // 5（余分な label は無視される）

data は Point だなんて一言も言ってないのに、x と y を持ってるから distance に渡せる。C# なら「Point 型じゃないからダメ」と弾かれるところ。

これが便利でもあり、後で説明する怖さの源でもあります。

ミニマム検証のハンズオン

小さく試すなら、tsc（TypeScript コンパイラ）か、ブラウザの TypeScript Playground で十分。こんな感じで手元でサッと確認できます。

interface Named { name: string; }

const a = { name: "田中", age: 30 };
const named: Named = a;   // OK（name を持ってるから通る・age は無視）

console.log(named.name);  // 田中

実行結果（構造が合えば代入が通る・tsc --strict + 実行で確認）:

これをコピペして、name を消すと型エラーになる。プロパティの有無だけで互換が決まるのを、目で確認できます。1分で「あ、こういうことか」が掴めます！！

ハマりポイント（実体験ベース）

① 構造が偶然一致して、意図しない代入が通ってしまう

正直に言うと、俺もこれで詰まりました。

構造的型付けは、「別物のはずの2つの型が、たまたま同じ形だと互換扱いになる」。便利な反面、これがバグの温床になります。

interface UserId { value: number; }
interface ProductId { value: number; }

const uid: UserId = { value: 100 };
const pid: ProductId = uid;   // ❌ 通ってしまう（どっちも { value: number }）

UserId と ProductId は意味が全然違うのに、形が同じだから代入が通る。C# の公称型なら名前が違うので弾かれますが、TS は通します。

対策は、わざと形を変えて区別する branded type（タグ付け）。

interface UserId { value: number; _brand: "UserId"; }
interface ProductId { value: number; _brand: "ProductId"; }
// これで形が変わり、取り違えをコンパイル時に弾ける