©KAKEHASHI inc. 他言語経験者が知っておきたい TypeScriptのクラスの注意点 2026/1/27 @Tech Encounter ソフトウェアエンジニア kosui 

©KAKEHASHI inc. 自己紹介 kosui (@kosui_me) 岩佐 幸翠 趣味: 最近はActivityPubの独自実装に夢中 宣伝: SREKaigi 2026で登壇します 開発チームが信頼性向上のためにできること Embedded SRE不在でも開発チームが信頼性に責任を持ち、改善を続け るための具体的な方法論と、運用を通じて学んだ教訓を紹介します。 

サーバサイドTypeScript、 不安じゃないですか? Java / C# / Go などの経験者の方へ 

©KAKEHASHI inc. よくある不安 型システムが弱い? JavaScriptベースだから、 型が緩いのでは... 堅牢な設計ができる? 「ユーザーIDと店舗IDを 区別する」など実現できる? 実行時エラーが多い? 型情報がランタイムで 消えるって聞いたけど... 

TypeScriptには、 TypeScriptならではのアプローチで 堅牢な設計を実現する方法がある 

©KAKEHASHI inc. 今日お伝えしたいこと 違いを知る TypeScriptならではの 特性を理解する むしろ強力 関数型アプローチで より堅牢な設計が可能 対処法がある 落とし穴には 確立されたパターンで対応 

©KAKEHASHI inc. 1⃣ 違いを知る:構造的部分型 Java/C#: 公称的部分型(クラス名で型の互換性を判断) TypeScript: 構造的部分型(構造が同じなら互換性あり) 

😱 UserとProductが混ざる! 情報漏洩のリスクも... でも、対処法があります 

©KAKEHASHI inc. 2⃣ 対処法：Branded Types 型レベルでユニークな「ブランド」を付与し、公称的部分型のような振る舞いを実現 💡 RustのNewtype Patternと同じ 

©KAKEHASHI inc. 3⃣ むしろ強力：代数的データ型 エンティティの状態ごとに持つべきプロパティを定義 例) ブログ向けのCMSの記事エンティティ 「ドラフトなのにレビュアーIDが設定されてしまう」 のような思わぬミスをトランスパイル時に検出できる 💡GoFのStateパターンに近い 

©KAKEHASHI inc. 3⃣ むしろ強力：関数型ドメインモデリング データと 振る舞いを分離 ✅ 謎の内部状態に振り回されない 事前条件・事後条件が明確になる 例) ブログ向けのCMSの記事エンティティ 「”レビュー中” の記事だけを “発行済み” にできる」を 型システムで保証できる 

©KAKEHASHI inc. 網羅性チェック switch文で型を絞り込み、すべてのケースを網羅しているかコンパイル時に検証 💡 Java 21+でもSealed Classes + Pattern Matchingで同様のアプローチが可能に 

©KAKEHASHI inc. カケハシでの実践 認証権限基盤での採用 ● 関数型ドメインモデリングを全面採用 ● Branded Types + Zod でスキーマ定義 ● 判別可能なユニオン型で状態遷移を表現 得られた効果 ● 型による制約で不正な状態を防止 ● テストが書きやすい（純粋関数） ● コードレビューの負担軽減 ● 新メンバーのキャッチアップが容易 「これまでの設計経験がそのまま活きた。 TypeScriptならではの表現方法も学べた」 — 入社半年のバックエンドエンジニア 

©KAKEHASHI inc. まとめ あなたの経験は活きる ドメインモデリング、型システム、デザインパターン そして、新しい武器も手に入る 関数型アプローチ、判別可能なユニオン型、Branded Types 

©KAKEHASHI inc. 詳しくはブログで！ 本日の内容をより詳しく解説しています ● 構造的部分型の詳細 そもそもなぜこのような設計になっているのかも含めて ● `this` の振る舞いとその対策 ● アクセス修飾子の注意点 ● 型ガード関数の使い方