TSKaigi 2026に参加してきました

はじめに

2026年5月22日(金)・23日(土)の2日間、ベルサール羽田空港とオンラインのハイブリッドで開催されたTSKaigi 2026に、学生支援制度を利用してオフライン参加しました。今回で3回目、テーマ「学び、繋がり、“型”を破ろう」のもと、オフライン・オンライン合わせて2,500名規模、国内最大級のTypeScriptカンファレンスです。

この記事では、私が見たセッションの所感と、カンファレンス全体の体験をまとめます。

学生支援にスポンサー頂いた企業様は以下の通りです(敬称略・順不同):

株式会社アイスタイル
株式会社アサイン
株式会社SmartHR
ソフトバンク株式会社
株式会社ドワンゴ
株式会社プレイド
株式会社LayerX
レバレジーズ株式会社

事前イベント・スカラシップランチ・懇親会

めっちゃ色んな人に会いました。スカラシップランチで提供されたお肉をいっぱい食べつつ、普段はオンライン越しにしか話せない人やそもそも交流を持てないような人たちと同じテーブルを囲めるありがたさを噛みしめました。友人とも合流して、懇親会では大いに語り合えました。

オフラインの強さは何と言っても、同じテーマに対して異なる前提で取り組んでいる人たちとその場で語り合えるところだと思います。普段のオンラインコミュニティのメンバーともリアルで会い、型とプログラミングに関する議論が白熱してとても楽しかったです。言語仕様はエンジニアを信頼するべきか、Branded Typesの実用性、教条的な設計のメリットと限界etc。テキストチャットでは中々生まれない密度の会話が、3次元空間を共有するだけで立ち上がるのはやはり特別だと思います。

セッション - tsgo

tsgoはTypeScriptコンパイラのGo移植で、今回3つのセッションがありました。私はGopherでもありますから、初日はこのテーマの公演を意識的に聞いて回りました。非常に興味深い話を聞くことができました。

tsgoは2026年4月21日にBetaがリリースされたばかりで、TypeScript 6.0と比較して実測で約10倍の高速化とメモリ使用量の大幅削減を実現しています。 RustではなくGoが選ばれた背景には、

循環参照を含む既存のデータ構造をそのまま移植できるGCの存在
TypeScriptの関数+構造体中心のコードベースがGoのイディオムとほぼ1:1で対応していたこと、
go buildでクロスプラットフォームの単一バイナリが容易に配布できること

といった複合的な理由があるそうです。 Hejlsberg氏自身はこのリプレイスを「plug and play replacement(差し替えるだけ)」と表現しているようです。 ~~そんなことないだろ~~

それぞれのセッション内容と所感をまとめます。

決定論的な型チェックへ：Go製コンパイラによる10倍速の裏側で —stableTypeOrdering から見える並列化への挑戦

tsgoが高速化を果たした大きな要因である、並列化に関するセッションです。処理の重複をある程度許容しながらも、結果的に強烈な高速化と省メモリを実現しているアプローチはすごいの一言でした。

並列化によってIDの採番順が非決定的になってしまうという課題が取り上げられていました。一見するとプログラムの動作自体には問題なさそうに見えるけれど、Git管理をする上では差分が毎回生まれてしまうため、確かに面倒な問題になり得る。 tsgoではこの問題に対し、並列化の恩恵を保ちつつ差分が安定するオプションが提供されているそうです。

並列化の恩恵の裏にある泥臭い課題解決の面白さを感じました。

tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか

DenoがどのようにTypeScriptを統合してきたかという歴史と、tsgoへの移行の苦労話でした。

DenoはTypeScriptコンパイラ(JS化済み)をV8スナップショットとして取り込み、起動の高速化とV8 Isolateとの一体化を長年やってきました。 TSとJSを同じランタイムで扱うためのオプションもDeno発で、後発のルール整備にも影響しているそうです。そこへtsgoという別プロセスの選択肢が現れたことで、Rust - V8 - Goという三層構造をどう接着するかが課題になりました。

V8 Isolate内に取り込んでいたものをサブプロセス化するという動きは、tsgoの制約がなかったとしても、V8と密結合しすぎていた関係を整理する良い契機だったように見えました。しかし、低レイヤの密結合な部分を「ただ外に分離すればいい」という単純な話ではないのが難しいところ。個人的には同じV8で動いてほしい気持ちもあるんですが。

そして、Rust - JS - Goが組み合わさるスタックはシンプルに辛そうだなと同情してしまいました。最終的に、公式npmをそのまま使用する方向で収束したようです。Deno向け構文を公式ツール群に読み込ませるために自動生成tsconfigを利用するというのは、奇しくも自動生成コードを多用するGo言語らしい解決案になったのではないかと感じました。

制約と時代から読み解くTypeScriptコンパイラ設計史

TypeScriptの歴史において、初期のJS環境の制約や、後のVSCodeとなるmonacoでのドッグフーディングを大前提として進化してきた過程が語られていました。

エディタでの効率的なデータ操作を実現するために、ASTが構文情報だけでなく意味解析などの様々な情報を持つようになったとのこと。ドッグフーディングが効率的であることはよく分かりますが、結果として異常に肥大化していくASTをよく安定的に成立させられてきたなと、その凄みに感心しました。

一方で、JSベースゆえのメモリ消費の重さという苦しみも限界に達していたようで、値型化やメモリレイアウトの最適化が効くGoでの再実装の話を聞くと、そらGoで改善せなあかんわと深く納得させられる内容でした。

セッション - 巨大な型

tsは無限()に自由な型を定義できるのが魅力の一つですね。こいつの自由度の高さといったらなくて、ちゃんと使いこなせるのは1年後くらいかなと諦めてます。当然、型に関する諸々の機能やハックも豊富に存在します。正直、Goのような制約の中で行動するほうが好きなのですが、これをマスターすると強くなれそうなので今後も挑戦していきたいですね。

checker.tsにチキンレースを仕掛けてみた：型エラー(TS2589)が発生する境界線を求めて

自由すぎて異常な再帰構造になってしまった時に出てくるエラーの話です。これは「型インスタンス化が極端に深く、おそらく無限に続く」という主旨のエラーで、TypeScriptの型インスタンス化の深さ/インスタンス化回数が内部制限に達した時に出されます。条件型の末尾再帰最適化が入ったことで上限はかなり緩和されたそうですが、それでも循環的な型構造やmapped typeの多用で簡単に踏み抜きます。

正直こういう観点から型を見たことがなかったし、自分とはなかなか縁遠いレベルの高い話だなと思いました。コンパイラの型チェッカーを「境界条件を探る対象」として攻める姿勢は、ある種のアセンブル感すらあって面白かった。登壇者は実際にコンパイラの該当箇所を読みにいって条件をいじっていたそうで、深入りするとTypeScript自体のソースを読む旅が始まるらしいです。

型の深宇宙へ飛び込め ─ tscを遅くする記述パターンの全解剖 ─

再帰、Union、mappedは重たくなるよねという話です。これも普通の使いかたをしていてその状況に陥るかな?と考えると現状の私ではあり得ない気もするが、再帰は遅延評価しよう、Unionは勝手に展開されないようにしよう、asでhomomorphic性を壊さないようにしようという話でした。

冒頭でも触れられている通り、型はコンパイル時に実行されるプログラムのようなものであるという認識は(少なくとも自分は)頭で理解していてもコードを書くときに意識していなかったものだから、これからもっと意識して書くべきかなぁと思います。 mapped typeのhomomorphic性は知らないと容易に壊すし、壊した瞬間に推論コストが爆発するので、コンパイラに思いやりを持ったコードを書けるようになりたいです。

コンパイラにここまで気を配らなければならないのは、自由度が高い言語ならではの悩みでしょうね。 Goが自分にとって書きやすくてコンパイルが早いのは、そのあたりの自由度を意図的に下げられているからなのでしょうね。

セッション - その他の型

巨大でない型についても、当然興味深い要素と言えます。学生が普通に使う文には、大きい型よりもより良い型について考えることが大事だと言えるでしょう。

TypeScriptでWebAssemblyを用いた型安全なプラグイン設計

GopherとしてはインタプリタなんだからTypeScriptで書けばいいだろと思ったのですが、WebAssemblyには興味があるし、高速化のために必要になるかもと思ったので聞きに行きました。

発表内容としても、コールドスタートに時間は掛かるし処理内容によっては計算時間すら遅くなるしで、これなら多くの場合まだTSで書いた方が良いかなという結果でした。登壇者様も同じ結論のようです。

軽量VMとしてはおそらくかなり優秀なのでしょうけど、現状では別言語の既存資産をそのまま取り込みたいケースや、計算機資源が極端に制限されたエッジ環境くらいでしか実用上の旨味が薄いのかなと思いました。 Wasm/WASIの進化次第では数年後にもう一度見直す価値がありそうです。

ReactとSvelteのその先、Ripple-TS

もうこれ以上増やさないでください(泣)。

Ripple-TSは独自の拡張子を採用し、TypeScriptのスーパーセット上にJSX的なテンプレートを載せる構成になっています。同一ソースをターゲット別プラグインを介してReact、Preact、Solid、Vue、ネイティブRippleへコンパイルできる点が特徴。条件分岐やループがテンプレート内に書けるなど、VueのSFCに近い宣言性をTypeScript側に持ち込む設計です。

私としてはVueのSFCの概念が最も気に入っています。マークアップとしてのHTMLの形をしっかり維持しているのが非常に印象が良いので。

その点、Ripple-TSのTSRXはよりTypeScript的な書き方ができるのは魅力的ではあるものの、HTMLから乖離しているのがちょっと気になりました。厳密なレイヤ分けを結構好んでやる人間なので、個人開発では使わないかもしれないです。

ただ、こういった新しいアプローチが出てくるのは面白いし、今後どう発展していくのかは注目していきたいと思います。 Volarベースと言語サーバーが分離しているのはエコシステムへの組み込みやすさを感じさせます。

LLM時代のリファクタリング戦略：AIエージェントによる段階的・安全なTS移行方法

非常に堅実な方法でのAIエージェントによる段階的な移行の話でした。大規模なリファクタ/移行プロジェクトであれば、新規に移行用のエージェントを起こして任せるというのは、口で言うには簡単ですがよく実行できたなと思います。

OpenAPI Generatorで生成したSDKの型情報を一次情報源として、AIが独自に型を推測しないようにする設計が印象的でした。型を「コードから抽出する」のではなく「契約として配布する」という逆転の発想で、AIにとっても人間にとっても同じ型を参照できる状況を意図的に作っている。セッションをまたいで関数に違う型が付く問題が消えるというのはなるほどと思った。 AIエージェントの設定ディレクトリ配下にルール・エージェント・スキルを階層化して整理し、モデルのサイズ違いを役割ごとに割り当てる運用も、コストと品質の両立策として参考になりました。

キャリア25年目にしてTypeScriptに出会うまで

私はほとんど「今」のプログラミング言語しか知らないものですから、実際に長くコードを書いてきた人の意見は本当に助かりますね。

登壇者はJava/C++/Scalaなど複数の言語を渡り歩き、プログラミング言語における「型」の役割が時代とともにどう変遷してきたか、そしてTypeScriptの異常な自由度の型は、エンジニアの味方としての型のあるべき姿を体現しているといった話をされていました。

なんで動的型付け言語が流行っているのかよくわからなかったのですが、昔の型はエンジニアの味方と断言できるほどのものではなかったのかなと思います。 TypeScriptの異常な自由度の型は、まさにエンジニアの味方としての型のあるべき姿なのでしょうね。長年の経験を踏まえての発言だからこその重みがある。

childrenの順序まで型で縛る ── Branded Typesで実践するJSXの構造安全

めちゃくちゃ面白かった、面白かったが…これはJSXなのか?

発表の核は、ReactのCardコンポーネントを例に、子要素の順序制約をタプル型にすることで静的に縛ろうというアプローチです。ただしJSX式の戻り値が常にJSX要素として潰されてしまう関係で、ブランド情報が消えてしまいます。回避策として子要素を関数として呼び出すという荒業が必要になります。 Branded Typesを関数戻り値に被せ、JSX要素への代入を構造的に不可能にすることで、タプルの順序と型を保ったまま子要素を構築する、という構成でした。

不正な構造を型で防止できることは確かに重要ですが、関数としてコンポーネントを呼び出すのはちょっと違和感があるなぁと思いました。まぁ発表でも向き不向きあると明言されてましたね。

まぁ安全性を取るか書き心地を取るかという話なのでしょうね。安全側に倒したくなるのは自分と同じだし、案外やってみたら慣れるのかもしれない。 DevToolsに子コンポーネント名が出ない、Hooks/Suspense/Contextが使えない、表示専用に限定される、という実用上の制約は明確で、トレードオフを把握した上で採用したい手法です。

スプレッド構文によるブランド流出問題を乗り越えて、オブジェクト型に対する Branded Types を使い倒す

構造的部分型のTypeScriptは大変だなぁと見てて思いました。自由度が高いゲームほど意味の分からないバグがあるように、自由度の高いプログラミング言語であるTypeScriptは型の同定一つでも結構苦労するのですね。

発表の肝は、Branded Typesをオブジェクト型に拡張する上で、スプレッド構文でブランド情報が流出してしまい、型の上では別物として扱われるべき値が同一として判定されてしまう罠を避ける方法。外から見えない専用フィールドでブランドを隠蔽するというのはなるほどな発想でした。opaque typeのようなものを自前で実装するイメージでしょうか。可視性を限定する修飾子だと同一モジュール内ではブランドが剥がれてしまうため、パッケージ境界を跨ぐならさらに厳しい修飾子に置き換えるという逃げ道もセットで提案されていました。

とはいえ、このレベルの制約をしなくても大抵はエンジニア側がいい感じになんとかしてブランド型を運用しているのでしょうけど。ただ、提案されている手法は乗り換えコスト低そうなので今後のスタンダードになるのかもしれないですね。 35ファイル/51種類のブランド型を実運用しているというのは説得力があります。

セッション - コード品質

実用の上ではコレが一番重要と行っても過言ではありませんからね。この時代ですから、AIエージェントと同共存するかという方向性でよく考えなければならない課題です。

AI Agentに”攻略本”を渡したら、150フォームの移行が回り始めた話

こちらも移行の話でした。こちらは、AIエージェントが統一感あるコードを記述するための工夫について重点的に解説されていました。

AIに何度書かせても同じようなコードにするというのはただでさえ難しいのに、TSのような機能が豊富な言語では特に難しいでしょうし、やはりフレームワークというか決まった書き方というのを作ってそれに従わせるのが良いと思います。

「入力型と出力型でスキーマの境界を引く」「1フォームに対してInput・Output・Factoryという命名規則を機械的に決める」「YAML frontmatterとMarkdownで判断基準を配布するAgent Skills」という3点が柱で、150フォームの移行を5ヶ月で大半完了させたという事例は、攻略本の効果が分かりやすいです。入力フォームにはInput型、送信ハンドラにはOutput型を渡すという型境界を握る書き方は、AIの出力揺れを型システムで抑える好例だと感じました。

いつテストを書くか?―ソフトウェア開発における安心と不安について考える

変更可能性がソフトウェアの核心だというのは、それはそうではあるのですが、それを予期的変更容易性と経験的変更容易性という2つの観点で言語化していたのはすごいなと思います。

変更の機会を増やすことと、変更することに合理性があること。この両方が揃って初めて、変更可能性が高いと言えるのだなと納得しました。

また、テストの問題が構造上の問題を示唆しているというのは非常に鋭い指摘だなと思いました。

不適切に分割された関数のテストがめちゃくちゃ脆くて苦労したのを思い出しましたね…あのときはテストの改良で対応したが、もっと真摯に取り組んでおけばよかったかも知れない。

静的解析への投資がAI時代のコード品質を支える ── カスタムESLintルールの設計と運用

機械的な処理はlinterにやらせよう!

何でもかんでもAIにやらせすぎている側面はあると思うのですよね。可能なら確実な方法でコードを整形したほうがいいのは間違いありません。

linterにしろボイラープレートのコードジェネレーターにしろ、ああいうのを準備するのは非常に大変ではあるんですが、それこそAIを使って一回だけしっかりreviewしろという話ですしね。

知らなかったlinterの機能は知れたし、linterをテストするという概念は持っていなかったので、何気にこの発表が一番の収穫かもしれません。ルールのユニットテストを書く、プラグイン内部でASTを直接読んで高精度に判定する、自動修正を提示するAPIを整備するといった一連の流れは、AIに同じことをやらせるよりずっと再現性が高く、速く、説明可能な世界になるなと納得しました。

ブース

非常にたくさんのブースが出展されていました。各社本当に多種多様なサービスを提供されていて、見て回るのがとても楽しかった。スカラシップ参加者向けのノベルティや、出題に答えると景品がもらえるクイズ形式の展示など、遊び心のあるブースが多かった印象です。

その他

NFCカード

カンファレンス参加者に配られたNFCカードにブログの情報を書き込みました。来場者同士でタップすると連絡先交換ができる仕組みで、この規模のカンファレンスではあったほうがいい装備だと感じました。非常にいいものをもらえた。

コミュニティ日本地図・イベントカレンダー

会場のコミュニティ関連展示で、自分が参加しているVRChat.tsがしっかり記載されていました。やったー!

VRChat上でTypeScriptの勉強会をやっているコミュニティで、VR空間という制約の中でテキストベースの勉強会をどう成立させるか日々工夫しています。記事を見ているそこのあなたも、来んしゃいVRChat.ts!

おわりに

tsgoを軸に参加計画を立てたつもりでしたけど、難しかったこともあり、後半は実用寄りの方の話を多く聞く感じになりました。セッションの内容自体もさることながら、同じテーマに対して異なる前提で取り組んでいる人たちが一堂に会し、その場で語り合える環境の貴重さを改めて感じました。

学生支援という形で参加させてもらえたこと、並びに素晴らしい運営とスポンサーに感謝します。来年もぜひ参加したいです。