2026年1月15日、MicrosoftはTypeScript 7.0を正式リリースした。その核心は、TypeScriptコンパイラ（tsc）をJavaScriptからGo言語で完全に再実装した「tsgo」である。VS Codeの150万行コードベースのコンパイルが89秒から8.74秒へ──10.2倍の高速化。メモリ消費は2.9倍削減。これは単なるパフォーマンス改善ではなく、CI/CDパイプラインのコスト構造、モノレポ開発のフィードバックループ、そしてエンタープライズにおける開発者体験（DX）を根底から書き換える構造変化である。テクノロジーの視点から、tsgoの技術仕様・導入手順・実測ベンチマークを定量的に分析し、Next.js 16×React 19のエンタープライズ移行と並ぶ2026年フロントエンド基盤の転換点として位置づける。

tsgoの技術アーキテクチャ ── なぜGoが選ばれたのか

TypeScript 7の開発コードネームは「Project Corsa」。Anders Hejlsberg率いるTypeScriptチームが2024年末から本格着手し、2025年3月に正式発表、同年5月23日に初のネイティブプレビュー（@typescript/native-preview）を公開した。2025年12月のRC（Release Candidate）を経て、2026年1月15日に安定版がリリースされている。

Go言語が選択された理由は、技術的合理性に基づく3つの要因に集約される。

第一に、ガベージコレクション（GC）との親和性である。TypeScriptコンパイラは内部的に巨大な循環参照を含むオブジェクトグラフを構築する。型チェックのプロセスでは数百万のノードが相互参照し、手動メモリ管理は現実的ではない。Rustのボローチェッカーは循環参照との相性が悪く、既存コードの移植コストが膨大になる。Go は成熟したGCを備えつつネイティブバイナリを生成できる唯一の実用的選択肢であった。

第二に、移植容易性である。Hejlsberg自身が「copy, paste, and adjust」と表現したように、TypeScriptコンパイラのJavaScriptコードをGoに機械的に変換する戦略が採られた。完全な再設計（rewrite）ではなく移植（port）であるため、20,000件超のコンパイラテストケースの互換性を維持しながら段階的に移行できた。最終的に型チェックの互換率は99.63%（約20,000テスト中74件のみ不一致）に達している。

第三に、共有メモリ並列処理である。Goのgoroutineと共有メモリモデルにより、ファイル単位の並列型チェックが自然に実装できる。JavaScriptのシングルスレッド制約では実現不可能だった真の並列処理が、約3倍のスループット向上をもたらした。ネイティブコンパイルによる約3倍の高速化と合わせて、合計約10倍の性能向上が実現された構造である。

導入手順とプロジェクト移行 ── 実践ハンズオン

tsgoの導入は既存のTypeScriptプロジェクトに対して極めて低摩擦で実行できる。以下に具体的な手順を示す。

インストール

# TypeScript 7（tsgo）のインストール
npm install -D typescript@^7.0.0

# または、プレビュー版での検証
npm install -D @typescript/native-preview

# バージョン確認
npx tsc --version
# Version 7.0.0 (native)

tsconfig.json の確認ポイント

TypeScript 7はES2022以降のターゲットで最も安定している。レガシーターゲットを使用している場合は更新を推奨する。

{
  "compilerOptions": {
    "target": "ES2022",        // ES2022以降を推奨
    "module": "nodenext",       // モダンモジュール解決
    "strict": true,
    "incremental": true,        // tsgo でもインクリメンタルビルド対応
    "composite": true,          // プロジェクト参照利用時
    "declaration": true,
    "skipLibCheck": true
  }
}

既知の互換性に関する注意点

移行にあたって把握すべき非互換事項は限定的だが存在する。

  • JavaScript emit: ES2021以前のダウンレベルコンパイルは一部未完了。target: "ES2022"以降であれば問題ない
  • デコレータ: TC39 Stage 3デコレータのemitサポートは進行中。型チェック自体は正常に動作する
  • JSDoc: @enum、@constructorタグは非推奨化。@typedefで@templateを使用するパターンはimport()型参照への置き換えが必要

筆者自身、複数のプロダクションプロジェクトでTypeScript移行を経験してきたが、あらゆる技術を横断してきたからこそ断言できる──技術選定でバイアスなく最適解を選ぶためには、まず自プロジェクトのtarget設定とデコレータ使用状況を棚卸しすることが最優先である。移行の成否はコードベースの特性を正確に把握しているかどうかで決まる。

実測ベンチマーク ── プロジェクト規模別の高速化係数

公式ベンチマークおよびコミュニティの実測値を統合すると、tsgoの高速化係数はプロジェクト規模に強く相関する。

プロジェクトコード行数tsc（秒）tsgo（秒）高速化倍率メモリ削減
VS Code150万行89.118.7410.2x2.9x
Sentry約80万行133.0816.258.2x2.5x
中規模モノレポ（10-50万行）10-50万行30-603.4-6.88.8x2.7x
小規模プロジェクト（1万行未満）<1万行2-50.5-1.34.0x2.0x

注目すべきは、型チェック単体では30倍以上の高速化が計測されている点である。tscで0.10秒かかっていた型チェックがtsgoでは0.003秒に短縮される。この差はエディタ上のリアルタイム型チェック体験──赤波線の表示速度やオートコンプリートの応答性──に直接反映される。

規模別の傾向として、50万行超の大規模コードベースほど恩恵が大きい。これはGoの並列処理が大量のファイルに対して効率的にスケールするためであり、小規模プロジェクトではネイティブコンパイルの恩恵（約3倍）が支配的になる。エンタープライズのモノレポ環境こそがtsgo導入の最大の受益者と言える。

CI/CDパイプラインへの経済的インパクト

TypeScriptのコンパイル時間はCI/CDコストの支配的要因の一つである。GitHub ActionsやCircleCIの従量課金モデルでは、ビルド時間の短縮が直接的にコスト削減に結びつく。サーバーサイドJSランタイムの選定と同様に、ツールチェーンの性能はインフラコストに直結する構造的問題である。

コスト削減の試算モデル

典型的なエンタープライズのTypeScriptモノレポ（50万行、1日あたり50回のCI実行）を想定する。

項目tsc（従来）tsgo（TypeScript 7）削減率
1回のビルド時間45秒5.1秒-88.7%
1日のビルド合計時間37.5分4.25分-88.7%
月間ビルド時間18.75時間2.13時間-88.7%
GitHub Actions月間コスト（$0.008/分）$9.00$1.02-$7.98

TypeScriptのコンパイルはビルドパイプライン全体の一部に過ぎないが、テスト実行前のボトルネックを解消する効果は大きい。特にPR（Pull Request）ごとの型チェック──多くのチームがtsc --noEmitをCIに組み込んでいる──が30倍高速化される影響は、開発者のフィードバックループ短縮に直結する。

GitHub Actions設定例

# .github/workflows/typecheck.yml
name: Type Check
on: [pull_request]

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npx tsc --noEmit  # tsgo が自動的に使用される
        # 50万行モノレポ: 45秒 → 5秒

150人月規模の大規模プロジェクトを率いた経験から言えば、CI/CDのフィードバック速度はチーム全体の生産性を非線形に左右する。ビルドが5分かかるチームと30秒で完了するチームでは、1日のイテレーション回数が根本的に異なり、コードの品質にも差が出る。tsgoの8.8倍高速化は、開発プロセス全体の加速装置として機能する。

エディタ体験の構造変化 ── Language Serverの高速化

tsgoはコマンドラインコンパイラだけでなく、Language Server（言語サービス）も完全にGo実装に移行している。これにより以下のエディタ機能が劇的に高速化される。

  • Go to Definition: 大規模コードベースでの定義ジャンプが即座に応答
  • Find All References: 150万行規模でも数百ミリ秒以内
  • Auto Import: コード補完時のインポート候補生成が高速化
  • Rename Symbol: プロジェクト横断のリネームがリアルタイムに近い速度で完了
  • Hover Tooltips / Signature Help: 型情報の表示遅延が体感できないレベルに

VS Code、Zed、Neovim（nvim-lspconfig経由）など主要エディタでtsgoのLanguage Serverが利用可能である。特にVS Codeでは内部的にTypeScriptチーム自身が「ドッグフーディング」しており、150万行のVS Codeコードベース上での日常開発にtsgoを使用している。

// VS Code settings.json（tsgo Language Serverの有効化）
{
  "typescript.tsdk": "node_modules/typescript/lib",
  // TypeScript 7がインストールされていれば自動的にtsgoが使用される

  // インクリメンタルビルドの有効化（推奨）
  "typescript.preferences.includePackageJsonAutoImports": "on"
}

エディタ上の型チェック応答が30倍速くなるということは、コードを書いてから赤波線（型エラー）が表示されるまでのレイテンシがほぼゼロになることを意味する。これはIDEの「反応速度」を根本的に変え、開発者がフロー状態を維持できる時間を延長する。金融系システムの開発でミリ秒単位のレイテンシが損益に直結する世界を経験してきたが、開発ツールのレイテンシもまた、開発者の生産性に対して同様の非線形な影響を与える。

モノレポ・プロジェクト参照への影響と移行戦略

TypeScript 7はプロジェクト参照（Project References）と--buildモード、--incrementalビルドを完全サポートしている。これはTurborepo、Nx、pnpm workspacesなどのモノレポツールとの組み合わせで最大の効果を発揮する。

モノレポでの設定例

// tsconfig.json（ルート）
{
  "compilerOptions": {
    "composite": true,
    "incremental": true,
    "declaration": true,
    "target": "ES2022"
  },
  "references": [
    { "path": "./packages/core" },
    { "path": "./packages/ui" },
    { "path": "./packages/api" }
  ]
}

# プロジェクト参照を利用したビルド
npx tsc --build          # 全パッケージのビルド
npx tsc --build --watch  # ウォッチモード

プロジェクト参照ではパッケージ間の依存グラフに基づいて並列ビルドが実行される。tsgoのgoroutineベースの並列処理により、独立したパッケージのビルドが同時に進行し、モノレポのビルド時間は従来の8〜10倍短縮される。2026年のメタフレームワーク選定においても、ビルドツールチェーンの性能はフレームワーク選択に影響を与える要因として重要性を増している。

段階的移行のロードマップ

大規模プロジェクトでの推奨移行パスは以下の通りである。

  1. Phase 1: 検証（1-2週間） ── @typescript/native-previewをdev dependencyに追加し、CIの型チェックジョブを並列実行して結果を比較
  2. Phase 2: CI移行（1週間） ── 型チェック（tsc --noEmit）をtsgoに切り替え。emitは従来のtscを維持
  3. Phase 3: エディタ移行（即日） ── チーム全体のTypeScriptバージョンを7に更新。Language Serverが自動的にtsgoに切り替わる
  4. Phase 4: 完全移行（ターゲット確認後） ── ES2022以降をターゲットにしている場合、emitもtsgoに統一

TypeScript 6との共存とエコシステムへの波及

TypeScript 6.0は2026年3月23日にリリースされた、JavaScript実装としての最終バージョンである。TypeScript 7への移行が即座に必要でないプロジェクト（ES2021以前のターゲット、デコレータ多用など）はTypeScript 6を継続利用できる。

エコシステムへの波及として、以下のプロジェクトがtsgo対応を進めている。

  • WordPress Gutenberg: Issue #76148でtsgo移行を追跡中
  • Vue Language Tools: Issue #5381でネイティブTypeScriptサポートを追跡
  • Zed Editor: tsgo拡張を公式提供
  • Sentry: 内部で早期採用し、80万行コードベースで8.2倍の高速化を実証

TypeScriptはプライベートリポジトリで前年比33%の成長を記録しており（パブリックリポジトリの19%を上回る）、エンタープライズでの採用加速が顕著である。tsgoの10倍高速化は、この成長トレンドをさらに加速させる触媒として機能するだろう。

FAQ

TypeScript 7（tsgo）は既存プロジェクトにそのまま導入できるか？

ES2022以降をターゲットとしているプロジェクトであれば、npm install -D typescript@^7.0.0でほぼそのまま導入可能である。型チェックの互換率は99.63%に達しており、大多数のプロジェクトで非互換に遭遇することはない。ES2021以前のターゲットやデコレータを多用している場合はTypeScript 6の継続利用を推奨する。

tsgoとtscは共存できるか？

可能である。CIパイプラインで型チェックにはtsgo（tsc --noEmit）、emitには従来のTypeScript 6のtscを使用する二段構成が、移行期の推奨パターンである。@typescript/native-previewパッケージを併用することで、同一プロジェクト内での比較検証も容易に行える。

CI/CDコストはどの程度削減できるか？

TypeScriptのコンパイル・型チェック部分に限定すると、最大88%のコスト削減が見込まれる。ただし、CIパイプライン全体にはテスト実行、リンティング、デプロイ等が含まれるため、パイプライン全体のコスト削減率はプロジェクトの構成に依存する。型チェックがボトルネックとなっている大規模モノレポほど効果は大きい。

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

TypeScriptコンパイラは循環参照を含む巨大なオブジェクトグラフに依存しており、ガベージコレクションが不可欠である。Rustのボローチェッカーは循環参照との相性が悪く、既存コードの移植コストが膨大になる。GoはGCを備えつつネイティブバイナリを生成でき、かつ既存コードの「copy, paste, and adjust」による移植を可能にした唯一の現実的選択肢であった。

TypeScript 6はいつまでサポートされるか？

TypeScript 6.0は2026年3月23日にリリースされたJavaScript実装の最終版である。Microsoftは明示的なEOL（End of Life）を発表していないが、新機能の追加はTypeScript 7に集中するため、TypeScript 6は「安定版としてのメンテナンス」に移行すると見られる。ES2021以前のターゲットが必要なプロジェクトはTypeScript 6を継続利用しつつ、ターゲット更新の計画を立てることを推奨する。

参考文献