TypeScript 7.0 RC 登場 — Go製コンパイラ「tsgo」が10倍速い理由と移行の勘所
はじめに
Microsoft が TypeScript 7.0 の RC（Release Candidate） を公開した。最大の特徴は、これまで TypeScript 自身で書かれていたコンパイラを Go で完全に書き直した 点にある。新しいコンパイラ tsgo は「従来の tsc と同じ振る舞いをしながら、おおむね10倍速い」と謳われ、RC発表から約1ヶ月で正式リリースが予定されている。本記事では、なぜGoへの移植がそこまでの高速化をもたらすのか、その仕組みと、既存プロジェクトを移行する際に踏むべき注意点をエンジニア視点で整理する。
何が起きたのか — tsgo の登場
TypeScript 7.0 は、コードネーム「Project Corsa」として進められてきたコンパイラ再実装の成果だ。注目すべきは、これがゼロからの作り直しではなく、TypeScript 6.0 の型チェックロジックと構造的な等価性を保ったままGoへ移植された点である。つまり言語仕様や型推論の挙動は変えず、実装基盤だけを差し替えている。
公式が示すベンチマークはインパクトが大きい。40万行規模の VS Code リポジトリのビルドは89秒から8.74秒へと 10.2倍 高速化し、Sentry は133秒→16秒、Playwright は9.3秒→1.24秒に短縮された。エディタ上でも、言語サーバーのコマンド失敗が 6.0 比で 20倍以上 減少したという。すでに Figma、Google、Slack、Vercel、Notion といった大規模ユーザーが内部検証に参加している。
導入はnpm経由で試せる。
npm install -D typescript@rc
# nightly版を使う場合
npm install -D @typescript/native-previewVS Code では「TypeScript Native Preview」拡張がLSP（Language Server Protocol）経由でエディタ支援を提供し、これによりVS Code以外のエディタでも同じ言語サーバーを利用できる設計になっている。
なぜGoだと10倍速いのか — 技術的背景
「JavaScriptで書かれたコンパイラをネイティブ言語に置き換えれば速くなる」のは直感的だが、本質はそれだけではない。高速化を支えているのは主に2つの要素だ。
ひとつは ネイティブコード実行と共有メモリ並列性。従来の tsc はJavaScript（V8）上で動くため、JITウォームアップやGCの影響を受け、かつスレッド間でメモリを共有しにくい。Goはコンパイルされたネイティブバイナリでありながらゴルーチンによる軽量並列が容易で、型チェックという本質的に並列化しやすい処理をマルチコアで分散できる。
そのため 7.0 では並列化が明示的に制御できる。型チェッカーはデフォルト4ワーカーで --checkers フラグで調整でき、プロジェクト参照のビルドは --builders で並列度を指定する。デバッグや制約環境向けには --singleThreaded も用意されている。
# 型チェックワーカーを8並列に
tsgo --checkers 8
# 並列化が問題を起こす場合はシングルスレッドで切り分け
tsgo --singleThreadedもうひとつが メモリレイアウトの最適化だ。Goの構造体ベースのデータ表現は、JavaScriptのオブジェクトより遥かにメモリ効率が良く、AST（抽象構文木）や型情報といった大量のノードを扱うコンパイラと相性が良い。Microsoftチームが「なぜRustではなくGoなのか」という問いに対し、既存のTypeScriptコードベースとの**移植のしやすさ（構造の対応関係を保てる）**を理由に挙げているのも、この「等価移植」戦略を貫くためだった。
エンジニアへの影響 — 移行で何に注意すべきか
7.0 は 6.0 互換を維持する（stableTypeOrdering 有効時）が、6.0のデフォルトを採用し、非推奨機能を削除している点に注意が必要だ。実務で影響しそうな主な変更は次の通り。
- ES5 ターゲットのサポート廃止 —
target: "es5"に依存する古い設定は動かない baseUrlの削除 — パスエイリアスはpathsを絶対基準で書き直す必要があるamd/umdモジュールの削除、moduleResolution: classicの削除rootDirとtypesの明示的な指定が必要になるケースがある
つまり「インストールすれば即10倍」ではなく、tsconfig.json の棚卸しが前提になる。レガシーなビルド設定を引きずっているプロジェクトほど、移行時の修正コストは無視できない。逆に言えば、これは古い設定を整理する良い機会でもある。
実務上の現実的な進め方としては、まず @typescript/native-preview をCIに並走させて tsgo で型チェックだけ通るか確認し、差分が出た箇所を潰してから本採用する形が安全だ。なお、安定版のプログラマブルAPI（コンパイラAPIを使うツール作者向け）は 7.0 ではなく 7.1 で提供予定のため、ts-morph などコンパイラAPIに依存するツールチェーンは少し待つ判断もありうる。
まとめ
- TypeScript 7.0 RC は、コンパイラをGoへ等価移植した
tsgoを中核とし、実測で約10倍の高速化を達成した - 速さの源泉はネイティブ実行＋共有メモリ並列性と、Goの効率的なメモリレイアウトにある
--checkers/--buildersで並列度を制御でき、大規模モノレポほど恩恵が大きい- 一方でES5ターゲットや
baseUrlなど旧機能が削除され、移行にはtsconfigの見直しが必須 - 正式版はRCから約1ヶ月後、安定APIは7.1で登場予定
ビルド待ち時間とエディタの体感はフロント開発の生産性を直接左右する。レガシー設定の整理と引き換えに10倍の高速化が得られるなら、検証を始める価値は十分にある。