Pockit
Back

TypeScript 7とProject Corsa：Goで書き直された10倍速コンパイラの全貌

2025年3月、Anders Hejlsbergがカメラの前で、誰も予想していなかったことを口にしました。

「TypeScriptコンパイラをGoに移植します。」

Rustじゃない。段階的な書き直しでもない。コンパイラ、言語サービス、型チェッカー — TypeScriptエコシステムの中枢すべてを、まるごとGoに移す。MicrosoftはこれをProject Corsaと名づけ、いまTypeScript 7.0として世に出ようとしています。

数字を見ればインパクトは一目瞭然です。VS Codeのリポジトリ、TypeScript 150万行。従来のtscでコンパイルすると約78秒。Goベースの新コンパイラtsgoだと7.5秒。2倍じゃないです。10.4倍。

ちょっとしたツールの更新ではありません。TypeScript 12年の歴史で最大の転換点であり、ビルド・デプロイ・設計の考え方そのものに影響します。一つずつ見ていきましょう。

なぜ書き直すのか

Project Corsaの背景には、既存コンパイラの明確な限界があります。

もともとTypeScriptのコンパイラはTypeScript自身で書かれていました。10年以上うまく回っていたセルフホスティングですが、TypeScriptがWeb開発のメインストリームになるにつれ（2025年8月、GitHubでJavaScriptを追い抜きました）、自身の成功を支えきれなくなってきました。

どこで詰まったか

  • エンタープライズのコードベースが巨大化。 Google、Microsoft、Stripeといった企業が数百万行のTypeScriptを運用しています。そのスケールではIDEの応答が目に見えて遅くなり、エラー表示が数秒遅れ、オートコンプリートに2-3秒、プロジェクト全体のリネームがタイムアウトする状況でした。

  • CI/CDがボトルネックに。 数百パッケージのモノレポだとtsc --buildがパイプライン全体で最も重いステップになることも多く、フルタイプチェックに10分以上かかるケースもありました。

  • シングルスレッドの壁。 JavaScriptランタイムは生まれつきシングルスレッド。型チェックもパースも推論も全部1コアで順番待ち。M4 Proに16コアあっても残り15コアは暇してるわけです。

なぜGoだったのか

みんなが聞く質問です。

Rustじゃだめだったの？ 性能は最強でしょうが、開発スピードとのトレードオフが大きすぎました。TypeScriptコンパイラのコードはクロージャだらけ、再帰データ構造だらけ、判別ユニオンのパターンマッチだらけの関数型スタイル。Rustのオーナーシップモデルがこのスタイルと相性が悪く、チームの試算ではRust版は3-5倍の期間がかかり、アーキテクチャも根本から設計し直しになるとのことでした。

Goが選ばれた理由：

  1. コードとの相性がいい。 TypeScriptコンパイラのコードは意外と手続き的＋関数型。Goのインターフェース、第一級関数、シンプルな構造体が既存パターンにぴったりハマります。

  2. goroutineで並列が楽。 スレッドを手動管理する煩雑さなしに、軽量な並列処理ができる。ファイル間の型チェックを同時に走らせるのに最適です。

  3. 性能がぶれない。 GoのGCは低レイテンシ向け。V8のGCみたいに突然止まることがなく、IDE言語サービスの応答に安定感があります。

  4. バイナリ一つで完結。 GoバイナリはNode.js不要、npm install不要。ダウンロードして即実行です。

  5. チームの習得が早かった。 RustよりGoのほうが圧倒的に早くキャッチアップでき、それでいて必要十分な性能向上を達成できました。

アーキテクチャはどう変わったか

Project Corsaは「同じコンパイラの高速化」ではありません。中身の設計から変わっています。

Before / After

TypeScript 5.x/6.x（JavaScript版）：

ソース → Scanner → Parser → Binder → Type Checker → Emitter
         ↑                                            ↓
    シングルスレッド、逐次パイプライン             .js + .d.ts
    V8 + Node.js
    インストール ~14MB

TypeScript 7.x（Go版）：

ソース → Scanner → Parser → Binder → Type Checker → Emitter
         ↑          ↑                    ↑            ↓
      並列I/O    並列パース       マルチスレッド     .js + .d.ts
                               型チェック
      ネイティブバイナリ ~25MB
      ランタイム依存なし

裏側で何が起きているか：

  1. ファイルを同時に読む。 goroutineでファイルの読み込みとパースを並行実行。数千ファイルの規模だと、これだけで2-3倍速くなります。

  2. 型チェックも並列。 最も重い処理 — 型チェック — を、依存関係のないモジュール間で同時に実行。10倍改善の大半はここから来ています。

  3. メモリを共有。 JSのworker threadはデータをシリアライズして受け渡す必要がありますが、goroutineはメモリ空間を共有。シンボルテーブルをコピーする必要がありません。

  4. データ構造がネイティブ。 Goのslice・mapはV8ヒープオブジェクトより割り当てパターンが予測しやすく、GC負荷軽減とキャッシュ効率向上につながります。

tsgo CLI

新コンパイラはtsgoという名前で、従来のtscと併存します：

# 従来コンパイラ（TS 6.x、引き続き動作）
npx tsc --build

# Goベース新コンパイラ
npx tsgo --build

# スタンドアロンバイナリ（Node.js不要）
tsgo --build

tsconfig.jsonはそのまま使え、出力も同じ。tscで通るコードなら、tsgoでも同じ.jsと.d.tsが得られるはずです。

TypeScript 6.0 — 橋渡しリリース

TS 6.0はJavaScript時代からGo時代への移行期にあたります：

TS 5.9（2025年末）  → 最後の通常リリース
TS 6.0（2026年2月） → 橋渡し：非推奨化 + 移行準備
TS 7.0（2026年半ば）→ Goコンパイラ（Project Corsa）

TS 7.0に向けてTS 6.0で変わること：

  • target: "es5" 非推奨。 TS 7ではES5出力なし。必要ならBabel・SWC・esbuildを別途使用。
  • 旧moduleResolution 非推奨。 "node"（レガシー）と"classic"は廃止へ。"node16"、"nodenext"、"bundler"を使用。
  • デフォルト値変更。 targetは"es2025"、moduleは"nodenext"がデフォルトに。
  • Temporal API型。 JavaScript Temporal APIのビルトイン型を搭載。

10倍って本当？

「10倍速」の見出しを鵜呑みにする前に、文脈を確認しましょう。

フルビルド

リポジトリTS行数tsc (TS 6.x)tsgo (TS 7.x)高速化
VS Code150万~78秒~7.5秒10.4x
Playwright~80万~45秒~3.5秒12.9x
TypeORM~35万~28秒~2.8秒10x
中規模アプリ (5万)5万~4秒~0.8秒5x
小規模アプリ (5千)5千~1.2秒~0.5秒2.4x

傾向は明確です。プロジェクトが大きいほど効果も大きい。 ファイルが多いほど並列化の恩恵を受けやすく、20ファイル程度のサイドプロジェクトでは体感しにくいでしょう。

IDE体験

ほとんどの開発者にとって、ビルドより実感が大きいのはこっちかもしれません：

500ファイルのTypeScriptプロジェクトを開いた場合

TS 6.x：
  初期ロード：           4-6秒
  最初の補完：           2-3秒
  定義ジャンプ：         500ms-1秒
  型ホバー：            200-500ms
  全体リネーム：         5-15秒

TS 7.x (tsgo)：
  初期ロード：           0.5-1秒
  最初の補完：           200-400ms
  定義ジャンプ：         50-150ms
  型ホバー：            30-100ms
  全体リネーム：         1-3秒

IntelliSenseが速くなると、待ち時間が減り、集中が切れにくくなり、コーディング自体がスムーズになります。

メモリも削減

VS Codeコードベースの型チェック

TS 6.x (Node.js)：
  Peak RSS：~4.2 GB
  平均：    ~3.1 GB

TS 7.x (tsgo)：
  Peak RSS：~1.8 GB
  平均：    ~1.2 GB

約57%削減

CI環境でのRAM節約、ノートPCでスワップなしの開発、Dockerコンテナのメモリ制限をタイトに設定できるなど、実利が多いです。

何が壊れるか

TS 7は動作互換を目標にしていますが、「目標」と「現実」は別です。

🔴 高リスク：Compiler APIプラグイン

TypeScript Compiler API（ts.createProgram、ts.transformなど）を使っている場合、最も注意が必要です。Goコンパイラは別のプログラマティックAPIになるため、JS向けCompiler APIで書いたカスタムトランスフォーマーはtsgoで動きません。

// ❌ tsgoでは動かないコード
import * as ts from 'typescript';

const transformer: ts.TransformerFactory<ts.SourceFile> = (context) => {
  return (sourceFile) => {
    return ts.visitEachChild(sourceFile, visitor, context);
  };
};

影響を受けるツール：

  • ts-morph
  • ttypescript
  • 全ts.LanguageServicePlugin
  • Compiler APIを深く使うビルドツール

TS 7ではgRPC/IPC経由の新クロスランゲージAPIが提供予定。ただし既存プラグインは作り直し必須です。

🟡 中リスク：Strictがデフォルト有効

TS 7ではstrict: trueがデフォルトです。明示的にOFFにしていないと、以下が全部有効になります：

{
  "compilerOptions": {
    "strict": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictBindCallApply": true,
    "strictPropertyInitialization": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "useUnknownInCatchVariables": true
  }
}

strictを使っていなかったコードベースでは、アップグレードで数百〜数千のエラーが出ます。現状維持するなら"strict": falseを明示的に追加してください。

🟢 低リスク：出力の微差

tsgoのJS出力はtscと機能的に同じはずですが、ホワイトスペースやソースマップに微小な差異があり得ます。ほとんどのプロジェクトでは気づきません。

いまできる準備

TS 7正式版を待つ必要はありません。

1. tsconfig.jsonの確認

npx tsgo --build --noEmit 2>&1 | grep -i "deprecated"

手動でチェック：

  • target: "es5" → "es2020"以上に
  • moduleResolution: "node" → "node16"または"bundler"に

2. Strictモードを試す

npx tsc --strict --noEmit 2>&1 | wc -l

対処できる数なら今すぐON。数千なら、フラグを一つずつ段階的に有効化しましょう。

3. tsgoで動作確認

npm install -D [email protected]
npx tsgo --noEmit

# 速度比較
time npx tsc --noEmit
time npx tsgo --noEmit

エコシステムへの影響

バンドラー

Vite / Rolldown / esbuild / SWC： コア機能は影響なし。CIの型チェックをtsgoに変えれば高速化できます。

webpack（ts-loader）： Compiler APIを直接使うため、tsgo対応のアップデートが必要。

IDE

VS Code： Goベースの言語サービスを統合予定。大規模ワークスペースでIntelliSenseが体感レベルで速くなります。VS Codeチーム自身がすでに内部でtsgoを使用中。

フレームワーク

Next.js / Nuxt / Remix / SvelteKit： tscをtsgoに差し替えるだけで速くなるはず。コード変更不要。

Angular： ngcがCompiler APIに深く依存しているため、エコシステム内で最も大変な移行になりそうです。

"TypeScriptなのにTypeScriptで書かれていない"問題

発表直後、コミュニティでは議論が起きました。セルフホスティングの原則が崩れるとか、JS開発者向けの言語なのにコアツールがGoなのは皮肉だとか。

現実的に考えると、TypeScriptという言語自体は何も変わりません。 .tsファイル、型アノテーション、tsconfig.json — 全部そのまま。コンパイラは実装上の選択に過ぎません。Pythonだってもっともポピュラーな実装はC言語で書かれたCPythonですし、同じ話です。

正直なところ、78秒が7.5秒になるのを見たら、議論はわりとすぐ収まりました。

JS ツールの「ネイティブ移行」トレンド

TypeScript 7は単発の出来事ではなく、JSツーリング全体の流れの一部です：

ツール元の言語移行先高速化
TypeScript 7 (tsgo)TypeScriptGo10x
RolldownJavaScriptRust10-15x
esbuild—Go100x vs webpack
SWCJavaScriptRust20x
BiomeJavaScriptRust25x
OxcJavaScriptRust50x

パターンは明確。パフォーマンスが重要なインフラはシステム言語に移し、開発者向けAPIはJS/TSのまま。JavaScriptが消えるのではなく、役割が分化しているのです。アプリロジック・UI・ビジネスルールはJS/TS、コンパイル・リント・バンドルは、マルチコアと効率的なメモリ管理が活かせるツールが担う構図です。

今後のスケジュール

短期（2026年Q1-Q2）

  • TS 7.0ベータ利用可能
  • tsgo CLIがnpmインストール可能
  • 主要バンドラー・フレームワークがtsgo統合開始

中期（2026年Q3-Q4）

  • TS 7.0安定版リリース
  • VS CodeがGoベース言語サービスをデフォルト化
  • プラグインが新APIへ移行

長期（2027年〜）

  • TS 6.x（tsc）メンテナンスモード
  • 新機能はGoで先行実装
  • JSコンパイラでは不可能だったことが実現可能に

まとめ

TypeScript 7とProject Corsaは、TypeScript史上最大の転換点です。JSのセルフホステッドコンパイラからGoネイティブバイナリへ — これは単なる高速化ではなく、新しい可能性を開くアーキテクチャの進化です。

ほとんどの開発者にとっては、いい意味で地味なアップグレードになるでしょう。コードはそのまま、設定もそのまま、ただすべてが速くなる。圧倒的に速くなる。

78秒のビルドが7.5秒になって笑顔にならないなら、一体何を見れば笑顔になれるんでしょうか。 😄

TypeScriptGocompilerperformancetoolingJavaScriptdeveloper-toolsProject Corsa

関連ツールを見る

Pockitの無料開発者ツールを試してみましょう

ページ番号追加
書類整理を完璧に。カスタマイズ可能なページ番号をPDFに追加し、資料の完成度を高めます。
使ってみる
PDFページ整理
PDFページの並び替え・削除・回転をドラッグ＆ドロップで。無料オンラインPDF編集ツールで文書ページを即座に再構成。インストール不要、ブラウザで100%安全処理。
使ってみる
コード整形・圧縮
1行にギュッと詰まった圧縮コードを読みやすく整形したり、本番用にサイズを小さくしたり。JS、CSS、HTML対応。ブラウザで完結するからコードは外に出ません。
使ってみる
JSONフォーマッター
乱雑なデータを見た目良く整理しましょう。JSONの構文エラーを自動で修正し、読みやすい形式に整形します。
使ってみる
私のIPアドレスと端末情報
接続情報をワンクリックで。自分のIPアドレスやプロバイダ情報を、ブラウザだけで安全かつ詳細に確認できます。
使ってみる
Lorem Ipsum生成
デザインの隙間を埋めましょう。レイアウト確認に最適なダミーテキストを、必要な分だけ瞬時に生成します。
使ってみる