MicrosoftはTypeScript 7(コード名「Corsa」)として、TypeScriptコンパイラをGoで再実装するネイティブポートを進めている。2025年3月にAnders Hejlsbergが発表したこのプロジェクトは、VS Codeの150万行コードベースのコンパイル時間を77.8秒から7.5秒へ短縮し、10倍以上の高速化を実現した。本記事では、このネイティブコンパイラの技術的仕組み、TypeScript 6.0ブリッジリリースとの関係、そして大規模プロジェクトにおける移行戦略を解析する。

Project Corsaの背景と発表経緯

TypeScriptの生みの親であるAnders Hejlsbergは、2025年2月28日にTypeScriptコンパイラのネイティブポートを正式に発表した。Hejlsbergは「TypeScriptの核心的価値は優れた開発体験にある。コードベースが成長するほどTypeScriptの価値は高まるが、多くの場合TypeScriptは最大規模のコードベースにスケールできていなかった」と述べ、JavaScript実装の限界を認めた。

従来のTypeScriptコンパイラ(tsc)はJavaScriptで実装されており、Node.jsのシングルスレッド実行モデルに制約されていた。企業規模のモノレポでは型チェックに数分を要し、CI/CDパイプラインのボトルネックとなっていた。この構造的問題を解決するため、MicrosoftはProject Corsaとしてコンパイラ全体のGoへの移植を決定した。

なぜGoが選ばれたのか ── 言語選定の技術的根拠

TypeScriptチームはC#、Rust、C++を含む複数の言語を評価した上で、Goを選択した。この判断には明確な技術的根拠がある。

第一に、構造的互換性である。TypeScriptチームは「イディオマティックなGoは既存のTypeScriptコードベースのコーディングパターンに強く類似しており、移植作業をはるかに扱いやすくする」と説明している。これは完全な書き直し(rewrite)ではなく、既存コードの構造を保った移植(port)であるため、元のコードとの対応関係を維持できる言語が求められた。実際にMicrosoftはGoコードを自動生成するツールを開発し、多くの箇所で行単位の対応関係を実現している。

第二に、メモリ管理モデルの適合性である。コンパイラはAST(抽象構文木)をプログラムの生存期間中保持し続けるため、ほとんどのメモリ確保は初期段階で行われる。GoのGC(ガベージコレクション)はこのパターンにおいてランタイムコストが最小限となる。Rustの借用チェッカーとライフタイム管理は、この種の構造的移植には過度な書き換えを要求する。

第三に、並行処理の容易さである。Goのgoroutineとchannelは、ファイル単位の並列パース・バインディング・エミットといったコンパイラの並列化に自然に適合する。C#も検討されたが、既存の設計パターンに対してより根本的なアーキテクチャ変更が必要となるため見送られた。

共有メモリ並列処理のアーキテクチャ

TypeScript 7の性能向上は、単にGoがJavaScriptより高速であるという事実だけでは説明できない。コンパイラのアーキテクチャレベルで並列処理が再設計されている。

従来のtscはシングルスレッドで動作し、パース→バインド→型チェック→エミットの各フェーズを逐次実行していた。TypeScript 7では、Goの共有メモリモデルを活用し、複数のフェーズを並列化した。具体的には以下の3層構造で並列性を実現している。

パース・バインド・エミットの並列化: これらのフェーズはファイル間の依存関係が少なく「恥ずかしいほど並列」(embarrassingly parallel)なタスクである。利用可能なすべてのCPUコアを活用して処理される。

型チェックのマルチスレッド化: 型チェックはファイル間の依存グラフを考慮する必要があるため完全な並列化は困難だが、複数のスレッドに分割して効率を改善している。メモリ使用量はわずかに増加するが、処理速度は大幅に向上する。

プロジェクト参照のマルチプロジェクトビルド: --buildモードでは複数のプロジェクトを並列にビルドできるようになった。モノレポにおいて、依存関係グラフに基づく並列ビルドが可能となり、従来の逐次処理から大幅に高速化される。

Go実装による並行処理は全体の高速化のうち約3倍の寄与をしているとされ、残りはGoのコンパイル言語としてのネイティブ実行速度とメモリ効率による。全体として約10倍の高速化が実現される構造である。

ベンチマーク結果の詳細分析

Microsoftが公開したベンチマークデータは、規模の異なる複数のプロジェクトで一貫した高速化を示している。

2025年3月の初回発表時点では、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倍、rxjs(2,100行)が1.1秒→0.1秒で11.0倍の高速化を記録した。

2025年12月の進捗報告では、TypeScript 6.0ベースラインとの比較で更新されたベンチマークが公開されている。Sentry(大規模プロジェクト)が133.08秒→16.25秒で8.19倍、VS Codeが89.11秒→8.74秒で10.2倍という結果となった。エディタの起動時間も、VS Codeで9.6秒から約1.2秒へと8倍の改善が確認されている。

メモリ使用量については「全体的なメモリ使用量は現行実装のおよそ半分」と報告されている。コンパイル速度だけでなくメモリ効率も大幅に改善されたことは、CI/CDの実行コストに直接影響する。

TypeScript 6.0ブリッジリリースの役割

TypeScript 6.0は2026年2月11日にベータが公開された、JavaScript実装としての最後のメジャーリリースである。TypeScript 5.9とTypeScript 7.0の間の橋渡し(bridge)として明確に位置づけられている。

TypeScript 6.0は、TypeScript 7.0で予定される破壊的変更を事前に周知する役割を担う。主な非推奨化項目として、ES5ターゲット、AMD・UMD・SystemJSモジュール、baseUrlオプション、レガシーモジュール名前空間構文、import assertsキーワード(withに置換)が含まれる。

デフォルト設定も大幅に変更された。strict: trueがデフォルトとなり、module: esnexttarget: es2025types: [](明示的宣言が必要)がデフォルトに設定される。これらはTypeScript 7.0のデフォルトと揃えられている。

TypeScriptチームはts5to6という移行支援ツールも提供している。このツールはtsconfig.jsonを自動的に更新し、extendsreferencesのヒューリスティクスを用いてプロジェクト全体の設定を変換する。さらに--stableTypeOrderingフラグにより、TypeScript 6.0と7.0間の型の順序差異を検出できる。

大規模コードベースにおける移行戦略

TypeScript 7.0への移行は段階的なアプローチが推奨される。Microsoftが示す3フェーズの移行パスは以下のとおりである。

フェーズ1: テスト(現在〜2026年前半)npm install -D @typescript/native-previewでtsgoをインストールし、既存プロジェクトでの型チェック互換性を検証する。約2万件のコンパイラテストケースのうち不一致は74件のみであり、ほとんどのプロジェクトで互換性は高い。

フェーズ2: 準備(TypeScript 6.0安定版リリース後)。TypeScript 6.0で非推奨化された機能を段階的に除去し、新しいデフォルト設定に移行する。ts5to6ツールと--stableTypeOrderingフラグを活用して差異を特定する。

フェーズ3: 本番移行(TypeScript 7.0安定版リリース後)。安定版リリースを待って本番ビルドを切り替える。移行期間中はCI/CDでTypeScript 6.0による実コンパイルとtsgoによる高速型チェックを併用するハイブリッド戦略が推奨される。

注意すべき制約として、TypeScript 7.0のAPI(Corsa API)は既存のStrada APIと大幅に異なる。リンター、フォーマッター、IDEプラグインなど、コンパイラAPIに依存するサードパーティツールは互換性を失う。ESLint、Prettier、各種エディタプラグインのエコシステムがCorsa APIに対応するまでに時間を要する可能性がある。また現時点ではJavaScriptのエミットパイプラインが不完全で、ダウンレベルコンパイルはes2021までに制限されている。

CI/CDパイプラインへの構造的影響

TypeScript 7のネイティブコンパイラは、CI/CDパイプラインの設計前提を根本から変える。従来、TypeScriptの型チェックはCI/CDの中で最も時間を要するステップの一つであり、大規模プロジェクトでは数分単位の待ち時間が常態化していた。

10倍の高速化により、かつて10分を要した型チェックが1分以内に完了する。これは単なる「待ち時間の短縮」にとどまらず、開発ワークフロー全体の再設計を可能にする。Pull Requestのマージ前チェックが高速化されることで、開発者のコンテキストスイッチが減少し、レビューサイクルが短縮される。

メモリ使用量の半減もCI/CD環境では重要である。GitHub ActionsやGitLab CIのランナーはメモリリソースに制約があるため、メモリ効率の向上はジョブの安定性向上とコスト削減に直結する。--incrementalモードの再実装により、差分ビルドではさらに高速化が期待される。小規模な変更に対するビルドは「瞬時」と感じられるレベルにまで短縮される可能性がある。

ただし、配布形式の変更にも注意が必要である。tsgoはGoでコンパイルされたネイティブバイナリとして配布されるため、CI/CDのベースイメージにNode.jsだけでなくtsgoバイナリが必要となる。Docker イメージの構成やキャッシュ戦略の見直しが求められる場面もあるだろう。

FAQ

TypeScript 7はいつ安定版がリリースされるのか?

2026年2月時点で安定版の正式なリリース日は未発表である。ナイトリープレビューは公開されており、TypeScript 6.0ベータが2026年2月にリリースされたことから、2026年中盤以降の安定版リリースが見込まれる。

既存のTypeScriptプロジェクトはそのまま動作するのか?

約2万件のコンパイラテストケースのうち不一致は74件のみであり、型チェックの互換性は非常に高い。ただしAPIが変更されるため、コンパイラAPIに依存するサードパーティツール(リンター、フォーマッター等)は対応が必要となる。

なぜRustではなくGoが選ばれたのか?

既存コードの構造的移植(port)が目的であり、GoのコーディングパターンがTypeScriptの既存コードベースに最も類似していたためである。Rustの借用チェッカーは構造的移植に過度な書き換えを要求するとされた。

tsgoを今すぐ試すにはどうすればよいか?

npm install -D @typescript/native-previewでインストールし、tsgoコマンドで実行できる。VS Code向けには「TypeScript Native Preview」拡張機能が毎日更新されている。

参考文献