2026/05/22,23開催で羽田空港にある巨大なイベント会場で開催されてた。
勉強になることもたくさんあったので、参加レポートとしてまとめです！
拝聴したセッション
「関数型プログラミング」を分解する.ts
登壇者: おーみーさん
セッションURL: https://2026.tskaigi.org/talks/3
資料URL: https://tsk-2026-aumy.vercel.app/1
正直、関数型プログラミングをちゃんと理解していないので、理解を深める機会になればと思って参加したセッションでした。
関数型プログラミングについて整理をした後に、
一部の概念はTSだと実現できないこと、
そして、それでも擬似的に再現する方法を紹介するセッションでした。
結局関数型プログラミングが何を目的にやってるかを立ち返って、その目的のために、TSでできることを紹介してくれたのがすごく良かった。
特に、「継続」という概念が初めて知った概念ですごく面白かった。
- 継続は計算の残りの部分で、コールバックによって表現されると、「継続渡しスタイル」と呼ぶ
- 継続渡しスタイルとしてJSのPromiseチェーンなどがこれを実現している
- 継続渡しスタイルはコールバック地獄になりやすいので、
async/awaitは手続き的なスタイルで書けるようにしている - Rustの
Optionもand_thenを使えば継続渡しスタイルになるが?演算子を使えば手続き的なスタイルで書けるようにしている
個人的にはTSの例だけじゃなく個人的にRustの学習もしていることもあって、RustのOptionなどについても理解を深められる機会になった。
業務に残された「よくない型」で考える「TypeScriptの難しさ」
登壇者: Sajiさん
セッションURL: https://2026.tskaigi.org/talks/5
資料URL: https://speakerdeck.com/sajikix/ye-wu-nican-sareta-liang-kunaixing-dekao-eru-typescriptnonan-sisa
業務でよくない型ってどういうのだろう?、そして仕事で使ってるTSのコーディングの観点を見直す機会になればと思って参加。
どうしてもasや@ts-ignoreなどの型について妥協してしまうケースを分類して、どのように対処すればいいのかを紹介するセッションでした。
7つのパターンに分解してくれていて、ちゃんとそれぞれのケースについて具体的な解決策を紹介してくれていたのがすごく良かった。
TSの言語の仕組みとしての問題や、その問題がバージョンアップによって徐々に改善されていってるというのが印象的でした。(ちゃんとバージョンアップしていかないとと思えた。)
また、チェックリストも用意してくれてこれからの業務でも活用したいと思えた。
権限チェックの一貫性を型で守る TypeScript による多層防御
登壇者: 北川 直昭さん
セッションURL: https://2026.tskaigi.org/talks/9
これからTSでバックエンドを少し書くことになりそうなので、実運用でどういう権限、型管理をするべきかの参考にしたいと思い拝聴。
権限チェックがfrontend, backend, DBで同じルールがあるが、それぞれで定義すると保守のリスクがあるため、SSoT(Single Source of Truth)で管理するという話だった。
SSoTという概念は初めて知ったが、1つのルールを一箇所で管理して、それを他にも流用するというものらしい。
frontend, backendはわかるがDBでどう実現するんだと思っていたが、psqlのplv8というJSを実行する拡張機能を使うことで検証を行うことを可能にしていることが印象的だった。
個人的にはTSが構造的型付けというのもあり、別にそれぞれで定義してもいいだろうとは思っていたが、別のセッションで同じ構造のデータを間違って渡してしまっていたケースなどの紹介があり、確かにSSoTで管理するのは保守の観点からも良さそうだなと思えた。
TypeScriptのclassはなぜこうなったのか — 歴史・落とし穴・そして使いどころを探る
登壇者: kosuiさん
セッションURL: https://2026.tskaigi.org/talks/16
資料URL: https://kosui.me/slides/2026/tskaigi/1
私はTSのclassの挙動があまり好きでなく、あまり使わないようにしているのですが、どうしてこういう挙動になっているのかを知りたいと思い拝聴。
以下の３つの問題点をベースに問題を整理して、いつ使えばいいかを紹介するセッションでした。
- 構造的部分型との相性が悪い
- 問題: そもそもTSが同じ構造なら型エラーにならないため、classに名前をつけても意味がない
- 対策:
BrandedTypeを使用する
- 型が消去されてしまう
- 問題: オブジェクト(広義)としてのプロパティが同じなら、オブジェクト
{}とclassでランタイム上は区別がつかない(型消去) - 対策: 型消去されないようなオブジェクトのプロパティを用意して、
Discriminated Unionを使用する
- 問題: オブジェクト(広義)としてのプロパティが同じなら、オブジェクト
- prototypeベースのJS/TSの相性も悪い
- 問題: JS/TSの
thisは諸問題の原因になる - 対策:
thisを使わないようにする
- 問題: JS/TSの
classの使い所については以下のように整理されていた
- Custom Error: Errorクラスを継承してtry/catchをする慣習のためclassを使った方が都合がいい(
Error.isErrorもあるし) Symbol.disposeで処理後にリソースを解放するとき:usingを使ったリソース管理のためにclassを使うと都合がいい
また、classを書くのはFWによっても異なると紹介されていた。Angularなどでは使うのは避けられないが、React, Vueなどは使わなくていいと紹介されていた。
私の業務ではVueを使用しており、一部モデルなどでclassを使用しており、あんまり使わない方がいいのかもと思った。
ビジネスモデルから紐解く、AI+型駆動開発
登壇者: omoteさん
セッションURL: https://2026.tskaigi.org/talks/18
資料URL: https://speakerdeck.com/hirokiomote/hisinesumoterukaraniu-jie-ku-ai-plus-xing-qu-dong-kai-fa
私は最近業務でAIと設計をし、実装させるということを行なっており、そのための知見を得るために拝聴。
プロダクトを以下の4つに分類し、それぞれどこを中心に型を設計していけばいいのかを考えるセッションでした。
- SaaS型
- データ依存型
- API中心型
- マーケットプレイス型
新規プロダクトの設計となれば特に意識する必要があると感じた。
私が今携わっているプロダクトはマーケットプレイス型だと思ったので、今それが中心になっているかを改めて考える機会になった。
TS 7: How We Got There
登壇者: Jake Bailey
セッションURL: https://2026.tskaigi.org/talks/37
資料URL: https://jakebailey.dev/talk-tskaigi-2026/1
MircrosoftのTSの開発者本人から話が聞ける貴重な機会だと思い参加。
tsgoのリリースが近づいている中、どのような経緯でTSの実装をTSからGolangに切り替えたのかという経緯が聞けるセッションだった。
並列処理やVSCode(Electron)のメモリ制限などの問題があったのがきっかけだった話は初めて聞いて面白かった。
また開発の中で、思ったより速度改善されなかった、そしてそれをどう乗り越えて速度を上げることができたのかという開発裏話が聴けたのも印象的だった。
実際にVSCodeのビルドをts5とts7を比較する実演タイムがあり、 3分以上かかっていたビルドが、15秒程度になっていたのは衝撃的だった。
個人的にwebpackのビルドがめちゃめちゃ遅いので、それも解決できそうに思えた。
400超のデータポイントを型で制す —— UPSIDERの与信審査エンジンを支えるTypeScriptの「柔軟性」と「結合力」
登壇者: 泉雄介さん
セッションURL: https://2026.tskaigi.org/talks/39
資料URL: なし
大規模なデータを扱うプロダクトでどのようにしてTSを利用しているのかが気になって参加。
400以上ある特徴量をどうTSで管理しているかを紹介するセッションでした。
400以上の特徴量を1つの型で管理しているという部分が衝撃的だった。
またAI導入後の開発チーム体制についての言及も参考になった。
- Rubyも検討したが、型があるTSの方がいいと判断
- 慎重に作業する部分が変わった: コーディングからレビューやテストにシフト
- 仕様書はPRDで管理していた
- チーム人数が10~20人から1 pizzaになった
- PRも巨大になった(旧体制からはギャップを感じる)
私が所属している組織でもAIによって開発体制が大きく変わっている最中であるため、AI導入後の開発体制の話が参考になりました。
React の props は値の集合ではない — UI の状態を宣言するコンポーネント設計
登壇者: nabeliwoさん
セッションURL: https://2026.tskaigi.org/talks/41
資料URL: https://nabeliwo.github.io/slides/talks/20260523_tskaigi-2026_react-props/1
propsは値の集合ではないというタイトルに惹かれて参加。
propsの型設計には問題があって、あり合えない組み合わせを防げないという話だった。
Discriminated Unionを使うことで、あり合えない組み合わせを防げるようになると紹介されていた。
また、非同期データについてはSuspesnceなどを使用するようにとも紹介されていた。
個人的には、validationで防ぐものかと思っていたが、型で防げた方が型情報だけでわかるのでこっちの方が絶対いいと思った。
また、VueにもSuspenseがあるか確認したらちゃっかりあった。これをVueでも使っていきたいと思った。
型プラグインシステムの実装に使われるテクニック
登壇者: elecdeerさん
セッションURL: https://2026.tskaigi.org/talks/42
資料URL: https://speakerdeck.com/teamlab/tskaigi-typed-plugin-system
型システムについて理解を深めたくて参加。
ライブラリなどで使われる型実装のテクニックを紹介するセッションでした。
業務ではあんまり使いづらそうだが、ライブラリがどういう思想で型を導入しているかをしれて面白かった。
Auth.jsからBetter Authへの移行に見る「型とランタイム」の設計思想の変化
登壇者: 宇根昇汰さん
セッションURL: https://2026.tskaigi.org/talks/43
資料URL: https://speakerdeck.com/nowaki28/tsservertohahe-tatutanoka-korekaratounarunoka
3連続セッションでなんとなく知らないライブラリだったが認証っていつの時代も大事なので、ふらっと拝聴。
Auth.jsがBetterAuthに移行が推奨されており、どのような変更があるかどうかのセッションだった。
思想自体が自分で定義するのではなくSSoTに沿ったもので他のセッションでもあったが、SSoTがだいぶ主流になってるんだと感じた。
tsserverとは何だったのか、これからどうなるのか
登壇者: 中村遼大さん
セッションURL: https://2026.tskaigi.org/talks/51
資料URL: https://speakerdeck.com/nowaki28/tsservertohahe-tatutanoka-korekaratounarunoka
私はZedのLSPが整ってない頃にLSP拡張機能を作ろうとしたことがあるLSPオタクなので、聞いてみたいと思って参加。
ts6まではtsserverでLSPと非互換だったが、ts7からはtsgoを直接--lspを指定すればLSPを起動することができるようになったことを紹介するセッションだった。
tsserverはなんとなく単語は知ってたが、typescript-language-serverは馴染み深かった。
それが、まさかtypescript-language-serverがtsserverをラップしているだけのものだったとは知らなかった。
また、tsserverがなんでLSP非互換なのかという歴史的背景も知れて面白かった。
そして、ts7からはtsserverがなくなり、vueなどの旧式のAPIを使っていたツールチェーンが対応に追われてしまうという話があり、Vueユーザーとしてはもう少しts7を使うのは待たないといけないかもなと思った。
Node.js+TypeScriptにおけるCJS/ESM相互運用の最新ポイント
登壇者: 桐生直輝さん
セッションURL: https://2026.tskaigi.org/talks/56
資料URL: https://speakerdeck.com/grainrigi/esmxiang-hu-yun-yong-nozui-xin-pointo
個人的にもESMやらCJSやらでごちゃごちゃ煩わしく思っていたため、どうやって運用すればいいかの知見を得るために参加。
tsconfigでmodule=nodenextを指定すると、基本的に気にしなくて良くなるらしい。
この問題の元凶の紹介もあり、top level awaitというほとんど使われない機能のせいでrequireが同期的に動かなくなってしまっため、esm側がrequireでのimportを禁止したのが原因だと紹介があって、数年越しに理由を知れて興味深かった。
enum よ、さようなら
登壇者: takuma-ruさん
セッションURL: https://2026.tskaigi.org/talks/57
資料URL: https://speakerdeck.com/teamlab/tskaigi-goodbye-enum
私はenumアンチ(tsのバージョンで挙動違ったりするので)なので、共感しそうだなと思って拝聴。
enumが使わない方がいいことを前提に、なんでenumが微妙なのか、そしてこれから残り続けてしまうことを紹介するセッションでした。
enumが微妙な理由は以下の通りと紹介された
- enum数行で生まれるJSコードが長すぎる(バンドルサイズが大きい)
- 途中でTSが方針転換し、enumが生きづらい世界に
ただし後方互換のため、enumは残り続けることが紹介されていた。
歴史的背景も知れて面白かったです。
inferと仲良くなる10分間
登壇者: infixerさん
セッションURL: https://2026.tskaigi.org/talks/58
資料URL: https://speakerdeck.com/ryokatsuse/infertozhong-liang-kunaru10fen-jian
初心者向けのinfer解説のセッションでした。
infer日頃そんなに使わないので、ちょうどいい具合に思い出せてよかったです。
いつテストを書くか？―ソフトウェア開発における安心と不安について考える
登壇者: lacolacoさん
セッションURL: https://2026.tskaigi.org/talks/63
AIの登場のなかいつテストを書いた方がいいんだろうという疑問を持ってたので、テストの書き方についての知見を得るために拝聴。
そもそもソフトウェアは変更のしやすさがソフトであると紹介した上で、その変更しやすさに必要なものは何か、そしてテストはそれにどういう役割を果たすのかを紹介するセッションでした。
変更のしやすさについて以下の2つの視点から紹介されていた
- 予期的変更容易性: 「この変更やばそうだな…」と思わないこと
- 経験的変更容易性: 変更中に「しんどい…」ってならないこと
テストはこれらの変更のしやすさを担保するための手段の1つであると紹介されていた。
テストの種類によってどこに作用するかが変わっており、以下のように紹介されていた。
- E2E/結合テスト: 予期的変更容易性に作用する
- 単体テスト : 経験的変更容易性に作用する
また、テストを書くということにも副次的なメリットがあり、書いている時の書きづらさ = どこかおかしいってなるので、これってプログラムの構造のFBになってるという話もあり、衝撃だった。
経験則的に、テストを書くと対象がいいコードか悪いコードかわかるなと思っていたが、それがフィードバックになっていたという話を聞いて点と点が繋がった。
テストがあると品質が安定するという話はよくある話だが、メンタル面で変更しやすさを分解して、テストがある意味を紹介してくれたのが斬新で自分の中でのテストに対する考え方が変わった。
聞きたかったセッション
tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか
登壇者: maguroさん
セッションURL: https://2026.tskaigi.org/talks/2
資料URL: https://www.docswell.com/s/magurotuna/59NRVP-tskaigi-2026
Vueの非公式だがtsgoに対応したVueのツールチェーンを紹介していたらしい。
まだ安定版なので使えないと思うが、Vueのlanguage toolsはts 7.1のリリースを待ってから実装するらしいのでかなり時間かかりそう。
業務ではまだ使えないが、安定版になったら検討してもいいかもしれない。
次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解
登壇者: Yuta Takahashi
セッションURL: https://2026.tskaigi.org/talks/65
Linterが大好きなので、tsgoでどう変わってくんだろうと思って聞いてみたかった。
資料を見る感じ、やっぱり今のtsのeslint pluginが一番今は安定してそう。
LSPの時もそうだったが、やっぱりts側がコンパイル以外のところでの型認識をどうするか(ts7.1)が固まらないと、他も動きづらいんだろうなと思う。
ESLintは重いので早く、tsgoに対応してほしい。あとBiomeとOxlintにVueのtemplate構文をサポートしてほしいが、もう少し待ちそうです。
まとめ
個人的には去年とはまた違う視点が多かった気がする。
BrandedTypeを使ってるケースが増えていたように思えて、型の安全性を高めるために工夫している人が多い印象だった。