TSKaigi資料まとめ

非常に学びが多く、刺激的な時間でした。…が、あまりに内容が濃く、逆に記憶に残らない！
そんな自分のために、登壇者の方が公開してくださっている資料をまとめました。

もともとは完全に自分用のメモなのですが、「こんなの欲しかった」と思ってくださる方がいればと思い、共有してみます。

内容に誤りや抜けがあれば、ぜひコメントなどでご指摘いただけると嬉しいです。修正していきます！

※本記事では、TSKaigi 2025の各登壇者が公開されている資料・概要を引用・紹介しています。
※引用元・登壇者情報は公式サイトおよび各スライド共有サービスからのリンクに基づいています。
※内容の正確性については各登壇資料をご確認ください。

2025/05/23 Room: トグル

招待講演　The New Powerful ESLint Config with Type Safety

Introduction to the new flat config and the new possibilities it enables, the new utilities and ecosystem around it, and how you can do it in a type-safe way.

checker.tsに対して真剣に向き合う

checker.ts は TypeScript のコードベースの中でも特に行数が多いファイルとして知られていますが、その中身まで読み込んだことがある方は多くないかもしれません。

本セッションでは、tsc コマンドを実行した際に checker.ts 内でどのような処理が行われているのかを追いながら、TypeScript の型検査の仕組みと checker.ts の役割について解説します。

また、TypeScript 7.0 で導入が予定されている typescript-go における実装とも可能な限り比較し、今後の変化についても触れていきます。

撤退危機からのピボット：4年目エンジニアがリードする TypeScript で挑む事業復活

入社4年目のエンジニアがリードを務めた CARTA HOLDINGS のゲームメディア新規事業。順調な矢先に予期せぬ急落に見舞われ、事業は深刻な危機に陥りました。撤退も視野に入る中、ビジネスサイドとエンジニアが一体となり事業ピボットを決断、TypeScript を活用して事業要求に応える復活に踏み切りました。本セッションではこの厳しい状況下で、TypeScript を武器にどのように新プロダクト開発を推進し、事業課題の解決に貢献したか、そのリアルな経験をお話しします。このセッションは「技術を武器に事業課題の解決へ挑戦したい」と考えているエンジニアの方におすすめです。セッションを通じて、目の前の事業課題に対し、技術を活用しアクションに繋げる考え方・取り組み方を伝えます。

推し活を支えるAngularアプリ量産体制

TwoGateでは音楽アーティストやタレントYouTuber, VTuberなどの、イベントグッズ販売やチケット販売などを支えるマルチテナントサービスを複数提供しています。 これらのサービスは、Webアプリやモバイルアプリで提供しており、Angular, Ionicを活用して開発しています。 テナント総数は200を超えており、これらを10人程度のチームで量産するためには、ローコード化して個々のテナントを立ち上げるコストを下げ、運用を効率化する必要があります。 本セッションでは、Angular Schematics, TypeScriptを活用して、テナントごとにカスタマイズしたマルチテナントサービスを量産する体制の構築についてお話します。

生成AI時代にフルスタックTypeScriptの夢を見る

Nstockでは現在「株式報酬SaaS事業」、「セカンダリー事業」、「スタートアップへの再投資事業」の3つの事業がそれぞれ独立して開発を進めています。「株式報酬SaaS事業」では完全にクライアントサイドで動作するStaticなNext.jsを、「セカンダリー事業」ではReact Router v7を活用したサーバーサイドレンダリング構成を選択しています。 この異なるアプローチは各事業の課題とリソースを考慮した戦略的判断です。本トークでは、生成AIがもたらす開発パラダイムの変化を踏まえつつ、「スタートアップへの再投資事業」におけるフルスタックTypeScriptの可能性と、AIとの協働を視野に入れた技術選定の新たな判断基準について考察します。

AsyncAPIを使ってPub/Subを型安全にする

AVITAでは、一部のリアルタイム通信機能の開発に Pusher Channels を利用しています。本LTでは、AsyncAPI と modelina を活用してイベント定義の型を自動生成し、フロントエンドとバックエンド間で発生していたイベント名・チャンネル名の認識ずれ問題を解消する手法をご紹介します。

TypeScriptで実践するクリーンアーキテクチャ ― WebからもCLIからも使えるアプリ設計

本セッションでは、TypeScriptの型安全性と柔軟なモジュール設計を活かし、Web（Next.js）とCLI（inquirer.js）の両方から操作できるスクラム管理アプリをサンプルとした実践例を紹介します。

TypeScriptを選んだ理由は、強力な型システムとバックエンドとフロントエンドのどちらでも一貫して使えるため、フレームワーク非依存の設計と相性が良いからです。

クリーンアーキテクチャは「詳細に依存せず抽象に依存する」ことを基本理念とする設計方針です。TypeScriptを用いて重要なビジネスロジックを分離することを紹介します。

・フレームワークに依存しないアプリケーションの構築方法
・TypeScriptの型システムを活かしたドメインロジックの実装
・Next.jsとCLIの両方で動作するそれぞれのPresentation層の設計

本セッションを通じて、フロントエンドとバックエンドの関係を再考し、TypeScriptで変更に強い柔軟なアプリ設計を実現する方法を紹介します。

本発表は以下の記事に即した内容です。
「TypeScriptでクリーンアーキテクチャを実践する - WebでもCLIでも使えるアプリケーションの作り方」

堅牢なデザインシステムをつくるためのTypeScript活用

本セッションでは、TypeScriptを活用してFigmaのデザインデータ資産を効率的にコードへ反映させ、デザインシステムを堅牢に構築・運営する手法を紹介します。

Figma APIやStyle DictionaryなどのツールとTypeScriptを組み合わせて活用することでデザイントークンやコンポーネントを利用する際の型安全性を確保でき、これによりデザインシステムのルールを自然なかたちで強制することができます。

さらに生成AIドキュメント自動生成や、Figma APIを利用したコンポーネント情報の自動取り込みなど、実際の開発現場で役立つ具体的な事例を交えて解説します。

この題材を選んだ理由は、デザインと実装の橋渡しをよりシンプルかつ堅牢に行うことで、チーム全体の生産性向上に直結するソリューションを提供できると確信しているからです。

参加者には、TypeScriptの静的型チェックを活かした実践的な技術と運用ノウハウを体感していただき、より一層のUI品質向上を目指すヒントを得ていただきたいと考えています。

AI Coding Agent Enablement in TypeScript

私が所属するユビーでは、Full-Stack TypeScriptのコードベースにおいて、CursorやDevinをはじめとするCoding Agentを活用した開発をいち早く実践してきました。その中で、人間のエンジニアと同様にCoding Agentをイネーブルメントする重要性が見えてきました。
本発表では、Full-Stack TypeScript環境でCoding Agentを最大限に活用するためのイネーブルメント戦略をお伝えします。

まず、エンジニア（人）による開発とCoding Agentによる開発を比較しながら、Coding Agentの特性とイネーブルメントの重要性を理解します。

次に、具体的なイネーブルメント戦略をご紹介します。実感できるようにデモを交える予定です（AIのデモはドキドキしますね！）。例えば次のようなテーマを含みます。

AIが解釈しやすいアーキテクチャ
静的解析・自動テストによるAIの自走
デザインシステムによる「コーディング」以外の支援
最後に、TypeScriptエコシステムとCoding Agentの親和性、およびエコシステムの進化を見据えた展望をお話します。

本発表を通じて、皆さんがよりCoding Agentを使いこなす手助けになればと思うと同時に、TypeScriptにフォーカスしたCoding Agent活用の議論がより盛り上がるきっかけになることを期待します。

TypeScriptとReactで、WAI-ARIAの属性を正しく利用する

WAI-ARIAは、スクリーンリーダーなどの支援技術とWebコンテンツを連携させるための仕様です。複雑なWebアプリケーションのアクセシビリティを高めるためには、時としてWAI-ARIAの提供する role 属性や aria-* 属性を使わなければなりません。WAI-ARIAの仕様では、利用できる属性の組み合わせに制約がありますが、現在のTypeScript (tsx) + React の環境では、残念ながらこの制約に対するサポートは不十分です。このセッションではTypeScriptによるWAI-ARIA属性へのサポートの現状を紹介し、型安全性によってWAI-ARIAを正しく利用できるようにするための具体的な実装について解説します

TypeScriptとは何であって何でなく、誰のもので、どこへ向かうのか

TypeScriptは特殊なプログラミング言語です。TypeScriptコードをそのまま解釈して実行できる主要な処理系は存在せず、実際には高級な動的型付け言語であるJavaScriptへコンパイルしてから実行されています。

このコンパイル処理は、型に関する構文を取り除くという単純な仕組みであり、TypeScript CompilerやBabel、SWC、esbuild、oxcなど、さまざまなコンパイラ実装が存在します。一方、実際の型チェックは複雑で、現状ではMicrosoftが開発するTypeScript Compiler以外には事実上まともに対応できる実装はありません。

こうした状況の中、Node.jsがTypeScriptを公式にサポートするようになったり、JavaScriptの標準化委員会であるTC39でType Annotationが提案されたり、Biomeなどのリンターがtype-aware lintingの実現に取り組むなど、TypeScriptにまつわる議論が活発化しています。

本セッションでは、こうしたTypeScriptの言語特性を踏まえながらエコシステムの現状を整理し、今後TypeScriptとその周辺がどのように発展し、それが私たちTypeScriptプログラマーにどのような影響を与えるのかを考察します。

Rust製JavaScript/TypeScript Linterにおけるプラグイン実装の裏側

本トークでは、Rust製JavaScript/TypeScript Linterにおけるプラグイン実装について話します。

ESLintはそのプラグインシステムによって、さまざまなLintルールが生まれ、コミュニティを拡大させました。一方ここ数年でRust製JS/TS Linterの採用は増えつつあります。これらのツールにおいてもCustom Lint Ruleを書くためのプラグインシステムが実装されつつあります。
BiomeはGritQLによるプラグイン機能をv2.0でリリース予定です。deno lintではv2.2.0以上で実験的機能としてJS/TSによるプラグイン機能がリリースされています。oxcもまたプラグイン実装を行おうとしています。

プラグインシステム実装の裏側に着目し、整理・共有・理解することを目指します。

2025/05/23 Room: アセンド

高度な型付け、どう教える？

TypeScript の高度な型付けを導入すると型システムの恩恵を受けられる一方で、複雑さが増して可読性や学習コストの課題が生じます。チームの全員が型の専門家でなくとも最低限のレビューやメンテナンスができることは、プロジェクトの健全な運用に不可欠です。本セッションでは高度な型を導入する際に直面した課題や、それをチームにどう伝え理解を促すかについて発表者の試行錯誤を交えて紹介します。高度な型付けの学習ハードルをどうすれば下げられるか、どんな説明や工夫が有効なのかを考察し実践的な知見を共有します。

静的解析で実現したいことから逆算して学ぶTypeScript Compiler

静的解析には、コードベースから情報を抽出したり、自動的に編集を行ったり、多くの活用方法があります。ESTreeに関連したライブラリをベースに静的解析でなにかを実現することと比べて、TypeScript Compilerを活用することの難易度は高いです。これはプラグインの充実度や関連する資料の量などエコシステムとしての広がりの差に原因があると考えられます。

難易度が高いTypeScript Compilerですが、プロジェクトの型情報を活用できるだけでなく、提供されるAPIの型が強力であることや依存関係が少なくなることなど、ツールを作るベースとして採用する複数のメリットがあります。

この発表では、「静的解析で何を実現したいか」を軸にそこから逆算して必要になるTypeScript Compilerの知識を紹介します。TypeScript Compilerを使ってなにかを作るきっかけを提供できることを願っています。

Language Serverと喋ろう

普段開発で何気なく使っている「コード補完」「Go to Definition」「変数リネーム」のような機能を、エディタ操作以外で呼び出したいと思ったことはありませんか。このような機能は、コア機能を提供する「Language Server」とエディタ拡張がやりとりすることで実現されている言語が多いです。Language Server Protocol (LSP)はそのプロトコルであり、様々な言語機能について、言語やエディタに依存しない汎用的なインターフェースが規定されています。本来LSPは、エディタごと・言語ごとに言語サポートを実装する労力を省くためのものですが、エディタ外で前述の機能をprogrammaticに呼び出すことにも利用できます。

私はアプリケーションの挙動やコードを精査して脆弱性を探す業務をサポートするツールとして、セキュリティ的に怪しいコードに対し、その呼び出し元のチェーンを洗い出すことで影響範囲を調べるツールを開発しています。
TSに特化した処理をするならCompiler APIも良い選択肢ですが、それと違って様々な言語に適用できる点でLSPに注目しています。

セッションでは以下について話す予定です。

LSPでどんなことができるか (どのようなメソッドがあるか)
LSPを使った自作ツールの紹介
Language Serverとやりとりするサンプルコードと仕組みの解説
Compiler APIとLSPの比較

推論された型の移植性エラーTS2742に挑む

TypeScriptには多くのエラーが存在しますが、中でもTS2742エラーは理解しづらいものの一つです。このトークでは、TS2742エラーはなぜ起こるのかと、その解決方法について具体的な事例を交えながら紹介します。

TS2742エラーのメッセージ例:
'hoge'の推論された型には、'<foo module>'への参照なしで名前を付けることはできません。これは、移植性が無い可能性があります。型の注釈が必要です。(TS2742)

このエラーは、型推論によって導かれる型がプロジェクト内で明示的に参照されていない場合に発生します。特に、pnpmのようなフラットでないnode_modulesを生成するパッケージマネージャーを使用している場合に見られます。しかし、エラーメッセージだけではその解決方法が簡単には分かりません。本トークでは、このエラーが発生する状況の具体例と共に、ユーザ側及びライブラリ側で取れる解決策を紹介します。

TSConfig Solution Style & subpath imports でファイル単位で型を切り替える

Node.js の subpath imports を使うと特定の条件下において参照されるモジュールを切り替えることが可能になるため test や Storybook でモックする手法としてたびたび紹介されます。

ニッチではありますが、特定ファイルでのみ型の参照を切り替える方法として TSConfig の Solution Style と組み合わせて開発者体験を向上させた事例をご紹介します。

具体的には gql.tada による Fragment Colocation が Storybook 体験を複雑化させてしまう問題に対して、.stories.tsx ファイルでは fragment masking を解除させることで型をシンプルにし、Story によってはコード量を25~30%削減させることに成功しました。

主要ライブラリの実例に学ぶ、TypeScriptで実現する型安全な座標定義

位置情報技術において、緯度・経度は欠かせない要素ですが、その扱いには誤入力や不整合のリスクが伴います。例えば、緯度・経度の順番の誤りや、座標系の次元数の誤認などが挙げられます。本セッションでは、Leaflet、Turf.js、geolib など主要ライブラリが採用している、オブジェクト型、タプル型、ユニオン型、オーバーロード関数などを活用した型安全な座標定義のアプローチを解説します。各ライブラリがどのように座標定義を実現しているかの具体例とともに、柔軟かつ堅牢な設計のポイントやエラー防止の工夫についてご紹介します。

コンポーネントライブラリで実現する、アクセシビリティの正しい実装パターン

WAI-ARIA属性はリッチなアプリケーション作成を可能にしますが、誤用すると、スクリーンリーダーなどの支援技術で情報が正しく伝わらず、ユーザビリティを著しく損なうことが頻繁に発生します。

SmartHRでは、コンポーネントライブラリを用いてアクセシビリティの実装を隠蔽し、TypeScriptの型定義を活用することで、WAI-ARIA属性の値や組み合わせを制限し、開発者が意図しない誤用を開発時に防ぎます。このコンポーネントライブラリを利用することで、開発者はアクセシビリティについて深く理解していなくても、容易にアクセシブルなサービスを構築できます。LTでは具体的なコンポーネントの実装例や、アクセシビリティを考慮したコンポーネント設計の思想を紹介します。

この発表は、アクセシビリティに関心のあるフロントエンドエンジニアや、Web サービスのアクセシビリティ向上に取り組む方を対象としています。コンポーネントライブラリ導入による開発効率向上、アクセシビリティ担保の容易さ、そして運用上の課題や注意点などを、実例を交えて紹介します。

AWS LambdaをTypeScriptで動かして分かった、Node.jsのTypeScriptサポートの利点と課題

Node.jsがv23.6.0からTypeScriptを標準でサポートするようになり、おそらくv24.xにて正式展開されることと思います。
また現在、クラウド（特にサーバーレス）でAWS LambdaやAzure FunctionsなどのFaaS(Function as a Service)を使用するケースも多いと思いますし、FaaSにTypeScriptを採用することでトランスパイルやモジュールシステム(ESM/CJS)の問題から解放されることが想定されますが、本当にTypeScriptを直接実行することで何の問題もなくなるのでしょうか？

そこで本セッションでは、AWS Lambdaでカスタムランタイムを使いTypeScriptを直接実行した経験を元に、Node.jsでTypeScriptを直接実行することの利点、及び課題や問題点について紹介したいと思います。また実際にFaasにTypeScriptを採用した場合の問題点についても、私の実体験を元にAWS Lambdaを例に説明したいと思います。

fast-checkとneverthrowのPBT+Result型で堅牢なビジネスロジックを実現する

トークの主題
本セッションでは、サーバーサイドTypeScript開発におけるビジネスロジックの堅牢性向上を目指し、fast-checkによるプロパティベーステスト(PBT)と、neverthrowのResult型を組み合わせた手法について解説いたします。従来のテストに比べて幅広いパターンをテストしつつ、Result型で確実にエラー処理を強制する方法をコードを交えてお話しします。

トークの背景
Web開発において、ビジネスロジックのテストやエラーハンドリングは、信頼性を高める上で重要な要素です。
元々バックエンドの開発言語としてPythonを採用していましたが、TypeScriptへの移行を検討し、TypeScriptの型システムを活用して、ビジネスロジックの品質保証を強化する方法を模索しています。
Typescriptの柔軟かつ強力な型システムはビジネスロジックの信頼性を高めるための有力なツールとなり、動的言語であるRubyやPythonに比べて、型レベルでの品質保証が可能となります。
今回はTypescriptによるビジネスロジックの品質保証をさらに強力にするのPropetry-based Testing(PBT)とResult型を組み合わせた手法を紹介します。
fast-checkを用いたPBTは、多種多様な入力ケースを自動生成することで、隠れた不具合を網羅的に検出する効果が期待されます。一方、neverthrowのResult型を導入することで、エラー処理を明確にし、例外処理の乱雑さを解消できます。

トーク内容
fast-checkとPBT
PBTと従来のテスト手法との比較
fast-checkの概要と基本的な使用方法
neverthorwとResult型
Result型によるRailway Oriented Programmingの概念
neverthrowのResult型の活用
エラー分岐や例外処理を明確にするための実装パターン
fast-checkとneverthrowを組み合わせた具体的なコード例
今後の展望とさらなる応用可能性の検討

Interface vs Types 〜型推論が過多推論〜

通常の業務において、typeとinterfaceの使い分けは必要ないと思っていました。
実際の開発現場では、基本的にtypeを使用する人が多いかなという印象です。

型において、interfaceの方がパフォーマンスがいいですが、これが求められるというシーンはそうそう起こりません。
しかし、typeの交差型を使用して全てがanyになるという事態が発生しました。
主に具体事例、interfaceとtypeをついに使い分ける日がくるとは…というライトな内容で発表しようと思っています。

Wasmを用いて他言語資産をTypeScriptで活用する

本発表では、WebAssembly（Wasm）の基本概念や実行環境、クロスプラットフォーム対応といった特性に注目し、異なる言語で実装されたライブラリや資産を効率的に統合する方法について紹介します。近年、システム間の相互運用性や資産の再利用が重視される中、Wasm Interface Types（wit）を用いることで、ホスト環境とWasmモジュール間に型安全なインターフェースを構築し、従来は別々に管理されていたコード資産の連携を容易にする仕組みが実現されています。さらに、witから自動的にTypeScript用の型定義を生成するツール「jco」を取り上げ、他言語で記述されたライブラリをWasmとwitを介してTypeScript環境で活用する方法を紹介します。多くのTypeScript実行環境がWasmランタイムと連携している現状を踏まえ、既存資産の再利用による実装上のメリットや注意点についても言及し、Wasm活用の普及と他言語資産統合の可能性を探る内容となっています。

型パズルを好きになるために、競プロを型システムだけで解いてみることにした

TypeScript の型システムに興味を持ち、「type-challenges」で学ぼうとしましたが、思ったよりも難しく、すぐに挫折してしまいました。しかし、私は競技プログラミングが好きで、アルゴリズムを解くのは得意です。そこで「型パズルを競プロのように解けば楽しく学べるのでは？」と考え、TypeScript の型システムだけを使って競プロの問題を解いてみることにしました。

TypeScript の型システムはチューリング完全であり、本質的にはプログラミングが可能です。型の推論や再帰型を駆使することで、典型的な競技プログラミングの問題を解くことに挑戦しました。本セッションでは、その試行錯誤の過程を共有しながら、型レベルプログラミングの面白さと難しさをお伝えします。型パズルを学ぶのが難しいと感じている方に向けて、新しいアプローチを提案できればと思います。

タイプレベルリファクタリング奮闘記〜この「型パズル」は読めません！〜

業務でいわゆるDataGridを型安全に定義できるユーティリティを作成した発表者。しかし、型の推論を頑張りすぎて型の記述だけで300行を超えるようになってしまう。チームのメンバーには「ちょっとこの型は読めないですね」と言われてしまい、発表者自信もこれからメンテナンスできるのかが不安に……。
そんな事態から、メンテナンスしやすい型にするためにやったことを話します。例えば、以下のようなことを話す予定です。

型のテストを書き、安心して変更できるようにする
型から値に複雑性を移す
コメントの書き方を工夫する
生成AIを使って型をリファクタリングする

2025/05/23 Room: レバレジーズ

スキーマと型で拓く Full-Stack TypeScript

Full-Stack TypeScript はフロントエンド・バックエンドを統一し、素早いプロダクト立ち上げを可能にします。しかし実際には、プロダクトが複雑化するにつれて適切な境界設計が難しくなり、開発スピードや拡張性が失われるケースも少なくありません。このトレードオフを乗り越ていくにはどのような設計戦略が必要でしょうか？

SANUでは、IoT連携による鍵管理や多様な課金モデルを含む複雑なサービスを、短期間でノーコードから内製化しました。私たちが選んだのは、「スキーマ」と「型」を中心に据えた戦略的な境界設計です。

GraphQL スキーマを軸にフロントエンドとバックエンドを疎結合化しつつ、コード生成によって最小限のオーバーヘッドで開発できるアーキテクチャを実現。更に Full-Stack TS ならではの単一プロセスによる実行や In-Process GraphQL を活用することで、運用のオーバーヘッドも最小限に抑えられることが分かりました。

本発表では、2010年代の Web サービス開発の知見を踏まえて、スキーマ駆動の Full-Stack TypeScript で速さと持続的スケールを実現する方法を紹介します。

SignalとObservable―新たなデータモデルを解きほぐす

近年Webフロントエンドの文脈で台頭しつつある Signal（シグナル）という概念をご存知ですか？ECMAScriptへの標準化の提案も出ているほどですが、実はSignalの歴史は長く、その文脈は数十年前から存在します。それがなぜ最近になって注目されているのでしょうか。また、同じくWeb標準には Observable という概念も組み込まれつつあります。おなじみの Promise との間にどのような関係があるのでしょうか。これらをWebフロントエンド開発におけるReactivity（リアクティビティ）をキーワードにしながら考えていきます。題材として具体的なライブラリ・フレームワークの内容にも触れますが、予備知識は必要ありません。

対象
GUIプログラミングの話題が好きな人
Webフロントエンドの話題が好きな人
アウトライン
Signalとは何か
ReactivityとSignal
Observableとは何か
ObservableとPromise
ObservableとSignal

TSConfigからTypeScriptの世界を覗く

TSConfigはプロジェクトのTypeScriptの振る舞いを規定するものです。
しかしながら、TSConfigのオプションは無数に存在していることや、一度設定してしまえば特に問題なく動作することからしばしばその存在を軽視されがちです。
TSConfigを理解し、適切に設定すれば、TypeScriptそれ自体の理解を深めることやソフトウェア開発の安全性の向上に繋がります。
また、TypeScriptのアップデートに伴い、設定可能なオプションも追加され続けているため、キャッチアップも重要になります。

本セッションでは、TSConfigの各種オプションの紹介を通してTSConfigの魅力を再発見し、TypeScriptへの理解に寄与することを目標とします。

学生でもここまで出来る！ハッカソンで爆速開発して優勝した話

みなさんは，おそらく実務などでじっくり腰を据えて開発することが多いでしょう．
そういう開発では当然TypeScriptは活躍します．
ですが，短期間で大量のコードを書くことが迫られるハッカソンではどうでしょうか？
一般に，TypeScriptはJavaScriptと異なり型付き言語で，エラーが発生しやすく処理量も増えるため，速度が求められる開発では避けられる傾向にあります．
今回は，JPHACKS 2024優勝チームが，ハッカソンにてTypeScriptを用いて開発した体験談を踏まえて，短期開発におけるTypeScriptの利点を語ります．
これにより，TypeScriptの利便性をより明確にし，より幅広い場面でTypeScriptが使われるようになることを目指します．

『Python→TypeScript』オンボーディング奮闘記

トグルホールディングスではTypeScriptを中心にプロダクト開発を行っています。私はメンターとして、Pythonエンジニアのオンボーディングを担当しました。動的型付けに慣れたエンジニアが静的型付けを前提とした環境に移行する際、型定義の方法やコンパイルエラーへの対応に苦労するケースが少なくありません。本セッションでは、メンター経験を通じて頻繁に直面した課題や具体的なトラブル事例を挙げ、それらを解決に導く効果的な指導法やアドバイスをお伝えします。異なる言語間のギャップを埋め、スムーズに新たな開発環境へ適応するための実践的なノウハウを紹介します。

転生したらTypeScriptのEnumだった件～型安全性とエコシステムの変化で挫けそうになっているんだが～

「…ここは、一体？」

気づけば俺は、TypeScriptのEnumとして異世界転生していた。与えられたのは名前付き定数を表現する力「列挙型」。
しかし型安全性を重視する世界において、Union型とconst assertionsたちが我が物顔で闊歩し、俺の居場所を奪っていくのであった。

可読性と保守性を高めるために生まれたはずの俺が、今や時代遅れの遺物扱い。
さらに追い打ちをかけるように、Node.jsの「--experimental-strip-types」とTypeScriptの「--erasableSyntaxOnly」のオプションたちが、存在そのものを消し去ろうとする。

「このままでは…このままでは俺は消えてしまうのか…？」

それでも俺は諦めない。同じように居場所を失いかけている仲間たちと共に、俺は立ち上がる。型安全性、エコシステム、そして自身の存在意義についてを考える旅が今始まろうとしていた…。

この発表ではTypeScriptにおけるEnumが辿ってきた歴史とその苦境についてを解説していきます。聴者がEnumを使うことを改めて見つめ直すような内容を提供いたします。

URLPatternから始めるWebフレームワーク開発入門

URLPatternはURLによるルーティングパターンを作成することができる新しいWeb APIの1つです。Interop 2025の重点領域にも選ばれ、将来的に全てのブラウザ、ランタイムで動作することが予想されます。

本LTでは、URLPatternを用いてHono、Expressのような軽量Webフレームワークを作りながら、URLPatternとTypeScriptの活用についてご紹介いたします。HTTPメソッド、URLパターンにおけるマッチング処理と、型推論によるパスパラメータの取得のやり方、URLPatternの特徴とテンプレートリテラル型を使った型推論の活用に着目してお話しします。また、Web標準なAPIを用いて開発を行うことで、不要なパッケージに依存しない開発が行える可能性について示します。

TypeScriptエンジニアがAndroid開発の世界に飛び込んだ話

Webフロントエンド開発とAndroidネイティブ開発は一見まったく異なる世界に思えますが、TypeScriptとKotlin、Web FrontendにとAndroid Appには驚くほど多くの共通点があります。本セッションでは、バックエンドおよびフロントエンド開発を15年経験し複数の言語環境を経験してきたエンジニアが、Androidアプリ開発に挑戦した経験を共有します。複数の言語パラダイムを渡り歩いてきた視点から、両言語の類似パターン、設計思想の共通点、そして相違点から学んだ貴重な教訓を紹介し、Web Frontend領域のエンジニアにAndroidアプリ開発の敷居を下げられるようなお話をします。

Valibot Schema Driven UI - ノーコードWebサイトビルダーを実装してみよう！

近年 Bubble や Webflow、日本だと STUDIO などのノーコードプラットフォームが注目を集めています。これらのツールは、プログラミングの知識がなくてもユーザーが思い思いの UI を構築できる機能を提供し、アプリケーション開発の民主化に貢献しています。

このようなノーコードでユーザーが自由に UI を組み立てる仕組みはどのように構築されているのでしょうか。一見複雑に見えますが、基本的な考え方を理解すれば独自のエディタを構築することは難しくありません。アーキテクチャの中核となるのは、動的な UI コンポーネントを表現するスキーマ定義と、それを実際の UI 要素に変換する仕組みです。

本発表では、スキーマバリデーションライブラリであるValibotとReactを利用し、型の力を最大限に活用して動的なUIを作る仕組みを紹介します。

Rust製JavaScript EngineのTypeScriptサポート

近年、TypeScriptは広く普及し、主要なJavaScriptランタイムも対応を進めています。しかし、これらはあくまでランタイム側でのサポートであり、エンジン自体がTypeScriptを直接実行するわけではありません。

本LTでは、Rust製JavaScriptエンジン Nova におけるTypeScript実行の取り組みを紹介し、エンジンレベルでのTypeScriptサポートの可能性について考察します。

TypeScript だけを書いて Tauri でデスクトップアプリを作ろう

Tauri はデスクトップ/モバイルアプリケーションを開発できるフレームワークであり、バックエンドを Rust で、フロントエンドを JavaScript/TypeScript で記述するものとよく説明されます。しかしながら用意されている API やプラグインを使用すれば、Rust を書かずに TypeScript だけを書いても充分に実用的なアプリケーションを開発できます。そんな Tauri の嬉しさ、TypeScript オンリー開発による良さやその制限、実際に開発してみてのツラさや注意点などをお話しします。

型安全なDrag and Dropの設計を考える

Drag and Drop (DnD) は、UIにおいて直感的な操作を実現できる便利な仕組みです。しかし、その実装の自由度の高さゆえに、型安全性の確保が課題となることも少なくありません。例えば、複数の異なる種類の要素をドラッグ可能にしたい場合や、特定の要素にのみドロップを許可したい場合、あるいはドラッグ可能な要素がDOMツリー内で深くネストしているような複雑なケースでは、意図しない要素のドラッグや誤った場所へのドロップといったランタイムエラーのリスクが増大します。

本発表では、TypeScriptの強力な型システムを駆使し、このような複雑なDnDの制約を静的に表現する方法を深く掘り下げて解説します。「どのような種類の要素がドラッグ可能なのか？」、そして「それらはUIのどの領域にドロップできるのか？」といったルールを、interfaceやGenericsを用いて明確に定義し、型レベルで安全性を保証するDnD設計の手法をご紹介します。

型の力を最大限に活かし、複雑な要件にも柔軟に対応できる、拡張性のあるDnD設計を一緒に探求していきましょう！

GitHub ActionsをTypeScriptで作ろう！

主題：GitHubのカスタムアクションにはTypeScriptがオススメ

GitHub ActionsのカスタムアクションはJavaScriptしか直接動かせませんが、公式からTypeScript向けのbootstrapリポジトリやライブラリが提供されています。そのため、GitHub Actionsのカスタムアクション開発ではTypeScriptが非常に使いやすいです。

私はOSSの「GitHub Actions OpenTeremetry」をTypeScriptで開発しています。この開発を通して感じた、型安全性や開発効率の良さなど、TypeScriptを使ってよかった点を紹介します。

2025/05/24 Room: トグル

TypeScriptネイティブ移植観察レポート TSKaigi 2025

主催者講演
TypeScriptのネイティブ実装への移植は、TSKaigi 2025のプロポーザル締切直後の3/11に発表されました。発表から2ヶ月が経ち、発表直後の大盛り上がりは落ち着いて、粛々と開発が進んでいます。ネイティブ実装への移植によって何がどう変わるのかをおさらいし、GitHub上を中心として様々に明かされた経緯や展望をまとめて紹介します。

TypeScript Language Service Plugin で CSS Modules の開発体験を改善する

コンポーネントに CSS を当てる手法の1つに、CSS Modules があります。広く使われている手法ですが、エディタ上の開発体験が悪いという欠点がありました。*.tsx と .module.css の Language Server が分かれているために、.tsx と *.module.css を横断する言語機能 (Rename,Find All References ) の挙動に問題があるのです。

長らくこの問題は解決困難と思われてました。しかし TypeScript Language Service Plugin を使うと、実は解決できるのです。この発表では、TypeScript Language Service Plugin とは何か、そしてそれを使って作ったツールについて紹介します。

• TypeScript Language Service Plugin とは
• CSS Modules Kit の紹介
• Volar.js を使って .module.css を TypeScript コードに偽装する
• Navigation 機能の実装 (Go to Definition, Rename, Find All References)
• 壊れかけのファイルをサポートする
• エディタにエラーを表示するには
• Code Action と Applicable Refactor の実装

複雑なフォームを継続的に開発していくための技術選定・設計・実装 #tskaigi / #tskaigi2025

みなさんは Web アプリケーション中の複雑なフォームを開発するとき、何を考え・どうやって実装しますか？

ひとことで「フォーム」と言っても、その仕様や特性・機能によって適切な技術や設計・実装手法は変わるでしょう。
「よく使われるライブラリを使えば大丈夫」 ということはなく、そのフォームに適したライブラリや設計を選択する必要があります。
「TypeScript で書けば大丈夫」 ということはなく、TypeScript であっても効果的に利用できなければ、拡張に弱い・壊れやすいフォームとなってしまうかもしれません。

本発表では実際の複雑なフォームを持つプロダクト - ユーザが柔軟にフィールドを追加し、バリデーションを設定できるようなフォームを題材とし、その設計・技術選定・実装について紹介します。
複雑なフォームを安心して拡張していけるようにするために、どのような設計を考え、技術を比較・選択肢し、かつ拡張に強いプロダクトにするために TypeScript をどのように活用したかについてお話します。

バックエンドのコードファーストなOpenAPIスキーマ駆動開発 - TSKaigi2025

バックエンドのコードから自動で openapi.json を生成できるWebフレームワークを活用し、 「スキーマ駆動開発」を進めている社内の実践事例を紹介します。 開発の流れや、コードファーストにすることで得られたメリット、現場で工夫したポイントについてお話しします。

バランスを見極めよう！実装の意味を明示するための型定義

TypeScript には優秀な型推論の仕組みがあり、多くの型注釈を省略してコードを書いても問題なく開発が行えます。 JavaScript では一部、引数や戻り値を省略すると undefined として評価され、構文上もランタイム上もそれだけではエラーにはなりません。このように、いろいろなものを暗黙的にしたままコードを書いていても、静的型解析によりある程度の堅牢性が担保できるのは TypeScript の良いところです。 しかし、長期にわたり複数人でメンテナンスするコードベースでは、あえて明示的に書いておいたほうが良いもの（型注釈, 引数, etc.）があります。暗黙的にしておくと、将来の変更によって実装当初の前提や結果が崩れるだけでなく、それに気が付きにくくなる場合があるからです。 ダイニーではこれを防ぐために意識していることがあります。今回はその中からいくつかピックアップしてご紹介します。

PandaCSSでつくる 型で守られたスタイリング基盤

バックエンドのコードから自動で openapi.json を生成できるWebフレームワークを活用し、 「スキーマ駆動開発」を進めている社内の実践事例を紹介します。 開発の流れや、コードファーストにすることで得られたメリット、現場で工夫したポイントについてお話しします。

TSでシステムが堅牢になっていくさまをスポンサーになるたびに報告 〜型定義から始めるリファクタリング編

弊社ではNuxt ☓ TypeScriptを利用してフロントエンド開発を行っています。 開発開始から約3年ほど経過し、複雑化したコードベースを型定義を起点にリファクタリングした事例を紹介します。

技術書をソフトウェア開発する - jsprimerの10年から学ぶ継続的メンテナンスの技術

発表概要
技術書の執筆とソフトウェアの開発に、大きな違いはありません。
LLMを使って自然言語でコードを書ける/読めるようになった現在では、この違いはますます小さくなっています。
約10年・6つのメジャーバージョンを経ているJavaScript入門書 jsprimer を例に、技術書のソフトウェア開発手法について紹介します。

特に次の点を中心にお話しします。

ドキュメントとコードの自動テスト - textlintやpower-doctestなどのTypeScriptで書かれたツールでの自動テスト
ECMAScript年次更新への追従プロセス - 言語仕様の変化に合わせた計画的な更新手法
ドキュメントに対するDesign Doc - 文章を書く前に文章の設計をソフトウェア開発のように行う方法
コミュニティ貢献を促す仕組み - 累計で100名以上のコントリビューターが参加するjsprimerの運営方法/Open Collectiveの設計
「TypeScriptは型を消せばJavaScript」と言われるように、TypeScriptとJavaScriptには密接な関係があります。
この発表では、TypeScriptの基盤となるJavaScriptの学習リソースがどのように持続的に更新されてきたか、その技術的な工夫をお話しします。

技術書は、ソフトウェアと同様に適切な設計・開発・運用プロセスを持つことで、長期的なメンテナンスと進化が可能になることについて、約10年間の具体的な実践例を通してお伝えします。

対象者
TypeScript/JavaScript開発者：更新され続ける言語仕様に追従する方法について知りたい方
技術書籍・ドキュメント作成者：継続的に更新される技術文書の作り方を知りたい方
OSSメンテナー：ドキュメント中心のプロジェクト運営、コントリビューター獲得に悩む方

ts-morphで、人間も編集できるコード生成を実現しよう！

概要

/* This file is auto generated. Do not edit manually */

というコメントに見覚えのある方は多いのではないでしょうか。

このセッションでは、自動生成したコードと、プログラマが書いたコードを両立させるアプローチについて説明します。

背景と内容

昨今、OpenAPIなどのスキーマファイルからコードを生成するアプローチはポピュラーなものとなっています。

しかし、クラスを使ったアプローチをするフレームワーク・言語と違い、私が業務で利用している Fastify は生成したコードを人の手で編集したい要求があります。

// ここのテンプレート部分は自動生成したい
server.post("/hoge", hogeSchema, async (req) => {
  // 関数呼び出しの中身は、自分で実装したい & 次生成した場合に消えたら困る。
   someLogic(req.body.id)
})

1つのファイルの中で、「自動生成したいコード」と「人の手で編集しコード生成時にも消してほしくないコード」が入り混じることになります。これは、従来のトップダウンなコード生成では実現が難しく、現状の実装を解析し、必要な部分だけ再生成する戦略が必要です。

今回は、この解析部分と自動生成部分にts-morphを利用し、自動生成と手動編集を両立させる方法を扱います。

対象

• コード生成に興味がある方
• ASTに触れてみたい方
• Fastify・Expressなどを利用したバックエンド開発を効率化したい方

機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

フロントエンド開発におけるコンポーネントの共通化や分割は、保守性や拡張性の観点で重要です。しかし、過度な共通化や粒度の細かすぎる分割は、可読性や変更容易性を損ない、結果として開発効率を下げてしまうこともあります。

本セッションでは、「機能的凝集」という観点から、コンポーネント設計の適切な粒度と分割の判断基準について実践的に紹介します。特に、ts-pattern や TypeScript のジェネリクス型を活用し、型の恩恵を受けながら機能的凝集を実現する手法にフォーカスします。

登壇者のチームでは、複数ロール・多機能を持つシステムにおいて、関心ごとや機能的責務が重なるコンポーネント群をどのように意味のある単位へ構造化するかについて議論・検証してきました。設計の選択肢が豊富だったプロジェクト立ち上げ期の経験をもとに、以下のようなパターンと改善例を紹介します：

• ロールごとに異なる画面構成
• 新規作成画面と編集画面などの類似ページ構成
• コンポーネント内部の部品単位での差分
• 表示アイテムの種類に応じたList構成の違い
• 差分が最小限の場合と複数箇所に波及する場合の対処法
• 差分の分岐ポイントがルーティングか、取得データかの違い

これらのパターンをもとに、論理的凝集から機能的凝集への改善プロセスを具体的なコード事例とともに紹介します。

本トークを通じて、機能的凝集を前提としたコンポーネント境界の設計判断を議論するための共通言語を提供し、プロジェクトごとの制約に応じた設計意思決定の一助となれば幸いです。

TS特化Clineプログラミング

今現在、我々プログラマは TypeScript とプログラミングのドメインエキスパートとして、LLMに形式知やワークフローを叩き込む必要があります。

モデル性能は向上していますが、汎用プロンプトだけではコーディングエージェントの力を引き出せているとは言えません。

自分は次のような実験によって、TypeScript によるプログラミングの自動化を試みています。

• deno によるプロトタイピング
• コンテキスト境界を最小化するモジュール設計
• npm ライブラリのサマリの自動作成
• 型シグネチャファーストな設計
• TDDによる実装

Cline と TypeScript を通してAIプログラミングの未来を考察します。

型がない世界に生まれ落ちて 〜TypeScript運用進化の歴史〜

5年前、私たちのプロジェクトではJavaScript or flowがコードベースの大部分を占めており、フロントエンドにはTypeScriptの厳密な型が導入されていませんでした。

そのため、型の恩恵を十分に受けられず、運用面での課題が多くありました。

しかし現在、最も開発が活発なリポジトリはTypeScriptオンリーとなっており、ts-ignoreもほとんど存在しない状態になっています。

さらに、フロントエンドのテストカバレッジも90%近くに達しており、型の厳密性とテストの充実が相まって、より堅牢な開発環境が実現されています。

ただ「型安全なコードが理想だから」といった議論だけでは、このような健全なコードベースは実現できませんでした。

現場では、どのように周囲を巻き込み、組織として継続的に運用していくかが重要なポイントとなります。

本発表では、5年前とのBefore ~ Afterの経緯を組織論の視点も交えながらお話しします。TypeScriptの運用に悩んでいる方、型安全なコードベースを目指しつつも組織の壁にぶつかっている方にとって、実践的な知見を共有できればと思います。

Type ChallengesにPRを出して新しい問題を追加した話

みなさんはType Challengesをご存知でしょうか？

Type ChallengesはTypeScriptの型システムをハンズオンで学べるOSSリポジトリです。

型の問題がたくさん用意されており、それを解いていくことでTypeScriptの型システムについて学ぶことができます。

私自身もType Challengesを通じてTypeScriptの型システムについて学び、楽しんでいました。しかしそれだけでなく、他の人の学びになるような問題を追加したいと思いPRを出してみました。

結果としてはマージされ、新たな問題として追加されました。

https://github.com/type-challenges/type-challenges/issues/35252

そこでこの発表では、

・Type ChallengesにPRを出すまでにしたこと

・実際に作った問題の解説とポイント

などについてお話しさせていただこうかと思います。

ProxyとTypeScriptのおいしい関係

本発表では、ReactのフォームライブラリであるConformを題材に、Proxyによる動的なプログラミングにTypeScriptの型を被せることで優れた開発体験が得られることを見ていきます。

Proxyはオブジェクトに対する操作をインターセプトできるデータ型で、ECMAScriptの標準です。

Proxyを使えば、例えばあるオブジェクトのプロパティに対するget操作にログ出力などの処理を挟むことができます。

しかしConformでは、空オブジェクトをProxyでラップし、プロパティアクセスを全て動的に生成する、という大胆なことをしています。

一見このような動的なプログラミングとTypeScriptは相性が悪そうですが、

ConformはむしろTypeScriptの型を存分に活かした開発体験を提供しています。

本発表では、その点についてConformのサンプルコードや内部実装を追いながらお話します。

https://conform.guide/

Panda-CSS はどのように型安全にしているのか

Panda-CSS は型が効く Tailwind という印象を持たれていることが多いように思います。実際、Tailwind と同じような記法で型安全に実装することができるわけですが、どのような方式で型安全にしているのか、というテーマで簡単にお話ししようと思っています。

お話しする内容の詳細について記載します。Panda-CSS では、定義ファイル（panda.config.ts）に対してカラーバリエーション等の定義をします。この定義ファイルが元となり、型定義ファイル（.d.ts）が出力されています。出力された型定義ファイル（.d.ts）は、ユーティリティ関数の引数等の型定義に使用されており、開発ではユーティリティ関数を使用するため、型安全に実装することができます。Panda-CSS 以外にも型安全にCSSを実装できるライブラリとして stitches などがありますが、Panda-CSS は事前に定義ファイルから型定義を出力する部分が他のライブラリの異なる点であり、これによって型推論にかかるコストを抑えることができています。ただ、この方式にもデメリットはあり、事前に型定義を出力する、という開発のための事前準備が必要になっています。型を効かせて実装を進めるために、どのタイミングで型に関するコストを支払うか...という問題に帰着します。

また、型定義ファイル（*.d.ts）の出力の仕組みについても、シンプルな実装で実現されているため、Panda-CSS のライブラリの実装を見つつ簡単にお話しします。

（参考：Panda-CSS の型定義の出力の実装）

2025/05/24 Room: アセンド

フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない

プロダクト開発において、フロントエンドとバックエンドをTypeScriptで統一することは、型共有や開発効率の向上といった多くのメリットがあります。しかし、プロジェクトやチームによっては他の選択肢も有効です。本トークでは、バックエンドにPHPを採用するという選択肢について、PHPのエコシステムや開発サイクル、アーキテクチャやデプロイ手法などを通じて、TypeScriptではないバックエンドを持つことの魅力を紹介します。また、PHPエンジニア目線から見たTypeScriptとの組み合わせによる実践的な開発フローやバックエンド、フロントエンド分離案を提案します。本トークを通じて、言語に閉じない多様な視点を提供します。

Pragmatic Functional Programming in TypeScript

関数型プログラミングを学んでも、実務での活用方法に悩む方は少なくありません。純粋関数、イミュータブルな値、モナドなどの概念を、具体的なコードにどう落とし込むかが明確でない場合が多いからです。

そこで本セッションでは、Dmitrii Kovanikov 氏の提唱する 5 つの原則（Parse, don’t validate／Make illegal states unrepresentable／Errors as values／Functional core, imperative shell／Smart constructor）を「事前条件」「事後条件」「不変条件」という Design by Contract の視点で再構成し、TypeScript による実装例とそのメリットを解説します。

加えて、当社が開発している API ゲートウェイを題材に、これらの原則を戦術的 DDD に基づくレイヤードアーキテクチャに適用する例もご紹介します。バックエンド開発におけるコードの堅牢性と保守性の両立を目指すだけでなく、状態管理の複雑なフロントエンド開発でも応用可能な設計手法をお話しします。

型システムを活用した ESLint カスタムルール開発入門 〜固有ドメインにおけるコーディング規約を開発する〜

ESLint は JavaScript/TypeScript における主要な Linter として広く採用されており、その特筆する機能として、 AST を活用したカスタム Lint ルールの実装が可能である点が挙げられます。
このカスタム Lint ルールは、チーム固有のコーディング規約を自動化する強力なアプローチを提供しますが、その実装には AST への理解が求められ、多くの開発者に難易度が高い印象を与えているのではないでしょうか。

本セッションでは、AST の基礎概念から解説を始め、段階的にカスタム Lint ルールの開発方法を解説します。
また、固有ドメインに対するカスタム Lint ルールの開発アプローチとして、 TypeScript の型システムを活用した Lint ルールの開発方法を、 AWS CDK 用カスタム Lint ルールの開発経験をもとに解説します。

VueUse から学ぶ実践 TypeScript

トークの主題
VueUse（Vue.js用の人気ユーティリティライブラリ）のコードベースから、TypeScript の型機能の実践的な使い方を紹介します。
TypeScript の基本を理解している方を対象に、実際のOSSから学べる型システムの利用例をお伝えします。

発表内容
VueUse の以下の2つの関数に注目し、実際のコードを通じてその活用方法を解説します。

useClipboard
関数オーバーロードと Conditional Types の連携

useChangeCase
複数の型機能の組み合わせによる高度な型生成

型推論の扉を開く―集合論と構造的型制約で理解する中級へのステップ

TypeScript の型システムを「実行時の値の型」としてではなく、「その変数が取り得る値の集合（ドメイン）」として捉える視点を提示し、初心者から中級者へのステップアップのきっかけを作るための発表です。

TypeScript を学ぶ上で、「型」はしばしば静的なラベルのように扱われがちですが、本発表では 「型＝値の集合」 という視点を導入し、型推論や型操作を数学的な集合論の観点から解説します。

TypeScript ASTとJSDocで実現するコードの自動削除

TSKaigi 2024でTypeScriptのASTに触れたことをきっかけに、ASTを実際の業務で活用してみました。

私の業務ではプロダクトへの機能追加の際にA/Bテストをよく実施しており、テストの結果、企画が棄却された場合は実装したコードを削除します。
TypeScriptのASTとJSDocを組み合わせることで、不要になったコードの一部を機械的に検出し、安全に削除する仕組みを実現したので、その紹介をしようと思います。

次のような流れでお話しする予定です。

自動化に至った背景と課題
ASTとJSDocを組み合わせた課題解決のアプローチ
今後の展望

これは型破り？型安全？真実はいつもひとつ！（じゃないかもしれない）TypeScriptクイズ〜〜〜〜！！！！！

TypeScriptの最大の強みであると言っても過言ではない型システム、時に役に立ち、時に開発の効率を下げてしまうこともあるかもしれません。
実際の現場で出会いそう or 出会った or そんな使い方しねーよ！など TypeScript の理想的な使い方や、少しクセの効いた使い方、はたまた型破りな使い方をクイズ形式でテンポよく紹介していきます！参加者が実際にクイズに参加してもらうような形式のLTにしたいと思ってます！

題材を選んだ理由は、型安全と型破り（今回のTSkaigiのテーマ）という二つのアプローチを実際に使い分けることで、開発者がこれから出会うであろうコードや一生見ないようなコードを紹介することで、セッションに参加していただいた皆様のこれからのTypeScriptの使い方をより効率的に活用するための知識を提供したいと考えたからです。
クイズ形式で進めることで、参加者が積極的に学びながら楽しめる内容にし、型の概念や実践的な技術を自然に理解してもらうことを目的としています！

Lookback TypeScript ESM support and what should we do now.

TypeScriptのESM（ECMAScript Modules）サポートは、JavaScriptとその周辺エコシステムのESM対応と共に進んできました。

一方でこれはJavaScriptとそのエコシステムが持つモジュールシステムの複雑さをTypeScriptが同じように引き継いでしまっているとも言えます。実際これまで段階的に行われてきたTypeScriptのESMサポート機能は単純ではなく、特に初学者やJavaScriptのモジュールシステムに詳しくない人にとっては理解しづらいものになっています。

本セッションでは、JavaScriptのモジュールシステムの基礎的な部分から始め、TypeScriptにおけるESMサポートの歴史と現状を整理します。さらにESM移行への課題とその解決策、ユースケースに応じた設定の例などを紹介することで、実際のプロダクトへ活用できる内容とします。

"良い"TSのコードを書く為のマインドセット

概要：
Run time時における型の正確性がクオリティに直結するTypeScriptにおいて、重要ですがマイナーな概念であるSoundness(サウンドネス)を紹介することでTS上で良いコードを書くためのマインドセットを紹介します。

説明：
プログラミングにはType Soundness(型の健全性)という概念があります。これは端的に説明すると実行時にコード上で書かれた型が保証されているかということを示す言葉です。

O’Reilly社の"Learning TypeScript"の著者、Josh Goldberg氏はその書籍内でTypeScriptの型システムをStructurally typed(構造的)と表現しています。これは型の構造に相互性があれば受け付けてしまうというTypeScriptの型システムの動きに起因しています。

このトークでは、構造的型システムによって引き起こされるありがちなTypeScriptの直感に反した動き(readonly周り等)を紹介しつつ、Soundnessという概念の重要性を伝えたいと思います。

令和最新版TypeScriptでのnpmパッケージ開発

令和7年になりほとんどのソフトウェアエンジニアはnpmパッケージの開発にTypeScriptを採用する時代になっています。

しかしnpmパッケージの作成は歴史的背景から仕組みが複雑化し、ベストプラクティスも日々変化しています。

この登壇では、tsc/rollup/esbuildなどのバンドラツールの選定基準やESMに関する設定やTypeScriptでの開発体験向上に寄与するIsolated Declarationsなどtscのオプションを中心に令和最新版のnpmパッケージ開発に必要な知識や設定を共有します。

キーワード:

tsconfig.json
Pure ESM package
provenance
Isolated Declarations
erasableSyntaxOnly

コンパイルオプションで変わる型世界

TypeScriptを使っている皆さん、tsconfig.json のコンパイルオプションを意識したことはありますか？多くのプロジェクトではすでに設定されており、普段触る機会は少ないかもしれません。しかし、コンパイルオプションの設定次第でTypeScriptの型安全性が大きく変わることを知っていますか？

今回は、あえてTypeScriptのコンパイルオプションをオフにし、TypeScriptの機能を1つずつ剥がしていく ことで、「どの設定が型安全性を担保しているのか」を部分的に体感してもらいます。

TypeScriptをもっと活用するために、ぜひこの機会にコンパイルオプションを見直したり、学びましょう！

TypeScriptのmoduleオプションを改めて整理する

本発表は、TypeScriptにおけるmoduleオプションについて、その基本的な役割と設定時に注意すべきポイントを体系的に整理します。

moduleオプションは、TypeScriptが出力するモジュール形式を指定するための重要な設定項目であり、ESModuleやCommonJSの違い、Node.jsにおける実行時の挙動、さらにはビルド結果の違いを正確に理解しておかねば、意図しないトラブルに見舞われるリスクが高まります。

そこで、発表では実際に私が遭遇したトラブル事例をもとに、moduleオプションがもたらす挙動の微妙な違いとその影響を解説し、さらにTypeScript 5.8で導入されたnodenextの仕様変更がどのような影響を及ぼすのかについても触れます。

主な対象は、日常的にTypeScriptを活用している開発者で、特にtsconfig.jsonの設定に携わる機会のある方々です。基本的なTypeScriptの知識があれば参加可能な内容となっています。

発表を通じて複雑なmoduleオプションに対する苦手意識を払拭し、基礎知識と最新の挙動を理解する方法を知ることで、自信をもって設定に臨めることを目指します。

Project Referencesを活用した実行環境ごとのtsconfig最適化

本セッションでは、実行環境に合わせて tsconfig を最適化する手法を解説します。

1 つの tsconfig ですべてを実装すると、ブラウザ向けコードで Node.js のライブラリを誤って使用したり、サーバー向けコードで window にアクセスしてしまったりしても気付けないといった課題が生じます。
さらに、対応ブラウザに合わせて target や lib を古いバージョンに設定すると、サーバー内や開発時のみで動くコードにおいても最新のメソッドが使えず、逆に ESNext を指定すると古いブラウザで動かないメソッドを使ってしまうリスクが発生します。

こうした課題を解消するために、Project References を駆使して複数の tsconfig を使い分け、各環境に最適化する具体的なアプローチを紹介します。

2025/05/24 Room: レバレジーズ

TypeScriptとVercel AI SDKで実現するLLMアプリケーション開発：フロントエンドからバックエンド、そしてChrome拡張まで

LLM（大規模言語モデル）を活用した開発においてはPythonが主要なプログラミング言語として広く認知されていますが、TypeScriptにもVercelが開発するOSSのAI SDKという便利なツールキットが存在します。このAI SDKを利用することでTypeScriptでもLLM関連のアプリを比較的簡単に作成できることをお伝えしたいと思います。

本発表では、AI SDKの基本機能から応用事例までを紹介します。AI SDKは、Azure OpenAI、AWS Bedrock、Google CloudのVertexAIなど、多様なベンダーのLLM推論APIの呼び出しを統一的なインターフェースで扱うことが可能です。AI SDKがベンダー間の差異を吸収してくれるため、開発者は使用するLLMを柔軟に切り替えることが容易になります。

さらにUIフレームワーク向けの機能も提供されており、例えばReact向けのuseChathooksを利用することでよくあるチャット型のUIを比較的簡単に実現可能です。このようにAI SDKを利用することでフロントエンドとバックエンドをTypeScriptで一貫して開発可能です。

サイボウズでは、実際に社内用チャット型LLMアプリをNext.jsとAI SDKを用いて開発していますので、インフラも含めたアプリの構成例を紹介いたします。

さらに応用事例として、手元のMacBook上で動かすローカルLLM + AI SDKによるオフラインでも動作するChrome拡張機能の作り方も紹介したいと思います。

注：本発表ではプラットフォームとしてのVercelの話はありません

feature flag 自動お掃除のための TypeScript プログラム変換

feature ブランチの寿命を短く保ったり、特定ユーザ向けに機能をリリースして反応を見る A/B テストのために、feature flag という手法がよく利用されています。一方、機能のリリースや A/B テストが完了して安定化した feature flag は、積極的に削除しなくともアプリケーションの動作に直接的な問題がないため、削除されずに負債化する可能性があります。
本発表では、保守的なデッドコード除去で削除することが難しい安定化した feature flag を、よりアグレッシブな手法で削除する方法、実装、実際のコードベースに適用したときの効果について説明します。

この実装では TypeScript の静的解析と構文木の操作を通じたソースコード編集といったプログラム変換を用います。この発表を通じて、プログラム変換の楽しさと業務における可能性を感じて欲しいと考えています。

Web Streams APIの基本と実践、TypeScriptでの活用法

ストリームはデータを効率よく低遅延に処理する方法として、多くの言語でインターフェースが提供されています。
Web標準でも2015頃からStreams APIが整備され、Fetch APIのレスポンスボディもストリームオブジェクトになっています。

しかし、Streams APIを直接利用している方は少ないように思います。これは活用方法が十分に知られていない、もしくはより昔からあるNode Streamのように扱いが難しいと思われていると、想像しています。

Web Streams APIはインターフェースが簡潔になり、型情報も整備されているため、TypeScriptからも扱いやすいものとなっています。
このセッションではそんなWeb Streams APIの基本概念や利用シーンなどをお話しします。
Node.jsのStreamとの違いや、Async Iteratorとの関係性についても触れていきます。

アウトライン
Web Streams APIの概要
独自のストリームオブジェクトを定義する
ストリームによる逐次処理の具体的な用例
Node.jsのStreamとの違いと互換性
Async Iteratorとの相互運用性

Result型、自前で書くか、ライブラリ使うか

関数型ドメインモデリングの影響もあり、TypeScriptでResult型を使って、失敗する可能性がある関数を明示的に取り扱う方法が普及しつつあります。しかし、TypeScriptには組み込み型でのResult型は存在しないため、自前で型定義をするか、ライブラリを利用する必要があります。fp-ts、neverthrow, Effect.jsといったライブラリと自前での実装の方法について比較しながら解説します。

型付け力を強化するための Hoogle のすゝめ

TypeScript を使って開発を進める中で、「なんだか実装が複雑になってきたけど、どのように型を付けるべきだろう。そもそもこの実装は正しいのだろうか ...... 🤔」と思い悩む瞬間はありませんか？

実装の複雑さや破綻の兆候は、かなりの確度で型付けのあり方から推察できると考えています。では、そもそも型付けのあり方を学ぶにはどうすれば良いでしょうか？

この LT では、Haskell の API 検索ツールである "Hoogle" を活用し、型シグネチャを『検索』しながら、TypeScript 開発におけるより良い型の付け方や実装の整理の仕方を学ぶことを目指します。

React19で変化したuseReducerの型から学ぶTypeScriptの型推論

@types/reactのバージョン19では、React本体の変更に対する追従の他に幾つかの変更が加えられました。その中の一つとしてuseReducerの型の変更があります。

useReducerの型の変更は型推論の向上を目的として行われました。これまではuseReducerを用いるためにジェネリクスで型を保管するのが一般的でした。しかし、バージョン19からは引数から型を推論する形に変更され、ジェネリクスを用いないことがベストプラクティスになりました。
これにより、開発者が冗長な型定義を行うことを防ぎつつ、堅安全性を維持することが可能になりました。

本発表では、
・useReducerの新しい使い方
・変更の背景から学ぶ、TypeScriptの型推論の活かし方
を紹介します。

ReactのAPIに関連する内容ですが、本発表はReactのAPIを元にしたTypeScriptユーザー全般に役立つ内容となります。

クラサバ境界を失った現代 TypeScript コードベースに秩序をもたらしたい

現代の Full-Stack TypeScript 的なコードベースは、DBから UI コンポーネントに至るまで型を一貫して共有できることが多く、これは開発体験に大きく貢献しています。
一方で、クライアントとサーバーの境界が曖昧になったことで、意図しない情報の露出や、一箇所の変更による型エラーがコードベース全体に伝播して影響範囲が大きいなど、課題も抱えています。
このトークでは、いくつかの手法や設計を用いて、Full-Stack TypeScript の恩恵を得ながら、コードベースに秩序を取り戻して安全な開発ができる方法について提案します。

君だけのオリジナル async / await を作ろう

TypeScript でジェネレータ関数を使った独自の async / await ライクな記法の作り方を紹介します。

Promise を扱うときには欠かせない async / await ですが、この記法が一般的に使われるようになる前はジェネレータ関数を使って同様の記法を実現するテクニックが使われてきました。
このテクニックは今でも Promise 以外のデータに対して簡便な記法を導入する際には有効です。

この発表では (いくらか歴史を振り返りつつ) JavaScript におけるジェネレータ関数を使った async / await の実装方法と、それに対して TypeScript で型を付けるためのちょっとしたトリック、Promise 以外のデータへの適用について紹介します。
また私自身が取り組んでいる Algebraic Effects への応用など、発展的な話題にも触れられたらと思います。

想定聴衆

neverthrow や Effect などのライブラリに登場する yield* の正体が気になっている方
async / await ライクな記法を自分でも作りたい方

TypeScript製IaCツールのAWS CDKが様々な言語で実装できる理由 〜他言語変換の仕組み〜

AWS CDKとは、様々なプログラミング言語でインフラ定義を実装できるIaCツールであり、実態はTypeScriptによるOSSです。リソースの宣言方法まで全てTypeScriptで実現されていますが、ユーザーは様々な言語でリソース定義を実装できます。

本セッションではそれが可能な理由、つまりTypeScriptコードを他言語で使用できるように変換する仕組みを解説します。

この原理をAWS CDK以外にも応用することで、TypeScriptを起点にプログラミング言語の壁を超えて開発者への価値提供に繋げることができます。またAWS CDKではこの仕組みを通して、TypeScriptがたくさんの他言語ユーザーの支えになっているというTypeScriptの影響力についてもお伝えします。

TypeScript のプログラミング技法に関心のある方

ts-morph実践：型を利用するcodemodのテクニック

ts-morphを使うと大量のコードを一度に安全に修正することができることは皆さんご存知かと思います。既存のインポート名やフィールド名をまとめて修正するなどには簡便です。ts-morph自体はあくまでもASTを編集するだけですが、その真の力は、スコープ情報や型情報など、TypeScript自体が提供する機能を活用するコードを記述することによって開放することができます。そのような実用例を紹介します。

declaration mergingの威力：ライブラリアップデート時の書き換え作業を90%短縮するテクニック

TypeScriptライブラリのバージョンアップ作業は、多くの開発者にとって煩雑で手間のかかるものではないでしょうか。 ライブラリの型定義や関数定義の変更により、手作業での修正とそれに伴うエラー対応が発生し、開発効率を低下させます。

本LTでは、declaration mergingというテクニックを活用したライブラリアップデートの効率化方法を紹介します。この手法を用いることで、一定の状況下ではライブラリアップデート時の型書き換え作業を大幅に削減することが可能です。

古い型の検出から新しい型への一括置換まで、具体的な手順とその効果について詳しく解説します。 ライブラリアップデート作業の負担を少しでも軽減する参考になれば幸いです。

バリデーションライブラリ徹底比較

TypeScriptにおけるバリデーションライブラリの選定基準と比較について解説します。Zod・Typia・Valibot・ArkType等を取り上げ、型安全性、記述の簡潔さ、パフォーマンス、他ライブラリへの移行のしやすさや依存度などの観点から比較します。また、実際のコード例を交えて実用的な知見を提供します。

Standard Schema: スキーマライブラリの統一規格とは何か

近年のアプリケーション開発では、ZodやValibotなどのスキーマによるバリデーションをおこなうライブラリが注目をあつめ、ライブラリの選択肢も増えています。ランタイムでのバリデーションに加え、定義したスキーマから推論された型を利用した型安全な開発が実現できるようになりました。

しかし、それぞれのライブラリが提供する機能をつかってスキーマを定義する場合には型を重複して定義する必要がなくなった一方、独自の型をスキーマライブラリに適用する場合には、それぞれのライブラリのためのロジックやアダプタを記述することが必要な状況になっています。このような状況に対して、Zod、Valibot、ArkTypeの作者たちがスキーマライブラリの統一規格「Starndard Schema」を策定し、ライブラリ間の相互運用性を高める運動をはじめました。

このLTでは、上記の経緯を説明した上で、「Starndard Schema」によって開発者が得られる利点を解説します。