TypeScript 6.0 の到来 — JS版最終リリースと、Go移植で何が変わるか

author

authorDisplayName

Kentaro Ogawa

TypeScript 6.0 と 7.0 — 何が起きているのか

まず全体像を整理します。

バージョン	実装言語	位置づけ	2026年2月時点の状態
TypeScript 5.x	JavaScript	現行安定版	5.8 / 5.9 が利用可能
TypeScript 6.0	JavaScript	JS 版の最終メジャーリリース	ベータ公開中
TypeScript 7.0	Go	ネイティブ版（Project Corsa）	プレビュー版

TypeScript チームは Go でコンパイラを書き直すプロジェクトを Project Corsa と名付けました。Go 版のコマンドは tsgo です。従来の JavaScript 版は Strada と呼ばれ、TypeScript 6.0 がその最終形になります。

TypeScript 6.0 では、TypeScript 7.0 で削除される設定オプション（--target es5、--moduleResolution node など）が非推奨になります。つまり 6.0 は「Go 移行への橋渡しリリース」 という性格を持っています。

Go 版の方は、2025年5月にプレビュー版が npm で公開され、同年12月には型チェックの互換性が TypeScript 5.8 とほぼ一致するレベルまで進みました。2026年2月時点では @typescript/native-preview として試せる段階であり、正式リリースは2026年前半〜中盤に見込まれています。VS Code 向けのプレビュー拡張機能もマーケットプレイスから利用可能です。

では、Go 版はどれくらい速いのか。公式ベンチマークの数字を見てみましょう。

プロジェクト	コード規模	従来	Go 版	倍率
VS Code	150万行	77.8秒	7.5秒	10.4倍
Playwright	35.6万行	11.1秒	1.1秒	10.1倍
TypeORM	27万行	17.5秒	1.3秒	13.5倍
date-fns	10.4万行	6.5秒	0.7秒	9.5倍
tRPC	1.8万行	5.5秒	0.6秒	9.1倍

大規模プロジェクトでは10倍前後の高速化が報告されています。ただし、小規模プロジェクト（数万行以下）では2〜5倍程度にとどまるケースもあり、効果はプロジェクト規模によって異なります。メモリ使用量について、公式ブログでは "roughly half"（おおむね半分）と報告されていますが、最適化はまだ本格的に行われていない段階とのことです。後述する独自検証では33%の削減でした。

なぜ Go なのか — 言語選択の裏側

「なぜ Rust ではなく Go なのか」。発表直後、この疑問はコミュニティで大きな議論を呼びました。Hejlsberg 自身が説明した理由を整理します。

1. 構造的類似性 既存の TypeScript コンパイラのコードスタイルが Go に近く、ポート（移植）がしやすいこと。これは「書き直し」ではなく「忠実なポート」であることを意味します。既存コンパイラには100人年以上の投資が蓄積されており、それをゼロからやり直す選択肢は現実的ではありませんでした。

2. ガベージコレクション（GC）の存在 TypeScript コンパイラは循環的なデータ構造を多用しています。Rust の所有権モデルとはアーキテクチャ上の相性が悪く、Rust への移植は「ポート」ではなく「根本的な再設計」が必要になる。公式の説明（GitHub Discussion #411）でも、Rust ではメモリ管理・ミュータビリティ・データ構造・ポリモーフィズムなどを根本から再設計する必要があり、ポートの難易度が大幅に上がると指摘されています。

3. goroutineによる並行処理 高速化の約半分はネイティブコードによるもの、残りの半分は共有メモリの並行処理によるものです。Go のgoroutineを活用することで、マルチコアでの並列型チェックが自然に実装できます。

一方で、代償もあります。TypeScript が TypeScript で書かれている、いわゆる self-hosting が失われるという点です。self-hosting には「自分の言語で自分のツールを改善できる」という大きなメリットがありましたが、パフォーマンスのために実利を取った形です。エンジニアリングにおける典型的なトレードオフの判断だと思います。

小規模アプリで検証してみた

公式ベンチマークは VS Code（150万行）のような大規模プロジェクトが中心です。実際の開発現場では数千〜数万行規模のプロジェクトの方が多いはずなので、検証用にシンプルな勤怠打刻システムを Next.js で構築し、tsc 5.9.3 / tsc 6.0.0-beta / tsgo 7.0.0-dev を比較してみました。

（出勤と退勤時間を記録して提出。管理者が承認や差し戻しができるシステムを作りました）

計測対象

指標	値
フレームワーク	Next.js（App Router）
TypeScript/TSX ファイル数	53
ソースコード行数	7,262 行
主な構成	Server Actions + shadcn/ui + Drizzle ORM
node_modules 型定義ファイル数	17,132

計測環境は Apple M4 / 24GB RAM / macOS（Darwin 25.3.0）/ Node.js v25.2.1 です。 /usr/bin/time -l で wall-clock time と最大 RSS を計測し、tsc --noEmit（型チェックのみ）を各3回実行しました。

計測結果

ㅤ	tsc 5.9.3	tsc 6.0.0-beta	tsgo 7.0.0-dev
コールド起動（1回目）	3.40s	2.02s	0.70s
安定時（3回目）	1.60s	0.98s	0.22s
メモリ（安定時）	515 MB	507 MB	344 MB

安定時の速度比較:

比較	倍率
tsgo vs tsc 5.9.3	7.3x 高速
tsgo vs tsc 6.0.0-beta	4.5x 高速
tsc 6.0.0-beta vs tsc 5.9.3	1.6x 高速
メモリ削減（tsgo vs tsc 5.9.3）	33% 削減

7,000行規模の小さなプロジェクトでも、tsgo は tsc 5.9.3 比で 7.3倍 の高速化が確認できました。公式ベンチマーク（大規模プロジェクトで10倍前後）には及びませんが、1.60秒が0.22秒になるのは体感で明確にわかる差です。

興味深いのは tsc 6.0.0-beta が 5.9.3 から 1.6倍速くなっている 点です。Go 版に注目が集まりがちですが、TypeScript 6.0 ではデフォルト設定が合理化されており（strict: true、module: esnext、target: es2025 など）、公式ブログでは types の設定を適切にするだけで 20〜50% のビルド時間改善 が報告されています。tsgo への移行がすぐにできない場合でも、6.0 へのアップデートだけで恩恵が得られます。

互換性の注意点

tsgo と tsc 6.0.0-beta の両方で、tsc 5.9.3 にはなかった型エラー TS2882 が1件検出されました。


error TS2882: A module specifier that ends in '.css' cannot be resolved
  without specifying a different import assertion or module declaration

import './globals.css' のような CSS の side-effect import に対して型宣言を要求する、TypeScript 6.0 で追加された新しいチェックです。暫定的には以下のような型宣言で回避できます。


// globals.d.ts
declare module '*.css' {}

Next.js 側の型定義更新で正式に解消される見込みですが、移行時にはこうした差分の確認が必要です。

開発現場で何が変わるか — 3つのインパクト

公式ベンチマークと今回の検証結果を踏まえて、開発現場への影響を具体的に考えてみます。

インパクト 1: CI/CD パイプラインの高速化

TypeScript プロジェクトの CI で、型チェック（tsc --noEmit）がボトルネックになっている現場は多いのではないでしょうか。VS Code クラス（150万行）のコードベースで77.8秒かかっていた型チェックが7.5秒になるというのは、CI 全体の体験を変える数字です。

先ほどの検証でも、7,000行規模のアプリで型チェックが 1.60秒 → 0.22秒に短縮されました。単体では小さな差に見えますが、PR ごとの CI に型チェックを含めていると、1日に何十回も走るステップです。ビルドのたびに数十秒〜数分を費やしていたのが数秒に短縮されれば、フィードバックサイクルが目に見えて速くなります。

Cloud Build や GitHub Actions のようなマネージドビルドサービスを使っている場合は、ビルド時間の短縮がそのままコスト削減にもつながります。小さなプロジェクトでは差額は微々たるものですが、複数のマイクロサービスを並列ビルドしている組織では、積み上がると無視できないコスト差になります。

インパクト 2: 開発者体験（DX）の向上

CI だけでなく、日々のコーディング体験も変わります。

公式ブログ（2025年3月の発表記事）によると、VS Code でのプロジェクト読み込み時間が 9.6秒から1.2秒 に短縮されています。8倍の改善です。大きなプロジェクトを開いたときに IntelliSense（コード補完やエラー表示）が効き始めるまでの待ち時間がほぼなくなるということです。

数字以上に、体で感じる差は大きいはずです。エディタの「もたつき」は、コンテキストスイッチの原因になりがちです。型チェックが走っている間に Slack を見て、戻ってきたら何をしていたか忘れる——そういう経験がある人は少なくないと思います。こうした小さなロスの積み重ねが減るのは、生産性の面で想像以上に効いてきます。

2025年12月の公式進捗報告では、rename、find-all-references、auto-imports、go-to-definition といったエディタ機能が再実装され、日常的に使える状態になったとされています。VS Code 向けのプレビュー拡張機能をインストールすれば、この高速化を体験できます。

インパクト 3: エコシステムの移行コスト

一方で、移行にはコストが伴います。ここは冷静に見ておく必要があります。

Strada API の非互換: TypeScript 7.0（Go 版）は、従来の JavaScript ベースの内部 API（Strada API）とは互換性がありません。ESLint のカスタムルール、独自の TypeScript プラグイン、フォーマッターなど、TypeScript の内部 API に依存しているツールは影響を受ける可能性があります。

TypeScript 6.0 での deprecation: TypeScript 6.0 では多くの設定が非推奨・削除になります。--target es5 や --moduleResolution node（node10）に加え、--module amd/umd/systemjs、--moduleResolution classic、--outFile なども対象です。TypeScript 7.0 でこれらは完全に削除される予定のため、6.0 の段階で対応しておく必要があります。

バンドラーとの棲み分け: esbuild（Go 製）や swc（Rust 製）のようなバンドラー/トランスパイラは、型チェックを行わない代わりに高速なビルドを提供してきました。TypeScript 7.0 でコンパイラ自体が高速化された今、これらのツールとの使い分けは改めて整理が必要です。ただし、esbuild や swc はバンドリングに強みがあるため、完全な置き換えにはならないでしょう。

移行に向けて今からできること

TypeScript 6.0 ベータが出た今が、移行準備を始めるタイミングです。

フェーズ 1: tsgo プレビュー版で事前検証

Go 版はプレビュー版としてすでに試せる状態です。まずは既存プロジェクトに対して tsgo --noEmit を実行し、ビルド時間を計測してみることをおすすめします。


npm install -g @typescript/native-preview
tsgo --noEmit

今回の検証も、この手順で30分もかからずに結果が出ました。現状のビルド時間と比較するだけでも、移行する価値があるかどうかの判断材料になります。新しい型エラーが出た場合は、その内容を確認しておくと正式リリース後の対応がスムーズです。

フェーズ 2: TypeScript 6.0 の deprecation 対応（ここが本丸）

TypeScript 6.0 は2026年3月の正式リリースが見込まれています。非推奨になる設定は --target es5、--moduleResolution node だけでなく、--module amd/umd/systemjs、--outFile、--moduleResolution classic など多岐にわたります。tsconfig.json を確認し、非推奨の設定がないかチェックしておくのがよいでしょう。TypeScript 7.0 ではこれらのサポート自体が削除されるため、6.0 での対応が実質的な移行の第一歩になります。

フェーズ 3: TypeScript 7.0 への本番移行

CI/CD パイプラインへの組み込み、エディタの設定変更、依存ツールの互換性確認を経て、本番環境へ移行します。特に Strada API に依存しているカスタムツールがある場合は、事前に代替手段を調査しておくことをおすすめします。

おわりに

TypeScript 6.0 のベータ公開は、JavaScript 版コンパイラの終わりの始まりです。10倍速の Go 版コンパイラは、CI の待ち時間やエディタのもたつきといった日々の開発体験を根本から変えるポテンシャルを持っています。一方で、エコシステムの移行コストやプレビュー段階の制約もあり、本番投入までにはまだステップが残っています。

TypeScript 6.0 が出た今このタイミングで、まずは tsgo をプレビューで試してみる。deprecation 対応で tsconfig.json を見直す。そうした小さな一歩が、TypeScript 7.0 への移行をスムーズにしてくれるはずです。