TypeScript 7の襲来 — tsgoがもたらすパラダイムシフト

TypeScript 7の襲来

2026年4月21日、Microsoftは TypeScript 7.0 Beta を公式に発表しました。これはTypeScriptの12年の歴史における最大級のアーキテクチャ転換であり、TypeScript自身で書かれてきた既存コンパイラを丸ごと Go へ移植 した、いわば「中身を入れ替えた」リリースです。

本記事では、TypeScript 7 の目玉である tsgo の正体、なぜ Go が選ばれたのか(Rust じゃないのか)、現行の 5 系・6 系との違い、そして 7 への移行で準備すべきことを整理します。

TypeScript 7 の主要な機能

正直に言うと、TypeScript 7 は 言語機能 のリリースではありません。ユーザーから見える文法やジェネリクスの拡張はほぼなく、変化のほとんどは コンパイラ実装そのもの に集中しています。だからこそ、目玉機能は一つしかありません。

目玉機能: tsgo — 10 倍速の新コンパイラ

tsgo は Microsoft が Project Corsa というコードネームで開発してきた Go 製の TypeScript コンパイラ です。現行 tsc と同等の型チェック結果を出すことを最優先に設計され、ベンチマーク上は多くのコードベースで 約10倍 の高速化を実現しています。

公式に公開されている代表的なベンチマーク:

コードベース	行数	tsc (TS 6.0)	tsgo (TS 7.0)	高速化率
VS Code	約 150 万行	77.8 秒	7.5 秒	10.4x
Playwright	約 35.6 万行	11.1 秒	1.1 秒	10.1x
TypeORM	約 27 万行	17.5 秒	1.3 秒	13.5x
date-fns	約 10.4 万行	6.5 秒	0.7 秒	9.5x

ビルド時間だけではありません。エディタ起動時のプロジェクトロードは 約 8 倍 高速化、メモリ使用量は おおむね半分 に削減されています。

ベータ版は次のように導入できます:

npm install -D @typescript/native-preview@beta
npx tsgo --version
# => Version 7.0.0-beta

将来的にこの実装が typescript パッケージ本体にマージされ、最終的には従来どおり tsc コマンドから呼び出せるようになる予定です。今はあえて tsgo という別名で配布し、現行 tsc と共存させて検証できるようにしている、というフェーズです。

tsc の役割と技術的負債

そもそも、なぜここまでの大手術が必要だったのか。

現行の tsc は TypeScript 自身で書かれたセルフホストコンパイラ です。「TypeScript で TypeScript を生む」という美学的・哲学的な意義は確かにありました。が、現実は容赦なく、いくつかの構造的な負債が積み重なっていきました。

• Node.js 上の JavaScript として実行される ため、起動コストと GC の影響を避けられない
• コードベース規模が爆発的に拡大 し、Microsoft 社内ですら型チェック待ちが看過できないコストに
• 本質的に並列化が難しい — V8 のシングルスレッドモデルが、モノレポ・大規模プロジェクトでのスケーラビリティを縛る
• 言語サーバ(IDE) のレスポンス遅延が DX 悪化の主要因 になりつつあった

TypeScript 最大の強みは「型による開発者体験」のはずなのに、その肝心の体験を ツール自身がボトルネック化させている ——これがチームの問題意識でした。

tsc と tsgo の比較

観点	tsc (TS 5/6)	tsgo (TS 7)
実装言語	TypeScript (JS)	Go
実行形態	Node.js + JS	ネイティブバイナリ
並列処理	限定的	共有メモリ並列(goroutine)
起動時間	遅い	高速
メモリ使用量	多い	約半分
型チェック	基準	完全互換を目標(~99.99%)
配布	npm + Node.js 必須	単一バイナリ

注目すべきは、tsgo が単なる「ネイティブで速い」だけではないという点です。共有メモリベースの並列性を最大限活用 することにこそ本質があります。Hejlsberg 氏自身、ネイティブ化による高速化が約 3 倍、並列化でさらに約 3 倍、掛け合わせて 約 10 倍 に到達した、という旨を語っています。

つまり、「Go にしたから速くなった」のではなく、「Go にしたから真の並列化が現実的になった」 のです。

なぜ Go なのか — Rust ではない理由

「なぜ Rust ではなく Go なのか」は、発表当初もっとも議論された点でした。Microsoft 内には C# というカードもあり、Rust コミュニティからは強い期待もありました。

C# / TypeScript の生みの親である Anders Hejlsberg 氏自身が、選定理由を詳しく語っています。要点は次の 4 つです。

1. これは「リライト」ではなく「ポート」だから

チームは ゼロからの再設計ではなく、既存実装の構造を保ったままの移植 という方針を取りました。リライトには年単位の時間がかかるうえ、TypeScript エコシステムを支える数万のプロジェクトに 互換性破壊を持ち込むリスク が大きすぎる、という判断です。

2. TypeScript コンパイラの内部構造は循環参照だらけ

これが最も技術的に効いた理由です。

• AST のノードは 親と子の両方 へのポインタを持つ
• シンボルは宣言を参照し、宣言は AST ノードを参照し、AST ノードは再びシンボルを指す
• 型システム自体が 再帰的・循環的

こうした 循環的データ構造は Rust の所有権モデルと借用チェッカに根本的に合いません。Rust 移植を真面目にやると、データ構造を全部 Rc<RefCell<…>> や Arena で組み直す必要があり、それは事実上の全面再設計です。

一方 Go には GC があり、TypeScript の元コードがそうであったように 循環参照を素直に書ける。これがポート作業を実現可能なスケールに収めた、最大の要因です。

3. Go は「ちょうど良い」抽象度

Go はネイティブコード生成、GC、メモリレイアウトの制御、そして goroutine による軽量並列性を備えます。Hejlsberg 氏は Go を「全プラットフォームで最適化されたネイティブコードを得られる、最も低レベルな実用言語」と表現しています。

C++ ほど低レベルではなく、Rust ほど厳格ではない、しかし JavaScript よりは圧倒的に速い。コンパイラの実装言語として、ちょうど狙ったゾーンに収まる選択でした。

4. Go の構文が TypeScript に近い

意外と効いたのがこれです。TypeScript コンパイラのコードベースは 関数と構造体ベース で書かれており、クラス指向ではありません。これは Go へほぼ機械的に翻訳できる構造です。

逆に C# 移植では、強い OOP 指向との不一致 が翻訳の妨げになります。「C# の生みの親が C# を選ばなかった」ことは、この事実から考えれば自然な結論でした。

余談ですが、SWC 作者の DongYoon Kang 氏は、過去に Rust → Go → Rust と何度も型チェッカ実装に挑戦した末、完成には至っていません。エコシステム全体のリスクから見ると、移植の主導権を TypeScript チーム自身が握ったこと自体 が、最も重要な意思決定だったとも言えます。

現行の 5 系と 7 の違い

「現行 = 5 系」 vs 「7」を直接比較する前に、まず押さえるべきは TypeScript 6.0 が両者の間にブリッジとして存在する という点です。5 から 7 への変化は大きく次の 3 軸に整理できます。

1. パフォーマンス

すでに見たとおり、tsgo で型チェック・ビルドが約 10 倍、IDE 起動が約 8 倍、メモリ使用量が約半分になります。これは CI の設計や、モノレポ運用の前提が変わる スケールの変化です。「ジョブを 1 つ並列化する」みたいなチューニング努力が、極端に言えばいらなくなります。

2. デフォルト設定の刷新

TypeScript 6.0 で 9 つのデフォルト値が変更され、それがそのまま 7 に引き継がれます:

• strict: true がデフォルト
• module: esnext がデフォルト
• target: es2025 がデフォルト
• moduleResolution: bundler がデフォルト
• esModuleInterop: true がデフォルト
• types のデフォルトが空配列
• rootDir が tsconfig のあるディレクトリに

ES5 を前提とした時代の名残が一掃され、「現代的な JavaScript 環境」を前提に振る舞いが揃えられました。新規プロジェクトの tsconfig.json がほぼ空でも、まともに動く のはありがたい変化です。

3. 削除された構文・オプション

5 系で当たり前のように使えていたいくつかのレガシーオプションが、7 では 完全に削除 されます。詳しくは後の節で扱います。

6 の立ち位置

TypeScript 6.0 は、歴史的に少し特殊な位置にあります。

• TypeScript 自身で書かれる最後のバージョン(tsc の最終形)
• 5 系から 7 系への「ブリッジリリース」
• 新機能はほぼ無く、deprecation 警告と挙動の整合性合わせが中心

公式も明言しているとおり、6.0 は 「7.0 で何が壊れるかを事前に明らかにするためだけに存在する」 リリースです。設計思想としてかなり潔い。

// tsconfig.json
{
  "compilerOptions": {
    // 6.0 で出る deprecation 警告を一時的に抑制
    "ignoreDeprecations": "6.0"
  }
}

このオプションを使えば、6.0 では 警告のみで動作させ続ける ことができます。ただし、7.0 では削除対象のオプション群そのものが消えるため、ignoreDeprecations で蓋をしていた問題は 7.0 で必ず噴き出す ことになります。

つまり 6.0 は、「いきなり 7 に飛ばずに、警告を一つずつ潰すための猶予期間」 として用意された、開発者にとって極めて親切なリリースです。

5 → 7 の飛び級は推奨されません。 公式が想定する移行ルートは 5 → 6 → 7 の段階的アップグレードです。

7 が来る前にしたほうがいいこと

7.0 の安定版は 2026 年中のリリースが予告されており、ベータの時点ですでに 「多くの実運用ワークフローや CI で本番投入可能」 と Microsoft 自身が評価しています。猶予はそれほど長くありません。

優先度順に整理します。

利用できなくなる主要なオプション・構文

6.0 で deprecated 化され、7.0 で 削除予定 の主なものは以下のとおりです。

• target: es5 — ESNext が主流の今、ES5 ターゲットは廃止
• --downlevelIteration — 同上
• --moduleResolution node (旧 node10) と --moduleResolution classic — node16 / nodenext / bundler へ移行
• module: amd / umd / systemjs — レガシーモジュールシステムの完全削除
• --baseUrl — 暗黙的解決の温床。paths で明示マッピングへ
• --outFile — ファイル結合出力。バンドラの仕事になった
• --esModuleInterop false / --allowSyntheticDefaultImports false — デフォルトが逆転
• --alwaysStrict false — strict 系は常時オン
• namespace のレガシー構文(モジュール宣言の旧形式)
• import 文の assert キーワード(→ with に統一)
• no-default-lib ディレクティブ

特に baseUrl と outFile への依存度が高いプロジェクトは要注意 です。これらは「設定一行を書き換えれば終わり」ではないことが多く、ビルドパイプライン全体の見直し が必要になるケースがあります。

推奨される移行ステップ

1. まず 5 系の最新版(5.9 系)に上げる
2. TypeScript 6.0 に上げる — ここで deprecation 警告が一挙にフィードバックとして得られる
3. ignoreDeprecations: "6.0" を一時的に有効化 してまず通す
4. 警告を一つずつ潰す。baseUrl、outFile、moduleResolution: node、target: es5 あたりは早めに着手
5. tsgo --noEmit を非ブロッキング CI ジョブとして追加

# GitHub Actions の例
- name: TypeScript 7.0 beta check
  run: npx tsgo --noEmit
  continue-on-error: true

tsgo は型チェック結果が tsc とほぼ同一になることを目標としているため、ここで差分が出たら 「コードが何かの実装詳細に依存しすぎている」サイン と見て調査するのがよいでしょう。

tsgo の特性として知っておくべきこと

• 単一バイナリで動作する: Node.js 依存がない。CI イメージサイズや起動時間に好影響
• JSDoc 型注釈の JS 型チェックはノイジーになりやすい: 既存 JS コードベースで tsgo --noEmit を回すと、tsc より多く検知される傾向がある。typescript-go リポジトリの CHANGES.md で詳細を確認すること
• --outFile のサポートは正式に外れる: 代替は esbuild / Rollup / Vite などのバンドラへの移行
• デコレータや ES2021 未満の emit target は現在も対応中: 古いブラウザを直接ターゲットにしているケースは要注意
• 言語サービスは「rock-solid」レベルに到達: VS Code 向けには TypeScript Native Preview 拡張で先行体験可能
• プログラマブル API の安定版は 7.1 以降: コンパイラ API を直接叩いているツール(ts-morph 等)は、しばらく tsc 側を併用する必要がある

まとめ

TypeScript 7 は、TypeScript が「JavaScript の上で動く言語ツール」から 「ネイティブツールチェーン」 へと姿を変える、節目のリリースです。

• 目玉は Go 製コンパイラ tsgo。約 10 倍の高速化と、メモリ使用量約半減を実現
• Go が選ばれたのは、循環的データ構造との相性 / リライトではなくポート戦略 / ちょうど良い抽象度 という極めて実務的な理由
• TypeScript 6.0 はブリッジリリース。ここで deprecation 警告を潰しておくことが、7.0 移行への最大の近道
• target: es5、baseUrl、outFile、レガシーな moduleResolution などは 7.0 で 完全削除
• 7.0 安定版は 2026 年中の予定。tsgo --noEmit を CI に非ブロッキングで追加する のが現時点のベストプラクティス

「コンパイラが速い」というだけで、開発者体験は劇的に変わります。CI が待つ時間も、保存のたびにエディタが固まる時間も、地味だが累積するとプロジェクト全体の生産性を蝕む類のコストです。5 系で止まっているプロジェクトは、6.0 をスキップせず、段階的に 7.0 へ進む のが安全策です。

楽しい移行作業を。

参考

• Announcing TypeScript 7.0 Beta — Microsoft DevBlogs
• Announcing TypeScript 6.0 — Microsoft DevBlogs
• Progress on TypeScript 7 - December 2025 — Microsoft DevBlogs
• microsoft/typescript-go (GitHub)
• Why Go? · microsoft/typescript-go Discussion #411