こんにちは！ファインディの大石（@bicstone）、甲斐（@karukan013L23）、千田（@_c0909）です。先日、ファインディはベルサール羽田空港で開催された「TSKaigi 2026」に協賛しました。
今回はDevRelメンバーとフロントエンドエンジニア3名で参加し、ブース運営を行いました。本記事ではTSKaigi 2026において印象深かったセッションの紹介や登壇、ブース出展などの活動内容を紹介します。
ブースで実施したユーティリティ型アンケートの集計結果（480票）も後半で公開していますので、ぜひ最後までお読みください。
TSKaigi 2026について
TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。東京都大田区のベルサール羽田空港にて、2026年5月22日(金)〜23日(土)に開催されました。
印象深かったセッション
興味深いセッションが多くありましたが、その中でも3名それぞれが印象に残ったセッションを紹介します。
【大石】TS 7: How We Got There
TypeScriptチームのJake Baileyさんによる、TypeScript 7をGo言語へ移植した経緯と成果についての基調講演です。
特に印象的だったのは、Goを採用した理由を体系的に知ることができた点です。
JavaScriptではスレッド間でオブジェクトを共有できず、async/awaitが関数全体に伝播してしまうため、並列化が困難でした。
Goのgoroutineを活かすことで、Parse・Bind・Emitの各フェーズを並列化し、Checkerも複数並べることで高速化を実現しています。
VS Code (Electron) のプロジェクトをtscとtsgoそれぞれで実行した際の所要時間とCPU使用率の差を見せていただいたデモでは、マルチスレッドの活用やCPU使用率の変化が一目で分かり、なぜ大幅な高速化を実現できたのか直感的に理解できました。
発表のなかで繰り返し強く呼びかけられていたのが、コミュニティからのフィードバックでした。「ぜひbetaやnightlyを試してほしい」「VS CodeのNative Preview拡張を入れてほしい」「クラッシュやコンパイル挙動の変化、特にAPIへの意見を送ってほしい」と呼びかけていました。
過去1年でコミュニティから1141件のIssueと1487件のマージ済みPRが寄せられ、テレメトリ経由のクラッシュ情報も含め、利用者からの報告が開発の方向性を支えていることが伝わってきました。
私たちのチームでは、すでにコミット時のフックでtsgoを試験的に採用しています。今後は開発フロー全体への導入を進めながら、検知した問題は積極的にフィードバックを送っていきたいです。
ファインディでも従来からOSSへのIssue起票やPull Requestの作成、メディア企画を通じた寄付などの形で支援を続けてきましたが、TypeScriptのように多くの利用者を抱えるプロジェクトでは、利用者一人ひとりの報告こそが大きな貢献になることを再認識しました。
これまで断片的にしか追えていなかったTypeScript 7について体系的に理解でき、とても学びの多い発表でした。社内にもぜひ共有していきたいと思います。
【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか
Denoのmaguroさんによる、DenoのTypeScript基盤をtscからtsgoへ移行する取り組みについてのセッションです。
元々DenoはTypeScriptをフォークしたパッケージを使用し、Deno Rust側と必要な情報をやり取りし、Deno固有の概念をtscが解釈できるよう、tscにパッチを当てたものをDeno binaryの中に埋め込んでいました。
tsgoへの移行の最初のアプローチはtsgoをフォークし、Deno固有の概念をtsgoに渡せるようにするアプローチでした。
tsgoはDeno固有の概念をそのまま解決できないため、Deno Rust側で処理できるよう対応しています。LSP対応のコスト、フォークしたパッケージのメンテナンスコストが高く、現在はフォーク版ではなく公式のTypeScriptパッケージを利用するアプローチが試みられています。
TypeScript向けにDenoの依存と型をローカル生成することで、パッチを当てずにDeno固有の概念を解釈できる構成にしています。
特に印象的だったのは、DenoのWeb標準の哲学を少し曲げてでもTypeScriptで扱える形に寄せていった点です。Deno binaryの中→Deno binaryの外→Deno projectの外へTypeScriptパッケージが押し出されており、フォークによる運用コストの増加を避けつつ実行可能なアプローチをとっています。
型チェックを使用したい他のライブラリも同様にフォーク以外の選択肢を模索しており、方向性は同じだがそれぞれ異なるアプローチになっていることが興味深かったです。
普段Denoは使用していませんでしたが、現在の形に辿り着くまでにどのような意思決定があったかを見ていくことで、ここに至るまでの課題や意思決定ごとのトレードオフを学ぶことができ、現在の思想を理解する助けとなりました。
今後もツールチェーンやライブラリの意思決定の背景を学ぶ機会を定期的に設けていきたいなと思います。
【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？
株式会社うるるの藤田翔雅さんによる、OxlintがESLint / typescript-eslintをどこまで置き換えられるのかを整理したセッションです。
特に印象的だったのは、Type-Aware Linting（型情報を使ったLint）の有無でパフォーマンスが大きく変わる点をベンチマークで示していたことです。
型情報を使わない比較ではESLintの8.213秒に対しOxlintは0.304秒と約27倍速く、型情報を使うルールを有効にしてもESLintの16.121秒に対しOxlintは0.807秒と約20倍速いという結果でした。
型情報を使わないLintが構文解析だけで完結するのに対し、型情報を使うLintはプロジェクト全体の型グラフ構築（tsc/tsgo）を必要とするためボトルネックになる、という構造的な解説も理解の助けになりました。
導入判断についても踏み込んでおり、型情報を使わないLintであればOxlintは主要ルールを十分カバーしており移行は現実的である一方、oxlint-tsgolintによるType-Aware Lintingはまだ非安定版であること、カスタムルールを抱えるプロジェクトでは移行コストが上がることなど、現場目線のトレードオフが具体的に語られていました。
結論として、非Type-Aware LintingであればOxlintへの移行を推奨するというメッセージが明快でした。
私たちのチームでもESLint + Prettierを利用しており、CIの実行時間は継続的な課題です。すでにOxc系（Oxlint + Oxfmt）への移行を計画しており、既存のプロダクトはType-Aware Lintingに依存しない構成となっています。
本セッションの「非Type-Aware LintingならOxlint移行を推奨」という結論は私たちの状況に当てはまり、実際の移行計画に重ねて考える良い機会になりました。
【大石】CfP登壇: TypeScript 6.0での型推論修正を追う
当日のCfP枠では、大石が「プロパティの順序で型推論が壊れる!? TypeScript 6.0の修正からContext-Sensitivityの仕組みを追う」というタイトルで登壇しました。
プロパティの記述順序を入れ替えるだけで型推論が壊れる挙動を入口に、TypeScript 6.0でマージされたPRの中身まで踏み込んだ内容です。詳細は別記事にまとめていますので、あわせてご覧ください。
ファインディの活動
ファインディはGoldスポンサーとして協賛し、ブース出展という形で支援しました。
ブースでは「よく使うユーティリティ型」をテーマにしたアンケート企画を実施しました。普段の開発でよく使うユーティリティ型を選んでいただく内容で、2日間かけて多くの方に投票いただきました。
x.comTSKaigi2026始まりました！入口すぐです！
— いわさき@Findy DevRel (@iwasakitchen) 2026年5月22日
お待ちしております🌟#TSkaigi2026 #tskaigi pic.twitter.com/ecf1Zzok0V
アンケートの最終結果はこちらになります。たくさんの投票ありがとうございました。
x.comTSKaigi 2026改めて2日間ご参加いただき、ありがとうございました！よく使うユーティリティの「型」は？の最終結果です！😊🎊#TSkaigi #TSkaigi2026 pic.twitter.com/0Nt4xun2bQ
— いわさき@Findy DevRel (@iwasakitchen) 2026年5月23日
アンケート結果
総数：480票
| 順位 | ユーティリティ型 | 割合 | 票数 |
|---|---|---|---|
| 1位 | Record<Keys, Type> |
33.3% | 160票 |
| 2位 | Pick<T, Keys> |
17.7% | 85票 |
| 3位 | Readonly<T> |
14.6% | 70票 |
| 4位 | Partial<T> |
9.4% | 45票 |
| 5位 | ReturnType<T> |
8.8% | 42票 |
| 6位 | Exclude<T, U> |
4.2% | 20票 |
| 7位 | Extract<T, U> |
2.5% | 12票 |
| 8位 | NonNullable<T> |
2.5% | 12票 |
| 9位 | Awaited<T> |
1.0% | 5票 |
| - | その他 | 6.0% | 29票 |
その他内訳
| ユーティリティ型 | 票数 |
|---|---|
| その他・使っていない | 22票 |
Omit<T, Keys> |
5票 |
Beautify<T> |
1票 |
&、| |
1票 |
加えて、マーケティング担当のメンバーがAIを活用して自ら開発したルーレットアプリと、ファインディオリジナルのノベルティをご用意し、立ち寄っていただいた方に楽しんでいただきました。
さいごに
セッションは多岐にわたるなかで、私たちが特に注目したのはGoによるコンパイラの再実装（コンパイラ本体のネイティブ化）、tscからtsgoへの基盤刷新（他ランタイムによる採用）、Rust製Linterの可能性（周辺ツールへの波及）でした。
3つを通して、TypeScriptエコシステムがNative実装へと動いている流れを実感する2日間となりました。TSKaigiはとても温かい素敵なコミュニティで、いち参加者としても多くの学びと交流の機会を得ることができました。
カンファレンスの開催にあたりご尽力いただいた、運営スタッフの皆様、関係者の皆様、登壇者の皆様に感謝申し上げます。
お知らせ
同日参加したファインディのDevRelメンバーによるレポート記事も公開されています。あわせてご覧ください。
TSKaigi 2026のアフターイベント「TSKaigi Night talks 〜after conference〜」をスポンサー企業9社で共催します。当日のCfP枠で採択されなかった知見もコミュニティへ還元することを目的としたイベントです。
ファインディからは千田が「OSSのUIライブラリでESLintのカスタムルールを作っている話」、甲斐が「Temporal - TypeScript 6.0で始める新しい日時API」というテーマで登壇予定です。
2026年6月10日(水)19:00から、ファインディのイベントスペースにて開催します。TSKaigi 2026に参加された方も、参加できなかった方も、ぜひお越しください。
ファインディでは一緒に働くメンバーを募集しています！
興味がある方はこちらから ↓ herp.careers
