TypeScript 7.0 Betaは、単なるマイナーバージョン更新ではありません。コンパイラと言語サービスの土台をGoへ移し、ビルドと編集体験を大きく変える転換点です。大規模コードベースを扱う開発現場ほど、この差は効きます。

この記事では、TypeScript 7.0 Betaで何が変わったのか、どこに導入価値があるのか、既存のTypeScript 6.0とどう付き合うべきかを整理します。

  • 何が速くなったのか
  • 既存コードにどこまで互換性があるのか
  • どの導入手順が現実的か
  • 6.0との併用で何に注意すべきか

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/

Goベースに移った意味

TypeScript 7.0 Betaの最大の変更は、実装基盤がGoになったことです。従来のTypeScriptはTypeScript自体で書かれたコードベースでしたが、7.0ではネイティブコードの速度と共有メモリ並列化を活かす設計に変わりました。Microsoftは、この変更でTypeScript 6.0よりおよそ10倍速い場面があると説明しています。

ここで重要なのは、単に新しいから速いわけではない点です。既存の型チェックの意味論を保ったまま、実装だけを新しい土台に移しています。つまり、開発者が欲しいのは派手な新機能よりも、日々のtsc実行時間の短縮です。その期待に真正面から答えています。

何が速くなるのか

速さの恩恵は、巨大なリポジトリほど大きくなります。TypeScript 7.0 Betaは、解析、型チェック、emitを並列化します。特にモノレポでは、複数プロジェクトを同時にビルドするための--builders、型チェックワーカー数を調整する--checkersが効きます。

編集体験も改善対象です。VS Code向けのTypeScript Native Preview拡張を使えば、エディタ上でも同じ基盤の高速化を受けられます。ビルドが速いだけではなく、補完、ホバー、移動、診断の待ち時間が短くなるのが実務上の価値です。

すぐ試す方法

導入は難しくありません。Beta版は@typescript/native-preview@betaとして入手でき、tsgoをtscの代わりに使います。今のプロジェクトに影響を抑えながら評価できるよう、TypeScript 6.0と並行運用しやすい設計です。

この「並行運用できる」点は重要です。新基盤が出ると、通常は既存ツールチェーンの崩れが心配になります。しかし今回は、互換パッケージ@typescript/typescript6まで用意されています。移行時の混乱を減らすための配慮が明確です。

既存プロジェクトで気をつける点

性能だけ見て導入を急ぐと、設定変更でつまずきます。7.0ではstrictがデフォルトで有効になり、moduleやtarget、typesの既定値も変わります。特にrootDirとtypesは、既存のtsconfig.jsonに依存するプロジェクトで影響が出やすい箇所です。

また、古い設定の一部はハードエラーになります。moduleResolution: node10やmodule: commonjsの一部の運用は見直し対象です。これを厳しくなったと捉えるより、今後の標準に合わせて整理する機会だと見たほうが実務的です。

どんなチームに向くか

向いているのは、まずモノレポを抱えるチームです。プロジェクト数が多く、CIが重く、エディタ応答が鈍い環境では、並列化の効果が出やすいからです。次に、型安全を重視しつつもビルド時間を削りたいチームです。品質を落とさず速度を上げたいなら、今回の方向性はかなり筋がいいです。

一方で、小さなプロジェクトでは体感差が薄い場合があります。その場合でも、Betaを試しておく価値はあります。将来の本番移行に向けて、設定差分や互換性の論点を先に把握できるからです。

まとめ

TypeScript 7.0 Betaは、機能追加よりも土台の刷新が主役です。Goベース化、並列処理、6.0との並行運用という3点で、開発速度と移行のしやすさを両立しようとしています。大規模開発ほど恩恵が大きく、特にCI時間と編集応答を詰めたいチームには有力な候補です。

本番導入を急ぐより、まずはBetaを別ブランチや一部プロジェクトで試し、tscとの差分を測るのが現実的です。速度だけでなく、設定変更の影響まで見ておくと、7.0への移行判断がぶれません。