学生旅費支援でTSKaigi 2026に行った話

小林碧唯（AoiKobayashi）です。2026年5月22日・23日に羽田で開催されたTSKaigi 2026に、学生旅費支援制度を使って現地参加してきました。

普段はハッカソンに出たり、インターンでTypeScriptとNext.jsを書いたりしている専門学生です。手は動かしているんですが、白状すると、これまでの自分はTypeScriptを使っているだけでした。型推論もLSPもビルドも、毎日ありがたく使っているのに、その裏で何が起きているかはほとんど知らなかった。

そのままの状態でこのカンファレンスに飛び込んだら、2日間でTypeScriptの裏側にひたすら殴られて帰ってくることになりました。せっかくなので、その熱が冷めないうちに書き残しておきます。

なお、この記事は学生旅費支援制度で参加した立場で書いています。支えてくださったスポンサー企業・運営の方々への感謝も込めて。

TSKaigi 2026 とは

TSKaigi 2026 は、日本最大級のTypeScriptをテーマにした技術カンファレンスです。今回は羽田（ベルサール羽田空港・羽田エアポートガーデン周辺）で2日間にわたって開催されました。

掲げられていたミッションは「学び、繋がり、"型"を破ろう」。コンパイラ設計の踏み込んだ話から、AIコーディングエージェント、フロントエンドのアーキテクチャ設計まで、TypeScriptを軸に扱う領域がとにかく広い。

規模もすごくて、最終日に知ったんですが現地参加者だけで800名を超えていたそうです。TSKaigiとしては過去最大級だったらしく、会場に入った瞬間の人の多さで「想像してたやつと違うぞ」となりました。

• 日程: 2026年5月22日(金)・23日(土)
• テーマ: TypeScript
• 規模: 現地参加者800名超、オンライン参加も多数、スポンサー多数

---

参加のきっかけ

きっかけは、Xで流れてきた学生旅費支援制度の告知でした。

技術カンファレンスにはずっと興味があったんですが、学生だし、お金も掛かる、なんとなく一歩を踏み出せずにいました。そこに旅費まで支援してくれる制度があると知って、これは行くしかないなと。普段からTypeScriptをよく書いていて好きな言語だったので、招待をいただけたときは素直に嬉しかったです。

先に書いておくと、この一歩を踏み出して本当に良かったです。

---

事前オンライン顔合わせ会

開催の２日前に、学生支援対象者と企業紹介とオンライン交流会がありました。内容は支援企業の紹介と、オンライン交流会です。

企業紹介では、名前は知っていたけど何をやっているか曖昧だった会社の事業内容が聞けたり、まったく知らなかった会社のプロダクトを知れたりしました。オンライン交流会では、紹介いただいた会社様の中から2社がランダムに割り当てられました。学生も数人のグループに分かれて、15分ほどその会社の働き方などを聞くことができました。学生同士でも、同年代の人や同じ学生支援で来る人が事前に分かるので、開催当日に「あ、あのとき話した人だ」となれて気が楽でした。

---

Day 1

会場に着いてまず圧倒されたのは、セッションよりも企業ブースの熱気でした。気になるセッションには目星をつけていたはずなのに、ブースの数と人の多さに飲まれて、一瞬セッションのことを忘れてブースに夢中になっていました。

企業ブースとスタンプラリー

数多くの企業ブースが出展していて、くじ引きやクイズ、サービスデモなど、各社の企画が本当に多彩でした。技術書やHHKBが当たるくじを引けるブースもあって、ブースだけでセッションに負けないくらい盛り上がっていた印象です。

ブースを回ってスタンプラリーを集めると抽選に参加できる仕組みになっていて、初日は抽選条件のスタンプ数を目指して無心でブースを巡っていました。

ただ、巡って良かったと思ったのは、抽選やノベルティ目当てというより、各社がどんなプロダクトを作って、どんな技術的な課題と戦っているのかを中の人から直接聞けたことです。実務でTypeScriptがどう使われているかを肌で聞けるのは、現地ならではでした。

また、今使ってるサービスの会社の方や、ワークショップでお世話になった会社様もいていろんな方としゃべることが出来ました。

印象に残ったセッション（Day 1）

ここからは、自分が実際に聞いたセッションの中から特に刺さったものを紹介します。スライドの写真も撮ってきたので、できるだけそのまま載せます。

業務に残された「よくない型」で考える「TypeScriptの難しさ」（Saji さん）

実務で as や unknown、any がどうしても残ってしまう現実から、TypeScriptの難しさを考えるセッション。

特に刺さったのが、型の問題を「境界由来か内部由来か」「安全圏に押し戻せるか」で分類する視点でした。as って単なる逃げみたいに扱われがちなんですが、コンパイラの推論限界を人間が補う手段なんだ、という捉え方は実務で効きそうだなと。型を信仰しすぎない感覚を持てたのが収穫でした。

権限チェックの一貫性を型で守る TypeScript による多層防御（北川直昭 さん）

権限制御（認可）って、画面・API・DBそれぞれでチェックが必要で、どこかで漏れると事故るやつですよね。それを型で一貫させて多層防御する、という話でした。

権限チェックが漏れていたらコンパイルが通らない、という状態を型で作る発想がよかったです。認可を人間の注意力じゃなくコンパイラの制約に落とし込む方向性は、聞いていて気持ちよかった。

TypeScript と Angular Signal で実現する保守性の高いアプリケーション設計（たつかわ さん）

3層アーキテクチャによる責務分離の実践。コンポーネントにロジックを全部詰め込んでFat化するの、自分もインターンやチーム開発でよく悩むところなんですが、その対策として各層の責務を型で厳密に分けるという話でした。

特に「データアクセス層はHTTPと命名変換（camelCase → snake_case）だけに専念する」という割り切りが綺麗で。どの層がどこまで知っていいかを型で縛って、「この層はこれ以上の知識を持たない」をコンパイラで保証する。理想論で終わらせずに制約に落とし込んでいるのが良かったです。

// データアクセス層: HTTP と命名変換に専念
@Injectable({ providedIn: 'root' })
export class UpdateUserAPIService {
  private readonly http = inject(HttpClient);

  updateUser(params: UpdateUserParams): Observable<UpdateUserResponse> {
    const requestData = this.mapToApiRequestFormat(params); // camelCase → snake_case
    return this.http
      .put<UpdateUserResponse>(this.apiUrl, requestData)
      .pipe(catchError(this.handleError));
  }
  // UpdateUserParams（フロント型・camelCase）と UpdateUserRequest（API型・snake_case）を別の型として定義
  // 命名規則の違いは「この層のみ」が知っている
}

OSSのコードベースにneverthrowを漸進的に導入して、AIにも人間にも優しく（IkedaNoritaka さん）

エラーハンドリングを try/catch の例外じゃなく、Result 型（neverthrow）で「失敗を型に乗せる」話。スライドで挙げられていた主張が腑に落ちました。

• Result 型は失敗した型を定義できるので、エラーを握り潰さない
• .andThen() チェーンで逐次処理の可読性が上がる
• チームでよく議論して学習コストを乗り越える
• AIモデルの進化で、過剰なガードレールなしでもneverthrowを使える

一番面白かったのが、neverthrowを入れたことで「AIが安易にエラーを握りつぶさないので、デバッグが楽になって開発が楽になった」という効果でした。型でエラーを明示することが、人間だけじゃなくAIへの指示としても効く。そういう時代なんだなと。

アンチパターンを避ける型駆動React最適化（Kazuya Serizawa さん）

Day1で一番「そういうことか」となったセッション。React Compilerが最適化してくれるかどうかの判定基準が、突き詰めるとそのコンポーネントが純粋に書けているかどうかだ、という話でした。

コンパイラは「何が変わると何が変わるか」を見ていて、user や theme が参照等価で変わらなければJSX全体をキャッシュできる。だから、副作用やミュータブル操作をrenderの外に追い出すことが最適化に乗る条件になる。

// 最適化される（純粋）
function Total({ items }) {
  const total = items.reduce((a, b) => a + b.price, 0);
  return <p>{total}</p>;
}

// 最適化されない（render中に副作用）
function Total({ items }) {
  let total = 0;
  items.forEach(i => { total += i.price; });
  logger.info(total); // この副作用が"諦め"の原因
  return <p>{total}</p>;
}

「render中のI/Oと let / push を見直す」というスライドでは、NGとOKが並べられていてイメージしやすかったです。

// A. 副作用の混入
function Now() { const t = Date.now(); return <p>{t}</p>; }   // NG
function Now() { const t = useNow();  return <p>{t}</p>; }   // OK

// B. ミュータブル操作
const sorted = items; sorted.sort((a, b) => a.id - b.id);    // NG（props.items を破壊）
const sorted = [...items].sort((a, b) => a.id - b.id);       // OK

renderは値を返す関数であって、副作用は useEffect やイベントハンドラ、専用フックに切り出す。フレームワークの最適化に乗れるかどうかは結局、自分が純粋に書けているかで決まるんだな、というのが一番腑に落ちました。自分でもコンパイラの中身を追って、ちゃんと最適化に乗れているか確かめてみたくなりました。

TypeScriptの型だけでオセロを完全実装する ── 型は"仕様"をどこまで語れるか（籏野 拓 さん）

オセロの合法手や盤面進行みたいな複雑な仕様を型だけで表現する、というセッション。控えめに言って技術力がバグってました。

ただ、これは単なるネタではなくて、TSの型システムが「データ構造の定義」を超えて「仕様そのものを記述する言語」に近づいている証拠なんだと思います。型が形から言語へ寄っていく感じで、こういう突き抜けた発表に触れられるのは現地のいいところでした。

---

幕間 — ごはんとホテル

スカラシップランチ

Day 1のお昼はスカラシップランチ。支援企業のエンジニアの方と学生数名で、ビュッフェ形式の交流ランチでした。

「学生向けランチ」と聞いていたので軽食を想像していたら、出てきたのは普通にホテルビュッフェ。種類も多くて美味しかったです。食べながら企業の方に事業内容やプロダクト開発の難しさやAIの使い方を直接聞けて、これが良かった。こういう偶然の組み合わせで生まれる会話って、オンラインだと発生しないんですよね。それを全部スポンサー企業さんに支えてもらっているのは、ありがたい限りです。

Day 1 の夜ごはんはしゃぶしゃぶ

Day 1の夜は、友達としゃぶしゃぶを食べに行きました。タッチパネルで注文して、ポン酢とゴマだれを並べて、肉をしゃぶしゃぶしながら、その日聞いたセッションの話で盛り上がる。1日インプットした直後に、それを誰かと話しながら消化できる時間が良くて、これも現地に来たからこそだなと思いました。

---

Day 2

Day 2は、Day 1で回りきれなかったブースを制覇しつつ、気になるセッションをしっかり聞く方針で動きました。コンパイラ・型・アーキテクチャの濃いセッションが多くて、頭がずっとフル回転でした。

Day 2 のお弁当

Day 2のランチはお弁当でした。これが想像以上にちゃんとしていて感心しました。

そぼろと錦糸卵の二色ごはんに、唐揚げ・コロッケ・シューマイ・だし巻き・煮物と品数が豊富。しかも味が濃すぎず脂っこすぎず、食べ終わったあとに眠くならない。長時間座ってセッションを連続で聞くイベントで、午後の集中力を奪わないお弁当って、地味によく考えられているなと思いました。

印象に残ったセッション（Day 2）

React の props は値の集合ではない ── UI の状態を宣言するコンポーネント設計（nabeliwo さん）

propsを「ただの値の入れ物」ではなく「UIの状態を宣言するもの」として捉え直す設計の話。ありえない状態を型で表現できないようにする（make illegal states unrepresentable）方向で、コンポーネント設計の見方が少し変わりました。

Real World Effect-TS: 堅牢なプロダクトを型で組み上げる（asa1984 さん）

Effect-TS という、エラーハンドリング・DI・非同期処理をオールインワンで提供するライブラリの実践話。Effect<A, E, R> という型で、成功値（A）だけでなく失敗（E）と依存（R）まで型に乗せるのが特徴です。

スライドでは、Effect-TSの pipe / andThen を素のTypeScriptの if / early-return に書き換える before/after が並べられていて分かりやすかったです。

// Before — pipe / andThen
export const OrderRepository = {
  save: (order: Order) =>
    pipe(
      OrderQuery.findByUserAndProduct(order.userId, order.productId),
      Effect.andThen(existing => {
        if (existing) return Effect.fail(new OrderRepoError('Duplicated'));
        return Effect.succeed(order);
      }),
      Effect.andThen(OrderCommand.insert),
    ),
};

// After — if / early-return（素のTypeScriptで）
const save =
  (dep: { orderCommand; orderQuery }) =>
  async (order: Order) => {
    const existing = await dep.orderQuery.findByUserAndProduct(/* ... */);
    if (!existing.success) return Result.failure(/* ... */);
    if (existing.value) return Result.failure('...Duplicated' as const);
    return dep.orderCommand.insert(order);
  };

Effect.fail(new Error) を Result.fail('...' as const) に、暗黙DI（Context.Tag）を明示DI（関数引数 dep）に、と対応づけながら、Effect-TSと心中する覚悟が要るかどうかを現場目線で問い直す話で、トレードオフの議論が面白かったです。

ts-morph でプロジェクト固有のアーキテクチャガードレールを作る（msuto / Michimasa Suto 氏）

ts-morph（TypeScript Compiler API のラッパー）で抽象構文木からコードを構造として読み取り、プロジェクト固有のアーキテクチャルールをCIで自動検出する仕組みの話。

人の手間を仕組みで減らす思想に共感しました。一方で、独自ルールだからこそ、最初に検知スクリプトをどれだけ作り込むか、テストケースをどれだけ用意するかがCIの質を左右する、という現実的な話もあって勉強になりました。

いつテストを書くか？──ソフトウェア開発における安心と不安について考える（lacolaco さん）

内部品質が高い（high internal quality）コードは、最初こそ立ち上がりが少し遅いが、その後はより速く、しかも安く機能を届けられる。そしてこの分岐点は数ヶ月後ではなく数週間後に訪れる。

このセッションはコードがほとんど出てこなくて、それでいて一番本質的でした。テストの捉え方も変わって、今までは「とりあえず書いて、通ればOK、CIを通す」くらいの認識だったんですが、「テストは開発者の不安を取り除くためのもの」という話で見え方が変わりました。

そのテストが何を保証しているのか、壊れたときに原因が分かるのか。そこまで設計されていないと、あっても意味が薄い。安心と不安という軸でテストを語るのが、自分にはしっくりきました。

---

懇親会

Day 2の夜は懇親会。正直、ここが一番記憶に残っているかもしれません。

ビュッフェが用意されていて、和食からイタリアンまで多彩。さらに寿司職人がその場で握ってくれる寿司まで出てきて、もうイベントの規模感が分からなくなりました。一口目で「うまっ」と声が出るレベルで、懇親会というより寿司屋でした。

でも何より良かったのは、会話がずっと技術トークだったことです。

• AIが出る前と今で開発がどう変わったか
• 普段どういう開発をしているか
• なんで今日TSKaigiに来たのか
• サマーインターンについて

こういう話が途切れず続いて、まったく飽きませんでした。技術の話だけでこんなに盛り上がれる場があるのか、と素直に感心しました。技術というより、人のつながりの密度が高い空間だったと思います。

---

全体を振り返って

今回いちばん感じたのは、自分はTypeScriptを使っているだけで、その裏側をほとんど知らなかったということでした。「どうすれば変更し続けられるソフトウェアになるか」という実際のプロダクト開発の課題につながっていたのが、一番の発見でした。型もテストも静的解析もアーキテクチャも、結局は安心して変更し続けられる状態を作るために存在している。今回の2日間、自分は「どう作るか」以上に「どう変更し続けられるか」を見ていた気がします。

もうひとつ強く感じたのが、オフラインで参加する価値でした。セッションの熱はもちろん、人との偶然の出会い、ごはん、懇親会、ノベルティ、会場の空気、移動の時間。現地に行ったから生まれた体験が大きかったです。「またどこかのカンファレンスで会いましょう」みたいな会話が自然に出てくる感じは新鮮で、技術イベントというよりコミュニティそのものを体験している感覚に近かったです。

---

おわりに

こういう経験ができたのは、学生旅費支援制度を運営・支援してくださったスポンサー企業の方々と、TSKaigi運営の方々のおかげです。ありがとうございました。ごはんも宿泊も移動も全部支えていただいて、学生のうちにこの場に来られたこと自体、貴重な経験だったと思っています。

TSKaigi 2026 学生旅費支援企業（五十音順）

• 株式会社アイスタイル
• 株式会社アサイン
• 株式会社SmartHR
• ソフトバンク株式会社（satto事業開発本部）
• 株式会社ドワンゴ
• 株式会社プレイド
• 株式会社LayerX
• レバレジーズ株式会社

技術カンファレンスに興味はあるけど踏み出せていない学生の方へ。自分もずっと「行きたいけど」で止まっていた一人でしたが、一歩外に出るだけで見える景色は変わります。TSKaigiに限らず、機会があればぜひ。

次回は TSKaigi Sendai が開催されるそうです。学生支援があるなら、また行きたいです。最高の2日間でした。ここまで読んでいただき、ありがとうございました。