こんにちは。
kickflowでエンジニアをしている芳賀です。

先日開催されたTSKaigi 2025に、kickflowはブロンズスポンサーとして参加させていただきました！
本記事では、イベントの様子や聴講したセッションの概要、そして独自に行った「フロントエンドのAI開発」に関するアンケートの結果などをご紹介します。

TSKaigi 2025 について

TSKaigiは、TypeScriptをテーマとした技術カンファレンスです。今回のTSKaigi 2025は、都内のカンファレンス施設にて開催され、多くのTypeScriptに関心を持つエンジニアや開発者が集まりました。
参加者の年代層は20代が多めなような印象でした。
また、各セッションやブースでは活発な議論や交流が見られ、熱気あふれる雰囲気の中、多くの知見が共有されました。

私たちkickflowは、ブロンズスポンサーとしてこの素晴らしいイベントをサポートさせていただきました。
パンフレットなどに弊社ロゴを掲載いただきました。少しでも多くの方にkickflowを知っていただくきっかけとなれば幸いです。

聴講したセッションの紹介

ここからは、私が聴講したセッションの中から、特に印象に残ったものをいくつかご紹介します。

1日目

基調講演

スライド Anthony Fu 氏による基調講演では、ESLintの未来について非常に興味深いお話がありました。
主なトピックは以下の通りです。

FlatConfig の導入と普及
- @eslint/migrate による移行支援
ESLintの役割の変化
- Formatterとしての側面 (stylisticルールの分離)
- Codemodとしての活用可能性
Lintの未来についての考察

ESLintが単なる静的解析ツールに留まらず、開発者体験を向上させるための多角的な進化を遂げようとしている様子が伺えました。

AI Coding Agents Enablement in TypeScript

このセッションでは、AIコーディングエージェントをTypeScriptプロジェクトで効果的に活用するための「イネーブリング」という概念が紹介されました。特に印象的だったのは以下のポイントです。

「解空間」という言葉がキーワードとして出てきました。ざっくりな理解ですが、AIが生成するコードの取りうる範囲を指すとのことであり、この範囲を適切にコントロールすることが重要そうです。
この解空間の定義のためにAIへのイネーブリングが必要であり、新入社員にOJTを行うように、AIに対しても（clinerulesなどで）適切なコンテキストを与え、導く必要があります。

また、並行して以下のような機械的検査（型チェックやLint）でAIの解がズレた場合に解空間に押し戻す、という必要もあります。

型による制約: 型定義だけでなく、「制約付きデコーディング」によってAIが生成するコードが型定義に準拠するように導くアプローチ。
Lintの役割: 古典的ですが依然として有効な手法。AIの出力にフィードバックを与え、ルールから逸脱しないようする。
※ プロンプトを修正する前に、まずLintルールを見直すという視点が大事とのことです

総じて、コード生成AIの登場により開発のスピード感が変わる中で、型の複雑性がコード生成によって緩和される可能性や、人とAIが協調して開発を進めるための最初の一歩としてのイネーブリングの重要性が語られました。 AIと共存する未来の開発スタイルについて、具体的なヒントを得られるセッションでした。

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

スピーカーノート

このセッションでは、TypeScriptの現状と未来について深く掘り下げられました。

ここ数年のTypeScriptの進化は目覚ましいものがある
- 個人的にはJavaScript 界隈の大きな潮流のなかに埋もれてしまいがちでした
ViteのようなTypeScriptを扱うビルドツールは増えていますが、TypeScriptのコアである型チェックを行うツール（tscの代替）はなかなか登場しない、あるいは頓挫を繰り返している
- その点で、Microsoftが進めているGoによるtscの再実装に期待
ビルドレイヤの未来
- バックエンドにおいては、高速化が進むことで将来的には「ビルドレイヤが溶けていく」（ビルドプロセスを意識しなくなる）可能性があるという予測
- フロントエンドにおいては、実行環境がエンドユーザーに委ねられるため、バンドルサイズの最適化や実行時パフォーマンスチューニングといった観点から「ビルドレイヤは溶けない」だろうとのこと。
  - ただし、開発体験そのものはビルドの高速化によって向上していくと予測されていました。

TypeScriptの現在地と、そのエコシステムが今後どのように進化していくのか、大きな視座を与えてくれる内容でした。

LT

1日目のLTでは、実務に役立つテーマからユニークな試みまで、多様な発表がありました。特に印象的だったのは、TypeScriptで競技プログラミングに挑戦するという内容で、TypeScriptの新たな可能性を感じさせられました。
また、複雑な型定義をAIを活用してリファクタリングするという発表は、日々の開発業務ですぐにでも試してみたいテクニックでした。

2日目

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

こちらのセッションでは、TypeScript処理系のネイティブ実装に関する動向や観察レポートが共有されました。パフォーマンス改善やエコシステムの今後に繋がる重要なテーマだと感じました。特にネイティブ化による「10x Faster」は開発者体験としてとてもインパクトのあるもので、早く試してみたい限りです。

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

スライド

このセッションでは、特定のドメイン知識に基づいたコーディング規約をESLintのカスタムルールとして実装する方法が紹介されました。特に以下が印象に残りました。

ドメイン固有規約の有効性: プロジェクト固有の命名規則や設計パターンなどをルール化することで、前述のAIセッションで出てきた「解空間」内にコードを留める助けとなり、コードの一貫性や品質向上に繋がりそうだと感じました。
型情報を活用したLintルール: TypeScriptの型情報を利用することで、より高度で意味的なチェックを行うカスタムルールを作成できる点が興味深かったです。例えば、特定の型を持つ変数名の命名規則を強制するなどに活用できそうです。こちらも「解空間」内にコードを留める助けになりそうです。

ESLintのカスタムルール開発はこれまで経験がありませんでしたが、プロジェクトの品質を維持・向上させるための強力な手段となり得ると感じました。

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

このセッションでは、TypeScriptで「良い」コードを書くとはどういうことか、特にコードの健全性（Soundness）と使いやすさ（Usability）の観点から考察されました。

コードの健全性: 型安全性が高く、実行前後の状態が予測可能であること。
ユーザビリティ: APIの分かりやすさ、利用しやすさなど、開発者体験に関わる部分。
ここから、TypeScriptは、これらの健全性とユーザビリティを開発者がコントロールできる言語であると述べられました。

また、上記のトレードオフについても言及され、健全性を追求しすぎると型定義が複雑になりユーザビリティが低下することがあり、逆にユーザビリティを重視しすぎると型安全性が損なわれる可能性があります。この二つのバランスを意識し、プロジェクトの状況や目的に応じて最適なトレードオフを選択することが重要であるというメッセージが心に残りました。
ソフトウェア開発における様々な局面で発生するトレードオフについて、TypeScriptの文脈で改めて考える良い機会となりました。

凸企画：フロントエンドの AI 開発、どうしている？

今回のTSKaigiでは、スポンサーブースなどを訪問させていただいた際に、いくつかの企業の方々に「フロントエンドにおけるAI開発の現状」について、簡単なヒアリングを行ってみました。（ご協力いただいた皆様、ありがとうございました！）
対象は、主に自社でWebサービスやアプリケーションを開発されている方です。

Q1. AI（コード生成など）を開発業務に導入していますか？
- 導入している: 90%
- 検討中: 10%
Q2. （Q1で「導入している」と回答した方に）バックエンド開発でAIを活用していますか？
- 活用している: 100%
Q3. （Q1で「導入している」と回答した方に）フロントエンド開発でAIを活用していますか？
- 活用している: 100%
Q4.（Q3で「導入している」と回答した方に）既存画面の改修（機能追加やUI変更など）にAIを活用できていますか？
- できている: 30%
- できていない: 70%

考察

今回の小規模なヒアリングではありますが、いくつかの興味深い傾向が見られました。

AI導入の浸透: 多くの企業が、バックエンド・フロントエンド問わず、何らかの形でAIを開発業務に導入し始めているようです。新規開発 vs 既存改修の観点で見てみますと、新規のコード生成や小規模なコンポーネント作成においてはAIが積極的に活用されている一方で、既存の複雑な画面やロジックの改修となると、まだ活用が進んでいないケースが多いようです。
また、フロントエンド特有の課題感としてはフロントエンド開発では、ビジネスロジックとUIの関心事が同居しているコードベースが多く、AIが意図通りに改修を行うことが難しいという課題感が聞かれました。AIが便利である一方、既存の設計や文脈を無視して「よしなに」コードを生成・変更してしまうことへの懸念があるようです。
AI活用の工夫: Q4で「できている」と回答した企業では、以下のような工夫が見られました。

ビジネスロジックをUIから切り離し、まずはロジック部分の改修にAIを活用し、UIとの結合や最終調整は人間が行う
改修対象を極力小さなコンポーネント単位に分割し、その単位でAIに作業をさせ、人間がレビュー・統合する
大まかな骨子や定型的な部分をAIに記述させ、詳細な部分やエッジケースの考慮は人間が担当する

総じて、AIコーディングは特に新規開発や定型的なタスクにおいては強力なツールとなりつつありますが、既存コードの複雑な改修や、フロントエンド特有の課題に対しては、まだ人間の判断やきめ細やかな作業が不可欠であると言えそうです。「モノ（関心事）の分割」や「手順の分割」といった工夫によって、AIと人間が協調して開発を進めていくのが現状の現実解なのかもしれません。

まとめ

TSKaigi 2025は、TypeScriptに関する最新の知見やコミュニティの熱気に触れることができる素晴らしい機会でした。
基調講演で語られたESLintの未来像や、各セッションでのAI活用、型システムの深化、そして開発マインドセットに至るまで、多岐にわたるトピックから多くの刺激を受けました。
特に、AIと共存する開発スタイルが現実のものとなりつつある中で、TypeScriptの型システムやLintといった仕組みが、AIによるコード生成の質を担保し、開発者をサポートする上でますます重要になってくると感じました。