TSKaigi 2026に協賛・参加してきました

TypeScript Event
このエントリーをはてなブックマークに追加 follow us in feedly

Tech Blog: TSKaigi 2026

はじめに

こんにちは。重道、高橋、上山、白木、遠藤です！

今回は、TSKaigi 2026に協賛・参加してきましたので、カンファレンスの様子や印象に残ったセッションについて紹介します。

今年のTSKaigiでは、OPTiMはブロンズスポンサーとして協賛させていただきました。 さらにはTSKaigiの登壇者として、弊社からもエンジニアがカンファレンスで登壇しました。

弊社のエンジニアが、国内最大級のTypeScriptカンファレンスで登壇しているのを見て、とても刺激を受けました。また、技術的な知見を社外へ発信できていることも、とても嬉しく感じました。

この記事では、会場の雰囲気や印象に残ったセッションについて紹介していきます。

TSKaigi 2026について

TSKaigiは、TypeScriptに関するさまざまなテーマを扱う国内最大級のカンファレンスです。

今年も、TypeScript Compilerや静的解析、型システム設計、AI活用など、TypeScriptを軸にした幅広いテーマのセッションが数多く開催されていました。

特に今年は、AIエージェントとの協働や、AI時代における型・静的解析の価値をテーマにしたセッションが多く、会場全体としてもかなり盛り上がっていた印象です。

また、弊社はブロンズスポンサーとして協賛させていただきました。

OPTiMメンバーの登壇

今回のTSKaigi 2026で登壇した、弊社のエンジニアのセッションを紹介します。

TypeScriptでドット絵エディタ実装録: 状態設計と実装判断

登壇者: つくだに

本セッションでは、TypeScriptとCanvas APIを用いて開発したWeb上のドット絵エディタを題材に、「高機能なエディタを作る」のではなく、「シンプルで触りやすいエディタを実現する」という視点から、機能要件をどのように設計へ落とし込んだかが紹介されました。

セッションでは、直線描画や塗りつぶし、レイヤー機能といったドット絵エディタの基本機能をどのように実装したのかが解説されました。特にレイヤー機能については、複数レイヤーを毎回合成して描画するのではなく、「描画したピクセルが最前面のレイヤーに存在するか」という情報を保持することで、不要なレイヤー走査を削減し、効率的に描画をする工夫が紹介されました。

また、一般的な描画アプリで採用される複雑な実装をそのまま持ち込むのではなく、アプリの目的や規模に合わせて必要十分な設計を選択していた点も印象的でした。

感想としては、レイヤー機能については必要に応じて複雑なロジックを採用する一方で、塗りつぶし機能についてはシンプルな実装を選択していた点が印象的でした。

特に、ドット絵エディタでは扱うピクセル数が限られているため、一般的には懸念される再帰処理のコストも呼び出し回数が過剰に多くならなければ実用上は問題になりにくく、「要件に対して十分かどうか」という観点で実装方法を選択していることがよく伝わってきました。

開発では、機能ごとにベストプラクティスとされる実装手法や一般的な設計を採用したくなることがあります。しかし実際には、アプリケーションの規模や利用シーンによって求められる要件は異なります。このセッションを通して、まず解決したい課題を明確にし、その要件に対して適切な実装を選択することの重要性をあらためて学びました。

(重道 記)

印象に残ったセッション

TanStack Router の型定義を読み解く

登壇者: IORIさん

本セッションでは、TanStack Routerの型定義を題材に、型安全なルーティングを支えるTypeScriptの仕組みについて解説されました。

TanStack Routerでは、ルート定義をもとに型安全なルーティングを実現しており、定義されていないパスを利用した場合はコンパイルエラーとなります。例えば、"/users" と定義されているルートに対して、誤って "/uers" のようなtypoを含むパスを指定した場合でも、実行時ではなくコンパイル時に検知できます。これにより、パスのtypoや誤った移動先の指定を防ぐことができます。

また、パス文字列からパスパラメータの型を自動的に推論できる点も特徴です。例えば、"/user/$id/posts/$postId" のようなルートを定義すると、idとpostIdがパスパラメータとして型情報に反映されます。そのため、postIdが必要な場面で誤ってcommentIdを渡してしまうようなミスもコンパイル時に検知できます。こうした仕組みによって、安全性だけでなく開発者体験（DX）の向上にもつながっています。

普段はTanStack Routerを利用する機会があまりなかったため、型安全なルーティングという特徴についても漠然とした理解しかありませんでした。しかし、ルート定義から型を導出し、パスのtypoやパラメータ指定のミスをコンパイル時に防ぐ仕組みを知り、その利点を具体的に理解できました。

(重道 記)

セッション: TypeScriptバックエンドのオブザーバビリティ戦略 — Datadog × NestJSの実践

speakerdeck.com

登壇者：山本大星さん

運用を担当する身として、「アラートの原因がすぐにわからない」という辛さには共感する方も多いのではないでしょうか。このセッションでは、NestJSバックエンドにDatadogを導入し、オブザーバビリティを整備していった実践事例が紹介されました。

特に印象に残ったのは、ベテランと新人のあいだにあるアラート対応の認識ギャップです。「いつも出るアラートだから無視してよい」というベテランの暗黙知は、新人には伝わりません。この課題に対して、オブザーバビリティの基盤を整え、状況を判断しやすくするというアプローチが示されていました。OnCallや保守の業務を担当した経験がある身としても納得感があり、Ask The Speakerの場でも複数の参加者が同様の課題意識を示していたのが印象的でした。

そのうえで私は、判断しやすい状態を作れたら、次は判断基準そのものを明文化することが重要だと感じました。判断基準が明記されたら、人だけでなくAIも扱いやすくなり、より自律的な運用につなげやすくなるはずです。

Ask The Speakerでは、外形監視（Synthetics）の運用方法についても質問しました。5分おきに簡潔なシナリオを実行し、毎週網羅的なテストを回すというアプローチを採用しているようです。外形監視をスモールスタートで始める際の実践例として参考になりました。

技術面では、ログとトレースを結び付けるために span_id と trace_id をログへ付与する重要性が強調されていました。また、「ツールを導入するだけでは不十分で、アプリケーション側の改修も必要」というメッセージも印象に残っています。

弊社には独自のオブザーバビリティ基盤があり、ログの構造化から始めれば、ログ、トレース、モニターを整備しやすい環境があります。そのため、新規プロダクトでもこうした仕組みを早い段階で取り入れ、外形監視や判断基準の整備まで進めていきたいと感じました。

私自身、現在0→1フェーズのプロダクト開発に携わっていますが、立ち上げ期の開発組織ではログの構造化が後回しになりがちです。その結果、あとから運用で苦労する場面も少なくありません。このセッションで語られていた「最初の一歩はログの構造化」というメッセージは、そうした現場にこそ重要だと感じました。

(白木 記)

セッション: React の props は値の集合ではない — UI の状態を宣言するコンポーネント設計

登壇者: nabeliwoさん

このセッションでは、状態をうまく表現するためのコンポーネント設計の手法の発表がされていました。 コンポーネントを実装するにあたって、PropsにUIの状態を持たせる設計手法がよくあります。 例えば、以下のようなPropsが想定されます。

type Props {
    data?: Data;
    error?: Error;
    isLoading: boolean
}

しかし、このProps設計だと、例えば「isLoading=trueかつdataとerrorのどちらにも値が入る」といったあり得ない状態が宣言できてしまいます。 このような事象を防ぐためには Discriminated Union(判別可能なユニオン型)と呼ばれる手法を取り入れることで、型レベルであり得ない状態を排除できます。(下記の例では、「fetch成功時のみdataを持ち、失敗時はErrorオブジェクトを持つ。fetch中はオブジェクトを持たない」という状態のみ型レベルで許容されます。)

type Props = 
    | { status: "loading"}
    | { status: "success"; data: Data}
    | { status: "error"; error: Error}

先の例では、「ロード中」「データ取得成功」「データ取得失敗」の3つの状態が宣言されていますが、プロダクトで利用されるコンポーネントの状態の数(Props)はさらに複雑になります。(例えば、再フェッチの状態や、テーブルなどのページネーションの状態など) これらの大量の状態に対して、あり得る状態をDiscriminated Unionでひたすらに宣言することも可能ではありますが、かなり大変です。

このセクションでは、このような場合の対処としてコンポーネントの責務を適切に考慮・分割し、JSXの構造でコンポーネントの状態を表現する手法が紹介されていました。 例えば、Dataを表示するコンポーネントはあくまでfetchに成功したデータの表示のみをする責務とし、エラーやデータfetch中のコンポーネント制御の責務を別コンポーネントに移譲することで、コンポーネントのPropsだけでなく内部実装も簡潔にできます。

<ErrorComponent fallback={<ErrorMessage />}>
    <Suspense fallback={<LoadingIcon />}>
        <DataList />
    </Suspense>
</ErrorComponent>

「型レベルで不正な状態を許さないPropsの考慮や、実装するコンポーネントが負うべき責務の考慮が重要である」という発表内容は、実務でコンポーネント設計・実装をする上で非常に良いヒントになりました。

(遠藤 記)

ハンズオン（TSKaigi運営）

2026.tskaigi.org

講師：berlysiaさん(TSKaigiコアスタッフ)

TSKaigi運営主催のハンズオンに参加しました。

タイムテーブル上は3枠を使った、かなり長丁場のセッションでした。 参加者はそれぞれ自分のPCで、用意されたハンズオン用の問題回答Webアプリにアクセスし、berlysiaさんの解説を聞きながら型パズルを解いていきます。 さながら大学の実習講義のような時間でした。

実務では、必要に応じて個別に知識を積み上げていくことが多いですが、このハンズオンではステップ・バイ・ステップで問題が構成されていて、久しぶりに体系的な学習が出来ました。

また、とても丁寧に解説してくださっていたこともあり、当初の目標の半分ほどしか問題を消化できなかったとのことでした。 ぜひ第2講目を受けてみたいところです👀

(上山 記)

セッション：いつテストを書くか？ ソフトウェア開発における安心と不安について考える

登壇者：lacolacoさん

lacolacoさんは、ご本人がパーソナリティを務めるポッドキャスト「リファクタリングとともに生きるラジオ」でも、ソフトウェアアーキテクチャや設計原則、テストについてよく話されています。 普段からポッドキャスト話を聞いている方の発表を現地で聞けたのも、個人的にはうれしい体験でした。

「ソフトウェアは “ソフト” である。“ソフト” であるということは、変更容易性が高いということである」という導入から、変更容易性を高め、維持するための道具としてテストをどう使うか、という話が展開されました。

発表では、変更容易性を次のような独自の2層モデルで整理し、既存の設計原則と結びつけながら説明されていました。

  • 予期的変更容易性
    • コードに変更を加える前に抱く不安。
    • 「あそこの部分は触りたくないなあ…」
  • 経験的変更容易性
    • 実際に変更している最中に、コード側から受ける抵抗。
    • 「うわぁ、ここも書き直さなきゃ…」

そして、ソフトなソフトウェアとは、これら2つの変更容易性を両立できているソフトウェアだと定義されていました。

また、それぞれが開放閉鎖原則（Open Closed Principle）と対応しており、この2つを維持することがソフトウェアアーキテクチャの理想的な状態だという整理が示されていました。

  • 開放
    • コードが拡張に対して開いていること
    • 予期的変更容易性が高い状態
  • 閉鎖
    • コードが修正に対して閉じていること
    • 経験的変更容易性が高い状態

テストについては、段階的に導入する人のために、「まずはここから」の入口がどこなのかを示してくださいました。

  • 予期的変更容易性（開放）の観点
    • 変更が怖いときに書く
    • 実装を支えるテスト
  • 経験的変更容易性（閉鎖）の観点
    • プロジェクトの構造を知りたいときに書く
    • 設計を支えるテスト

とても面白いセッションだったので、ぜひ実際のスライドを見ていただきたいです。

(上山 記)

セッション：柔軟なPDFレイアウトエディタを支える型システム設計 — Discriminated UnionとConditional Typeの実践

speakerdeck.com

登壇者：minako-phさん

この発表は、複雑なドメインを型安全に扱うための実践的な知見が詰まった発表でした。「ドメインで表現したい制約を型でどこまで担保できるか」を徹底的に追求した設計が印象的で勉強になりました。

よくあるJSON構造をそのまま利用するのではなく、Protoを単一のSingle Source of Truthとして、すべての型をそこから派生させている点が斬新でした。 複雑な業務ルールをテストで担保する前に型制約で表現している点が素直にすごいと感じました。 それにより設計段階で不正な状態を排除できていると感じ、ドメインとして達成したいことがコード上で明確に表現されており、まさに「型が仕様書として機能している」がうまく働いている例だ！と納得がいきました。

中でも、_exhaustiveCheck: never パターンがコードベースの58箇所で使われており

Proto に oneof の case を1つ追加すると該当する default 節がすべてコンパイルエラーになって修正漏れを構造的に防げる

という仕組みは、「型が変更すべき箇所を教えてくれる」設計の好例だと感じました。 型によって状態移動やデータ構造が守られることで、結果的にフローの実装もシンプルかつテスタブルになっているのが印象的で複雑な仕組みを構築する際にはぜひ参考にしたいと思いました。

(高橋 記)

最後に

TSKaigiでは、多くの技術的な知見だけでなく、技術に向き合うモチベーションも得ることができました。また、OPTiMのエンジニアが登壇している姿を見て、大きな刺激を受けました。

弊社では、日々の業務の中でさまざまな技術的な挑戦や知見の蓄積が行われています。フロントエンド推進室といった組織を横断した知見や課題を共有、改善していく取り組みから、技術広報室という技術ブログやイベント、カンファレンスを通じて社外へ発信していく活動にも力を入れています。 今回TSKaigiに初参加し、得られた知見も多くこういった活動は重要だとあらためて感じました。私自身も今回得た学びを日々の開発に活かしながら、将来的には技術コミュニティへ貢献できるような発信に取り組んでいきます。

直近にはなりますが、TSKaigiのアフターイベントとして2026/06/18(木) 19:30 〜 22:00から4社協賛で「TSKaigi 2026 しか型ん！」というイベントを開催します。

リンク：https://optim.connpass.com/event/395349/

ぜひ参加お待ちしています！

OPTiMはTSKaigiだけでなく、RubyKaigiやGo Conferenceなど、さまざまな技術カンファレンスへの協賛や参加を予定しています。

OPTiMには、技術を通じてより良いプロダクトを作りたい、継続的に成長したいという思いを持ったエンジニアが多くいます。私たちも引き続き技術コミュニティへの貢献を続けていきます。

こうした環境に興味を持っていただけた方は、ぜひ私たちと一緒に挑戦してみませんか？

www.optim.co.jp