MicrosoftのTypeScriptチームは、Goで書き直したネイティブ版のTypeScript 7.0を公開した。2026年7月8日付の発表で、npm install -D typescriptが新しいtscを導入する通常ルートになり、npmレジストリでもtypescriptのlatestは7.0.2を指している。これまでの@typescript/native-previewを試す段階から、標準パッケージで採用を検討する段階へ移った。
変化の中心は新機能ではなく、TypeScriptそのものの実装基盤だ。Microsoftは2025年3月に、既存のJavaScript実装をGoへ移植する計画を明かしていた。TypeScript 7.0はその成果であり、元のコードベースの構造とロジックをできるだけ保ったまま、ネイティブコードの速度、共有メモリを使うマルチスレッド、複数の最適化を取り込んだ。大規模なフロントエンドやモノレポにとって、型チェックの待ち時間は開発体験そのものを左右する。7.0はそこへ直接踏み込むリリースである。
8〜12倍の短縮は、待ち時間の性格を変える
Microsoftが示した実測では、TypeScript 7.0は大きなオープンソースプロジェクトのフルビルドでおおむね8〜12倍の高速化を見せた。VS Codeのコードベースでは125.7秒が10.6秒になり、11.9倍の短縮である。Sentryは139.8秒から15.7秒、Blueskyは24.3秒から2.8秒、Playwrightは12.8秒から1.47秒、tldrawは11.2秒から1.46秒になった。
メモリ使用量も同じ方向に動いている。VS Codeでは5.2GBから4.2GBへ18%減り、Blueskyでは1.8GBから1.3GBへ26%減った。Playwrightとtldrawも1割強から15%程度下がっている。すべての環境で同じ数字が出るわけではないが、速度の代償としてメモリを食うだけの移植ではない。
エディタでの体感差も大きい。TypeScriptチームによると、VS Codeのコードベースでエラーを含むファイルを開いてから最初のエラーが出るまでの時間は、従来の約17.5秒から1.3秒未満になった。13倍を超える短縮である。VS Codeチームの別記事でも、メインソースの型チェックはTypeScript 6.0の36秒からTypeScript 7の5秒へ、通常のnpm run watchは約80秒から20秒強へ短くなった。エディタがプロジェクトを読み込んで高度なTypeScript機能を使えるようになるまでの時間も、1分近くから約10秒まで縮んだ。
この変化は、人間の開発者だけに向いたものではない。TypeScriptの発表は、AIエージェントがビルドや型チェックを繰り返す場面にも触れている。型エラーを直し、再チェックし、また修正する反復では、1回の待ち時間がそのまま作業の粒度を決める。TypeScript 7.0は、型システムを弱めるのではなく、同じ検査を短い間隔で回せるようにする。
7.0への移行には、TypeScript 6.0の橋が残る
ただし、TypeScript 7.0は従来のTypeScriptを丸ごと置き換える最終形ではない。最大の制約は、7.0がプログラムAPIをまだ出していないことだ。TypeScriptチームは、7.1で新しく、従来とは異なるAPIを出す見通しを示している。それまで、typescript-eslintのようにコンパイラAPIへ依存するツールはTypeScript 6.0側を使う場面が残る。
そのためMicrosoftは、互換パッケージ@typescript/typescript6を用意した。このパッケージはtsc6という実行ファイルを持ち、TypeScript 6.0のAPIも再エクスポートする。npmの現在の情報でも、@typescript/typescript6は6.0.2として公開され、tsc6を提供している。つまり、開発者はtscでTypeScript 7.0を走らせながら、APIを必要とするツールには6.0を読ませる構成を取れる。
この併走は、7.0の番号だけを見て急ぐより現実的だ。TypeScript 6.0は2026年3月の時点で、5.9から7.0へ移るための橋として説明されていた。6.0ではstrictが既定でtrueになり、moduleはesnext、noUncheckedSideEffectImportsも既定で有効になる。rootDirは./、typesは空配列が既定になり、古い設定の洗い出しが進む。7.0はこの6.0のふるまいを前提にするため、6.0で警告や設定差を消しておくことが、7.0移行の前処理になる。
並列化は速いが、CIでは設定の掛け算を見る
TypeScript 7.0の速度は、ネイティブコード化に加えて並列化にも支えられている。7.0はパース、型チェック、emitの多くを並列に進める。型チェックでは既定で4つのワーカーを使い、--checkersで数を変えられる。Microsoftの表では、--checkers 8を使うとVS Codeの測定は7.51秒まで縮み、TypeScript 6比で16.7倍になった。
ただし、ワーカーを増やせば常に得をするわけではない。型チェックは依存関係を多く共有するため、ワーカーごとに重複作業が生じる。Microsoftも、コア数の少ないCIランナーやメモリの限られた環境では--checkersを下げる選択を示している。プロジェクト参照ビルド向けには--buildersも追加され、--checkers 4 --builders 4のような指定では最大16個の型チェッカーが同時に動き得る。モノレポでは、この掛け算を見ずに増やすと別の待ち時間を作る。
--watchモードも作り直された。TypeScript 7.0はParcelのファイルウォッチャーをGoへ移植した基盤を使う。純粋なポーリングは、大きなプロジェクトやnode_modulesの多い環境で負荷が大きい。一方で元のParcel watcherはC++で書かれており、ビルドにC++ツールチェーンを求める。TypeScriptチームはこの部分をGoへ寄せ、ウォッチ時の資源消費を抑える方向を選んだ。
設定面では、古いJavaScript環境を前提にした選択がさらに後ろへ下がる。TypeScript 7.0では、6.0で非推奨になったtarget: es5、downlevelIteration、moduleResolution: nodeまたはnode10、moduleResolution: classic、amd、umd、systemjs、noneなどが強いエラーの対象になる。baseUrlや、esModuleInteropとallowSyntheticDefaultImportsをfalseにする設定も同じ流れに入る。TypeScript 7.0は速い移植であると同時に、古い既定値を整理する節目でもある。
組み込み言語とJavaScript解析は、まだ境界線が残る
エディタ側では、TypeScript 7.0の言語サービスがLSPを使う。VS Codeには専用のTypeScript 7拡張機能があり、Visual Studioはワークスペースに応じて自動でTypeScript 7を有効にする。発表によると、TypeScript 7.0の新しい言語サーバーは、TypeScript 6.0と比べて失敗する言語サーバーコマンドを80%以上減らし、サーバークラッシュも60%以上減らした。
一方で、すべての編集体験が同じ日に置き換わるわけではない。VueやMDX、Astro、Svelteなどのワークフローや、Angularのテンプレート内型チェックのような特殊な組み込み処理は、安定したプログラムAPIを必要とする。TypeScript 7.0はそのAPIをまだ持たないため、これらの領域ではTypeScript 6.0へ戻す、またはCLIの広域エラー検出だけ7.0を使う、といった運用が残る。
JavaScriptファイルの扱いにも変更がある。TypeScript 7.0では、JSDocや古いClosure風の記法を特別扱いしてきた部分を見直し、TypeScriptファイルの解析に近づけた。値を型の場所で使う場合はtypeofを書く必要があり、@enumやClosure風の関数型構文など、これまで一部で認識されていた書き方は通らなくなる。JavaScriptをTypeScriptの型検査に載せているプロジェクトほど、ここはビルド時間より先に確認すべき点になる。
TypeScript 7.0は、発表時点でプレビュー用の@typescript/native-previewが週850万回以上ダウンロードされていたという。今後、夜間ビルドは標準のtypescriptパッケージのnextタグへ戻る。npmでもnextは7.1.0系の開発版を指している。7.0でネイティブ時代は始まったが、エコシステム全体の移行は7.1のAPI、各フレームワークの対応、CI設定の実測を見ながら進む。
