関係性から理解する"同一性"の型用語たち

TSKaigi 2026
https://2026.tskaigi.org/talks/6

Transcript

1. 関係性から理解する "同一性"の型用語たち pvcresin TSKaigi 2026
2. pvcresin 仕事　SansanでEightのWebエンジニア 興味　フロントエンド／デザイン／型 言語　TypeScript／Kotlin／Ruby 自己紹介
3. TypeScriptの話題において、nominal / structural / branded / opaque / phantomといった 型に関する用語を見かける機会が増えてきました。 しかし、これらの違いや関係性を説明しようとすると曖昧になりがちです。 私自身も「なんとなく分かったつもり」で流してしまった過去があり、 後からうまく説明できずに後ろめたさを感じる場面がありました。 本発表ではTypeScriptが構造的型付けであることを起点に、 型の同一性に関するこれらの用語を、コード例を交えて紹介します。 そのうえで、これらの違いと関係性を理解し、解説記事や議論を追える状態を目指します。  トーク概要
4. この発表のスコープ 話さないこと 話すこと - コード例を交えた型用語の解説 - それぞれの用語の関係性の整理 - 特定のライブラリの使い方
5. 型の同一性 A型の値を、 B型の値に代入できるか
6. アジェンダ - Nominal／Structural - プリミティブ型に関する課題 - Branded／Opaque／Phantom - まとめ
7. Nominal／Structural
8. Nominal／Structural Nominal Typing（名前的型付け） - 公称型とも呼ばれる - 名前や継承などで型を判別 - Java, C#, Kotlin, Go（struct）など Structural Typing（構造的型付け） - 構造的部分型とも呼ばれる - 構造で型を判別 - TypeScript, Go（interface）など
9. Structural Typing Nominal Typing クラス
10. type aliasはほとんどの言語で透過的 プリミティブ
11. Goのdefined typeはNominal プリミティブ
12. トレードオフ Nominal Structural 構造が同じ値の取り違え ✅ 名前で判別できる ❌ 混ざる可能性がある 別の型として渡す ❌ 変換が必要 ✅ 構造が合えば渡せる
13. Duck／Goose
14. Goose Typing - 実行時に対象の値が特定のクラスに 属しているかで型を判定 - Python（ABC + isinstance）, Ruby（is_a, kind_of, instance_of）, JavaScript（instanceof）など Duck／Goose Duck Typing - 実行時にその値が特定のメソッドや プロパティを持っているかで型を判定 - コードの再利用性を高められる - Python, Ruby, JavaScriptなど
15. Goose Typing Duck Typing Duck／Goose ※ 呼び出し前に事前チェックする場合 ※ PythonのABC相当なし
16. JavaScriptでのDuck Typingを静的な型に自然に落とし込むためには、 TypeScriptはStructuralな型システムである必要があった ここまでのまとめ 名前で判別 構造で判別 コンパイル時 Nominal Structural 実行時 Goose Duck
17. プリミティブ型に関する課題
18. プリミティブ型に関する課題 - 手軽に使えるため、プリミティブな値で管理する場面は多い - ID（UserId, GroupId, …） - 単位（JPY, USD, …） - 特定の文字列（Email, URL, …） - すべてがstringやnumberに潰れがちで、取り違えのリスクが高い - 一方、クラスは構造がユニークになることが多く、問題になりづらい
19. Branded
20. - 識別子となるプロパティを混ぜて、型を判別可能にする実装パターン Branded Type（ブランド型）
21. - クラス - オブジェクト - プリミティブ プリミティブな値を判別するアプローチ
22. - 両方とも中身が同じstringなので 判別できない - あ - あ - あ 元コード: プリミティブな type alias
23. - クラスは通常Structuralに判別 - 固有の変数を持つ場合はNominal - private, protected修飾子 - JavaScriptの#private field - 実行時オーバーヘッド クラス + private - あ - あ - あ
24. オブジェクトにネスト + string literal - オブジェクトにネストし、値の型を判別するための情報を追加する - 型をasで宣言することで、value以外に追加で__brandを設定しなくて済む - 実行時にオーバーヘッド
25. - プリミティブな値をそのまま使える - 実行時への影響がない プリミティブ + オブジェクト交差
26. プリミティブパターン良さそう 現状のコードだとまだ課題がある - __brandキーがstringなので、IDEの補完に出る／他コードと衝突しうる - 本当に欲しいのは 補完を汚さない／衝突しない／文字列で触れないキー
27. 衝突しない brandプロパティを作るなら Symbol Symbol - 必ず一意になるプリミティブ（型はunique symbol） - プロパティのキーに使うことで、補完を汚さず、不正なアクセスも防ぐ
28. - 実行時に値を生成しないよう、Symbol()で実体を作らずにdeclare const - 衝突なし・補完に出ない・不正にアクセスができないbrandプロパティ - モジュール内では__brandに代入が可能なため、readonlyで上書き防止 キーを unique symbol + readonly にする
29. - 識別子となるプロパティを混ぜて、型を判別可能にする実装パターン 【再掲】Branded Type（ブランド型）
30. Opaque
31. Opaque Type（不透明型） - 型の実体を外部に教えず、生成口を絞る運用パターン（＝カプセル化） - Scala, Swift, Flowなど
32. Opaque Type（不透明型） - TypeScriptには as 制限などの隠蔽機能がない - 「Branded Type + 生成口を1点に絞る運用」と捉えるのが現実的
33. Phantom
34. - 状態を表す型パラメータで判別 - 渡した型パラメータが、値の表現には 現れない - Haskell, Scala, Kotlinなど Phantom Type（幽霊型）
35. 代入できてしまう 素直にTypeScriptにすると
36. privateを導入して Nominalにすると実現可能
37. クラスにしないでも実現可能
38. まとめ
39. 型用語の関係性 実装に使う 生成口絞る Branded Type （ブランド型） 識別子を混ぜて型を判別 Opaque Type （不透明型） 型の実体を外部に教えない Phantom Type （幽霊型） 状態を型パラメータで持つ 判定タイミング 判定方式 Structural Typing （構造的型付け） 構造で型を判別 Nominal Typing （名前的型付け） 名前で型を判別 Goose Typing 実行時に 名前で型を判別 Duck Typing 実行時に 構造で型を判別 判定方式 Nominal模倣
40. - TypeScriptはStructural Typingだが、型の表現力でNominalを模倣できる - Branded Typeを活用すれば、実行時への影響なく型安全性を高められる - 実装は同じ見た目でも、用語によって重視する概念が異なる まとめ