TypeScript 7.0が正式登場 — Go製ネイティブコンパイラで最大11.9倍高速化、破壊的変更と移行の勘所を徹底解説
はじめに
Microsoft が TypeScript 7.0 を正式発表した。目玉は、これまで TypeScript/JavaScript で書かれていたコンパイラを Go言語でフルスクラッチ移植したこと。コード名は「Project Corsa」。ベンチマークではコンパイル速度が最大 11.9 倍、エディタのエラー検出は 13 倍以上高速化したという。Hacker News で 195 ポイントを集め、国内外で大きな話題になっている。
しかしこのリリースは単なる「速くなりました」では終わらない。strict が既定で有効化され、target: es5 が廃止されるなど破壊的変更も多く、Vue・Svelte・Angular といった主要フレームワークは現時点で TypeScript 7.0 を使えない。本記事では、なぜ Go を選んだのか、何がどれだけ速くなったのか、そして自分のプロジェクトを移行してよいのかを、実務目線で整理する。
何が起きたのか — Project Corsa の全貌
TypeScript 7.0 は、既存のコンパイラを「忠実に（faithfully）」Go へ移植したものだ。型システムのロジックやデータ構造の意味論を維持したまま実装言語だけを載せ替えることで、互換性を保ちながらネイティブバイナリの速度を得るというアプローチをとった。
公開されたベンチマークの数字は明確だ。
- VS Code（約40万行）: 125.7秒 → 10.6秒（11.9倍）
- Sentry: 139.8秒 → 15.7秒（8.9倍）
- Playwright: 12.8秒 → 1.47秒（8.7倍）
メモリ使用量も 6〜26% 削減され、VS Code は 5.2GB → 4.2GB（-18%）、Bluesky は 1.8GB → 1.3GB（-26%）となった。エディタ内のエラー検出では、VS Code のコードベースで 17.5秒 → 1.3秒と 13倍以上速くなっている。
実利用の声も具体的だ。Slack はマージキューの待ち時間を 40% 削減し、CI の型チェックを 7.5分 → 1.25分に短縮したと報告している。Canva もエディタでのエラー検出が 58秒 → 4.8秒に改善したという。数万行を超える大規模プロジェクトほど、この恩恵は大きい。
なお、新たに --checkers と --builders フラグで並列度を調整できるようになり、大規模コードベースでは --checkers 8 で最大 16.7 倍の高速化が観測されたケースもある。goroutine ベースの並列型チェックが効いている。
なぜ Rust ではなく Go なのか
大きな疑問は「なぜ Rust ではなく Go なのか」だ。速度を求めるなら Rust という選択肢もあったはずだ。TypeScript の生みの親 Anders Hejlsberg らの説明を整理すると、理由は主に3つに集約される。
1. 既存コードベースとの構造的な相性。 TypeScript コンパイラは、共有された可変データ構造・循環参照を含む参照グラフ・ポインタを多用したツリー走査に強く依存している。Go の構造的型付け（structural typing）とインターフェースは、この設計を素直に写像できる。一方 Rust では、借用チェッカ（borrow checker）がコアデータ構造の根本的な再設計を要求するため、単なる「移植」では済まなくなる。
2. ガベージコレクションの存在。 コンパイラは大量の動的メモリ確保と循環参照を扱うため、GC に強く依存している。Go は成熟した GC を備えつつネイティブバイナリを吐ける。GC を持たない Rust では、メモリ管理の仕組みそのものを作り直す必要があった。
3. 並行モデルと開発速度。 Go の goroutine は単一アドレス空間を共有するため、型チェッカが数千の軽量スレッドを起こし、シンボルテーブルをコピーせず読める。Rust で同じことをやると Arc の多用（性能低下）か全面的な再設計が必要になる。現実的な期間で出荷するには、Go の方が合理的だった、というのが結論だ。
つまり「最速の言語」ではなく「既存の設計を最も低リスクで移植でき、かつ十分に速い言語」として Go が選ばれた。移植の忠実性を優先した現実的な判断と言える。
エンジニアへの影響 — 破壊的変更と移行の判断
高速化は魅力的だが、TypeScript 7.0 は 6.0 の既定値を採用し、非推奨機能を削除するため、無条件で乗り換えられるわけではない。主な変更点は次の通り。
既定値の変更:
strictが既定でtruemoduleの既定がesnexttypesの既定が[]（必要なパッケージを明示列挙する必要あり）rootDirの既定が./（tsconfig.jsonの更新が必要な場合あり）
ハードエラーになる廃止事項:
target: es5のサポート終了baseUrlの廃止（pathsを使う）- Closure 形式の JSDoc 構文の廃止
- JavaScript 内の後置
!演算子の廃止
そして実務上もっとも重要なのが、Vue・MDX・Astro・Svelte・Angular のテンプレートは現時点で TypeScript 7.0 を使えないという点だ。これらは安定したプログラマティック API を必要とするが、その API がまだ整備されていない。該当するプロジェクトは当面 TypeScript 6.0 を使い続けるべきだ。typescript-eslint など 6.0 系 API に依存するツール向けには、互換パッケージ @typescript/typescript6 を npm エイリアス経由で併用する回避策が案内されている。
導入は npm install -D typescript、ナイトリー版は typescript@next で試せる。エディタ体験も刷新され、言語サーバーは LSP ベースで再構築されて 6.0 比でコマンド失敗が 80% 減、クラッシュが 60% 減。セマンティックハイライトやインポート整列、未使用インポート削除も追加された。
移行の判断はシンプルだ。大規模な素の TypeScript プロジェクトなら試す価値は非常に高い。 一方、Vue/Svelte/Angular などのフレームワークに乗っているプロジェクトは、対応 API が安定するまで待つのが賢明だ。
まとめ
- TypeScript 7.0 はコンパイラを Go へ移植した「Project Corsa」で、大規模プロジェクトで最大 11.9 倍、エディタのエラー検出で 13 倍以上の高速化を実現した。
- Rust ではなく Go を選んだのは、既存の GC 依存・共有可変データ構造・並行モデルを低リスクで移植でき、かつ現実的な期間で出荷できるためだ。
- 一方で
strict既定化やes5廃止など破壊的変更が多く、Vue・Svelte・Angular・Astro などは当面 6.0 を使い続ける必要がある。
Go 移植という思い切った判断は、TypeScript が JavaScript エコシステム全体の開発体験を底上げしにいく強い意志の表れだ。フレームワーク対応 API が安定すれば、CI 時間短縮とエディタ応答性の改善は多くのチームの生産性を確実に押し上げるだろう。まずは自分の環境で typescript@next を試し、体感速度を確かめてみてほしい。