TypeScript開発者にとって、ビルド待ち時間は長年の課題でした。しかし、TypeScriptの生みの親であるAnders Hejlsberg氏が発表した「TypeScript 7」は、その常識を根底から覆します。コンパイラの実装言語をTypeScript（JavaScript）からGoへ移行することで、ビルド速度が10倍以上高速化されることが明らかになりました。
150万行のコードを持つVS Codeプロジェクトにおいて、ビルド時間は77.8秒から7.5秒へと短縮。本記事では、日常的にTypeScriptを使用するエンジニアに向けて、なぜRustではなくGoが選ばれたのか、そして私たちの開発現場にどのような変化が訪れるのかを技術的背景とともに解説します。
概要と技術的背景
TypeScript 7における最大の変更点は、コンパイラ（コードネーム：Corsa）がネイティブバイナリとして動作するGo言語で完全に書き直されたことです。
これまでのTypeScriptコンパイラ（コードネーム：Strada）は、それ自体がTypeScriptで書かれ、Node.js上で動作するセルフホスティング形式でした。しかし、V8エンジンのシングルスレッド制限や、Worker Threadsの重いメモリフットプリントがボトルネックとなり、大規模プロジェクトでのパフォーマンス改善が限界に達していました。いくら最適化を重ねても、JavaScriptランタイム上で動く以上、並列処理とメモリ効率には構造的な天井があったのです。
なぜ「Go」だったのか
Goが選ばれた決定的な理由は、パフォーマンスの高さだけでなく、既存コードベースとの「構造的な類似性」にあります。
- 「ポート（移植）」戦略の採用: 数年かかるゼロからの「リライト（再設計）」ではなく、既存のロジックと構造を維持したまま1年で移植する「ポート」を選択。この判断によって動作互換性を99.99%以上保ちながら、短期間での実用化が実現しました。
- パラダイムの一致: 既存のTypeScriptコンパイラはクラスを使わず、関数とデータ構造で構成されています。これがGoの「関数＋構造体」というパラダイムに自然にマッチしました。
- Rustが選ばれなかった理由: パフォーマンスはGoと同等でしたが、Rustのボローチェッカーが壁となりました。コンパイラ内部の循環的なデータ構造（例：ASTノードが相互参照するケース）をRustで表現するには、設計を根本から作り直す（リライト）必要があり、互換性の維持が困難と判断されました。
- GCの影響: コンパイラの主要データ（AST等）はプログラムの全ライフタイムにわたって生存するため、ガベージコレクション（GC）のオーバーヘッドは無視できるレベルです。「GoはGCがあるから遅い」という懸念は、このユースケースには当てはまりません。
エンジニア「Goへの移行により、ネイティブコンパイルで5倍、共有メモリによる並列処理でさらに2倍、合わせて10倍という計算ですね。並列型チェック時でもメモリ増加がわずかなのは驚異的です。Worker Threadsだとプロセス間コピーが発生するので、並列化するほどメモリが膨らんでいましたが、goroutineならASTをそのまま共有できますから。」
デザイナー「エディタの応答速度が8倍速くなり、プロジェクトロードが1秒程度になるなら、開発のスイッチングコストが劇的に下がりますね。ビルドを待っている間に集中力が途切れることがなくなるのは、生産性的にもかなり大きい気がします。」
詳細解説：10倍高速化の仕組み
この刷新により、以下のような驚異的なパフォーマンス向上が実現されます。「速い言語に変えた」だけでなく、並列処理アーキテクチャとメモリ設計の両面から高速化を達成している点が重要です。
1. 圧倒的な並列処理（goroutine）
Goの軽量スレッドであるgoroutineを活用し、コンパイルパイプラインを高度に並列化しています。goroutineはOSスレッドとは異なり起動コストが数KB程度と非常に小さく、数千〜数万単位で立ち上げても現実的なリソース消費に収まります。これにより、CPUのコア数が増えるほどスケールする設計が実現しています。
- パースとバインド: ファイル単位で完全に並列実行可能。ファイル間の依存関係がないため、コアが増えるほどリニアにスループットが向上します。
- 型チェック: 最も重いフェーズ（全体の2/3）。複数の型チェッカーインスタンスがASTをメモリ上で共有しながら独立して動作します。従来のWorker Threadsではプロセス間でデータをコピーする必要があり、並列数を増やすほどメモリも倍増していました。goroutineではその問題が発生しません。
- 出力: ファイル単位で並列処理。さらに型チェックと一部オーバーラップして実行できるため、エンドツーエンドのレイテンシが縮まります。
2. メモリ効率の劇的な向上
JavaScript特有の各オブジェクトごとのメモリ割り当て（ヒープ上のポインタ参照）が解消され、Goによる構造体の配列一括割り当てが可能になりました。メモリの局所性が高まることでCPUキャッシュの命中率も向上し、実行効率がさらに上がります。
- メモリ使用量: 約50%〜70%削減。大規模プロジェクトほどこの差が広がります。
- スケーラビリティ: Worker Threadsと比較して極めて軽量なgoroutineにより、多コアCPUの性能をフルに引き出せます。
3. ベンチマーク結果
2025年3月の発表資料によると、主要プロジェクトで以下のような劇的な改善が報告されています。コードベースが大きくなるほど高速化倍率が高い傾向があり、モノレポなど大規模プロジェクトで特に効果的です。
| コードベース | 規模（行数） | 現行（TS 5.x） | Go版（TS 7.0） | 高速化倍率 |
|---|---|---|---|---|
| VS Code | 1,505,000 | 77.8秒 | 7.5秒 | 10.4倍 |
| Playwright | 356,000 | 11.1秒 | 1.1秒 | 10.1倍 |
| TypeORM | 270,000 | 17.5秒 | 1.3秒 | 13.5倍 |
エンジニア「CI/CDへのインパクトも見逃せません。型チェックに77秒かかっていたジョブが7秒台になれば、PRのフィードバックループが劇的に短縮されます。クラウドのビルドマシン稼働時間が減るので、コスト削減にも直結しますよ。」
デザイナー「移行は難しそうですか？既存プロジェクトがいきなり壊れたりしないか、少し不安です。」
エンジニア「段階的に進められるので、大丈夫です。まずTypeScript 6.0でデフォルト設定の変更や非推奨APIへの対応を済ませておき、それからTS 7.0に上げるのが推奨ルートです。いきなり7.0に飛ぶより、リスクをぐっと抑えられます。
注意が必要なのはCompiler APIを直接使うツール、たとえばtypescript-eslintやts-morphです。内部実装が変わるため、各ツール側の対応を待つ必要があります。逆にesbuildやViteは独自パーサーを持つので、ほとんど影響を受けません。」
実装・利用例と移行への準備
TypeScript 7への移行をスムーズに進めるためには、2026年3月にリリース予定の「TypeScript 6.0」での準備が不可欠です。
TypeScript 6.0での変更点
6.0は現行アーキテクチャ最後のメジャー版であり、7.0で変更されるデフォルト値の橋渡し役となります。今のうちにこの設定を適用しておくことで、7.0移行時の差分を最小限に抑えられます。
{
"compilerOptions": {
/* TS 6.0以降の新しいデフォルト設定 */
"strict": true,
"module": "esnext",
"target": "es2025",
"moduleResolution": "bundler", // nodeは非推奨へ
"esModuleInterop": true,
"types": [],
/* TS 7.0での非推奨警告を一時的に抑制する場合 */
"ignoreDeprecations": "6.0"
}
}廃止・非推奨となる機能
TS 7.0への移行前に、以下の対応が必要です。影響が広いものから優先的に確認しておきましょう。
- `–target es5` の廃止（es2015以上に変更が必要）。IE11向けビルドが残っているプロジェクトは特に注意が必要です。Babelなど別トランスパイラとの組み合わせで継続対応することになります。
- `import … asserts` 構文の廃止（`with` 構文へ変更）。JSONのインポート時に使っているケースが多いため、コードベース全体を検索して一括置換しておきましょう。
- Compiler APIへの依存: `typescript-eslint` や `ts-morph` など、内部APIを直接叩くツールは大規模な改修が必要になります。一方で、`esbuild` や `Vite` など独自パーサーを持つツールの影響は軽微です。使用ツールのGitHubリポジトリでTS 7対応のIssueやロードマップを事前に確認しておくと安心です。
推奨する移行ステップ
移行を安全に進めるための手順を整理しました。一気に移行しようとせず、段階を踏むことでリスクを最小化できます。
- Step 1 — プレビュー版で速度を確認する: まず `@typescript/native-preview` を開発環境に導入し、既存プロジェクトで体感速度を確かめます。型エラーの差分も確認しておきましょう。
- Step 2 — TS 6.0の設定に合わせる: `ignoreDeprecations: “6.0”` を外した状態で警告がゼロになるよう、tsconfig.jsonと各ファイルを整理します。
- Step 3 — 依存ツールの対応状況を確認する: `typescript-eslint`、`ts-jest`、`ts-morph` など、Compiler APIに依存するツールのTS 7対応リリースを待ちます。
- Step 4 — TypeScript 7.0へアップデートする: Step 1〜3が完了していれば、ほぼそのまま移行できます。CIで型チェックが通ることを確認して完了です。
ネイティブ版のプレビュー試行
現在公開されているプレビュー版で速度を体感できます。既存の `tsconfig.json` をそのまま使えるため、導入のハードルは低いです。
# コマンドラインでネイティブプレビューを試す
npm install -D @typescript/native-preview
npx tsgo --project tsconfig.jsonよくある疑問（Q&A）
Q: アプリ自体の実行速度は速くなりますか？
A: いいえ。高速化されるのはビルドと型チェックのみです。生成されるJavaScriptは同じであるため、ランタイム（ブラウザ/Node.js）の性能は変わりません。TypeScript 7はあくまで「開発体験の高速化」であり、プロダクションコードの動作には一切影響しません。Q: Goのインストールは必要ですか？
A: 不要です。コンパイラは各OS向けのネイティブバイナリとして配布されるため、これまで通りnpm installだけで利用可能です。チームメンバーがGoの知識を習得する必要もありません。Q: WebAssembly (WASM) で動作しますか？
A: 現時点では懸念があります。GoのWASMビルドはJS製より遅くなるケースが報告されており、ブラウザ内での動作には今後の改善が待たれます。CodeSandboxやStackBlitzなどのブラウザ型IDEへの影響については、引き続き公式の情報をウォッチしておくことをおすすめします。Q: 小規模プロジェクトでも恩恵はありますか？
A: あります。ただし、高速化倍率はコードベースの規模に比例します。ファイル数が少ないプロジェクトでは並列処理の恩恵が限定的なため、10倍という数字は主に大規模プロジェクトでの実績です。一方、エディタの補完速度や診断の応答性は規模に関係なく改善されるため、小〜中規模のプロジェクトでも開発体験の向上は体感できるでしょう。Q: 既存のCI/CDパイプラインへの影響は？
A: 移行後はビルドステップの実行時間が大幅に短縮されます。並列ジョブ数を減らす、タイムアウト設定を見直すなど、パイプラインの最適化の余地が生まれます。一方で、Compiler APIに依存するlintツールや独自スクリプトがある場合は、それらの対応状況を事前に確認しておく必要があります。
まとめ
- Go言語への完全移植により、ビルド速度が約10倍、エディタ起動が約8倍に高速化される。
- 「ポート」戦略により、99.99%の高い互換性を維持したまま短期間での移行を実現。
- 並列処理（goroutine）の活用により、大規模プロジェクトほど高速化の恩恵が大きい。
- TypeScript 6.0を導入し、非推奨警告やデフォルト設定の変更に対応しておくことが、7.0移行への最短ルートである。
- 今すぐ
@typescript/native-previewを試して、実際のプロジェクトで速度差を体感しておこう。
大規模プロジェクトにおいて「ビルド待ち」という概念を過去のものにする。それがTypeScript 7がもたらす新しい開発体験の本質です。
