TSKaigiの自分のレポートです。
初のオフライン参加かつ、業務時間での参戦だったので記録として残しておきます。
The New Powerful ESLint Config with Type Safety
- フラットコンフィグに関するお話
- 従来に比べてシンプルなconfig。
- TypeScriptベースで設定ファイルを構成可能に。
-
.tsによる型安全な設定ができ、型定義や補完もサポート。
- eslint-plugin-command
- コメントを読み取って自動的にフォーマットを行ってくれる。
個人的な感想として、jsonに依存しないconfigファイルの管理というのに衝撃を受けました。package.jsonもいずれpackage.tsで管理できる時代が来るのかも…?
スキーマと型で拓く Full-Stack TypeScript
- ノーコードからTSに全面リプレイスし、スケーラブルな開発へ。
- フルスタックTSでありながらバックエンドとフロントを明確に分離し、GraphQLのスキーマ駆動で疎結合を実現。
- モノレポ構成だが各サービスは独立。
- 型による安全性を維持しつつ、開発環境やCICDも統一。
- 将来的な技術スタック変更にも柔軟に対応可能。
将来的にバックエンドがTSじゃなくなってもいいような構成にしていることが将来的な成長を見据えられて良いと思いました。
GraphQLによるスキーマ駆動にすることでバックとフロントの齟齬を埋め、バックを他言語にリプレイスするとしても同じくスキーマ駆動にしていけば、そこまで負荷も高く無くなるなと感心しました。
かつスピード感もフロントと同じTSを採用することで高速な開発が実現できており、TS採用の理由にも納得がいきます。
TypeScriptでクリーンアーキテクチャを実践する – WebでもCLIでも使えるアプリケーションの作り方
- クリーンアーキテクチャとは「方針と詳細を分けて、安定度の高い方針に依存する」
- 方針とは、自身が何のアプリケーションなのか。
- 詳細は差し替え可能。
- よく図で出てくる同心円はあくまでもサンプルでしかない。
- コアになるのは方針と詳細の分離。
- 色々できてしまうのは良くないのでSOLID原則に従う。
- 依存関係の逆転は良くない。
- 方針(ロジック)と詳細(Web or CLI)を分けることで、詳細が置き換わってもロジックが変わらない。
- マルチプラットフォームに強い。
わかりやすくクリーンアーキテクチャの復習が出来ました。
一方で「ログイン機能を実装する」となるとWebにしかないセッションを、CLIでどうするかという点で依存性の逆転が起きてしまうのではないかとも思いました。
AWS LambdaをTypeScriptで動かして分かった、Node.jsのTypeScriptサポートの利点と課題
- Node.js 23.6以降ではトランスパイル不要でtypescriptが実行可能に（型除去が可能）。
- ts-node不要で高速化・パッケージ軽量化が可能だが、TSの一部機能（enumなど）非対応。
- aws lambdaではnode.js23.6は非対応 コンテナイメージなどで用意する必要あり。
- aws sdkが読み込めずエラー。
- デプロイパッケージが肥大化し、サイズ制限に引っかかる。
- 上記2点により、lambdaでの実行には現時点で難がある。
- awsではnodeをサポートしてもtsはサポートしない サーバーレスではトランスコンパイルはまだ必須。
- v24で正式に対応するかも。
どういった部分で役立つかというのもありますが、自分としてはlambdaはそういった簡易的なfunctionを行うモノであると認識しているので、トランスコンパイルなしでtsが実行できるようになればlambdaの可能性が広がるのではないかと思いました。
fast-checkとneverthrowのPBT+Result型で堅牢なビジネスロジックを実現する
-
ビジネスロジックの違反をどう伝えるか。
- 例外か戻り値か。
- 例外は楽だが、エラーの型がわからずどんな状況なのかわからない。
- 複数の例外が発生すると何が原因か分かりづらくなる。
- 戻り値は判別共用体を利用。
- どの型か判別することでエラー内容を判別可能。
-
result型でokかerrか判別。
- 型安全に成功したかエラーになったかを判別できる。
-
操作には骨が折れるので既存ライブラリを活用。
-
メソッドチェーンで表現することで型安全に処理できる。
-
プロパティベーステスト。
- 性質に対してテスト。
- 例として「ゼロでない値」「1文字以上7文字以下の英数字」など。
- 要件を満たせるテストデータであればなんでも良い。
- 例として「ゼロでない値」「1文字以上7文字以下の英数字」など。
- 性質に対してテスト。
かなりGoの感覚に近いなーと思いました。
ただ発表にもあった通り大体のライブラリは例外を投げることが多いので、エラーを型判別する今回の事例は限定的になるかと考えられます。
とはいえ複雑なロジックを採用するフロントエンドやHonoを採用している場合は活用の余地はありそうです。
TypeScriptネイティブ移植観察レポート TSKaigi 2025
-
CorsaというGo実装のTypeScriptコンパイラ（TS 7.0）が登場。既存のTypeScript（Starada, TS 6.x）に比べて最大10倍高速。
-
Microsoft BuildとTSKaigiが同時開催。新コンパイラのプレビューはKaigi前日に公開。
-
Goへの移植の背景と狙い
- TypeScriptの動作は多くのプロジェクトで依存されており、後方互換性が極めて重要（＝ハイラムの法則）。
- 目指すのは「既存のTypeScriptをそのまま置き換え可能なネイティブ実装」。
-
Goが選ばれた理由
- GCと循環参照の相性が良い
- 並列処理が自然
- クロスプラットフォームでのネイティブ実行が容易
-
技術的ポイント
- 並列化：Goのgoroutineとスケジューラで、パースや型チェックを並列化。
- 型チェックは4分割して並列処理（順序固定のため）
-
高速化の工夫
- JIT脱却で安定した最適化が可能
- メモリ構造の改善（データ構造のインライン化、文字列管理のUTF-8化）
- ネイティブ処理 + 並列処理で最大3×3.5倍の高速化
-
互換性テスト
- 10万件以上のエラー差分を検証
- Union型などに決定的順序付けを導入し、一貫した型推論が可能に
-
実装と移行について
- TS→Goの変換ツールが存在（ただしUnionやOption型など一部は手動で補完が必要）
- AIは使わず、スクリプトとレビューで移植を支援
-
開発エコシステムへの影響
- Compiler APIの仕様変更が避けられない
- IPCベースで外部との連携へ
- ts-morphなど内部API依存ツールは注意が必要
(長すぎたので一部ChatGPTに要約してもらっています)
「本家公式で速い」＝強い
これがすごいことだなと思いました。
課題、解決手法、選定理由にしっかりとした理由づけが行われていて、かつ高速性・互換性・実運用を高次元で両立しつつある点に非常に興奮しました。
また要約に漏れていますが、大規模プロジェクトでもOOMを引き起こしやすい問題にメスが入るとのことで、これに悩まされていた人の希望にもなるのではないでしょうか。
それとこれを書いている途中で、Honoがtsgoに対応していて早さに驚きましたw
複雑なフォームを継続的に開発していくための技術選定・設計・実装
-
フォーム開発の本質的な難しさ
- 複雑なUI・多数のフィールド・厳密なバリデーションにより、フォーム開発は難易度が高い。
- バグが致命的になりやすく、柔軟性と堅牢性の両立が求められる。
-
問題点とその根本原因
- 単純なフォームであればuseStateだけでも良いが、複雑になるとstateで管理しなければならない項目が増える。
- バリデーションがUIロジックに混在すると、宣言的UIの理念に反しテストもしにくい。
- フォームの複雑化の主因は「不明確なデータモデリング」にある。
- この辺が曖昧だと、保守性に難のあるフォームができてしまう。
-
改善アプローチと選択肢
-
- フォームライブラリ + バリデーションスキーマ
- react-hook-form + zod などでバリデーションを宣言的に管理。
- ただし、複雑な相互依存（例：合計金額など）は限界がある。
-
- 状態をクラスでモデリング（MobX）
- ドメインロジックをクラスに切り出してテスト性・保守性を確保。
- React側のstate管理を減らすことで効率化。
- 状態を「値」として扱う思想が、AI支援や可読性にも有利。
-
- 非同期処理にはJotai
- atomで状態を管理し、非同期（例：為替レート）も自然に記述可能。
- Promiseベースで中間状態を簡潔に管理。
- jotaiは単体テストしやすく、拡張性が高い。
-
-
本質的な設計指針
-
問題の性質に応じて、適切なモデル設計と技術を選ぶことが重要。
-
zodだけで済むシンプルなケースもあれば、classやatomの導入が必要な複雑なケースもある。
-
「初めから完璧を目指さない」こと。まずは「そこそこ良い設計」から始めて、壊れたときに早く気づける仕組みを整える。
技術選定と同じくフォームにもシルバーバレットは存在しないと思い知らされました。ただ柔軟なモデル設計やライブラリに頼るなど手段は存在するので、100点とまではいかずともそこそこいい感じにしておくと言うのを意識してみようかと思います。
ts-morphで、人間も編集できるコード生成を実現しよう！
-
課題：自動生成コードの「上書き問題」
- APIスキーマから生成したコードは再生成時に人間の手による編集が消えてしまう。
- この問題により、ロジックの自動生成と手動実装の両立が難しい。
-
アプローチ：自動生成と手動実装の共存
- スキーマファースト（OpenAPIなど）とコードファースト（先にコードを書く）両方のニーズに対応。
- Fastifyなどを用い、スキーマからのコード生成を行いつつ、ロジック部分は人間が記述。
- 既存コードをパースして、差分だけを反映することで、人間が書いた部分を残す工夫をしている。
-
技術的要点：ts-morphとASTの活用
- ts-morphを使うことでTypeScriptのASTを簡単に扱え、精密なコード編集が可能。
- 正規表現では難しい検出（例：タイムスタンプ関数など）も、ASTなら構造的に識別可能。
- ts-morphにより、ブラックボックス化せず、可読性の高いコード生成が実現できる。
-
注意点
- ASTベースの処理は強力だが複雑であり、エッジケースやバグに注意が必要。
- 実際に現場で適用する際には、堅牢性のためのテストと検証が不可欠。
- tsgoで今後のサポート体制が不透明。
既存コードを残したまま生成を行えるというのでも便利ですが、想像以上に理解しやすいコードでコード解析ができていたのが衝撃でした。
ただtsgoの登場や可読性があっても既存コードの条件まわりが複雑になりそうな懸念も考えられました。
機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する
-
コンポーネント分割の基本戦略
- ロールごとに条件分岐かコンポーネント分割か。
- 正解はない。
- 今回は「ロールごとのコンポーネント分割」にフォーカス。
- ロールごとに条件分岐かコンポーネント分割か。
-
凝集の種類と評価
-
実践パターンと対処法
- ロールごとの業務フローが異なる場合：
→ ロール単位でコンポーネントを分割。 - ルーティングで分けられるなら分ける：
→ コンポーネント内での分岐処理を減らせる。
- ロールごとの業務フローが異なる場合：
-
新規作成・編集画面のように似て非なる機能：
→ タイトルや初期値だけ違うなら、共通のフォームコンポーネントで対応可能。 -
分岐を完全に除けない（例：ファイル or ディレクトリ）：
→ 条件分岐責務をもつラッパーコンポーネントを設けて整理。 -
通知のようなパターンが多いUI：
→ ts-patternなどを用いて意味ごとに出し分けると機能的凝集に。
共通化できてしまうものであっても、可読性とって多少冗長にしたほうが後が楽になる部分に非常に共感しました。論理的凝集をしまくって、数ヶ月後に「なんじゃこりゃぁ！！！」となった記憶が蘇りました…
また何でもかんでもコンポーネントとして分離してしまうと責務の薄いコンポーネントが出来上がってしまい、逆に可読性を落とします。その辺のバランス感覚も必要とのことです。
TS特化Clineプログラミング
TDD＋型中心設計＋明示的な仕様分離が、TS×AI開発の鍵なのかなと思いました。AIには万能性を求めず、構造化と明確な入力を与えて補助してもらうというのが今の正しい使い方なのかなと思います。
「プログラミングの難易度自体は変わらないが、自然言語toコードにより学びやすくなっている」
これに尽きます。逆に人間がAIのコードが正しいかどうか判断する能力が求められていくのだろうとますます感じました。
TSという言語に限らない試みが色々存在し、見ていて飽きない、ワクワクする発表でいっぱいでした。
サーバーサイドTSのセッションも目立ち、スタートアップやハッカソンなどのスピード感を持たせたい開発に適するという学びも得ました。
また一部機能をASTで拡張するといったセッションもあり、発想がRubyに近いなーと思いつつ、MSがtsgoを発表したタイミングと重なり今後どうなるかわからんと言うオチをつける人もいて面白かったですw
逆にTSであれば何発表してもいいような雰囲気を感じ取ったので、来年はプロポーザルを出して登壇を目指したいと思います！！
お弁当も交流会も豪勢な食事が出て話が非常に弾みました！
最後にカンファレンスの運営、登壇者、スポンサー企業の皆様に感謝の意を表したいと思います。
本当にありがとうございました！！！
TSKaigiのサイトのタイムテーブル、現在時刻に合わせてnowと出ていたのをご存知でしたか？
気づいた時めちゃくちゃ感動しました。
今回対面で初めて会う人が多かったので、見つけてもらう&覚えてもらうことを意識してクセ強めでDay2に挑みました。
懇談会食いつかれたので今後もこれ意識して挑みますw
Views: 3
