はじめに
こんにちは。ニフティの塚崎・佐藤です。
5/22, 23の2日間にわたって開催されたTSKaigi 2026に初めて参加してきました。
TSKaigiとは？
TSKaigiは、日本最大級のTypeScriptをテーマとしたテックカンファレンスです。毎年、5月頃に開催されているようで、今年は現地参加者が約800名でオンライン参加者が約900名と合わせて1700名規模の大きなイベントとなりました。また今年の会場はベルサール羽田空港という場所で開催されました。
なぜ参加しようと思ったか
塚崎
元々、フロントエンド開発やTypeScriptが好きだったというのと、業務でも頻繁にTypeScriptを使うため今回参加することにしてみました。TSKaigi自体は昨年、オンラインで参加していたのですが、今年は同期の佐藤からの誘いもあり現地参加をしてみました。オフラインイベントへの参加経験もほぼなかったので、単純な興味というのも理由としてありました。
佐藤
普段は個人開発で最新のライブラリを試してみたり、毎日の習慣で技術ブログを読み漁ったりしています。現在所属しているチームの開発では割合としてはまだ低いですが、TypeScriptを採用する機会は増えてきており、APIの刷新ではHonoなどを採用しました。現在進行中の新規開発でも、引き続きTypeScriptを採用する予定です。 実務での経験を積むにつれて、他社エンジニアのTypeScript活用方法に興味が湧いてきました。そこで、普段からTypeScriptの話で盛り上がる同期の塚崎を誘い、今回のイベントへの参加を決めました。
印象に残ったセッション
塚崎
数あるセッションの中でも、特に印象に残ったのがKazuya Serizawaさんによる「アンチパターンを避ける型駆動React最適化」です。
https://2026.tskaigi.org/talks/17
こちらのセッションは、React 19から正式に登場したReact Compilerによってコンポーネントの最適化を行うという内容です。React Compilerが最適化できるのは純粋なコンポーネントだけですので、コンポーネントの純粋性をいかにして型とLintで担保するか、という型駆動のアプローチを紹介していました。また、コンポーネントを純粋に保つことは、最適化のためだけではなく、読みやすくメンテしやすいコードにも繋がると説明されていたのも印象的でした。
最適化ができない例として、以下の4つが紹介されていました。
- 副作用の混入：render中のDate.now() / ログ出力 / 乱数生成
- ミュータブル操作：letの再代入、push / sortなどの破壊的操作
- 参照不安定：毎回新規生成のオブジェクトや関数を子に渡す
- 非決定的な依存：モジュールスコープの可変変数をrenderから触る
これについては、以下のような型定義で対策をしていました。
|
1 2 3 4 5 6 7 8 9 |
type Props = { items: ReadonlyArray<Item>; user: Readonly<User>; }; function List({ items }: Props) { items.push(...) // ❌ コンパイルエラー const next = [...items, x]; // ✅ OK } |
ReactではPropsに対してミュータブル操作をしてはいけないのですが、これをReadonlyArrayやReadonlyを使って対策していました。型で定義し、そもそも書けないようにするというのは、TypeScriptの良さを最大限活かした設計だなと感じました。型定義であれば部分的にも導入がしやすいですので、現在担当しているプロジェクトにも適用してみようかと考えています。また、発展形として、Branded Typeを使った副作用のない関数しか受け付けない手法も紹介されていました。Branded Typeについては実務で使った経験もなく初めて知った手法だったので、もう少し調べてみようと思います。他にも型定義だけでなく、BiomeやOxcなどのLinterルールで防止するという多層的なアプローチも取られていました。型定義だけでは防げない操作をLinterで防ぐという手法で、型定義とLinterでより堅牢なReactアプリケーションが作れると実感できるセッションで非常にたくさんの学びが得られました。
佐藤
印象に残っているセッションは
の2つです。
前者は、型チェック（deno check）をはじめ、コードの解釈や実行を支える仕組みがどう変わってきたかをたどる内容でした。その中心にあるのが、JavaScriptで書かれた公式のTypeScriptコンパイラtscと、それをGoで再実装したtsgoです。タイトルの「tscからtsgoへ」が示す通り、Denoが模索してきた歩みが紹介されました。jsr:やnpm:、Deno独自APIといった概念をTypeScriptが読める形に「翻訳」する仕組みが、tscを抱え込む状態からtsgo、そして公式TypeScriptへと、次の3段階で外側へ移ってきたそうです。
- Phase 1：embedded tsc — パッチを当てたtscをV8 isolate内で実行。挙動は安定する一方、巨大バンドルや上流への追随コストが課題。
- Phase 2：forked tsgo — Go製のtsgoをサブプロセスで起動し
deno checkを高速化（簡易ベンチで約2.6倍）。ただしfork維持やLSP対応のコストが重い。 - Phase 3：公式npmパッケージへ — forkを捨て、Deno独自の依存をローカルにmaterializeして公式TypeScriptが読める形に橋渡しする方向へ。
私自身Denoを使ったことはないのですが、denoの裏側でこれほど大きな変遷が起きていたとは知らず、ツールの内部仕様を詳しく知ることができて、話を聞いていてとても面白かったです。「forkも再実装も避けたい」制約の中で、普段は意識しない内部の仕組みまで踏み込んで知ることで、内部アーキテクチャに対する理解が一段と深まったと感じています。
後者は、Sajiさんが実際の業務コードに残った「良くない型」（asや@ts-ignoreなど）を収集・分類し、そこからTypeScriptの難しさや限界、チームでの向き合い方を考えるという内容でした。普段は細かい型まで意識せずに書いてしまうことも多いため、型との向き合い方を改めて見直す良い機会になりました。AI駆動開発にも規約として活用できそうです。
イベントに参加してみて
塚崎
TypeScriptの高度な型定義について学びが得られたのは大きな収穫でした。
他にもTanStack Start、Oxlintのような最新のフレームワーク・ツールに関するセッションもいくつかあり、技術選定やツールチェーンの見直しの際の参考にもなったかなと思います。
AI周りについても知見を深められました。特にAI活用が当たり前になった現在でいかにして品質を担保するかという視点での学びは大きなものでした。
今回のイベントに参加してみて、勉強のモチベーションも向上したので今後もTypeScriptについて勉強していこうと思います。
佐藤
登壇者や参加者の方々の知識の深さに触れ、自分のTypeScript理解の浅さを痛感しました。
セッション以外でも、各社がスポンサードでブースや企画に趣向を凝らしており、多くの学びがありました。特に、学生支援制度のあるイベントは参加者層が広く、会場全体が活気にあふれていました。参加して良かったなと思います。
高まったモチベーションをそのままに、帰宅後はさっそく自分のポートフォリオサイトの改修に取りかかりました。引き続きTypeScriptについて勉強していこうと思います。
おわりに
例年通りであれば、YouTubeにアーカイブ動画が掲載されると思います。また、登壇された方々が発表スライドを公開しているので、興味を持った方はぜひ覗いてみてください。
来年は社内のメンバーも数人誘って、一緒に参加できればと思います！
本記事が来年以降にTSKaigiへの参加を考えている方の参考になれば幸いです。
