TypeScript 7.0が正式リリース — Go実装で最大12倍高速化、tsc全書き換えの中身を解説
はじめに
2026年7月8日（現地時間）、Microsoftは TypeScript 7.0 を正式リリースした。このバージョンの目玉は新しい言語機能ではなく、コンパイラそのものの実装言語を TypeScript から Go へ全面移植したことにある。結果として、フルビルドは大規模プロジェクトで 8〜12倍、エディタのエラー表示は 13倍以上高速化した。本記事では、この「tsc の全書き換え」が何を変えるのか、なぜ Rust ではなく Go だったのか、そして既存プロジェクトを移行するときに踏むべき注意点を、エンジニア視点で整理する。
TypeScript 7.0で何が起きたのか
これまでの TypeScript コンパイラ（tsc）は、TypeScript 自身で書かれ、Node.js のランタイム上で動いていた。TypeScript 7.0 では、Anders Hejlsberg 率いるチームが 1年以上かけてコンパイラを Go に移植（コードネーム tsgo）し、ネイティブバイナリとして動作するようにした。
Microsoft が公開した実測値は次の通りだ。
| プロジェクト | フルビルド高速化 |
|---|---|
| VS Code | 11.9倍 |
| Sentry | 8.9倍 |
| Bluesky | 8.7倍 |
| Playwright | 8.7倍 |
| tldraw | 7.7倍 |
VS Code（約150万行）のエディタ・プロジェクト読み込みは 77.8秒 → 7.5秒。ファイルを開いてからエラーが表示されるまでの体感遅延も、約17.5秒から1.3秒未満へと改善した。メモリ使用量も6〜26%削減されている。Bloomberg、Canva、Figma、Google、Notion、Slack、Vercel といった大手の実コードベースでテストされ、新言語サーバーではコマンド失敗が80%以上、クラッシュが60%以上減ったという。
なお、Microsoft は「おおむね10倍」と表現しているが、型が重いコードでは伸び幅が小さくなる。第三者ベンチマークでは type-heavy なコードで 3.9〜7.3倍にとどまるケースも報告されており、「常に10倍」ではない点は押さえておきたい。
技術的背景 — なぜRustではなくGoなのか
高速化の源泉は2つある。ひとつは Node.js を介さないネイティブ実行、もうひとつは 共有メモリによるマルチスレッド並列だ。従来の JavaScript ランタイムは基本シングルスレッドで、型チェックを複数コアに分散させるのが難しかった。Go 版は複数のワーカースレッドで型チェックを並列化できる。
では、なぜ Rust や C# ではなく Go を選んだのか。Hejlsberg の説明が要点を突いている。
Go は、全プラットフォームでネイティブコードの最適化サポートが得られる中で最も低レベルに寄れる言語で、データレイアウトの制御や循環データ構造の扱いに優れていた。
既存の tsc は、共有可変データ構造・参照グラフ・ポインタ多用のトラバースに深く依存している。これを Rust に移すと、借用チェッカー（borrow checker）がこうしたデータ構造の根本的な再設計を強いてしまう。一方 Go なら、GC（ガベージコレクション）と循環参照を許す設計のおかげで、既存の構造をほぼそのまま1ファイルずつ移植できた。「速さ」よりも「既存コードの構造を保ったまま移植できること」を優先した現実的な判断だったわけだ。
エンジニアへの影響 — 移行前に知っておくべきこと
TypeScript 7.0 は単なる高速化パッチではない。既定値（デフォルト）がいくつか変わっているため、そのまま入れ替えると挙動が変わる箇所がある。
strictモードが自動で有効化moduleがesnextに変更rootDirの既定が./に（srcを使う場合は明示指定が必須）typesの既定値が空配列に- 非推奨フラグが警告ではなく厳格なエラーに昇格
Microsoft は「6.0でクリーンにコンパイルできるコードはそのまま動く」としつつ、まず 6.0 で問題点を洗い出してから移行することを推奨している。いきなり本番プロジェクトを7.0に上げるのではなく、6.0の最新版で非推奨警告をゼロにしておくのが安全な段取りだ。
もうひとつ重要なのが エコシステムの追従だ。安定したプログラマティックAPIは TypeScript 7.1（7.0の数ヶ月後）で提供予定のため、typescript-eslint、ts-morph、カスタムトランスフォーマーなど tsc の内部APIに依存するツールは、7.1を待つのが無難だ。当面は @typescript/typescript6 パッケージで6.x互換を保てるので、ビルドは7.0で高速化しつつ、周辺ツールは6.x系に残すという併用構成も取れる。
導入自体は従来通り npm install -D typescript で完結する。まずはCIのビルド時間短縮という「効果が数字で見える」ところから試すのが投資対効果として分かりやすい。
まとめ
- TypeScript 7.0は、コンパイラをGoへ全面移植したネイティブ実装で、フルビルドを大規模プロジェクトで8〜12倍高速化した。
- 高速化の源泉はネイティブ実行と共有メモリ並列の2つ。ただし型が重いコードでは3.9〜7.3倍程度に落ちるため過度な期待は禁物。
- Goが選ばれたのは、既存のポインタ多用・循環参照のデータ構造を再設計せずに移植できたから。
strict自動有効化など既定値が変わるため、移行はまず6.0で警告を潰してから。周辺ツール依存があれば7.1まで待つ判断も現実的。
コンパイル速度はこれまで「我慢するもの」だったが、7.0でその前提が崩れた。まずはCIのビルド時間をベンチマークし、自分のコードベースで何倍になるかを測るところから始めたい。