TypeScriptが基盤技術における大きな転換点を迎えた。Microsoftは、根幹となるコンパイラおよび言語サービスのアーキテクチャを完全に再構築した「TypeScript 7.0 Beta」の提供を開始した。本リリースにおける最大の変革は、過去10年以上にわたって採用されてきた自己ホスティング（TypeScript自身による実装とJavaScriptへのコンパイル）から脱却し、基盤言語として「Go言語」を採用した点にある。ネイティブコード実行時の処理速度と、Go言語が備える共有メモリでの並列処理能力（Shared Memory Parallelism）を組み合わせることで、TypeScript 7.0は前バージョン（6.0）と比較して平均10倍という劇的なパフォーマンス向上を達成している。

AD

自己ホスティングの限界とGo言語アーキテクチャによるブレイクスルー

これまでのTypeScriptエコシステムにおいて、自己ホスティングの設計は言語自身の表現力を証明する役割を果たしてきた。しかし、フロントエンドおよびバックエンドのモノレポジトリ化が進行し、数百万行規模の巨大なコードベースが一般的な産業水準となる中で、Node.js環境におけるコンパイラの単一スレッド実行やメモリ消費のオーバーヘッドは構造的なボトルネックとなっていた。ビルド時間の増大や型チェックの遅延が引き起こす開発者の認知負荷の上昇は、大規模プロジェクトにおいて無視できないコスト要因として可視化されていた。

今回のGo言語へのポート（移植）は、単なる言語の置き換えに留まらない、並行処理アーキテクチャへの本質的な移行アプローチである。パース（構文解析）、型チェック、エミット（コード生成）の各段階に対し、独立して実行可能なタスクと相互依存性を持つタスクが厳密に切り分けられ、それぞれに最適なリソース割り当てが行われる設計へと進化した。

構造的同一性の維持と10年間のテスト資産に裏打ちされた互換性

新たなアーキテクチャへの移行に伴う後方互換性の喪失は、エンタープライズ領域における最大の懸念事項だ。しかしながら、Microsoftの開発チームはTypeScript 7.0をゼロから書き直すのではなく、既存の実装からの「体系的な移植（Methodical Porting）」というアプローチを選択した。これにより、型チェックロジックなどのコンパイラの振る舞いはTypeScript 6.0と構造的に同一であり、既存のセマンティクスに依存するあらゆる環境でそのまま機能する堅牢性を確保している。

このアーキテクチャの同等性を担保しているのが、過去10年間に蓄積された膨大なテストスイートだ。すでにBloomberg、Canva、Figma、Vercelといった巨大なコードベースを持つテクノロジー企業群で事前検証が実施されており、その安定性が立証済みである点は特筆に値する。開発者は、ローカル環境において npm install -D @typescript/native-preview@beta を実行し、既存の tsc コマンドを新バイナリの tsgo に置き換えるだけで、即座にこれまでの資産を活かしたまま高速なビルド環境にアクセスできる。

AD

並行処理アーキテクチャの最適化とリソース制御機構

TypeScript 7.0の高速化を支える中核は、複数ファイルにまたがる複雑な依存関係を持つ「型チェック」の並行処理アルゴリズムにある。完全に独立したチェッカーを動作させることは、同一の依存ファイルやグローバルスコープを重複して参照することになるため、メモリと計算リソースの浪費につながる。

これを解決するため、TypeScript 7.0はあらかじめ固定された数の型チェッカーワーカーを生成し、各ワーカーが独自の世界観（View of the world）を保持するアプローチを採用した。入力ファイルが同じである限り、ファイルは同一のパターンで分割され、一貫性のあるチェック結果が担保される。現在、デフォルトのワーカー数は4に設定されており、これは --checkers フラグによって調整可能である。CPUコア数の多い開発用マシンでは数値を上げることで更なるパフォーマンス向上が見込める一方、CI（継続的インテグレーション）環境向けのランナーなどでは、リソース制約に応じてこの数値を最適化するアーキテクチャ設計能力が求められる。

さらに、複数のプロジェクトに対するビルド操作を並列化する --builders フラグも実装された。プロジェクトリファレンスを多用する大規模モノレポ環境において、これらのフラグの組み合わせ（例：--checkers 4 --builders 4）はビルド時間を劇的に圧縮するポテンシャルを持つ。しかしながら、それは16の型チェッカーが同時稼働することによるメモリ消費の代償を伴うため、物理マシンのリソースに応じた細やかなチューニングが不可欠となる。あえて挙動をシングルスレッドに限定し、デバッグ目的やパフォーマンスの比較計測を行うための --singleThreaded フラグも用意されており、開発現場における柔軟性へ配慮されている。

モダナイゼーションを強制するデフォルト設定と特例措置の排除

後方互換性を重要視しつつも、TypeScript 7.0は言語仕様の厳格化とよりモダンな規約をデフォルトとすることで開発基盤のモダナイゼーションを推進している。バージョン6.0で非推奨とされていたオプション群はハードエラー（コンパイル停止）として扱われ、レガシー環境からの計画的な脱却が求められる。

具体的な規約変更として、strict: true や noUncheckedSideEffectImports: true といった厳格な型推論オプションがデフォルトで有効化される。また、モジュール解決に関しては module: esnext が導入され、以前の baseUrl 依存の絶対パス解決や、ターゲット層における es5 出力は一切サポートされなくなる。rootDir のデフォルト設定が ./ に変更され、内部のソースディレクトリが明示化された点や、types 配列が空として初期化され特定の型定義への依存ルールが厳格化された点は、プロジェクト構成ファイルの再点検を促す仕様変更である。

同時に、既存のJavaScriptファイル（.js）向けに提供されていたJSDoc解析エンジンにおける特例処理の大部分が解消された。Closure Compiler特有の関数構文のサポート終了や、@enum タグの特殊扱いの廃止により、TypeScriptファイルへの解析プロセスとの一貫性が強化された。

AD

言語サーバー基盤の進化と産業構造へのパラダイムシフト

パフォーマンスの向上はバックグラウンドのビルド操作（CLI環境）に限定されない。エディタ体験に直結する言語サーバー（LSP）機能についても、すでにVisual Studio Code向け拡張機能「TypeScript Native Preview」として提供されている。自動インポートやホバー表示、JSXの各種補完といった機能群がネイティブ環境上で実行されることで、数百万行のコードにアクセスする際にもコーディング時の体感速度が大幅に改善される。

現在ベータ版であるTypeScript 7.0の正式リリースは今後2か月以内と見込まれている。しかし、安定版のプログラムAPI（コンパイラ内部の抽象構文木操作などをフックするAPI）の提供はバージョン7.1以降まで先送りされる予定となっている。この過渡期に対応するため、TypeScript 6.0との共用パッケージである @typescript/typescript6 が公開された。これを利用することで、CLIにおける高速なコンパイルには tsc（元のtsgo）を活用しつつ、既存のコードジェネレーターや Linter（typescript-eslintなど）はAPI依存のため tsc6 を実行させるという並行利用が可能となる。

MicrosoftによるTypeScriptコンパイラのGo言語基盤への移行は、開発スピードを律速していた「コンパイル時間」がもはやシステムの制約ではなくなることを意味する。フロントエンド・バックエンドにおけるビルドエコシステムはより軽量化され、CI/CD環境での仮想マシン群に投下されていた過剰なコンピュートコストは、より効率的なソフトウェアの機能開拓やアジリティの向上へと振り向けられていくのだ。

Sources