TSKaigi 2025 １日目 に参加しました。
イベントの概要
学び、繋がり、”型”を破ろう
2024年に産声をあげ、大盛況のうちに幕を閉じた TSKaigi を今年も開催します！
私たちは、誰かの発表を聞くだけでなく、他の誰かに向けて発表することもまた学びの一つだと考えています。 参加者、登壇者、スタッフ、スポンサーをはじめ、TSKaigi に関わるすべての人たちが互いに学び合い、新たな繋がりを生み出し、型にとらわれないエンジニアとして生き生きと活躍できる世界を目指します。 その実現に向け、今年は会場を中野から神田へ移し、2日間開催とすることで、大幅にパワーアップしました。
TypeScript に関するあらゆるテーマを扱う国内最大級のカンファレンスとして、まさに「型破り」なイベントを目指し成長を続ける TSKaigi にご期待ください。
引用：
イベント参加の背景
- 今春より実装作業に復帰。フロントエンドは初TypeScript+Vue3。
- アセンド丹羽さんが登壇時にご紹介されているTSKaigiが気になっていた。
- これからTypeScriptに携わっていくにあたり解像度と気合いをあげたくて参加。
オープニングトーク
代表理事の竹下さんからのご挨拶。
TypeScript系カンファレンスのなかで規模世界一。
ミッション：学び、繋がり、“型”を破ろう
専門性に拘らず、新しいものを生み出していく。
TSKaigiセッション
-
The New Powerful ESLint Config with Type Safety
■メモ
２か月前にパリから東京に引っ越してきた。
フラットコンフィグについて。
ESLint v9.0.0。TypeScriptとの親和性が高い。
モノレポ構成に効果的。
ESLintはLinterを越える。
Formatterにもなる。eslint.styleCodemodにもなる。
他の言語のためのLinterにもなる。Vueやjson、yaml等にも利用可能。
One for All。すべてのプロジェクトに。すべてのために。
■感想
初学者＋英語リスニング中学レベルの人間には難しい内容だったものの、
フラットコンフィグが今までのLinterの認知負荷を下げただけでなく、
これまでの役割を大きく越えた活用を期待できるものと理解しました。
そして、展開された資料をNotebookLMに呑ませて復習しました。
開発ツールの採択に当たり開発生産性とエコサイクルを考慮に入れることも学びとなりました。
■参考 - 高度な型付け、どう教える？
■メモ
高度な型付けを教える側のための内容。
メンバーに教える必要ある？
メンバーに読めないと技術的負債になる。
なので、利用を諦めるorメンバーにも読めるようになってもらう。後者を選ぶ。
ハードル。
・書き手が処理の流れをイメージしづらい。
・デバッグしづらい。
・TypeScriptの挙動に癖がある。
解決策。JSで下書き。TSで翻訳をする。
下書きの恩恵：心理的ハードル下げられる。デバッグしやすい。
翻訳：JSの記載をTSの記載に置き換える。型づけをする。
注意点：完全対応はできない。TSの癖はそのまま。
３名対象にペアプロで実施してみた結果、うまくいった。
最初から型レベルプログラミングが解消。デバッグしながらなのでやりやすかった。
ただ、TypeScriptの挙動に癖があるという課題が残る。
そのための教えるための準備。下書きのJSをTSの書き味に近づけた。
JS⇒TSの翻訳が自明ではない。
結果、教師の下準備や教え方が難しい。
下準備をAIがやってみたら？
少し手を加えれば学習教材として使えるものが出力された。
最後のハードルはAIが緩和してくれる。
■感想
高度な型付けの複雑さを解消していくためのアプローチが勉強になりました。
最後に人の負荷を下げるためのAI活用も、
人の認知・負荷の軽減のための活用として良いなと思いました。 - TypeScriptで実践するクリーンアーキテクチャ ― WebからもCLIからも使えるアプリ設計
■メモ
・クリーンアーキテクチャ結局なに？
ボブおじさんの話が起因。
方針と詳細に分けて、安定度の高い方針に依存する。
同心円はサンプルでしかない。
少ない労力で大きな成果を得るためのもの。
コアの主張。アーキテクチャには共通のルールがある。構成要素を組み立てること。
方針と詳細の分割。関心の分離。結果、労力の最小化と成果の最大化。
プログラミングは、順次⇒選択⇒反復⇒関節参照でできている。
ポリモーフィズムを利用することで依存関係を制御する。
SOLID原則にそって開発する。依存関係逆転の原則が一番重要。
インターフェースを用意することで、制御の流れと依存の流れを逆転できる。
実態を差し替えることができる。
結果、クリーンアーキテクチャは、オブジェクト指向で、ポリモーフィズムの機能に着目し、DIPを活かして依存の方向を制御しているもの。
・具体的にどう開発する？
ドメイン層：ビジネスルールの記述
ユースケース層：アプリケーション固有の機能。様々なオブジェクトが協働して作業をする。
ゲートウェイ層：外部システムとの連携を扱う。ドメイン層のIFを実装する。
入出力層：アプリケーションに対するデータの出入力
・クリーンアーキテクチャがもたらすもの
別プラットフォームのUIを作れる。
DBも差し替えられる。
プロダクションレベルでの実装は『オブジェクト設計スタイルガイド』が参考になる。
クリーンアーキテクチャ本でモチベをあげて、スタイルガイド本でコーディングを学ぶ。
クリーンなコードは、AIフレンドリーなコードになる。
但し、ドメインオブジェクトは本当に安定しているのか？
■感想
クリーンアーキテクチャがモチベーションをあげるに大きく共感しました。
複雑なものを整理していく課題解決のためのアプローチはとても楽しい。
『オブジェクト設計スタイルガイド』も改めて読みたいと思いました。
PHP Conferenceも行きたいと思っていたので楽しみです。
■参考
- 堅牢なデザインシステムをつくるためのTypeScript活用
■メモ
デザインシステムの定義。
ルールセット＋ドキュメント＋実装の３点セット。
制約を整えてデザインを再現可能にすること。
figma上でいくら再現されても、実際のプロダクトで再現できないと意味がない。
UIライブラリとの違いは、【らしさの再現】が組み込まれていること。
デザイン原則、ボイス＆トーンからコンポーネント、デザイントークンに落とすことが重要。
ただ、デザインシステムから逸脱する。
そのために、善意に頼らず仕組みでルールを強制する。
逸脱している箇所を見つけやすくする。ドキュメントを更新し続ける。
デザインシステム：デザインに制約を加える装置
TypeScript：実装に制約を加える装置
TSを使ってデザインシステムの制約を強制する。
・コンポーネント自由度コントロール
・補完やサジェスト活用
・コンパイルエラーでルール違反を見つける
・LLMの出力をサポート
デザイントークンの活用。StyleDictionaryを活用する。
BrandedTypesを活用する。StyleDictionaryのregisterTransformを使う。
VSCode拡張をつくる。
Styleの上書きを許容しない。CSSを書かせない。
デザインシステムを使うのであれば、そうしたマインドセットを作り上げていく。
デザイントークンはビジュアルとセットで管理をする。
Figmaでデザイントークンを管理する。Git上では色味の変化が分からない。
GitHub Actions経由でデザイントークンを吐き出す。
ドキュメントがメンテされなくなると、誰もデザインシステムを使わなくなる。
デザインシステムはエンジニアとデザイナーの２つの役割の共有から運用が難しい。
LLMが活用し、メンテナンスを続ける。
■感想
デザインシステムほぼ知見の無い人間としてとても学びになりました。
重要な価値を実現するためのルールを決めたら、それに従うための制約を作る重要性。
デザインの情報をどこで管理すべきかの考え方もとても興味深かったです。 - AI Coding Agent Enablement in TypeScript
■メモ
AIを使いこなすという原動力には、AIの自走に対する希求がある。
Human-in-the-Loopをなるべくやりたくない。
デフォルトの解空間が大きすぎるので、精度が低い。
なので、適切な制約をエージェントに与えることで、解空間を絞る。
どうやるか？人間と同様にイネーブリングする。
例：コンテキストの注入。機械的検査。
アプローチ：
・型チェック
人にとって、型があるから精度が上がるわけではない。下手な型は逆効果。
型があるから良いコードを生成するわけではない。
AIにとっても同様。高度な型に対する対応力はまだない。
ドメインモデリングや関数のシグネチャの定義までは伴奏が必須。
その後の実装を自律的にやってもらう。
制約付きコーディングで型を守る。
・Linter
気になった出力にフィードバックして直す。
プロンプトを直す前にLinterする。
型チェックと違いネクストアクションの提示ができる。
プロンプトと違い決定的。（保証ができる）
なるべく同じレビューを二度としないようにできる。
・デザインシステム
コードもドキュメントになる。
エコシステムの未来。Speed is King。
■感想
エンジニアがAIに何を求めるかの言語化とそれに対する対策の明瞭化。
我々が思ったものをAIが自走して作ってくれる未来がすぐ先のことであるとイメージしました。
このセッションでもLinterやデザインに対して解像度をあげる必要があると理解しました。 - TypeScriptとReactで、WAI-ARIAの属性を正しく利用する
■メモ
WAI-ARIA。
Webブラウザは、スクリーンリーダーなどの支援技術に対し、アクセシビリティツリーを提供している。WAI-ARIAはこの連携のあり方を定義している仕様。developer.mozilla.org
WAI-ARIAの利用には、まだまだ課題がある。
そのために、
・属性名はキャメルケースで指定。
・ロールごとに厳格なaria-*属性を定義。
■感想
アクセシビリティは技術書典さんで購入の『アクセシビリティを考えはじめるための本』を読んだ程度の初学者です。
自分の担当しているプロダクトでは明確な意識を持っての取り組みができておらず、将来的には対応が必要になる可能性もあることから、自分たちも陥りやすそうと思いながらお話を聞いていました。
アクセシビリティの実現に対する課題解決尊い。
■お知らせ
いつか必ず通る道。サイン本やアクスタ貰えるのは今だけ。と購入しました。 - TypeScriptとは何であって何でなく、誰のもので、どこへ向かうのか
■メモ
TSのエコシステムに大きな変化が起きている。
その裏に何があるか。その流れの先に何があるかを考えたい。
TSはどんな言語？
他のAltJSと呼ばれる言語がいる。Kotlin、PureScript、Scala.jsなど。
その中でもTSはJSのスーパーセット風。型がある。
ビルドレイヤとランタイムが疎結合。ランタイムはJSで渡してくれればよい。
型チェッカー（checker.ts）はでかい。仕様が明文化されていない。
2010年代後半からTSエコシステムはどう進化してきたか？
大きく２つの流れ。
TSファーストな世界観、ツールチェインが早くなっている
参考：
型チェックの高速化が生まれてきている。
TypeScriptに対する取り組みが個人の趣味ではなく、事業として動いている。
企業間での競争がスピードを加速する。
では、今後TS周辺はどうなり、我々はどうするのか。
バックエンドでは特にビルドレイヤーが意識されない存在になる。
フロントエンドはそうはならない。
ミニファイへの希求がフレームワークで吸収されていく。
乗っかるブラックボックスを選ぶことが重要。
技術そのものの性質を抑えるだけでなく、周辺含めた技術の変化に追従していく。
TSはいい方向に進んでいて、我々は乗っていくと良い気がする。
■感想
TypeScript初学者にとって一番学びになったセッションかも知れないです。
私が気付いた頃にはTypeScriptは既にあったし、いつの間にフロントエンドの言語が置き換えられた印象があります。
そのうえで、いつの間にかフロントエンドかつバックエンドもTypeScriptという話を聞くようになり、エンジニアにとって避けて通れない言語になったイメージがあります。
そうしたなんとなく横でうっすら見ていた景色の解像度が上がった気がしました。
その上で、我々エンジニアがどこまでそこに解像度を持ってオーナーシップをもって扱えるかという議論もある気がしました。
ブース
すべてのブースに訪問しました。
色々お話をさせて頂き勉強になりました。ありがとうございます。
頂いたノベルティは早速鞄に飾ったり娘にあげたり。
匠技研さんやGMO Flatt SecurityさんのブースでTypeScriptのクイズに正解したのはかなり嬉しかったです。
Typescriptクイズ正解おめでとうございます！
— 和田 蒼汰 (@sota_HSW) 2025年5月23日
特注TSキーホルダーをプレゼントです！#TSKaigi #匠技研 #匠フォース@asagayanaoki pic.twitter.com/COKf6Kdrsx
後、ブースでではないですが、アセンド丹羽さんとご挨拶できて嬉しかったです。
アセンドさんのキャラ診断.tsも面白かったです。
TSKaigi盛り上げ企画！🎉
— 幡ヶ谷亭直吉@技術書典18さ05 (@asagayanaoki) 2025年5月23日
「キャラ診断.ts〜あなたの型、推論してみた〜」
私はobject型でした！#TSKaigi #TSKaigi2025 #キャラ診断ts
診断はこちらから👇 https://t.co/q7k3KB8Q8P
まとめ
TypeScriptの初学者にとって学びの激しい１日でした。
特に「デザイン」と「Linter」に関して、もっと深く学ぶ必要があると強く感じました。
これまで私が最も多く携わってきたのは、スマホアプリのバックエンド開発です。
そのため、Webシステムのデザインに関しては、知識がやや古くなっており、今回のセッションを通じて多くの気づきを得ました。
デザインもインフラと同様に「コードで表現できるもの」になってきていることを実感しました。
また、Linterについても、これまではJavaのFindBugsのような静的解析ツール程度の認識しかありませんでした。
しかし今回、Linterが開発プロセスやコード品質に与える影響の大きさを改めて理解することができました。
この2つの領域に対する解像度が上がったことで、ビジネスロジックを実装するだけではないエンジニアの実装工程での取り組みを意識することができました。
履修せねば。
自分で理解が追い付かなかったと思う講演資料をNotebookLMに音声化させることで、適度な復習ができることも大きな発見でした。初心者に優しい。
どのセッションからも、登壇者のTypeScriptへの愛と課題意識の深さが伝わり、大きな刺激を受けました。
明日もさらに学びを深められることを楽しみにしています。
