TSKaigi 2025 参加記

2025年05月29日

TSKaigi 2025 ステージ

こんにちは、.ごっちです。

2025年5月23日 - 24日に開催されたTSKaigi 2025へ現地参加してきましたので、その自分用の記録です。

前段階

今回は個人スポンサーとして参加しました。これは参加チケットを買おうとしてサイトをみたところ、個人スポンサー以外売り切れていて、「やったるか！」という気持ちで入手しました。

購入後に再度 販売サイトを見たらすべてが売り切れていたので、参加枠の最後の一席だったと思われます。

Day 1

The New Powerful ESLint Config with Type Safety

The New Powerful ESLint Config with Type Safety

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

気がついたらめちゃくちゃ進化していて、個人でなにか始めるときに再度採用してもいいかと考えました（個人ではほぼBiomeを採用していたので）。

コメントからコードを直してくれるの、生成AIとはまた違った体験ができそうで面白そうたと思いました。

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

スキーマと型で拓く Full-Stack TypeScript
  • 最初はノーコードツールを使ってサービス開発が進んでいたものを、フルTypeScriptへ全面的に移行。
  • フロントエンドとバックエンドの責務を分けて、間をGraphQLにした。
    • Schema駆動開発を採用した。バックエンドはスキーマを満たすように実装し、フロントエンドはスキーマにもとづいてクエリを作る。
    • Schema駆動なので、フロントエンド・バックエンドがTypeScriptでなくてもサービスを大きくできるようになっている。

いまお手伝いしている仕事では真ん中がGraphQLなのですが、（バックエンドにRuby on Railsを使った状態で）コードをベースにスキーマが作られるので進め方が違く興味深かったです。

スキーマがある状態からバックエンドのコードの雛形を作れるので、開発体験がとてもよさそうに見えました。また、バックエンドのインプット・アウトプット双方の型が決まった状態なので、テストや型チェックが楽に行えるというメリットもあり、さらによさそうです。うらやましい。

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

TypeScriptで実践するクリーンアーキテクャ
  • クリーンアーキテクチャの話でよくでてくる、あの同心円の図はサンプルでしかない。
  • コアとなるのは方針と詳細の分離
    • 方針は自分自身が何のアプリケーションなのかを表現している。
    • 詳細は差し替えができる。
  • 方針（バックエンドのロジックなど）と詳細（WebやAPI、モバイルアプリなど）を分けることで、詳細が変わっても方針が変わらない。
  • クリーンアーキテクチャの本を読んで知識をつけ、スタイルガイドの本で実践を学ぶ。

どちらの本を読んだことがないので、ちゃんとした知識をつけるために読もうと思いました。

登壇者については、Podcast番組で聴いてました。

TSConfigからTypeScriptの世界を覗く

TSConfigからTypeScriptの世界を覗く
  • tsconfigのオプションを見る事で理解が深まるはず。
    • 実際問題として、一度作成したらメンテをしない問題がある。
  • そもそも tsconfigは tsc のふるまいを規定するためにある。
  • tsconfigの大半は compilerOptionsにある。
  • tsconfigの中身の見直しポイントとして
    • strict: true であるか。型安全に開発するなら必須。これをベースに個別設定を整えていくとよさそう。
    • ECMAScriptのバージョン。最近は ES2024, ESNext
    • 公式にある recommendedなオプションを有効にする

最初に設定したままでいいだろうみたいな気持ちでいたけど、よく考えるとTS/JSがバージョンアップするとtsconfigも何かしら変化があるわけですと。

まとめてもいいような気もするし、 https://github.com/microsoft/TypeScript-Website にコントリビュートしてもいいかと思いました。

その他

stmnさんのブースでクジを回して当たりました！

—

ドリンクアップイベントにも参加しました！

座ってた席の後ろにあった、店独自のチンチロをプログラムすると・・みたいな話題でラスト盛り上がりました。優先順位が書かれていないので、仕様をもう少し詳しく書く必要があります。

俺魚流チンチロ

Day 2

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

TypeScriptネイティブ移植観察レポート TSKaigi 2025
  • Announcing TypeScript Native Previews - TypeScript: https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/
  • A 10x Faster TypeScript - TypeScript: https://devblogs.microsoft.com/typescript/typescript-native-port/
  • 1日目の午前0時にプレビュー版が出てしまった。
  • Go言語へ移植するにあたって従来の10倍近く高速になる（コンパイラ部分）
  • 作り直しではなく移植をしている。後方互換性を重要視している。
  • JITや動的オブジェクトモデルからの脱却。メモリの効率的な利用。JSではUTF-16が使われており、GoではUTF-8が使われている。部分文字列もGoのほうがいい
  • いままでのプロジェクトメンバーも移植プロジェクトに参画している。 TS->Goの構文変換ツールを実装。変換し人で修正しテスト検証する。AIで一括変換では使わずに、ちょっとしたスクリプトを作ったりレビューさせたりとで使っている。

「速いは正義」ということで、rust言語が選ばれてもおかしくないと思ったところでしたが、go言語の選定理由をみると納得のいく内容でした。たしかにバランスがよさそう。

ちょっとおためししたい。

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

複雑なフォームを継続的に開発していくための技術選定・設計・実装
  • フォーム難しい
    • UI・フィールド・バリデーションにより、難易度は想定以上に高い。
    • バグらせてはいけない場面が多く、柔軟性と堅牢性の両方が求められる。
  • めちゃくちゃシンプルなフォームであればuseStateで事足りるが、要素数が増えたら？
  • バリデーションロジックがUIロジックに混在すると、宣言的UIとは・・・となるし、テストもしにくい。
  • アプローチ
    • フォームライブラリとスキーマライブラリをいれる。(react-hook-formやzodなど)
      • カートにある合計金額の計算などのそうご依存に無理が出てきてしまう。
    • 状態をクラスをつかってモデリングする（MobX）
      • ドメインロジックをクラスににがすことで、コードの見やすさやテストのしやすさを確保できる。
    • jotaiで状態管理・非同期処理をする
      • 為替レートを別のAPIで取得するといったものに対しても対応できる
  • 本質として、設計が大事

フォーム周りだけでも技術選定の話題として取り上げて盛り上がりそうな予感がします。完璧なものはないので、メンテナンスしやすい作りをキープしておくのが大事だと感じています。

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

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

https://azu.github.io/slide/2025/tskaigi/jsprimer.html

言われてみれば確かにそう！みたいな話が多く、再認識できた次第です。知らないツールが多かったので、このブログシステムでも取り入れたいところです。

“良い”TypeScriptコードを書くためのマインドセット

「良い」TypeScriptコードを書くためのマインドセット
  • Usability「実用性」とSoundness「健全性」はトレードオフ。
  • この2つにはトレードオフがあることを常に意識しておく。
    • サーバサイドでがっつりバリデーションエラーあったり、小さい使い捨てのプロダクトであればUsabilityを優先でよさそう。
    • サービスやコードが大きかったり、ちょっと複雑になる見込みがあるなら堅牢に。

ただしく意識するのは難しい気がしますが、大事な観点だと思いました。このマインドセットはTypeScriptを使った開発だけでなく、ソフトウェア全般に家そうだとも感じました。

その他

—

オフィシャルパーティでは初めましてな方ともお話できて、とても楽しめました。福島県から参加した方が自分の他にもいたことに感動を覚えました。

福島県（もしくは郡山市）ベースでIT勉強会コミュニティを作る機運が少しだけわきました。もうちょっと参加見込人数を増やしたい。

懇親会

名刺的なものを持ち合わせていなかったので、次回のカンファレンス参加に向けてプレーリーカードを用意してもいいかなと考えてます。

デジタル名刺ならプレーリーカード｜簡単作成・おしゃれ・月額無料: https://prairie.cards

次回も開催するということなので、また参加したい気持ちです。自分が登壇者側に回るイメージを全く持てていないので次回開催以降もこういう参加になりそうですが、ネタ探しだけは意識しようと思います。

ProfilePicture

Yuta Goto

フリーランスのソフトウェアエンジニアです。現在はReact.jsを使用したWebフロントエンドの開発やRuby on Railsを使用したサーバサイドの開発を行っています。

Share for Bluesky