TypeScriptコンパイラをGoで書き直す「Project Corsa」は、単なる実装言語の置き換えではない。型検査の速度はエディタ体験、CI時間、モノレポ運用、さらには周辺ツールの役割分担まで規定してきた。TypeScriptチームは2025年3月11日、Go移植版（通称 tsgo）で大規模コードベースの型チェックが約10倍高速化する計測結果を公開し、プレビュー提供と段階的な置き換えロードマップを明確化した。

本稿は、TypeScript Go移植の公開情報を一次ソース中心に整理し、tsgoの技術設計、エディタ体験への影響、そして「RustではなくGo」を選んだアーキテクチャ判断が、Web開発ツールチェーンに与える構造変化を技術的に解析する。なお、2026年2月14日時点でnpmの安定版TypeScriptは 5.9.3 であり、ネイティブ移行はプレビューと並走する段階である（本稿は将来の最終リリース時期を断定しない）。

1. 「10倍高速化」が意味するもの: 型検査が支配してきた待ち時間の再編

TypeScriptの待ち時間は、トランスパイルそれ自体ではなく「型検査の前処理と探索」に支配されやすい。IDEでは診断・補完の応答時間、CIでは型チェックの壁、ローカルではウォッチの“再計算”がストレスの源泉になる。TypeScriptチームが示した計測では、代表的な大規模OSSでのビルド時間が大きく短縮された。例としてVS Codeは 77.8秒 → 7.5秒、Playwrightは 11.1秒 → 1.1秒 といった値が示されている（いずれも概ね10倍規模）。

重要なのは「平均が速い」ことより、開発者が日常的に遭遇する“最悪”の待ち時間が削れる点である。型検査が短縮されると、次にボトルネックになるのはバンドラ、テスト、リンタ、コード生成、あるいはリモートキャッシュ戦略へ移る。これにより、ツールチェーンの設計原理が「型検査を避ける」から「型検査を前提に最適化する」へ転換する。

2. tsgoの技術設計: 互換性を維持したまま“実装上の自由度”を取り戻す

Corsaの難所は、言語仕様の再実装ではない。TypeScriptコンパイラとLanguage Serviceは、巨大な既存コードとエコシステム（API互換、差分インクリメンタル、診断の互換性、微妙なエッジケース）を抱えた「実質的なプラットフォーム」である。TypeScriptチームは、移植の目的を互換性を保ちつつ性能を大きく引き上げることとしており、そのために段階的な置き換えと検証戦略を採っている。

公開された進捗では、ネイティブ版が単にtsc相当のCLIだけでなく、開発体験の中核である言語サーバ相当（tsserver系）まで視野に入れ、プレビューを通じて互換性と性能の両面でフィードバックループを回していることが示されている。

技術的に見れば、コンパイラの主要コストは「解析（parse）」「バインド（symbol付与）」「型チェック（checker探索）」に偏り、インクリメンタル更新時にはキャッシュの粒度と参照関係グラフの更新が勝負になる。Go移植は、これらの経路に対して、(1) データ表現（メモリレイアウト、アロケーション削減）、(2) 並列化余地（ファイル単位・フェーズ単位のパイプライン化）、(3) キャッシュの一貫性（再利用単位と無効化規則）を再検討する機会を与える。チーム自身も、パフォーマンス向上を主目的にネイティブ移行を進めている。

3. エディタ体験の変化: 「補完が速い」ではなく「作業の流れが途切れない」へ

開発者が体感する価値は、コンパイル時間の短縮だけではない。エディタ統合は、診断の更新頻度、補完の遅延、ジャンプやリネームの応答性といった“連続的な小さな待ち時間”の積み上げで決まる。ネイティブ移行が進むと、モノレポや大規模ワークスペースでの初回解析と差分更新の両方が短縮され、型のあるJavaScript/TypeScript開発が「重いから避ける」対象から「常時ONが前提」へ変化する。

TypeScriptチームは、ネイティブ版を将来的に既定へ移行する意図を述べつつ、プレビュー段階での互換性検証を重視している。ここでの互換性は、単にエラー数が一致するかではなく、Language Service APIの挙動や診断の安定性、ビルドパイプラインの期待を崩さないことを含む。

4. なぜRustではなくGoか: 「移植の現実」を優先した設計判断

ネイティブ実装の選択肢としてRustが取り沙汰されやすい一方、CorsaはGoを採用した。GitHub Discussionsでの説明では、現状のTypeScriptコンパイラが持つ設計上の前提（例: ガベージコレクションを前提としたグラフ状データ構造の多用）と、巨大な既存コードの移植・検証・運用を現実的に進める観点から、Goが適合すると整理されている。

ここで重要なのは、Goの採否が「性能だけで決まる話」ではない点である。最終的に必要なのは、(1) 正確な互換性、(2) 継続的な改善速度、(3) 多OS/多アーキでの配布と運用、(4) 周辺ツールとの統合である。Corsaは“置き換えのマラソン”であり、コンパイラ単体のベンチマーク最適化では到達できない。

5. Web開発ツールチェーンの構造変化: 「型検査を外部化する」時代からの転換

TypeScriptの性能が十分に高い世界では、ツールチェーンの分業が変わる。これまで高速化の主役は、(a) バンドラが型検査をスキップして高速トランスパイルする、(b) 型検査は別ジョブとして遅延実行する、(c) 変更範囲を極小化するためにプロジェクト参照やキャッシュを徹底する、といった“回避策”だった。ネイティブ版が普及すると、型検査は回避対象ではなく、ビルドと編集の中心に戻る。

具体的には、次のような変化が見込まれる。

  • CI設計: 型検査が短縮されると、テストやE2E、依存解決、ビルド成果物生成が支配的になる。TypeScriptは「前座」になり、パイプライン最適化の焦点が移る。
  • エディタと静的解析の統合: リントや規約チェックが、型情報を前提により深い解析へ寄る余地が増える。ただし、API互換の維持が前提であり、移行期は複数実装の並走を織り込む必要がある。
  • モノレポ運用: “ウォッチ時の再計算”が軽くなれば、細分化し過ぎたプロジェクト構成や過剰な分割を見直す動機が生まれる。逆に、型検査が速いほど依存関係の密結合が顕在化し、アーキテクチャ改善が進む可能性もある。

結論として、TypeScriptのネイティブ移行は、JavaScript/TypeScript開発を「型のコストが高いから妥協する」世界から、「型が十分に速いから前提にできる」世界へ移す。速度の向上は、そのまま設計の自由度の回復である。

FAQ

tsgoは今すぐ使えるのか？

TypeScriptチームはネイティブ版のプレビュー提供を公開しており、導入とフィードバックを促している。 一方、安定版の既定コンパイラがネイティブへ完全移行する時期は、公開情報だけでは断定できない（2026-02-14時点でnpmの安定版は5.x系である）。

既存のtsc/tsserverと互換なのか？

目標は互換性を保った置き換えであり、進捗更新でも互換性とフィードバックループが強調されている。 ただし移行期は差分が残り得るため、重要なプロダクション環境ではプレビュー導入を段階的に行うのが現実的である。

なぜネイティブ化でここまで速くなるのか？

公開されたベンチマークでは大規模リポジトリで約10倍の改善が報告されている。 これは単一の“魔法の最適化”ではなく、実行基盤（ランタイム）、データ表現、並列化、キャッシュ戦略の組み合わせで積み上げた結果と理解すべきである。

Rustで書けばさらに速いのでは？

速度だけでなく、既存コードの設計前提や移植の実務（検証・運用・配布）を含めた最適点がある。チームの説明では、現在のコンパイラの性質と移植現実の観点からGoが適合すると整理されている。

参考文献