TypeScript 7とは何か？Goネイティブ新コンパイラ採用など2025年最新バージョンの概要と特徴を徹底解説

TypeScript 7とは何か？Goネイティブ新コンパイラ採用など2025年最新バージョンの概要と特徴を徹底解説

TypeScript 7は、Microsoftが2025年にリリース予定の次期メジャーバージョンであり、最大の特徴はコンパイラと言語サービスをTypeScript/JavaScript（Node.js）実装からGo言語によるネイティブ実装へと全面的に移行した点です。このプロジェクトはコードネーム「Project Corsa」として進められ、TypeScriptの開発史上でも大規模なアーキテクチャ刷新となっています。従来のTypeScriptコンパイラ（tsc）はNode.js上で動作していましたが、TS7ではGoで書かれた新コンパイラが導入され、生のネイティブコードによる高速な実行性能、低いメモリ使用量、そしてマルチコアCPUを活かした並列処理を実現します。これにより、大規模プロジェクトで問題となっていたビルド時間やエディタの応答の遅さが劇的に改善され、開発者体験が飛躍的に向上します。

また、この新バージョンはTypeScript 6系からの大きな転換点でもあります。TypeScriptチームは「TypeScript 6.0を従来JavaScript実装の最後のメジャーリリース」と位置付け、6.0で将来的な非推奨項目の整理を行った上で、7.0から本格的にネイティブコンパイラへ移行する計画を明らかにしています。つまり、6.0が既存（“Strada”と呼ばれる旧コードベース）から新しいネイティブコードベースへの「ブリッジ（橋渡し）」となり、TypeScript 7.0以降はGo製コンパイラによる新体制が本流となるのです。

総じてTypeScript 7は、言語仕様そのものの大幅変更というよりは、開発ツールチェーンの土台を刷新し、パフォーマンスとデフォルト設定を大きく見直したリリースだと言えます。その結果、最大10倍のビルド高速化やメモリ効率向上といった恩恵に加え、デフォルトの型チェックモード変更など、開発者に直接影響するさまざまな改良が含まれています。以下、具体的な新機能・変更点や性能向上の仕組み、移行方法などについて詳しく解説していきます。

TypeScript 7で追加された主な新機能と変更点まとめ：10倍高速化からstrictモードデフォルト有効化まで

TypeScript 7で注目すべき新機能・変更点をまとめると、以下のようになります。

• ネイティブ実装コンパイラ「tsgo」によるビルド高速化: 新コンパイラの導入により、大規模リポジトリでビルド時間が従来比7～10倍程度も短縮されています。これは後述する並列処理対応などにより、フルビルドで劇的な時間短縮を実現したものです。
• strictモードのデフォルト有効化: 型チェックの厳格モード（--strict）が標準でオンになります。TS7ではtsconfigで明示しなくともstrict型チェックが適用され、これまで非strictモードに依存していたコードでは追加の型エラーが出る可能性があります。
• ターゲット指定のデフォルト変更と旧ターゲットの廃止: コンパイル出力のECMAScriptターゲット（--target）が最新の安定版（例えばES2025相当）にデフォルト変更されます。また古いES5ターゲットはサポート終了となり、TS7で指定可能な最も低いターゲットはES2015となります。
• モジュール解決とパス設定の整理: tsconfig.jsonのbaseUrlオプションが廃止されます。さらにモジュール解決オプションでは、旧来の--moduleResolution node（node10とも呼ばれる）オプションが削除され、代わりにbundlerやnodenextモードの利用が推奨されます。
• 各種エディタ機能のネイティブ実装での充実: 新しいネイティブ言語サービスは、コード補完や定義ジャンプ、リネーム、型情報ホバー表示など主要なエディタ機能をすべて実装済みです。従来プレビュー版で未対応だった自動インポート補完や検索（Find All References）機能も実装され、エディタ内でも遜色ない機能パリティが確保されています。

これらの変更により、TypeScript 7は開発体験の高速化・快適化と、安全性向上（デフォルトstrict化）、そしてモダンなJavaScript環境への最適化を同時に実現しています。「ビルドが遅い」「設定次第で型チェックが甘くなる」といったこれまでの課題に対し、デフォルトで最良の体験を提供する方向に大きく舵を切ったバージョンといえるでしょう。

TypeScript 7で刷新されたGo製新コンパイラ「tsgo」とは何者か？従来tscとの違いを探る

「tsgo」とは、TypeScript 7で導入された新しいネイティブコンパイラのCLI名称です。従来のtscコマンドに相当し、機能的にはtscとほぼ同等の操作が可能です。tsgoは@typescript/native-previewというパッケージとして提供され、npm経由でインストールすることで利用できます。tscとtsgoは同じプロジェクトで並行してインストール・使用することも可能であり、移行期間中は双方を使い分けることも想定されています。

tsgoとtscの最も大きな違いは内部実装とパフォーマンスです。tscがTypeScript（JavaScript）で書かれNode.js上で動作していたのに対し、tsgoはGo言語で書かれたネイティブバイナリです。そのため、実行のためのランタイムオーバーヘッドが小さく、CPUを直接マルチスレッドで活用できるため、処理速度が飛躍的に向上しています[1]（詳細は次節で解説）。たとえば大規模プロジェクトのフルビルドでは、tsgoはtscの7～10分の1程度の時間で処理を完了します。

もう一つの違いは対応する周辺ツール・APIです。tsc（～6.0まで）の内部API「TS Server (Strada)」を利用したリンターやコードフォーマッタ、各種IDE拡張は、TS7のtsgo（新API「Corsa」）とは互換性がありません。つまり、現時点でtsgoはコンパイル（型チェックやビルド）用途に専念しており、既存のサードパーティ製ツールはまだtsgoに直接統合できない場合があります。そのためTypeScriptチームも、当面はtypescript（従来コンパイラ）と@typescript/native-preview（tsgo）を併用し、ツール類は旧APIで動かしつつビルドは新コンパイラで高速化する、といった運用を推奨しています。

しかし、型チェックやビルドの機能面においてはtsgoとtscの差異はほとんどありません。TypeScriptチームの報告によれば、2万件のコンパイラテストのうち99%以上でtscとtsgoのエラー検出結果は一致しており、残りの僅かな差分も意図的な仕様変更や未実装機能によるものに過ぎないとのことです。さらに--incrementalビルドやプロジェクト参照（--buildモード）といった大規模プロジェクト向けの機能もtsgoに実装済みで、既存プロジェクトの多くがtscから大きな変更なくtsgoへ切り替え可能です。総じて、tsgoは「内部実装を一新し圧倒的に高速になったTypeScriptコンパイラ」であり、言語の互換性・機能性は維持しつつ、周辺エコシステムとの互換性に関してのみ過渡期の注意が必要、という位置付けになります。

Goネイティブ化でビルドが10倍高速化する仕組み：並列コンパイル活用とメモリ効率向上による圧倒的速度アップ

◆ 並列コンパイルによるマルチコア活用

TypeScript 7のコンパイラが高速化を実現した最大の要因は、マルチスレッドによる並列コンパイルにあります。Go言語への移行により、これまでシングルスレッドで動作していたTypeScriptのコンパイル処理を、複数スレッドに分散して同時実行できるようになりました[1]。具体的には、複数のファイルのパース・型チェックを並行して行ったり、--buildモードで複数のプロジェクト（プロジェクト参照）を同時にビルドしたりすることが可能になっています[2]。従来のtscではプロジェクト内のファイルを一つずつ順番に処理していたため、大規模プロジェクトではCPUコアの大半が遊休状態となりビルドに時間がかかっていました。一方、tsgoでは共有メモリ型の並行処理モデルによりスレッド間のやり取りを低コストで行えるため、各コアをフル活用して大規模コードベースを一気に処理できます。

さらに、TypeScript特有の増分ビルド（--incremental）機能も新実装によって強化されています。TS7では前回ビルド結果を活かした差分コンパイルも並列処理と組み合わせることで一段と効率化されており、大規模プロジェクトでも小さな変更であればビルドがほぼ瞬時に完了すると報告されています。以上のように、Goネイティブ化に伴う並列化対応こそが「ビルド10倍高速化」の原動力であり、従来はシングルスレッド制約で頭打ちだった性能をハードウェアリソースいっぱいまで引き出せるようになった点が画期的です。

◆ メモリ効率の向上と低オーバーヘッド化

高速化のもう一つの側面はメモリ使用効率の向上です。ネイティブコードへの移行により、V8エンジン上で動作するJavaScriptのランタイムオーバーヘッドが無くなり、メモリ管理もGoランタイムの下で最適化されています。その結果、コンパイラのメモリ消費量は大幅に削減されました。Microsoftによる初期プレビュー段階の発表では、エディタでプロジェクトを開いた際のメモリ使用量が従来実装の約半分程度になったと報告されています。さらに別の報告では、特定のケースで旧コンパイラの8分の1のメモリしか使用しなくなったとも伝えられています。

メモリフットプリントが削減されたことにより、ガベージコレクションの負担軽減など間接的な効果も含めてコンパイラ全体の効率が上がっています。大量の型情報を扱うTypeScriptでは、メモリ帯域やGC待ち時間がボトルネックになることが多々ありました。TS7ではそのボトルネックが緩和され、メモリ面でも無駄の少ない実行が可能になっています。特に大規模モノレポや複数プロジェクトを同時に開く状況でも、メモリ逼迫によるエディタの動作遅延が起こりにくくなるため、開発マシンやCIサーバー上での安定性・スピード向上に寄与します。

以上の並列処理とメモリ効率化により、TS7の新コンパイラは単に「Goだから速い」というだけでなく、設計段階からパフォーマンスを最大化する工夫が随所に盛り込まれていることが分かります。10倍という飛躍的高速化はこれら複合的な最適化の成果であり、TypeScript自体の実行速度（生成されたJavaScriptの実行速度）が向上するわけではありませんが、コンパイルに要する待ち時間が劇的に短縮される意義は非常に大きいと言えます。

TypeScript 7で変更・削除されるレガシーtsconfig設定：ES5向けターゲット廃止など互換性に関わる主な変更点

前述のように、TypeScript 7では将来の方向性に沿って既存のtsconfigオプションのいくつかに非互換な変更が加えられます。特に影響の大きいレガシー設定の廃止・変更点は次の通りです。

• --strict（strictモード）…デフォルト値がfalseからtrueに変更されます。TS7では明示しない限りstrict型チェックが有効になるため、strictモード非対応だったコードはエラーが増える可能性があります。
• --target（コンパイル出力ターゲット）…デフォルトが最新の安定版ECMAScriptに変更されます。具体的にはリリース時点の最新仕様（例えばES2025）がデフォルトとなり、古い環境向けにtargetを指定しない限り自動的にモダンな構文で出力されます。
• --target es5…サポート廃止されます。TS7ではES2015（ES6）以降を前提とする設計となっており、コンパイルターゲットの下限がES2015になります。ES5世代の古いJavaScript環境向けコード出力は基本的にサポート外となる点に注意が必要です。
• --baseUrl…サポート廃止されます。モジュール解決時のベースパス指定であるbaseUrlはTS7では非推奨となり、設定が無視されます。代替としては相対インポートの明示や、pathsオプションとモジュールバンドラの機能で対応することが推奨されます。
• --moduleResolution node（別名node10）…サポート廃止されます。従来デフォルトだったNode.jsスタイルのモジュール解決（CommonJS前提の解決ロジック）は削除され、TS7ではnodenextやbundlerといったES Modules対応の新しい解決モードに一本化されます。
• rootDirのデフォルト動作変更…TS7ではrootDirの自動推定挙動が変わります。outDirを指定してビルドする場合、デフォルトではtsconfig.jsonのあるディレクトリがrootDirと見做され、すべてのエントリソースはtsconfig.json直下に置かれている必要があります（それ以外の配置をする場合はrootDirを明示指定する必要があります）。

以上が主な非推奨・削除予定の設定項目になります。これらはTypeScript 6.0において非推奨警告が出るかドキュメントでアナウンスされており、7.0で正式に削除・仕様変更となるものです。もし既存プロジェクトがこれらの設定に依存している場合、TS7へのアップグレード時にコンパイルエラーや挙動の変化が発生する可能性があります。したがって、移行前に該当設定を使用していないか確認し、必要に応じて設定ファイルやコードを修正しておくことが重要です。

TypeScript 6から7への移行ポイントと注意点：互換性の壁とtsconfig移行ツールでスムーズにアップグレード

TypeScript 7は大きな内部刷新を伴うため、6系からの移行にあたってはいくつか注意すべきポイントがあります。まず前提として、前述したとおりTypeScript 6.0自体が7.0を見据えた「ブリッジ」リリースとして位置付けられています。6.0では将来削除されるオプション（strictのデフォルト無効やES5ターゲット対応など）が非推奨となり、可能な限り7.0と型チェックの挙動を合わせるよう調整されています。したがって、TS6.0にプロジェクトをアップデートし、そこで非推奨警告に対処しておくことがTS7への準備として有効です。TS6.0と7.0は型チェック結果がほぼ一致するよう作られているため、まず6.0で自分のコードが問題なくコンパイルできる状態にしておけば、7.0でも大きな問題なく移行できる可能性が高いでしょう。

特に、前節で挙げた設定項目についてはTS6のうちに対策しておくのが望ましいです。例えばstrictモードを有効にして発生するエラーに対処する、targetをES2015+に切り替える、baseUrlやnode_modulesパス解決の見直し（pathsの明示やBundler設定への移行）などです。そうした変更点を自力で洗い出すのが難しい場合、TypeScriptチームが提供する実験的な設定移行ツール「ts5to6」を試す手もあります。ts5to6はコマンドラインツールとして、既存のtsconfig.jsonを解析して非推奨設定を自動書き換えする補助を行います（現時点ではbaseUrlとrootDirの修正に対応）。以下のようにnpx経由で実行することで、対応する設定項目の変換を試みてくれます。

npx @andrewbranch/ts5to6 --fixBaseUrl your-tsconfig.json
npx @andrewbranch/ts5to6 --fixRootDir your-tsconfig.json

さらに、TypeScript 7の新コンパイラ(tsgo)を実際にプロジェクトに導入してテストしてみることも推奨されます。TS7の型チェック互換性は非常に高く、先述の通り既存コンパイラとほぼ同じエラーを検出できます。そのため、現行プロジェクトにtsgoを導入してコンパイルを試し、エラーの差分を確認することで、移行時に修正すべき箇所を事前に洗い出すことができます。幸いtsgoはnpmで簡単にインストールして既存tscと並行利用できるため、このような検証が容易になっています。

移行期間中の運用としては、tscとtsgoを併用する戦略も有効です。例えば、エディタやテストなど既存ツールチェーンとの統合が必要な部分では引き続きTS6.0（tsc）を使いつつ、CIでの型チェックやローカルビルド高速化のためにtsgoを使う、といった使い分けが考えられます。TypeScriptチームも「エディタや一部ツールは6.0、ビルドや型検証は7.0」といったハイブリッド運用が当面は現実的だと述べています。最終的にはTS7のみへ統一するにせよ、移行初期段階では無理に全てを切り替えず段階的に導入すると良いでしょう。

以上のように、TypeScript 7への移行ではコンパイラ高速化の恩恵を享受できる一方、設定面での非互換やstrictモード有効化によるコード修正が求められる場合があります。互換性の壁に備えて、事前準備と段階的な適用を心がけることで、スムーズなアップグレードが可能になるでしょう。

TypeScript 7ではstrictモードがデフォルトで有効化されることで何が変わるか：型チェック強化によるメリットと影響

TypeScript 7における大きな方針転換の一つが“strictモードのデフォルト有効化”です。strictモードとは、TypeScriptコンパイラの各種厳密な型チェックオプション（noImplicitAny, strictNullChecks, strictFunctionTypesなど複数の設定を包括した総称）をまとめてオンにする設定です。これまではこのstrictモードはデフォルト無効（任意で--strictを有効にする必要があった）でしたが、TS7からは何も指定しない場合にstrict相当のチェックが働くようになります。

では、この変更によって具体的に何が変わるのでしょうか。最大の影響は、厳格な型チェックが標準になることでコード中の潜在的な問題が洗い出されやすくなる点です。strictモードでは暗黙のany型許容が禁止されるほか、undefinedやnullの扱い、関数の引数・戻り値の変種関係チェックなどが厳密になります。そのため、strictモード非対応で書かれたコードでは、TS7にアップグレードした途端にこれまで見逃されていた型エラーが多数報告される可能性があります。例えば、「型注釈を省略していたためanyになっていた変数」や「nullを考慮していない非null型への代入」などが典型的なエラーとして顕在化するでしょう。

一方で、strictモードのデフォルト有効はTypeScriptコミュニティから歓迎される変更でもあります。なぜなら、strictモード運用は以前から推奨ベストプラクティスであり、大規模プロジェクトやライブラリ開発者の多くは既にstrictモードを有効にしていたからです。TS7によって新規プロジェクトは何も設定しなくても自動的に厳格な型チェック体制となり、「うっかりstrictをオンにし忘れて型の穴が生まれてしまう」といった事態を防げます。結果として、TypeScript全体のコード品質・安全性の底上げにつながるでしょう。

もちろん、strictモードによるエラー増加は一時的に開発者の負担を増やすかもしれません。しかしその多くは本来修正すべき潜在バグや型不整合を教えてくれていると捉えることができます。プロジェクトをTS7に移行する際は、まずコンパイルを走らせて出てくるstrict由来のエラーを一つ一つ対処していく必要があります。具体的には、明示的な型注釈の追加、不必要な型断言の除去、nullチェックの充実などが対応策となります。これらの修正作業を経てstrictモードに準拠したコードベースにすることで、結果的にバグの混入しにくい堅牢なコードへと生まれ変わるでしょう。

まとめると、TS7でのstrictモード標準化は「多少の移行コストを払ってでも型チェックを厳密化し、型安全性を高める」というTypeScriptチームの意思表示と言えます。strictモード有効化により得られるメリット（バグ検出率の向上、リファクタリングの安全性向上など）は、多少の修正コストを上回る価値があります。開発者側としても、この機会に自身のコードを見直し、よりTypeScriptの恩恵を享受できる状態へアップグレードすることが期待されます。

TypeScript 7のパフォーマンス検証：ビルド時間短縮とメモリ使用量削減の実測結果を徹底レポート

◆ ビルド時間の劇的短縮：公式ベンチマークの結果

TypeScript 7（tsgo）の性能は実際どれほど向上しているのでしょうか。Microsoftが公開したベンチマーク結果によれば、大規模リポジトリにおけるフルビルド時間は概ね7倍～10倍もの高速化が確認されています。具体例として、Microsoft自身が示したいくつかのOSSプロジェクトでのビルド所要時間を比較すると:

• Visual Studio Code (約150万行): tsc (TS6)で約89.1秒→tsgo (TS7)では8.7秒（約10.2倍高速化）
• Sentry (約50万行): tscで133秒→tsgoでは16.3秒（約8.2倍高速化）
• TypeORM (約27万行): tscで15.8秒→tsgoでは1.06秒（約9.9倍高速化）
• Playwright (約9万行): tscで9.3秒→tsgoでは1.24秒（約7.5倍高速化）

いずれのケースでも、従来はビルド完了まで分単位の待ち時間が発生していたものが、TS7ではほぼ秒単位に短縮されていることが分かります。特にVS Codeクラスの巨大プロジェクトでも10倍以上の短縮が実現しているのは驚異的です。これほどの高速化により、開発サイクルは大きく改善されます。コンパイル待ちのストレスが減るだけでなく、CIの所要時間短縮やデプロイ高速化にも直結します。また「型チェックのためにローカルでフルビルドを回す」といったケースでも負担が軽くなり、開発者はこれまで以上に頻繁にビルド・チェックを実行してコードの健全性を確認できるようになるでしょう。

さらに、エディタ上でのパフォーマンス改善も見逃せません。エディタ内でプロジェクトを開いた際の初期ロード時間について、VS Codeのコードベースを例に取ると、従来9.6秒かかっていた全プロジェクト読み込みが新言語サービスでは約1.2秒で完了したとの報告があります。このように、エディタ起動直後から快適に型情報が提供されるようになり、開発効率が飛躍的に向上します。TypeScript 7の高速化は単なる数値上の改善にとどまらず、開発体験そのものを次のレベルへ引き上げるインパクトを持っていると言えるでしょう。

◆ メモリ使用量の削減：軽量化されたコンパイラの実力

パフォーマンス検証においては、メモリ使用量の減少も重要な指標です。TypeScript 7のネイティブコンパイラはメモリ面でも顕著な改善を示しています。先述の通り、エディタでのプロジェクト読み込み時に使用するメモリがおおむね半減したとの公式報告がありました。これはつまり、同じ規模のコードベースを扱う場合でも、バックグラウンドで動くコンパイラプロセスが占有するメモリ量が約50%程度に抑えられることを意味します。

その後の続報や有志による検証では、ケースによっては従来比で80～85%ものメモリ削減（メモリ使用量1/6～1/8）が達成されたというデータもあります。例えば大量の型定義を含むプロジェクトをビルドした際、旧コンパイラでは数GBに達していたメモリ消費が、新コンパイラでは数百MB台で収まったといった報告も見られます（具体的な数値はプロジェクトに依存しますが）。

このメモリ削減の効果により、開発PCが扱えるプロジェクト規模にも余裕が生まれるでしょう。以前は「プロジェクトが巨大すぎてエディタが重くなる」「並行して複数リポジトリを開くとメモリ不足になる」といった問題がありましたが、TS7ではその懸念が緩和されます。CI/CDサーバー上でも、より少ないリソースで多数のビルドジョブを並列実行できる可能性があります。さらに、メモリ消費が減ることでOSのスワップ発生やGCポーズの頻度も下がり、副次的に処理のスムーズさや安定性も向上すると考えられます。

なお、TypeScriptチームは「現時点でもメモリ使用量は大幅に減っているが、まだ本格的な最適化調査を行う前の段階である」と述べており、今後さらなる改善の余地も示唆しています。つまり、TS7正式版や将来のアップデートで、現状以上にメモリ効率が高まる可能性があります。総合的に見て、TS7のパフォーマンス検証結果はビルド時間・メモリ使用量ともに大幅な改善を裏付けており、宣言通り「10倍速いTypeScript」が現実のものとなりつつあることを示しています。

既存プロジェクトでTypeScript 7（tsgo）を試す方法：導入手順と環境構築のポイントを詳しく解説

最後に、現行のプロジェクトでTypeScript 7の新コンパイラ(tsgo)を試してみたい場合の導入手順とポイントを解説します。一足先に次世代の高速コンパイラを体験し、そのメリットと移行に向けた課題を把握してみましょう。

1. VS Code拡張機能で新言語サービスを試す: VS Code利用者であれば、まず「TypeScript (Native Preview)」拡張をインストールする方法があります。これはTypeScript 7対応のネイティブ言語サービスを提供する公式拡張機能で、VS Codeマーケットプレースから入手できます[3]。この拡張は毎日更新されており、導入するとエディタ内でtsgoベースの型チェック・補完が利用可能です。
2. ネイティブプレビュー版コンパイラ(tsgo)をnpm経由で導入: コマンドラインでtsgoを使用するには、npmで新コンパイラのプレビュー版パッケージをインストールします。具体的にはプロジェクトにnpm install -D @typescript/native-previewと実行することで、tsgoコマンドが利用できるようになります。グローバルにインストールしてnpm install -g @typescript/native-previewとすることも可能です。このパッケージはTypeScript 7開発中のナイトリービルド版であり、バージョンは7.0.0-devのような形式で提供されます。
3. TypeScript本体（～6.x）との共存インストール: 上記パッケージはあくまで新コンパイラだけを含むプレビュー版であり、従来のtypescriptパッケージ（6系）とは別物です。tsgoを導入しても既存のtscが上書きされることはないため、typescript（従来コンパイラ）と@typescript/native-preview（新コンパイラ）を併存させておくことを推奨します。例えばpackage.jsonのdevDependenciesに両方を入れておけば、用途に応じてnpx tscまたはnpx tsgoを使い分けることができます。これは前述の通り、エコシステム上まだtsgoに完全対応していないツールがあるためで、当面は古いコンパイラも残しておく方が無難です。
4. tsgoでコンパイルを実行: tsgoを導入できたら、実際にプロジェクトのビルドや型チェックをtsgoで行ってみましょう。基本的な使い方はtscと同じで、例えばtsconfig.jsonを使ってビルドするにはtsgo -bやtsgo -p tsconfig.jsonといったコマンドを実行します。これにより従来のtscと同等のビルド結果（ただし圧倒的に高速）を得られるはずです。エラーや警告の内容もtscとほぼ変わらないことを確認してください。
5. 既知の制限事項を確認: 現時点のtsgoプレビュー版にはいくつか未実装/制限事項が存在します。例えば、古いターゲットへのダウンレベルコンパイルは未対応で、実質的に--targetはES2021以降しか機能しません（ES2015までのサポートは現在開発中）。またデコレーター構文の変換出力にも未対応です。さらに--watchモードの効率が現行コンパイラほど良くない場合があるとも報告されています。これらの制約に該当するケース（例えばES5向けにトランスパイルする必要があるプロジェクト）では、引き続きtscを使うか、対応完了を待つ必要があります。
6. 段階的に導入してフィードバックする: tsgoは既にかなり安定しており、内部テストではMicrosoft社内外の多くのプロジェクトで日常的に使用されています。とはいえ正式リリース前のプレビューであることから、本番適用には慎重さも必要です。まずは小規模なプロジェクトやCIの型チェック工程などからtsgoに切り替えてみて、得られる高速化のメリットや発生するかもしれない問題を評価してみると良いでしょう。何かバグや互換性問題を見つけた場合は、GitHubのTypeScriptリポジトリにissueを報告したりフィードバックを提供したりすることで、TS7の安定性向上に貢献できます。

以上のステップを踏めば、既存プロジェクト上でTypeScript 7（tsgo）の威力を実感できるはずです。公式の案内でも、VS Code拡張やnpmパッケージを使って新ツールチェーンを試し、従来の6.0系と並行運用しながら早期にフィードバックを得ることが推奨されています。ぜひ手元のプロジェクトで次世代の高速TypeScriptコンパイラを体験してみてください。ビルド時間短縮や型チェックの快適さに驚くと同時に、将来的な全面移行に向けた課題点も見えてくることでしょう。