TypeScript 7.0が正式リリース：Go製ネイティブコンパイラで何が変わり、いつ移行すべきか

2026年7月8日、MicrosoftのTypeScriptチームがTypeScript 7.0を正式リリースしました。コンパイラをGo言語でネイティブに移植した最初の正式版で、公式ブログでは多くのプロジェクトでビルドがおよそ10倍速くなると説明されています。私も日常的にNext.jsやGASの開発でTypeScriptを使っているので、速度の話だけでなく、移行時に引っかかりそうな点を中心に整理します。

何が起きたのか

TypeScript 7.0は、これまでJavaScript（TypeScript自身）で書かれていたコンパイラと言語サービスを、Goで書き直したものです。ネイティブコードで動き、構文解析・型チェック・出力を共有メモリ上で並列に処理します。

公式ブログでは、TypeScript 6.0と7.0の既定設定でのフルビルド時間を比較しています。

コードベース	TS 6.0	TS 7.0	速度比
vscode	125.7秒	10.6秒	11.9倍
sentry	139.8秒	15.7秒	8.9倍
bluesky	24.3秒	2.8秒	8.7倍
playwright	12.8秒	1.47秒	8.7倍
tldraw	11.2秒	1.46秒	7.7倍

型チェックを担うワーカー数は --checkers で指定でき、既定は4です。これを8に増やすと、vscodeでは16.7倍まで伸びたと報告されています。メモリ使用量もおおむね減っており、プロジェクトによって6〜26%少なくなっています。

エディタ側の体感も変わります。VS Codeのコードベースを開いてから最初のエラーが表示されるまでの時間が、約17.5秒から1.3秒未満に短縮されたとのことです。

何が変わるのか

速度以外で大きいのは、設定の既定値と非推奨機能の扱いです。6.0で非推奨とされていたものが、7.0ではエラーになります。

主な既定値の変更は次のとおりです。

• strict が true になる
• module の既定が esnext になる
• types の既定が [] になる（従来どおり全部読み込むには ["*"] を指定）
• rootDir の既定が ./ になる

エラーになる主な設定は次のとおりです。

• target: es5 と downlevelIteration
• baseUrl
• moduleResolution の node / node10 / classic
• module の amd / umd / systemjs / none
• esModuleInterop や allowSyntheticDefaultImports を false にする指定

古いテンプレートから作ったプロジェクトほど、これらの設定が残っている可能性が高いと見ています。特に baseUrl はパスエイリアスのために長く使われてきたので、影響を受けるプロジェクトは少なくないはずです。

もう一つの重要な点は、7.0にはプログラムから呼び出すためのAPIがまだないことです。新しいAPIは7.1で提供される予定で、現行の6.0とは別物になると告知されています。そのため、typescript-eslintのようにTypeScriptのAPIに依存するツールは、当面6.0を使い続けることになります。

この橋渡しとして、@typescript/typescript6 というパッケージが用意されました。6.0のAPIと tsc6 コマンドを提供するもので、7.0と並べて入れておけます。

実務での影響と対応

私の考えでは、すぐに全面移行するよりも、段階的に進めるのが現実的です。公式ブログも、7.0への移行を楽にするために、まず6.0を導入することを勧めています。

1. まず6.0で非推奨警告をなくす。6.0の段階で警告が出ている設定は、7.0ではそのままエラーになります。ここを先に片付けると、7.0への切り替えはかなり楽になります。
2. 型チェックだけ7.0で試す。ビルドや出力の仕組みは変えずに、CIの型チェックだけを7.0にすると、速度の恩恵をリスク少なく確かめられます。
3. APIに依存するツールは6.0を残す。ESLintの型情報付きルールなどを使っている場合は、@typescript/typescript6 を併用し、7.1のAPI提供を待つのが無難です。

インストール自体は従来と同じです。

npm install -D typescript

注意したいのは、フレームワーク固有のテンプレートです。公式ブログによると、Vue、MDX、Astro、Svelteなどのワークフローや、Angularのテンプレート型チェックは、APIが未提供のため7.0をまだ活用できない見込みです。これらを使っている場合は、エディタ支援のために6.0を維持するよう案内されています。

Next.jsのプロジェクトでは、tsconfig.json に baseUrl や moduleResolution: node が残っていないかをまず確認すると良いでしょう。数年前に作ったリポジトリほど、古い設定が残っている可能性があります。

中小企業の担当者の方にとっては、直接意識する場面は少ないかもしれません。ただ、外注先や社内の開発チームがTypeScriptを使っているなら、「6.0の警告をなくしてあるか」「7.0への移行計画はあるか」を確認しておく価値はあります。ビルドやCIの待ち時間が短くなれば、開発のサイクルが速くなり、結果としてコストにも効いてくると見ています。

AIコーディングツールとの相性も良くなりそうです。Claude Codeなどのエージェントは、コードを修正するたびに型チェックを実行して結果を確かめることが多くあります。この1回あたりの待ち時間が短くなるのは、地味ですが効果の大きい改善だと考えています。

まとめ

TypeScript 7.0は、Goによるネイティブ移植で、ビルドと型チェックを大幅に速くしたリリースです。一方で、strict の既定化や古い設定のエラー化、APIの未提供といった変更もあります。

私は、まず6.0で警告をなくし、CIの型チェックから7.0を試すという順番をおすすめします。APIに依存するツールやフレームワークのテンプレート検査を使っている場合は、7.1を待ちつつ6.0と併用するのが安全です。

参考リンク

• Announcing TypeScript 7.0（TypeScript公式ブログ）
• TypeScript 7.0が正式リリース（gihyo.jp）