TypeScript 7.0 RC とは何か

2026年6月18日、Microsoft が TypeScript 7.0 のリリース候補版（RC）を公開しました。今回のリリースで最も大きな変化は、これまで TypeScript 自身（JavaScript）で書かれていたコンパイラ本体を Go 言語へ移植したことです。Microsoft はこのネイティブ実装により、型チェックやビルドが多くの場合でおよそ10倍高速になったと説明しています。正式リリースは RC 公開からおおむね1か月以内を予定しているとされています。

TypeScript を日常的に使う Web エンジニアにとって、まず押さえておきたいのは「いますぐ手元で試せる」という点です。RC 版は次のコマンドで導入でき、既存の TypeScript と衝突せず併存してインストールできます。

npm install -D typescript@rc

開発の途中段階を追っているナイトリービルドは @typescript/native-preview パッケージとして提供され、コマンドのバイナリ名は tsgo です。正式版では従来どおり typescript パッケージへ統合される見込みで、コマンド名も tsc のまま使えるようになる予定です。すでに Google や Notion、Slack、Vercel といった大規模な利用者の間でも検証が始まっており、好意的な評価が伝えられています。新しい基盤に乗り換えるというよりも、同じ TypeScript がそのまま速くなる、という捉え方が実態に近いものです。

なぜコンパイラを Go に移植したのか

この移植を主導したのは、C# と TypeScript の生みの親である Anders Hejlsberg 氏です。背景にあったのは速度そのものよりも「並行処理」という構造的な課題でした。従来のコンパイラは JavaScript で実装されていたため、基本的にシングルスレッドで動作し、共有メモリを使った並列処理を活かせません。プロジェクトが大規模になるほど、マシンに余っている計算資源を使い切れないという限界が見えていたのです。

Hejlsberg 氏は Go を選んだ理由について、全プラットフォームで完全に最適化されたネイティブコードを得られる最も低レベルな言語であり、データレイアウトの細かな制御、循環するデータ構造の表現、ガベージコレクションによる自動メモリ管理、そして優れた並行処理のしくみを備えている点を挙げています。TypeScript のコンパイラは関数型的なコードが多く、クロージャや再帰的なデータ構造、抽象構文木（AST）の循環参照を多用します。こうした性質は、ガベージコレクションを持つ Go と構造的に相性が良いものでした。

候補に挙がりやすい Rust を採用しなかったのは、所有権モデルの制約と循環参照の多用が噛み合わず、大幅な再設計が必要になるためだと説明されています。Hejlsberg 氏自身が設計した C# を選ばなかったのは意外にも見えますが、こちらも実務的な判断によるものです。ここで重要なのは、今回の取り組みがゼロからの書き直し（rewrite）ではなく、既存実装の移植（port）だという点です。目標は旧来のコンパイラとまったく同じ挙動を再現することに置かれており、型チェックのロジックは TypeScript 6.0 と構造的に同一だとされています。

10倍高速化の中身をベンチマークで見る

高速化の源泉は、ネイティブコードによる実行速度と、共有メモリを使った並列処理の組み合わせです。Microsoft は実在する大規模プロジェクトでのコマンドラインビルドの測定値を公開しており、その数字を見ると10倍という表現が誇張でないことが分かります。

体感に直結するのがエディタの応答性です。言語サービスの起動時間は、VS Code のコードベースで約9.6秒から約1.2秒へと、おおむね8倍の短縮が報告されています。コードを開いてから補完やエラー表示が効き始めるまでの待ち時間が短くなるため、大規模リポジトリでの開発体験が大きく変わる部分です。メモリ使用量も全体として従来実装の約半分に収まっているとされますが、こちらの最適化はまだ初期段階だと説明されています。

注意したいのは、これらが特定の環境での公式測定値であるという点です。実際の高速化の度合いは、プロジェクトの構成やマシン性能、型の複雑さによって変わります。とはいえ、複数の大規模プロジェクトで一貫しておよそ10倍前後の改善が出ている事実は、自分のプロジェクトでも相応の効果を期待できる十分な根拠になります。

既存コードベースへの影響と移行のポイント

移植であってセマンティクスが同一であるという設計方針は、移行を考えるうえで大きな安心材料です。型チェックの挙動が変わらないため、多くのプロジェクトでは特別な書き換えをせずに高速化の恩恵を受けられます。導入時には従来版を tsc6 として横並びで残し、出力差分を比較しながら段階的に検証していく進め方が推奨されています。

一方で、まったくコストがかからないわけではありません。TypeScript 6.0 で非推奨とされていた一部の機能が、7.0 では完全なエラー（hard error）になります。たとえば古いコンパイル設定や旧式のモジュール指定が該当します。該当する設定を使っているプロジェクトは、移行前に tsconfig.json を見直しておく必要があります。

// 7.0でエラーになりうる代表的な設定の例
{
  "compilerOptions": {
    "target": "es5",        // 廃止された旧ターゲット
    "baseUrl": "./src",     // 非推奨だったパス基点
    "module": "amd"         // 旧式のモジュール形式
  }
}

新しい並列実行に合わせたフラグも追加されました。型チェッカーのスレッド数を指定する --checkers（既定値は4）、ビルダー数を指定する --builders、そしてパースから emit、型チェックまでを単一スレッドで実行する --singleThreaded などです。並列実行で問題の切り分けが難しいときは、単一スレッドで挙動を確認すると原因を特定しやすくなります。もうひとつの注意点は、安定したプログラマティック API が RC 時点ではまだ提供されていないことです。これは数か月後の TypeScript 7.1 で整備される予定とされているため、ビルドスクリプトやツールチェーンで tsc の内部 API に依存している場合は、当面従来版を併用する判断が現実的です。

今後の展望と開発現場への示唆

正式リリースは今後1か月以内が見込まれていますが、JavaScript 実装の TypeScript 6 とネイティブ実装の TypeScript 7 は当面のあいだ併存し、参照され続けるとされています。安定 API は前述のとおり TypeScript 7.1 での提供が予定されており、エコシステム全体がネイティブ版へ移っていくのはこれからの段階です。ネイティブ化と並列化によって、これまで型チェックに時間がかかっていた大規模コードベースにもスケールしやすくなり、CI のビルド待ちやエディタの応答遅延といった日々のストレスが軽くなることが期待できます。

当面の現実的な進め方としては、まず RC を併存インストールして手元のプロジェクトでビルド時間とエディタ応答を計測し、効果を確認することです。あわせて非推奨設定の有無を点検し、移行時の作業量を見積もっておくと安心です。型の挙動が変わらないからこそ、影響範囲は設定面に絞り込めます。

Ragate では、TypeScript を中心としたフロントエンド開発の生産性改善や、ビルドパイプラインの最適化、生成AIを組み込んだ開発プロセスの見直しを伴走型で支援しています。TypeScript 7.0 のような基盤の刷新を、どの工程からどう取り入れ、既存資産への影響をどう抑えるかといった検討には、現場での実装経験が活きます。新しいコンパイラの導入や開発体験の改善を検討されている方は、ぜひお気軽にご相談ください。