TSKaigi 2026 で話題をさらった3つの潮流 — TypeScript 7・AI×型駆動開発・Branded Types

TSKaigi 2026 とは

TSKaigi 2026 は、2026年5月22日（金）〜23日（土）にベルサール羽田空港で開催された、日本最大級のTypeScriptカンファレンスです。 約300件のプロポーザルから100名以上の登壇者が選ばれ、30分セッションと10分セッションの2本立てで多数のトークが並びました。

今年のタイムテーブルを眺めて強く感じるのは、議論の重心が大きく2つに割れていることです。 ひとつは 「言語処理系そのものの世代交代」。もうひとつは 「AIとどう向き合って型を書くか」。 この2軸が交差しながら、本記事で取り上げる3つの潮流を形づくっていました。

全体像：3つの潮流

数多くのトークを俯瞰すると、関心は大きく次の3つの潮流に収れんしていました。

flowchart TB
    T["TSKaigi 2026<br/>日本最大級のTSカンファレンス"]
    T --> C1["潮流1: TypeScript 7 / tsgo<br/>処理系のGoネイティブ移植"]
    T --> C2["潮流2: AI時代の型駆動開発<br/>型とAIの協働・テストの再定義"]
    T --> C3["潮流3: Branded Types<br/>型でドメインを縛り直す"]
    C1 --> C1a["キーノート: TS 7 How We Got There"]
    C1 --> C1b["tsgo / tsgolint / Flint / Oxlint"]
    C2 --> C2a["ビジネスモデル × 型駆動開発"]
    C2 --> C2b["いつテストを書くか？"]
    C3 --> C3a["堅牢な型付け・JSXの構造安全"]
    C3 --> C3b["ValueObject + Zod"]

順番に見ていきましょう。

潮流① TypeScript 7 / tsgo — 処理系がGoへ移る

今年の最大トピックは、間違いなく TypeScriptコンパイラのネイティブ移植 でした。 クロージングを飾ったキーノートは、Microsoftの Jake Bailey による 「TS 7: How We Got There」。 TypeScriptの処理系をJavaScriptからGoへ書き換える取り組みについて、その動機・移植手法・段階的なリリース戦略が語られました。

背景を振り返ると、Microsoftは2025年にコンパイラのGoネイティブport（通称「Project Corsa」）を公表し、 従来比 およそ10倍 のビルド・型チェック高速化を掲げました。 現行のJavaScript製コンパイラの集大成が TypeScript 6.0、そしてGo製ネイティブ版が TypeScript 7.0 という世代分けになっています。

「ネイティブ化」はエコシステム全体に波及した

注目したいのは、この移植が単なるコンパイラ単体の高速化に留まらず、 周辺ツール群を巻き込む地殻変動として複数のトークに現れていた点です。 キーノート以外にも、ネイティブ化を主題にしたセッションが目立ちました。

コンパイラがGoになり、リンタはRust（Oxlint）とGo（tsgolint）が混在する。 「TypeScriptツールチェーンの実装言語がJS/TS一色ではなくなった」という事実が、複数の角度から語られていたのが今年の特徴です。

# TypeScript 7 ネイティブプレビューを試す
npm install -D @typescript/native-preview

# 既存の tsconfig.json に対して実行
npx tsgo --project tsconfig.json

潮流② AI時代の型駆動開発

もうひとつの太い流れが、「AIエージェントが当たり前にコードを書く時代に、人間は型とどう付き合うのか」というテーマです。 型を「AIへの仕様の渡し方」「AI生成コードのガードレール」として捉え直す視点が、多くのトークに通底していました。

なかでも、複数の参加レポートで「一番よかった」と評されていたのが、 lacolaco（株式会社TwoGate） による 「いつテストを書くか？ — ソフトウェア開発における安心と不安について考える」です。

「いつテストを書くか？」が刺さった理由

このトークは、Agentic Coding（AIエージェントによるコーディング）が広がるなかで、 あらためて「テストを書く意義」を問い直すものでした。骨子は次のように整理できます。

• ソフトウェアの本質的な性質である 「変更容易性」 を補助線に置く
• 変更容易性を 予期的（これから来る変更への備え） と 経験的（実際に起きた変更からの学習） の2層で捉える
• 開放閉鎖原則（OCP）を「達成すべきゴール」ではなく 「漸近していく理想状態」 と位置づける
• テストとTDDは、そのOCPに徐々に近づくためのワークフローとして必要になる

「テストを書くべきタイミングは、変更容易性のどちらが阻害されているかで見え方が変わる」というのが、lacolacoの示した答えでした。 参加者からは 「TypeScriptに関連する発表という型にとらわれず、ソフトウェアそのものを考える切り口を示してくれた」 という評価が寄せられています。

潮流③ Branded Types ルネサンス

3つ目は、地味ながら今年「同時多発」していたテーマ — Branded Types です。 ひとつのカンファレンスで複数の独立した発表が同じテクニックを扱うのは、それだけ関心が集まっている証拠と言えます。

そもそもBranded Typesとは

TypeScriptの型システムは 構造的部分型（structural typing） を採用しています。 「形が同じなら同じ型」とみなすため、UserId と OrderId をどちらも string で表すと、 互いに取り違えても型エラーになりません。これを防ぐのがBranded Types（公称型の擬似的な実現）です。

// ❌ 構造的部分型: どちらも string なので取り違えてもコンパイルは通る
type UserId = string;
type OrderId = string;

function cancelOrder(id: OrderId) { /* ... */ }

const userId: UserId = "u_123";
cancelOrder(userId); // 危険なのに型エラーにならない

// ✅ Branded Types: 交差型で「ブランド」を付けて区別する
declare const brand: unique symbol;
type Brand<T, B extends string> = T & { readonly [brand]: B };

type UserId = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;

function cancelOrder(id: OrderId) { /* ... */ }

const userId = "u_123" as UserId;
cancelOrder(userId); // 今度はコンパイルエラーで取り違えを防げる

TSKaigi 2026では、この基本テクニックをさらに実戦投入した発表が並びました。

「AI時代に考える」「AI生成コードのガードレール」というキーワードが添えられている点に注目してください。 潮流②と潮流③は地続きで、「型でドメインを厳しく縛っておけば、AIが書いたコードの取り違えもコンパイラが弾いてくれる」という発想が共有されていました。

その他の見どころ

3つの潮流に収まりきらないながら、語られることの多かったトークも挙げておきます。 言語仕様の「なぜこうなっているのか」を歴史から解きほぐすセッションが厚かったのも今年の印象です。

まとめ：TSKaigi 2026から持ち帰るもの

個別のトークは多彩でしたが、エンジニアとして持ち帰るべき要点は3つに絞れます。

• ① ツールチェーンのネイティブ化は「準備しておく」フェーズに入った。 tsgo を一度手元で走らせ、自分のプロジェクトでの速度差と互換性を把握しておくと、7.0移行で慌てずに済みます。
• ② AI時代だからこそ「なぜ書くか」を言語化する。 テストも型も、AIに任せる範囲が広がるほど「何を担保するための仕組みか」を説明できることの価値が上がります。lacolacoのテスト論はその好例でした。
• ③ 型を「ドメインの制約」として使い倒す。 Branded Typesのような公称型テクニックは、人間にとってもAIにとっても有効なガードレールです。プリミティブを裸で使っている箇所から見直してみましょう。