Gemcook Tech Blog
✍️

TSKaigi 2025 参加レポート #Day1

に公開

2025/5/23(金)〜5/24(土)の二日間で、東京の神田で開催されるTSKaigi 2025の参加レポートです。

私が所属している株式会社Gemcookがスポンサーもしていることもあり、会社をあげてTypeScriptコミュニティを応援しています。

https://2025.tskaigi.org/

このレポートではDay1で私が聴講したセッションの軽いまとめ&感想と、全体の感想を書いていこうと思います!(ざっと備忘録的に書いているのであしからず...!!)

TSKaigiって...?

TSKaigiとは、一言で言えばTypeScriptコミュニティのお祭りです。
世界一のオフラインのTypeScriptカンファレンスで、TypeScriptに関わる開発者、エンジニア、企業が一堂に会し、最新の技術動向、ベストプラクティス、事例共有などを行う場として2024年に始まりました。

タイムテーブル

タイムテーブルについては以下リンクの通りです。

トグルルーム」「アセンドトラック」「レバレジーズトラック」の3つのステージがあり、それぞれでセッションがあります。(見たいセッションの時間帯が被ってしまった時は、断腸の思いで何のセッションを聞くのか決断する必要があります。)

https://2025.tskaigi.org/talks?day=1

聴講したセッション

The New Powerful ESLint Config with Type Safety

by Anthony Fu

https://talks.antfu.me/2025/tskaigi/1

Anthony Fu さんはESLintのエコシステムに大きく貢献している人で、ESLintのFlat ConfigやESLintのPluginのお話がありました。紹介されたプラグインの中で特に印象に残ったのは eslint-plugin-command です。

https://github.com/antfu/eslint-plugin-command

なんとこれはコメントをコマンドとして使用して、コード変換をするプラグインです。例ではアロー関数を関数宣言に変えたいといった時に、対象のアロー関数のところに/// to-functionとコメントするだけで、コードが関数宣言に変換されました。あまりにも天才でした。

ESLintの強みは拡張性であり、最近社内ではBiomeを使用していたのですがESLintいいなあーーとなりました。

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

by progfay

https://speakerdeck.com/progfay/gao-du-naxing-fu-ke-doujiao-eru

「高度な型付けをTypeScriptに不慣れな人にどう教えるのか」というお話でした。

高度な型付けを教えるために紹介された手法として、「慣れ親しんだ言語で処理を把握してから型プログラミングレベルに置き換えていく」というものでした。例で言うと、「JavaScriptで処理の下書きを書いて、それをTypeScriptに翻訳していく」といった流れになります。

// TS: Generics
type Identify<T> = T;
// JS: 関数の引数
const identify = (t) => t;

// TS: Conditional Types
type Cond<T, U, Then, Otherwise> = T extends U ? Then : Otherwise;
// JS: if 文
if (t instanceof U) { then; } else { otherwise; }

// TS: Mapped Types
type Mapped<T> = { [K in keyof T]: T[K] };
// JS: for 文
for (const k of Object.keys(t)) { t[k]; }

JavaScriptで書くことによってデバッグができるのが嬉しい点だなと感じました!型レベルプログラミングではデバッグがやりにくいなと個人的に感じてたので、この手法は魅力的だと思いました。
ただ、セッションの中でも話になっていましたが、TypeScript独特の挙動を把握するのが難しいのだなと感じました。type-challengesなどで数こなすのも大事ですね。

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

by lacolaco

https://bit.ly/3HjMqWq

SignalとObservableという2つのリアクティブなデータモデルについて、コードの例とともにどういったデータモデルなのかというお話でした。

Signalは、Observerパターンの一つであり、状態をUIに同期するレンダリングメカニズムです。元々は関数リアクティブプログラミング(FRP)から来ており、イベント駆動のGUIプログラミングに持ち込まれたという背景があるとのことです。普段何気なく使用している状態管理などもこのような背景があったのか...!!となりました。

Observableは、複数のイベントの非同期ストリームで、元々はC#におけるIteratorパターンの拡張であるとのことです。連続入力などを時間的な連続値として配列・イテレータとして扱うといった考え方になるほどなあ...!!となりました。

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

by takanorip

https://speakerdeck.com/takanorip/bulletproof-design-system-with-typescript

90%ぐらいのエンジニアはデザインシステムのルールを守らない...
では「TypeScriptを活用して堅牢なデザインシステムを作るにはどうしたらいいか」というお話でした。

  • デザイントークンの型定義を活用する。
    • Styled Dictionaryを活用する。
    • Branded Typesを活用する。
      • SpacingとRadiusなど構造が同一だが混同したくないものを区別できる。
    • VSCode拡張を使う。
      • CSSVariables形式などの補完が効くようにする。
  • コンポーネントのProps設計を考える。
    • styleをPropsで管理する。
    • CSS VariablesをTemplate Literalで管理する。
    • エディタの機能のJSDocを活用する。
  • LLMでドキュメントを更新し続ける。
    • ドキュメントを更新しない=ドキュメントの死(激しく同意)
    • ドキュメントの更新はエンジニアとデザイナーパートが混在しているから運用が難しい。
    • だが、LLMなら両方の視点からいける。
      • コメントやJSDocがLLMで役立つので、どんどん書いていこう!

恥ずかしながら私もデザインシステムを守らない90%側の人間になる(知らず知らずに...)ので、TypeScriptに頼りながら仕組みを作ってなんとか10%側にいきたいと思います...。

AI Coding Agent Enablement in TypeScript

by Yuku Kotani

https://speakerdeck.com/yukukotani/ai-coding-agents-enablement-in-typescript

「AIコーディングエージェントを使いこなしたい!(自走してほしい!!)」というお話でした。

  • 自走させるのにポイントとなるのは、可能な限り解空間を絞ること。
    • あらゆる言語という広い解空間ではなく、プロジェクト独自の解空間にして精度を高くする。
  • イネーブリングなアプローチ
    • 型チェック
      • 今は型をちゃんと書いても精度はそこまで上がらないが、今後は上がってくるので型はちゃんと書こう!(anyなどはノイズになって精度が落ちる。)
    • Linter
      • 一度AIにフィードバックした内容をLinterに入れておくことで二度と繰り返させない。
      • フィードバックベースで、二度と繰り返させないためにAIをガン詰めする。(Linterに入れさせる。)

AIコーディングエージェントを使う時に、また同じ間違いしているわ...みたいなことがあったのですが、今後はどんどんLinterに設定を追加していこうと思いました。

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

by Sosuke Suzuki

https://zenn.dev/sosukesuzuki/articles/5146c84504445f

「TypeScriptのエコシステムの変化を全体的に話す」といった内容でした。

TypeScriptのエコシステムの2010年代後半からの大きな変化として、TSファーストな世界観が広がり、SWC、Turbopack、Vite、Rspackなど速すぎるツールたちが次々と登場しました。ただ、問題として、TypeScriptの本質の型チェッカーに関しては、Microsoft公式のTypeScriptコンパイラのみが唯一の実装であるような状況がずっと続いていました。型チェッカーの実装が規模が大きくかつ複雑であったため、Microsoftしか開発ができなかった背景があるそうです。しかし、Microsoftが直々にGoで実装を行い、型チェックも高速になります!(以下のようなポストも本日ありました。)

https://x.com/typescript/status/1925569825306464534

今後は、特にバックエンドではビルドレイヤが誰にも意識されなくなる時代が来るという話が興味深かったです。一方で、フロントエンドはどのブラウザ・バージョンを使うかはユーザーが決めるため、そう簡単にはいかないという話もありました。(つらい...)

とはいえ、高速になるに越したことはないですね!!

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

by unvalley

https://speakerdeck.com/unvalley/typescript-linters

「Rust製のLinterのプラグイン実装について」のお話でした。

Rust製のLinterはプラグインの実装がこれまで提供されていなかった理由としては「パフォーマンス」と「コアへ集約する思想」であったそうです。パフォーマンスではJavaScriptとRust間のデータ転送コストにパフォーマンス懸念があり、またコアへの集約する思想については、Lintのルールなどをコアに集約する形で始まったプロジェクトが多いという背景があるようです。

ただ、BiomeではプラグインシステムのBetaが導入されました。パフォーマンスの懸念としては「GritQL」というRust製のソースコード構造検索を実行するためのクエリ言語を活用することでパフォーマンス的な懸念がなくプラグイン実装が可能になるそうです。

https://biomejs.dev/ja/reference/gritql/

Linterのプラグイン実装の裏側について知らないことだらけであったため、とても勉強になりました!

全体の感想

TSKaigi 2025の初日が終わりました!
セッションはどれも濃密で、TypeScriptの奥深さと可能性を改めて感じる一日でした。
また企業ブースも想像以上に盛り上がっていて、各社のTypeScriptへの取り組みや開発のデモも見ることができました。ノベルティも充実していました!(全てまわりきれていないので、明日まわりきりたい...)あと、お昼のお弁当がめちゃくちゃ美味しかったです。TSKaigiのお弁当は美味しいです(確信)。

何より、これだけ大規模なイベントをスムーズに運営してくださったスタッフの皆さんに感謝です。

明日のTSKaigiも楽しみです!!

Gemcook Tech Blog
Gemcook Tech Blog

Discussion