なぜ型を書くのか？ TSKaigi2026で改めて考える #tskaigi_smarthr

TypeScriptの型をなぜ書くのか、その理由を「集合」という視点から問い直します。
型を書くことは取りうる値の集合を絞ること、と捉え直すと、「テストは試した点の確認、型はありえない形をまるごと消すもの」という対比が見えてきます。

TSKaigi 2026事後勉強会: https://smarthr.connpass.com/event/392342/

X: https://x.com/kajitack

Transcript

2. 梶川 琢馬 𝕏 @kajitack 株式会社 TechBowl VPoT TechTrain の開発 / メンター フロントエンドは React / TypeScript、バックエンドも書いてます スライドは X で公開します！ x.com/kajitack 2/12
3. TSKaigi 2026 型の話が沢山ありましたよね 型だけでオセロを実装する話。型で副作用の順序を制御する話。コンパイラ設計史… OST でも「そもそも、なぜ型を書くんだっけ？」で議論になった そこで、改めて考えてみました 型でオセロを完全実装 https://speakerdeck.com/forcia/typescriptnoxing-dakedeoserowowan-quan-shi-zhuang-suru-xing-ha-shi-yang-wodokomadeyu-reruka 型で副作用の実行順序を制御 https://speakerdeck.com/yanaemon/typescript-noxing-defu-zuo-yong-noshi-xing-shun-xu-wozhi-yu-suru TypeScript コンパイラ設計史 https://www.docswell.com/s/6114195/K8NM12-2026-05-23-103822-tskaigi 業務に残った「良くない型」 https://speakerdeck.com/sajikix/ye-wu-nican-sareta-liang-kunaixing-dekao-eru-typescriptnonan-sisa 3/12
4. Types as Sets 「ビット列の解釈」としてだけでなく、「集合」として捉える ビット列の解釈 文字列や数字、配列などデータの扱い方やデータの サイズを意識した型定義 集合 bool → { true, false }　string → { "", "a", ... } 「取りうる値はこれだけ」と値の範囲を決め、 どういう入力・処理なのかを実行せずに判断する ための型定義 https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-oop.html#types-as-sets 4/12
5. 型を書くことは、集合を絞ること string のまま "pending" "paid" "shipped" "hoge" "" "payed" "PAID " "発送済み？" ありえない値の組み合わせが膨⼤ ドメインの知識で 絞る OrderStatus 型 "pending" "paid" "shipped" ありえない値は最初から⼊らない 5/12
6. ありえない状態を、最初から作れなくする テスト 1 つずつ試す ? ? ? ? 試した点しか分からない 型 まとめて禁⽌ 作れない ありえない形 取りうる値 ありえない形は作れない 6/12
7. データ取得中の画面、よく作るやつ https://example.com/users Loading... 7/12
8. フラグを並べると、ありえない状態が作れる 「loading 中なのに user も error もある」。仕様にない状態が作れてしまう // よくある：フラグとデータを別々に持つ function UserProfile() { const [isLoading, setIsLoading] = useState(false); const [error, setError] = useState<Error | null>(null); const [user, setUser] = useState<User | null>(null); } TypeScript 8/12
9. 2 × 2 × 2 ＝ 8 通り。有効なのは 4 つだけ isLoading error user 意味 false なし なし 未取得 true なし なし 読み込み中 false あり なし エラー false なし あり 取得済み true あり なし 読み込み中なのにエラー？ true なし あり 読み込み中なのに user？ false あり あり エラーなのに user？ true あり あり 全部同時？ 9/12
10. 誤りの集合を、設計段階で消す // バラバラの状態を、1 つの State にまとめる。ありえない状態は "書けない" type State = | { status: "idle" } | { status: "loading" } | { status: "error"; error: Error } | { status: "success"; user: User }; TypeScript Make illegal states unrepresentable — Yaron Minsky, Effective ML (2010) https://blog.janestreet.com/effective-ml/ 10/12
11. TS の型は「保証」ではなく「早期発見」 1 + true は JS では 2 。バグでも、そのまま動いてしまう TS なら「これ、たぶんバグですよね？」を、実行前に教えてくれる 早く気づくほど、直すコストは小さい。 それが「総合的に便利」の正体 健全な型システムは TypeScript の "非目標" — TypeScript Design Goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals 11/12
12. なぜ型を書くか？ 型は「集合」。書くことは、取りうる値に絞ること テストは試した分だけ。型は、ありえない形をまるごと消す 型を書くことで、誤りを設計段階で消し、 人間にも AI にも読める「仕様」にもなる 12/12