TSKaigi 2026 に参加しました

カンファレンス frontend

こんにちは、スタメンのWatchy開発チームのディアゴです。TypeScriptによるバックエンド開発を担当しています。最近は『ナニワ金融道』『ミナミの帝王』などの金融漫画にハマっています。

2026年05月22日〜23日の2日間、ベルサール羽田空港で開催された TSKaigi 2026 に、参加者として初参加しました。TSKaigiは国内最大級のTypeScriptのカンファレンスで、今年で3回目の開催となります。大規模な会場がかなり埋まっていて、大盛り上がりでした。今回スタメンは TSKaigi 2026 のブーススポンサーとして出展しており、ブースも大盛況でした!

現地で見た発表を、「明日からの仕事に活かせる」観点でピックアップして紹介したいと思います。

① 権限制御を型チェックで守る

セッションのテーマは、複雑なカスタマイズが可能な権限制御の開発をどのように安全に行うか、ということです。

型を駆使しつつ、型がカバーできない部分についてはバリデーション・リンター・テストでそれぞれ異なるレイヤーに対策していて参考になりました。

PostgreSQL の plv8(V8ベースのJS実行環境)は知りませんでした。複数のアプリケーションや直にデータベースを編集することはありうるので、DBレベルで複雑なロジックのバリデーションをしているのは安心できそうです。

権限チェック関数の呼び出し忘れはどうしようもないと思っていましたが、それさえLinterで守れるのに驚きました。

型がどこまでカバーしているかの境界の認識を持ち、それをほかのツールも組み合わせられる引き出しは重要そうだと考えました。

  • とりうる値が列挙できる(閉じた型) → 型だけで一貫性を担保できる
  • とりうる値が列挙できない(開いた型) → 型以外の手段で補う

② React の props は値の集合ではない — UI の状態を宣言するコンポーネント設計

props は値の集合ではない — UI の状態を宣言する React コンポーネント設計 - Slidev

テーマは、ReactでUIの状態を宣言する書き方でわかりやすくする、ということです。複雑な状態の表現に、Reactに限らず使える考え方だと思いました。また、例示されていたよくない例のPropsは自分が書いたことのある記憶があったので、こうすればよかったのか、と納得しました。

第1段階として、Discriminated Unionを使う方法を紹介しています。

// status によってとりうる値が異なる
type Props =
  | { status: "loading" }
  | { status: "error"; error: Error }
  | { status: "success"; data: User[] }

ありえない状態がなくなり、意図が明確で読みやすくなるメリットがあります。

第2段階として、さらにコンポーネントの責務を整理するのを提案しています。

  • Before: 渡されたPropsでUI表示
  • After: データフェッチ + 表示

これによって、JSXの構造でUIの状態を表現できる、と説明されていました。たしかにわかりやすくなったように見えます。

<ErrorBoundary fallback={<ErrorMessage />}>
  <Suspense fallback={<Spinner />}>
    <UserList />
  </Suspense>
</ErrorBoundary>

③ TypeScriptのclassはなぜこうなったのか

TypeScriptのclassはなぜこうなったのか - kosui

テーマは、直感的でないclassについて歴史を紐解き、さらに落とし穴の多いclassを使わずに同等のことを表現する方法を解説しています。

classの3つの特性と罠から、対策をまとめているのが理解しやすく感じました。

構造的部分型。

  • 問題点: classのプロパティが同じだと、class名が違ってもコンパイルが通る
  • 対策: Branded Type を使って、値で判定させるようにする

型消去。

  • 問題点: 型検査時と、実行時のinstanceofチェックが一致しない。classのコンストラクタで初期化した場合とオブジェクトリテラルで初期化した場合でinstanceofの結果が一致しなくなる
  • 対策: Discriminated Unionで、実行時に残る値で検証する

プロトタイプベース。

  • 問題点: classはprototypeに基づいて構築されていてthisが呼び出し方で動的に決まる。呼び出し方で結果が変わるケースがある
  • 対策: thisをもたない関数で表現する。classフィールドにアロー関数を入れるか、class外の関数を使う

classはなるべく避けたほうがいいことや代替の方法、また使わないといけない場面もまだ残っている、ということがよく理解できました。

まとめ

明日の仕事にすぐ役立つような、ビジネスロジックの表現や安全性についての発表が多く、たくさんの知見を得られました。いっぽうで、言語の深い部分(トランスパイラ、型システム...)についての発表はなかなか理解が追いつかなかったところもあります。まだまだ知らないことがあると刺激を受け、もっと勉強していきたいと思いました。

運営の皆さま、登壇者の皆さま、素晴らしい場をありがとうございました。 来年もぜひ、参加したいと思います!