TypeScript 7とは?Go製ネイティブコンパイラtsgoで最大10倍高速化|RC公開と移行の要点【2026年最新】
TypeScript 7は、コンパイラと言語サービスをGo言語によるネイティブ実装へ全面移行した次期メジャーバージョンです。開発時のコードネームは「Project Corsa」。2026年4月21日にBeta、2026年6月18日にRC(リリース候補)が公開され、正式版(GA)はRCの約1か月後が見込まれています。RC以降は配布方法が変わり、これまでの@typescript/native-preview(tsgoコマンド)に加えて、標準のtypescriptパッケージのRC版に同梱されるtscコマンド自体がGo製ネイティブコンパイラになりました。言語仕様の大改訂ではなく、ツールチェーンの土台を刷新し、ビルド速度とデフォルト設定を見直したリリースです。
まとめ:TypeScript 7の要点
- 正体:tsc/言語サービスをGoで書き直したネイティブ実装(Project Corsa)。言語仕様は原則そのまま。
- 時期:Beta 2026年4月 → RC 2026年6月18日 → GAはRCの約1か月後見込み。RCは
typescript@rcで入手できる。 - 速度:公式ベンチでフルビルドが最大約10倍高速(VS Codeで89.1秒→8.7秒、プロジェクトにより約7〜10倍)。メモリも約半減。
- 破壊的変更:
--strictが既定で有効化、target es5とbaseUrlとmoduleResolution node10が廃止、rootDir・typesの既定も変更。 - 移行:まずTS6.0(ブリッジ版)で非推奨警告を解消してから7へ上げるのが安全。
以下、各項目を公式のベンチマークと変更点に沿って詳しく見ていきます。
TypeScript 7の正体|Go製ネイティブ移行「Project Corsa」の全体像
従来のTypeScriptコンパイラ(tsc)はTypeScript自身で書かれ、Node.js上で動いていました。TS7ではこの実装をGo言語へ移植し、V8(JavaScriptエンジン)を介さないネイティブバイナリとして動かします。移植にあたってTypeScriptチームは、旧コードベース(コードネーム「Strada」)の構造をファイル単位でほぼそのままGoへ写し取る方針を採りました。挙動を再設計せず移植に徹したことで、型チェック結果の互換性を保ったまま実装言語だけを入れ替えられた、という点がこのプロジェクトの肝です。
結果として得られるものは主に3つ。ネイティブコード実行による起動・処理の高速化、Goのマルチスレッドを使った並列型チェック、そしてメモリ使用量の削減です。TypeScriptが生成するJavaScriptの実行速度が上がるわけではなく、あくまでコンパイル・型チェックにかかる待ち時間が短くなる点に注意してください。恩恵が最も大きいのは、ビルドやエディタの応答が重くなりがちな大規模プロジェクトです。
TypeScript 7はいつ使えるか|Beta→RC→GAのロードマップ
「TypeScript 7 いつ」という検索が多いので、時系列を先に整理します。TypeScriptチームは、2026年3月23日に公開されたTypeScript 6.0を7.0への「ブリッジ」リリース(JavaScript実装として最後のメジャー版)と位置づけ、6.0で将来削除する設定に非推奨警告を出し、7.0で正式に削除・既定変更する二段構えを取っています。7.0本体の公開ステップは次の通りです。
| 段階 | 時期 | 入手方法 | 位置づけ |
|---|---|---|---|
| Nightly / Beta | 2026年4月21日 | @typescript/native-preview |
日常利用・CIでの試用可 |
| RC(リリース候補) | 2026年6月18日 | typescript@rc |
tscが本命のネイティブ実装に |
| GA(正式版) | RCの約1か月後見込み | typescript@latest(予定) |
本番採用の目安 |
「本番で使ってよいか」を判断するなら、GA到達が一つの区切りです。ただしBeta時点でチームは「安定して互換性が高く、日々のワークフローやCIで試せる」と表明しており、CIの型チェックやローカルのビルド高速化なら、GA前でも段階的に導入する価値があります。GAの正確な日付とサポート範囲は状況で動くため、採用判断の前に公式リリースノートで最新を確認してください。
tsgoとtscの違い|RCで名称と配布はどう変わったか
実装とパフォーマンスの違い
tsgoは、ネイティブプレビュー版で提供されるコンパイラCLIの名称です。機能面はtscとほぼ同等で、-p tsconfig.jsonや--build(プロジェクト参照)、--incrementalといった主要オプションに対応します。両者の本質的な違いは実装言語と速度で、Node.js上で動くtsc(6系まで)に対し、tsgoはGoのネイティブバイナリとしてマルチコアを直接使えます。TypeScriptチームの報告では、約2万件のコンパイラテストのうち99%以上でtscとtsgoのエラー検出が一致しており、型チェックの結果はほぼ同じと考えて差し支えありません。
RCで変わった配布とコマンド名
ここが旧情報と食い違う最重要ポイントです。Beta段階まではネイティブコンパイラは@typescript/native-previewという別パッケージで、コマンド名もtsgoでした。RC(2026年6月)からは、標準のtypescriptパッケージのRC版に取り込まれ、tscコマンドそのものがGo製ネイティブ実装になりました。つまりRC以降の本命は「typescript@rcを入れて従来どおりtscを叩く」形です。tsgoという別名は引き続きnightly(@typescript/native-preview)で使われますが、正式版に向けてはtscへ一本化されていく流れだと理解しておくと混乱しません。
周辺ツールとの互換性には過渡期特有の注意が残ります。旧内部API(Strada)に依存していたリンターやフォーマッタ、IDE拡張は新API(Corsa)とそのままでは連携できません。この対応状況は後述のフレームワーク章で扱います。ESLintとは?VSCodeでの設定からflat config・Prettier連携まで解説のようなリンター運用を組んでいる場合は、この互換性の切り替わりが影響します。
Goネイティブ化で最大10倍高速化する仕組み
並列コンパイルによるマルチコア活用
高速化の最大の要因は、マルチスレッドによる並列型チェックです。従来のtscはファイルを1つずつ順に処理していたため、大規模プロジェクトではCPUコアの大半が遊んでいました。Go移行後は複数ファイルのパースと型チェックを並行実行し、--buildモードでは複数プロジェクトを同時にビルドできます。利用可能なCPUコア数に応じて複数のワーカーが並列実行され、コア数の多いマシンほど恩恵が大きくなります。増分ビルド(--incremental)も新実装で維持され、小さな変更なら再ビルドはほぼ瞬時です。
メモリ効率の向上
もう一つの改善がメモリ使用量です。V8のランタイムオーバーヘッドが無くなり、Goのメモリ管理下で最適化されたことで、エディタでプロジェクトを開いた際のメモリがおおむね半減したと公式は報告しています。ケースによっては旧実装の最大約8分の1(1/8)まで下がった例もあり、大量の型情報を扱うモノレポで効いてきます。実測のフルビルド時間は次の通りです(Microsoftが2025年3月に公開したベンチマーク)。
| プロジェクト | 規模の目安 | tsc(TS6) | tsgo(TS7) | 倍率 |
|---|---|---|---|---|
| Visual Studio Code | 約150万行 | 89.1秒 | 8.7秒 | 約10.2倍 |
| Sentry | 約50万行 | 133秒 | 16.3秒 | 約8.2倍 |
| TypeORM | 約27万行 | 15.8秒 | 1.06秒 | 約9.9倍 |
| Playwright | 約9万行 | 9.3秒 | 1.24秒 | 約7.5倍 |
分単位だった待ち時間が秒単位に縮む規模感です。CIの型チェックを回す頻度を上げても負担が小さく、ローカルでフルビルドして健全性を確認する運用が現実的になります。
TypeScript 7の破壊的変更とtsconfig|strict既定・baseUrl廃止・rootDir/types変更
TS7は将来方針に沿って、長く非推奨だった設定をまとめて削除・既定変更します。既存プロジェクトのビルドに直接影響するため、アップグレード前に該当箇所を洗い出してください。
strictモードが既定で有効化
最も影響が広いのが、--strictの既定値がfalseからtrueへ変わる点です。noImplicitAny・strictNullChecks・strictFunctionTypesなどがまとめて有効になり、これまでstrict非対応だったコードは型エラーが増えます。暗黙のanyやnull未考慮の代入が典型です。strictは以前から推奨されてきた設定なので、新規プロジェクトが最初から安全側に倒れる利点は大きい一方、既存コードには修正コストが発生します。
targetとモジュール解決の変更
target es5はサポート終了し、指定できる下限がes2015になります(推奨はes2020以上)。IE11向けにES5出力していたプロジェクトは、Babelで型チェックと分離するか6.x系に留まる判断が要ります。モジュール解決ではmoduleResolution node(別名node10)が削除され、nodenextかbundlerへ移行します。あわせてamd・umd・systemといった旧モジュール形式も外れます。
baseUrl・rootDir・typesの既定変更
設定ファイルの見直しで見落としやすい3点です。baseUrlは廃止され、パス解決はpaths(相対パス指定)へ寄せます。rootDirは推定挙動が変わり(composite構成ではtsconfig.jsonのあるディレクトリが既定)、tsconfig.jsonがsrc/の上位にある構成では"rootDir": "./src"を明示しないと出力ディレクトリ構造が崩れます。そしてtypesの既定が空配列[]に変わり、@types/nodeや@types/jestなどの環境グローバルが自動では読み込まれなくなります(この既定変更はTS6.0で導入され、7でも継続します)。テストや実行環境の型が急に見つからなくなったら、この既定変更を疑ってください。
TypeScript 6からTypeScript 7への移行手順
TS7への移行で最も安全なのは、いったんTS6.0を経由するやり方です。6.0は7.0を見据えたブリッジ版として作られ、削除予定の設定に非推奨警告を出し、型チェックの挙動を可能な限り7.0へ寄せています。手順の骨子は次の通りです。
- TS6.0へ更新し、非推奨警告を解消する:
strictを有効化してエラーを潰し、targetをes2020以上へ、baseUrlをpathsへ、rootDirとtypesを明示指定へ書き換える。 - RCのネイティブコンパイラで差分を確認する:
typescript@rc(または@typescript/native-preview)を並行導入し、tsc/tsgoでビルドしてエラーの差分を洗い出す。型チェック互換性が高いので、6.0で通っていれば7でも大きく崩れにくい。 - 段階導入する:エディタや一部ツールは当面6.0(従来
tsc)、CIの型チェックやローカルビルドはネイティブ版、というハイブリッド運用から始める。
設定の自動書き換えを補助する公式のコードモッドも案内されていますが、対応範囲と名称はバージョンで変わります。使う場合は最新の公式ドキュメントで対応オプションを確認してください。
フレームワーク・エコシステムの対応状況|vue-tsc・Nuxt・Next.js
旧記事に無かった論点がここです。ネイティブコンパイラは新API(Corsa)へ移ったため、.vueや独自ビルドを噛ませるフレームワークの型チェックは、対応ツール側の追随が要ります。2026年半ば時点の状況を整理します。
Vue / Nuxt
Vueの.vueファイル型チェックを担うvue-tscは、ネイティブ対応がVueの言語ツール側で進行中です。コミュニティ製のvue-tsgo(tsgo上に構築したCLI)を使ったNuxt 3の実測では、706個の.vueファイルを含むプロジェクトで従来のvue-tscが約135秒だったのに対し、vue-tsgoは約5秒まで縮み、.vueのエラー検出差分はゼロと報告されています。正式な統合前でも、大規模なVue/Nuxtプロジェクトほど高速化の余地が大きいことがわかります。
Next.js
Next.jsのネイティブコンパイラ対応は開発中です。現状は@typescript/native-previewをマーカー依存として追加し、next build側にネイティブ版を検出させて自前の型チェックをスキップさせる回避策が知られています。正式統合が入るまでは、型チェックをNext.jsのビルドから切り離して別途ネイティブ版で回す構成が現実的です。
テスト側も同様に過渡期です。Vitestの使い方|React Testing Libraryでコンポーネントテストを書く実践ガイドのようなテスト基盤やリンターは旧APIに依存している場合があるため、ネイティブ版へ切り替える前に各ツールの対応状況を確認してください。
既存プロジェクトでTypeScript 7を試す方法
手元のプロジェクトでネイティブコンパイラを検証する手順です。RCが出た今は、まずtypescript@rcを入れて従来のtscで試すのが素直です。
// RC版(tsc がネイティブ実装。本命の入手方法)
npm install -D typescript@rc
// nightly版(コマンド名は tsgo。最新の開発版を追う場合)
npm install -D @typescript/native-preview
// ビルド・型チェック(tsc と tsgo は使い方が同じ)
npx tsc -p tsconfig.json
npx tsgo -p tsconfig.json
VS Code利用者は、拡張機能「TypeScript (Native Preview)」を入れるとエディタ内の補完・型チェックをネイティブ言語サービスで試せます。導入後は既存のtsc(6系)と共存させ、用途に応じて使い分けるのが無難です。
現時点の制限も把握しておきましょう。古いターゲットへのダウンレベル出力やデコレーターの変換など一部が未対応の期間があり、ES5向けトランスパイルが必須のプロジェクトは従来tscを併用する必要があります。--watchの効率も現行版に一歩譲る場合があります。まずは小規模プロジェクトやCIの型チェック工程から切り替え、問題があればGitHubのTypeScriptリポジトリへフィードバックすると、正式版の品質向上に役立ちます。Node.js側の運用と合わせて見直すなら、Node.jsの脆弱性とは|影響の確認方法と対応バージョン・アップデート手順も参考になります。
よくある質問
TypeScript 7はいつリリースされますか?
Betaが2026年4月21日、RC(リリース候補)が2026年6月18日に公開されました。正式版(GA)はRCの約1か月後が見込まれています。正確な日付は公式リリースノートで確認してください。
tsgoとtscはどちらを使うべきですか?
RC以降はtypescript@rcに同梱されるtscがネイティブ実装の本命です。tsgoという名称はnightlyの@typescript/native-previewで使われます。安定運用ならRC版のtsc、最新の開発版を追うならnightlyのtsgoという使い分けになります。
TypeScript 7で既存プロジェクトはそのまま動きますか?
型チェックの互換性は高い一方、--strictの既定有効化、target es5とbaseUrlの廃止、rootDir・typesの既定変更により、設定やコードの修正が必要になる場合があります。まずTS6.0で非推奨警告を解消してから7へ上げるのが安全です。
baseUrlが非推奨と表示されます。どう直せばよいですか?
TS7でbaseUrlは廃止されます。モジュールのパス解決はpathsに相対パスで書き換えるか、バンドラのエイリアス設定へ寄せてください。TS6.0の段階で警告が出るので、そこで対応しておくと7への移行が滑らかです。
tsgoはどうやってインストールしますか?
RC版はnpm install -D typescript@rcで導入し、従来どおりtscを実行します。nightlyを使う場合はnpm install -D @typescript/native-previewでtsgoコマンドが利用できます。既存のtypescriptを上書きしないため、共存させて検証できます。あわせて、Prismaのバージョン完全ガイドについても解説しています。