はじめに
DIGGLE エンジニアのitoです。
DIGGLEではたびたびメンバーがカンファレンスに参加することがあります。今回、私は開発メンバーであるkishikawaさんとともにTSKaigi 2025に参加しました。
参加した際には感想の記事を作成・公開することが慣習になっているためkishikawaさんとともに参加した感想を書きたいと思います。
過去のカンファレンス参加記事はこちらから
TSKaigi 2025について
TSKaigi 2025は昨年のTSKaigi 2024から始まったカンファレンスです。
TypeScriptに関するカンファレンスとしては国内最大級で、TypeScriptを中心にフロントエンド/バックエンドといった領域を問わず発表がされます。
昨年参加したTSKaigi Kansai 2024の大元のイベントになります。
セッション/LTを見た感想
参加した中で面白かったセッションやLTの感想をまとめていきたいと思います。
TypeScriptで実践するクリーンアーキテクチャ ― WebからもCLIからも使えるアプリ設計
TypeScriptでのアプリケーション開発でクリーンアーキテクチャの考え方を活用することで、コアの実装をWebやCLIといった描画部分から切り離し同じコードで両方から使えるようにするといった発表でした。
クリーンアーキテクチャとはそもそもどういったものなのか？という整理から話をしていただいたことで以前読んだ本の内容を思い出しながら拝聴することができました。発表の中で「方針と詳細に分けて、安定度の高い方針に依存する」というルールが重要で有名な同心円の図は忘れてよいという話があり、クリーンアーキテクチャに対する自分の理解が大きく外れていなかったことがわかって安心していました。
実際にどのように実装したのかも共有していただいたため実装のイメージがつき、現在フロントエンドのリアーキテクチャを考えているDIGGLEにおいてとてもためになる情報をいただきました。
(ito)
静的解析で実現したいことから逆算して学ぶTypeScript Compiler
TypeScript Compilerの内部構造について詳しく解説された貴重なセッションでした。普段何気なく使っているtscですが、その内部でNode、SourceFile、Program、Symbol & Typeといった概念がどのように動作しているかを理解できました。 特に印象的だったのは、TypeScript CompilerとESTreeベースのツール群の違いについてです。ESLintやBabelなどのESTreeベースのツールは豊富なドキュメントがある一方で、TypeScript CompilerはAPIが公開されているものの、ドキュメントが少ないという現状があります。しかし、TypeScript Compilerの方ができることが多く、依存関係もシンプルで、強力な型による書き味の良さがあることを知りました。 また、LanguageServiceがVSCodeのTypeScript言語機能のベースとなっており、「VSCodeでできることはだいたいAPIとして呼べる」という言葉は、TypeScript Compilerの可能性の広さを感じさせてくれました。
(kishikawa)
堅牢なデザインシステムをつくるためのTypeScript活用
デザインシステムはルールセット/ドキュメント/実装がセットになっていて、制約を与えることで再現可能なデザインを実現することが目的という前提から、 堅牢なデザインシステムを作るにあたってどのようにTypeScriptの型や生成AIなどを活用していくとよいのかという発表でした。
「エンジニアは90%くらいはデザインシステムのルールを守らない (デザイナーも守らないこともある)」という言葉が印象深く、仕組みでルールを強制することが大切という点が今DIGGLEで進めているデザインシステムの整備において感じていることに近く共感をしました。
Linterでの制約だけでなく、TypeScriptによる制約の付け方も学ぶことができたため今後のデザインシステムの整備に活用していこうと思います。
(ito)
AI Coding Agent Enablement in TypeScript
Copilotからエージェント時代への移行について考えさせられるセッションでした。現在のCopilotはスニペット単位でhuman in the loop (人間の介在) ですが、エージェント時代になると、ループの輪が広くなった一方でLLM (大規模言語モデル) のデフォルトの解空間が大きすぎるという課題があります。 興味深かったのは、LLMにとっての型情報の価値についての研究結果です。研究レベルでは「型があるからといって精度は上がらない」どころか、anyや間違った型がついていると精度が下がるという知見でした。 しかし、単発のコード生成に役立たないとしても、自律的にエラー改善をするための制約として型情報が有用だろうという話が興味深かったです。一方で、複雑な型を処理して生成することはまだ難しいという現状もあり、ドメインモデルや関数の型などまではしっかり伴走して書きましょうという現実的なアプローチが示されていました。
(kishikawa)
型安全なDrag and Dropの設計を考える
DnD (Drag and Drop) 実装でよくある失敗談から始まり、型安全なDnDの設計について学べるセッションでした。「ドラッグ元・先がうまく描画できない、画面が真っ白になる」といった現実的な問題から出発し、draggable要素とdroppable要素の関係性を型レベルで安全に扱う方法が解説されていました。 draggable要素とdroppable要素を型で定義し、この型を利用して置けるのか、置いたらどうなるのかのルールをしっかり作り込むことで、型安全なDnDを実現することができるという点が非常に印象的でした。また複雑なDnDの実装においても、view (UIの見た目) の実装と分離することが重要であることを学びました。
(kishikawa)
GitHub ActionsをTypeScriptで作ろう！
特に印象的だったのは、TypeScriptがGitHub Actions Toolkitをフルに利用できる唯一の言語である点です。他言語だとDockerを使用する必要があるため、cold startが遅くなってしまいますが、TypeScriptなら直接実行できるので起動が早いという実用的なメリットがあります。 また、Octokitが利用可能で型定義付きで安全に開発できるという点も、GitHub Actionsを作成する際の強力な武器になります。実際にactionを作る際は、https://github.com/actions/typescript-action のテンプレートが活用できるとのことでした。
(kishikawa)
TypeScriptネイティブ移植観察レポート TSKaigi 2025
Microsoftが現在行っているTypeScriptのコンパイラのGoによる書き換えの状況を第三者の立場で解説をする発表でした。
TSKaigiの1日目に重なる形で発表されたPreview版も盛り込まれており、かつ発表内容にも丁寧に資料が記載された大充実の発表でした。
なぜネイティブ実装に移行するのか？なぜGoなのか？も含めて紹介されており、興味津々で聞いていたためかあっという間に終わってしまいました。
ハイラムの法則はDIGGLEでもよく発生しているものの、TypeScriptほどの規模になってしまうと開発者側が観測できていない挙動に依存していることまで考えていかなければならないのだということもわかり面白かったです。
正式なリリースが待ち遠しくなるような内容でした。
(ito)
フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない
フロントエンドエンジニアにバックエンドへの興味を持ってもらうという目的で始まったこのセッションは、技術選択の本質について考えさせられる内容でした。
現代のWebアプリケーション開発では、BaaSやIDaaSによってバックエンドが不要になると思われがちですが、実際にはセキュリティの担保、非同期処理・ジョブ実行など、バックエンドでしか対応できない領域が明確に存在します。
特に印象的だったのは、「責任分離が要点で、言語そのものは次点」という考え方です。バックエンドとフロントエンドを分離しておくことで、アーキテクチャ構成が柔軟になり、ビルドプロセスの分離やバージョンアップ・脆弱性対応などの個別対応が可能になります。
そして、この責任分離を確実に行うための手段として、あえて異なる言語を選択するという戦略が紹介されていました。同じ言語を利用すると、どうしてもアーキテクチャが密結合に寄りやすくなってしまいます。一度密結合してしまった部分を後から依存関係を整理して剥がすのは非常に大変な作業になります。しかし、言語自体を変えておくことで、物理的に密結合しにくい構造を最初から作ることができます。
昨今フルスタックTypeScriptが注目されつつありますが、このような観点から見ると、バックエンドに別の言語を選ぶことのメリットも多いということを再認識できるセッションでした。
(kishikawa)
複雑なフォームを継続的に開発していくための技術選定・設計・実装
フォームはユーザと直接インタラクションする部分であり、「ユーザのペインを引き受ける」という表現が印象的でした。UIに埋もれるバリデーション記述やテストのしづらさなど、フォーム開発の課題について深く掘り下げられていました。 技術選定では、zodのような「形状と制約」を扱うスキーマライブラリに加えて、状態管理の選択肢としてMobXとjotaiが比較されていました。オブジェクト指向のようなモデルがフィットする場合はMobXが選択肢に上がるものの、複雑すぎる依存ではデバッグが大変になるという課題があります。一方、jotaiはReactに非依存でテストフレンドリーという特徴があり、データ依存をDerivedValueに表現できる点が魅力的です。 「クラスっぽく書けるMobX、独自DSLっぽいjotai」という対比と、「プロダクトの複雑さ次第」という結論は、技術選択の本質をよく表していると感じました。フォームの本質的な複雑さを低減するために、適切なツールと設計パターンを選ぶことの重要性を学べるセッションでした。
(kishikawa)
技術書をソフトウェア開発する - jsprimerの10年から学ぶ継続的メンテナンスの技術
10年間継続されているjsprimerプロジェクトから学ぶ、技術書の継続的メンテナンスについて非常に示唆に富むセッションでした。
まず、技術書をソフトウェア開発の一部として捉えるという視点がとても新鮮でした。10年という長期間にわたって技術書をメンテナンスするために、持続可能な開発プロセスを確立することが重要であると強調されていました。
具体的には、技術書の内容をソフトウェアのようにバージョン管理し、CI/CDパイプラインを活用して品質を保つ方法が紹介されました。
技術的なツールとしては、以下の実践的な手法が紹介されていました：
- textlintによる読みやすさのルール化
- power-doctestによるmarkdown中のコードテスト
- 章ごとの依存関係の可視化
特に章を入れ替えやすくするための依存関係管理は、大規模な技術書を継続的にメンテナンスする上で重要な視点だと感じました。
また構成の作り方の話で印象的だったのは「Known-New Contract」 (既知・未知の順で説明する) という解説手法です。知らないことをいきなり話し始めると読者が止まってしまうため、まず知っていることを話してから未知の話をするというアプローチは、技術書だけでなく、ドキュメント作成や説明全般に応用できる重要な考え方だと感じました。
技術書のメンテナンスに関するセッションを聴講していたはずなのに、手法から考え方に至るまで、まるでソフトウェア開発のベストプラクティスを学んでいるような不思議な感覚でした。jsprimerの10年の歴史から、継続的なメンテナンスの重要性とその方法論を学べる非常に有意義なセッションでした。
(kishikawa)
君だけのオリジナル async / await を作ろう
ES2015で標準化された言語機能の一つであるジェネレータに焦点を当てたセッションでした。ジェネレータとは、ジェネレータ関数 function*とyieldキーワードを使用して、イテレーションを手続き的に記述できる機能です。
そのなかでもジェネレータ関数の中断・再開の仕組みや構文が async / await に非常に似ていることに着目し、独自の async / await を実装する方法が解説されました。その上で、型を付けるためにyield*を挟んで型を明示的に指定するといった工夫が紹介されました。
私は普段ジェネレータを使ったコードを書くことは少ないですが、ジェネレータの動きについて深く理解できる面白いセッションでした。
(kishikawa)
"良い"TSのコードを書く為のマインドセット
TypeScriptの本質について深く考えさせられるセッションでした。TypeScriptがstatic (Javaなど) とdynamic (JavaScript) の中間に位置し、動的言語であるJavaScriptとの親和性を高めるために構造的型システムを採用しているという設計思想を再確認できました。 TypeScriptの共同創案者であるAnders Hejlsbergの言葉を引用し、設計思想からJavaScriptとの関係性を理解することの重要性が強調されていました。
"TypeScript is structurally typed by design. It's what makes it useful in the wild west of JavaScript." TypeScriptが構造的型システムを採用しているのは、意図的な設計です。それこそが、JavaScriptという"西部開拓時代"のような自由すぎる世界で、実用的に使える理由なのです。
セッションのなかでも特に重要と感じたのが、健全性 (Soundness) と実用性 (Usability) のトレードオフについての考え方です。TypeScriptは「実行前のコード (型) が実行中にも同じ状態である」という健全性を追求することも、アサーションやanyなどを駆使し短いコードで動く実用性を追求することもできる言語であるという点が丁寧に解説されていました。組織にあった堅牢性、健全性、実用性のバランスを意識的に取ることが重要であり、TypeScriptを使う上で単に型を付けるだけでなく、SoundnessとUsabilityのバランスを意識することの重要性を学べる内容でした。
(kishikawa)
ブースに訪れた感想
TSKaigi 2025にはスタンプラリーがあり、また会場移動時の導線内にスポンサーブースが配置されていたため、各社のブースを訪れる機会が多くありました。型に関するクイズや開発手法に関する質問を出展しているブースが多く、お祭りのような雰囲気でした。現場でのTypeScriptの活用方法や、型安全な開発手法についての情報交換ができる貴重な機会であるとともに、開発にかける情熱を感じることができました。
昼食について
会場では参加者向けにお弁当が提供されていました。私 (kishikawa) はこういった技術イベントで食事が提供されるのは初めてだったのでとても驚きましたが、セッションの聴講や参加者同士への交流に集中できるような配慮がされていると感じました。お弁当は種類が豊富に用意されており美味しかったです。
全体を通して
TSKaigiでされた発表を通して改めてTypeScriptの知見を深めることができました。
さらにブースなどでTypeScriptを含めたフロントエンドのお話をさせていただくことができ、フロントエンドの楽しさや難しさを改めて感じることができたイベントでした。
stmnさまがサイドイベントとして用意されていたTSKaigi 2025 re:Cap in Nagoyaにも参加し、あらゆる形でTSKaigiを楽しむことができました。
来年も開催された際には、参加したいと思いました。
We're hiring!
DIGGLEではともにプロダクトを開発してくれるエンジニアを大募集中です。
少しでも興味があれば、ぜひ下記採用サイトからエントリーください。 カジュアル面談も実施しているので、気軽なお気持ちでご応募いただければと思います！
